rbs 4.1.0.pre.2 → 4.1.0

data/core/float.rbs

@@ -1222,8 +1222,6 @@ Float::EPSILON: Float
 #
 Float::INFINITY: Float
 
-Float::Infinity: Float
-
 # <!-- rdoc-file=numeric.c -->
 # The number of base digits for the `double` data type.
 #
@@ -1292,25 +1290,3 @@ Float::NAN: Float
 # decimal.
 #
 Float::RADIX: Integer
-
-# Deprecated, do not use.
-#
-# Represents the rounding mode for floating point addition at the start time.
-#
-# Usually defaults to 1, rounding to the nearest number.
-#
-# Other modes include:
-#
-# -1
-# :   Indeterminable
-# 0
-# :   Rounding towards zero
-# 1
-# :   Rounding to the nearest number
-# 2
-# :   Rounding towards positive infinity
-# 3
-# :   Rounding towards negative infinity
-#
-#
-Float::ROUNDS: Integer

data/core/match_data.rbs

@@ -92,7 +92,7 @@ class MatchData
   #     #<MatchData "hoge" foo:nil foo:"oge" foo:nil>
   #     m[:foo] #=> "oge"
   #
-  def []: (capture backref, ?nil) -> String?
+  def []: %a{implicitly-returns-nil} (capture backref, ?nil) -> String
         | (int start, int length) -> Array[String?]
         | (range[int?] range) -> Array[String?]
 

data/core/pathname.rbs

@@ -234,11 +234,6 @@ class Pathname
   #
   def +: (Pathname | String | _ToStr other) -> Pathname
 
-  # <!--
-  #   rdoc-file=pathname_builtin.rb
-  #   - /(other)
-  # -->
-  #
   alias / +
 
   # <!--
@@ -271,11 +266,6 @@ class Pathname
   #
   def ==: (untyped) -> bool
 
-  # <!--
-  #   rdoc-file=pathname_builtin.rb
-  #   - ===(other)
-  # -->
-  #
   def ===: (untyped) -> bool
 
   # <!--

data/core/ractor.rbs

@@ -470,11 +470,6 @@ class Ractor
   #
   def self.store_if_absent: [A] (Symbol) { (nil) -> A } -> A
 
-  # <!--
-  #   rdoc-file=ractor.rb
-  #   - <<(...)
-  # -->
-  #
   alias << send
 
   # <!--
@@ -746,11 +741,6 @@ class Ractor
   # Port objects transmit messages between Ractors.
   #
   class Port[T = untyped]
-    # <!--
-    #   rdoc-file=ractor.rb
-    #   - <<(obj, move: false)
-    # -->
-    #
     alias << send
 
     # <!--

data/core/rubygems/errors.rbs

@@ -17,7 +17,7 @@
 # Further RubyGems documentation can be found at:
 #
 # *   [RubyGems Guides](https://guides.rubygems.org)
-# *   [RubyGems API](https://www.rubydoc.info/github/ruby/rubygems) (also
+# *   [RubyGems API](https://guides.rubygems.org/rubygems-org-api/) (also
 #     available from `gem server`)
 #
 # ## RubyGems Plugins
@@ -90,6 +90,9 @@
 #
 # -The RubyGems Team
 #
+# <!-- rdoc-file=lib/rubygems/version.rb -->
+# Workaround for directly loading Gem::Version in some cases
+#
 module Gem
   # <!-- rdoc-file=lib/rubygems/errors.rb -->
   # Raised when RubyGems is unable to load or activate a gem.  Contains the name

data/core/rubygems/requirement.rbs

@@ -123,18 +123,8 @@ module Gem
     #
     def satisfied_by?: (Gem::Version version) -> bool
 
-    # <!--
-    #   rdoc-file=lib/rubygems/requirement.rb
-    #   - ===(version)
-    # -->
-    #
     alias === satisfied_by?
 
-    # <!--
-    #   rdoc-file=lib/rubygems/requirement.rb
-    #   - =~(version)
-    # -->
-    #
     alias =~ satisfied_by?
 
     # <!--

data/core/rubygems/rubygems.rbs

@@ -17,7 +17,7 @@
 # Further RubyGems documentation can be found at:
 #
 # *   [RubyGems Guides](https://guides.rubygems.org)
-# *   [RubyGems API](https://www.rubydoc.info/github/ruby/rubygems) (also
+# *   [RubyGems API](https://guides.rubygems.org/rubygems-org-api/) (also
 #     available from `gem server`)
 #
 # ## RubyGems Plugins
@@ -90,6 +90,9 @@
 #
 # -The RubyGems Team
 #
+# <!-- rdoc-file=lib/rubygems/version.rb -->
+# Workaround for directly loading Gem::Version in some cases
+#
 module Gem
   interface _HashLike[K, V]
     def each_pair: () { ([ K, V ]) -> untyped } -> self

data/core/rubygems/specification.rbs

@@ -19,5 +19,13 @@
 # #metadata for restrictions on the format and size of metadata items you may
 # add to a specification.
 #
+# Specifications must be deterministic, as in the example above. For instance,
+# you cannot define attributes conditionally:
+#
+#     # INVALID: do not do this.
+#     unless RUBY_ENGINE == "jruby"
+#       s.extensions << "ext/example/extconf.rb"
+#     end
+#
 class Gem::Specification < Gem::BasicSpecification
 end

data/core/rubygems/version.rbs

@@ -1,165 +1,5 @@
 %a{annotate:rdoc:skip}
 module Gem
-  # <!-- rdoc-file=lib/rubygems/version.rb -->
-  # The Version class processes string versions into comparable values. A version
-  # string should normally be a series of numbers separated by periods. Each part
-  # (digits separated by periods) is considered its own number, and these are used
-  # for sorting. So for instance, 3.10 sorts higher than 3.2 because ten is
-  # greater than two.
-  #
-  # If any part contains letters (currently only a-z are supported) then that
-  # version is considered prerelease. Versions with a prerelease part in the Nth
-  # part sort less than versions with N-1 parts. Prerelease parts are sorted
-  # alphabetically using the normal Ruby string sorting rules. If a prerelease
-  # part contains both letters and numbers, it will be broken into multiple parts
-  # to provide expected sort behavior (1.0.a10 becomes 1.0.a.10, and is greater
-  # than 1.0.a9).
-  #
-  # Prereleases sort between real releases (newest to oldest):
-  #
-  # 1.  1.0
-  # 2.  1.0.b1
-  # 3.  1.0.a.2
-  # 4.  0.9
-  #
-  # If you want to specify a version restriction that includes both prereleases
-  # and regular releases of the 1.x series this is the best way:
-  #
-  #     s.add_dependency 'example', '>= 1.0.0.a', '< 2.0.0'
-  #
-  # ## How Software Changes
-  #
-  # Users expect to be able to specify a version constraint that gives them some
-  # reasonable expectation that new versions of a library will work with their
-  # software if the version constraint is true, and not work with their software
-  # if the version constraint is false.  In other words, the perfect system will
-  # accept all compatible versions of the library and reject all incompatible
-  # versions.
-  #
-  # Libraries change in 3 ways (well, more than 3, but stay focused here!).
-  #
-  # 1.  The change may be an implementation detail only and have no effect on the
-  #     client software.
-  # 2.  The change may add new features, but do so in a way that client software
-  #     written to an earlier version is still compatible.
-  # 3.  The change may change the public interface of the library in such a way
-  #     that old software is no longer compatible.
-  #
-  # Some examples are appropriate at this point.  Suppose I have a Stack class
-  # that supports a `push` and a `pop` method.
-  #
-  # ### Examples of Category 1 changes:
-  #
-  # *   Switch from an array based implementation to a linked-list based
-  #     implementation.
-  # *   Provide an automatic (and transparent) backing store for large stacks.
-  #
-  # ### Examples of Category 2 changes might be:
-  #
-  # *   Add a `depth` method to return the current depth of the stack.
-  # *   Add a `top` method that returns the current top of stack (without changing
-  #     the stack).
-  # *   Change `push` so that it returns the item pushed (previously it had no
-  #     usable return value).
-  #
-  # ### Examples of Category 3 changes might be:
-  #
-  # *   Changes `pop` so that it no longer returns a value (you must use `top` to
-  #     get the top of the stack).
-  # *   Rename the methods to `push_item` and `pop_item`.
-  #
-  # ## RubyGems Rational Versioning
-  #
-  # *   Versions shall be represented by three non-negative integers, separated by
-  #     periods (e.g. 3.1.4).  The first integers is the "major" version number,
-  #     the second integer is the "minor" version number, and the third integer is
-  #     the "build" number.
-  #
-  # *   A category 1 change (implementation detail) will increment the build
-  #     number.
-  #
-  # *   A category 2 change (backwards compatible) will increment the minor
-  #     version number and reset the build number.
-  #
-  # *   A category 3 change (incompatible) will increment the major build number
-  #     and reset the minor and build numbers.
-  #
-  # *   Any "public" release of a gem should have a different version.  Normally
-  #     that means incrementing the build number.  This means a developer can
-  #     generate builds all day long, but as soon as they make a public release,
-  #     the version must be updated.
-  #
-  # ### Examples
-  #
-  # Let's work through a project lifecycle using our Stack example from above.
-  #
-  # Version 0.0.1
-  # :   The initial Stack class is release.
-  #
-  # Version 0.0.2
-  # :   Switched to a linked=list implementation because it is cooler.
-  #
-  # Version 0.1.0
-  # :   Added a `depth` method.
-  #
-  # Version 1.0.0
-  # :   Added `top` and made `pop` return nil (`pop` used to return the  old top
-  #     item).
-  #
-  # Version 1.1.0
-  # :   `push` now returns the value pushed (it used it return nil).
-  #
-  # Version 1.1.1
-  # :   Fixed a bug in the linked list implementation.
-  #
-  # Version 1.1.2
-  # :   Fixed a bug introduced in the last fix.
-  #
-  #
-  # Client A needs a stack with basic push/pop capability.  They write to the
-  # original interface (no `top`), so their version constraint looks like:
-  #
-  #     gem 'stack', '>= 0.0'
-  #
-  # Essentially, any version is OK with Client A.  An incompatible change to the
-  # library will cause them grief, but they are willing to take the chance (we
-  # call Client A optimistic).
-  #
-  # Client B is just like Client A except for two things: (1) They use the `depth`
-  # method and (2) they are worried about future incompatibilities, so they write
-  # their version constraint like this:
-  #
-  #     gem 'stack', '~> 0.1'
-  #
-  # The `depth` method was introduced in version 0.1.0, so that version or
-  # anything later is fine, as long as the version stays below version 1.0 where
-  # incompatibilities are introduced.  We call Client B pessimistic because they
-  # are worried about incompatible future changes (it is OK to be pessimistic!).
-  #
-  # ## Preventing Version Catastrophe:
-  #
-  # From:
-  # https://www.zenspider.com/ruby/2008/10/rubygems-how-to-preventing-catastrophe.
-  # html
-  #
-  # Let's say you're depending on the fnord gem version 2.y.z. If you specify your
-  # dependency as ">= 2.0.0" then, you're good, right? What happens if fnord 3.0
-  # comes out and it isn't backwards compatible with 2.y.z? Your stuff will break
-  # as a result of using ">=". The better route is to specify your dependency with
-  # an "approximate" version specifier ("~>"). They're a tad confusing, so here is
-  # how the dependency specifiers work:
-  #
-  #     Specification From  ... To (exclusive)
-  #     ">= 3.0"      3.0   ... &infin;
-  #     "~> 3.0"      3.0   ... 4.0
-  #     "~> 3.0.0"    3.0.0 ... 3.1
-  #     "~> 3.5"      3.5   ... 4.0
-  #     "~> 3.5.0"    3.5.0 ... 3.6
-  #     "~> 3"        3.0   ... 4.0
-  #
-  # For the last example, single-digit versions are automatically extended with a
-  # zero to give a sensible result.
-  #
   class Version
     include Comparable
 

data/core/thread.rbs

@@ -1565,10 +1565,10 @@ class Thread::Mutex < Object
 
   # <!--
   #   rdoc-file=thread_sync.rb
-  #   - mutex.lock  -> self
+  #   - mutex.unlock  -> self
   # -->
-  # Attempts to grab the lock and waits if it isn't available. Raises
-  # `ThreadError` if `mutex` was locked by the current thread.
+  # Releases the lock. Raises `ThreadError` if `mutex` wasn't locked by the
+  # current thread.
   #
   def unlock: () -> self
 end
@@ -1751,11 +1751,6 @@ end
 # See Thread::Queue for an example of how a Thread::SizedQueue works.
 #
 class Thread::SizedQueue[E = untyped] < Thread::Queue[E]
-  # <!--
-  #   rdoc-file=thread_sync.rb
-  #   - <<(object, non_block = false, timeout: nil)
-  # -->
-  #
   alias << push
 
   # <!--

data/docs/CONTRIBUTING.md

@@ -13,7 +13,7 @@ The RBS repository contains the type definitions of Core API and Standard Librar
 There are some discussions whether if it is the best to have them in this repository, but we have them and continue updating the files meanwhile.
 
 The target version of the bundled type definitions is the [latest _release_ of Ruby](https://www.ruby-lang.org/en/downloads/branches/) -- `4.0` as of 2026.
-Note, however, that the CI currently retains the tests on Ruby 3.2 as well.
+Note, however, that the CI runs the tests on every non-EOL Ruby -- `3.3` and later as of 2026.
 
 **The core API** type definitions are in `core` directory.
 You will find the familiar class names in the directory, like `string.rbs` or `array.rbs`.

data/docs/release.md

@@ -0,0 +1,69 @@
+# Releasing RBS
+
+Each release ships **two gems**:
+
+| Gem | Platform | Parser | How it is built |
+| --- | --- | --- | --- |
+| `rbs-X.Y.Z.gem` | `ruby` (MRI) | C extension | `rake release` (re-builds it) |
+| `rbs-X.Y.Z-java.gem` | `java` (JRuby) | WebAssembly (`lib/rbs/wasm`) | Docker image, pushed manually |
+
+The `-java` gem contains no native code — just `rbs_parser.wasm`. The Chicory/ASM
+jars it needs are not shipped in the gem; they are declared as `jar-dependencies`
+requirements and fetched from Maven when the gem is installed. So the gem can be
+built once in any environment and runs on every JRuby.
+
+## Prerequisites
+
+- Push rights to the `rbs` gem on RubyGems (`gem signin`). If your account has
+  MFA enabled, `gem push` / `rake release` will prompt for an OTP.
+- Docker, for the `-java` gem. The WASI SDK is baked into the image, so there is
+  nothing to install on the host.
+
+## Steps
+
+### 1. Release the `ruby` gem
+
+Once the version is bumped and committed, run on CRuby:
+
+```console
+$ bundle exec rake release
+```
+
+This re-builds the `ruby`-platform gem and then:
+
+- creates the tag `vX.Y.Z`,
+- pushes the current branch and the tag to `origin`,
+- pushes the gem to RubyGems,
+- runs `release:note`, which opens a GitHub **draft** release (with
+  `--prerelease` for `*.pre.*` versions) and prints the remaining manual steps.
+
+### 2. Build and push the `java` gem
+
+The `java` gem is not built by `rake release`, so build and push it manually:
+
+```console
+# Build from the committed state (the gemspec's file list comes from `git ls-files`).
+$ docker build -f Dockerfile.jruby -t rbs-jruby .
+
+# Build rbs_parser.wasm and the -java gem into ./pkg on the host. The Chicory/ASM
+# jars are not bundled; they are fetched from Maven when the gem is installed.
+$ docker run --rm -e RBS_PLATFORM=java -v "$PWD/pkg:/out" rbs-jruby \
+    gem build rbs.gemspec -o /out/rbs-X.Y.Z-java.gem
+
+$ gem push pkg/rbs-X.Y.Z-java.gem
+```
+
+Optionally confirm it installs and runs on JRuby before pushing:
+
+```console
+$ docker run --rm -v "$PWD/pkg:/pkg" -w /tmp rbs-jruby bash -c \
+    'gem install /pkg/rbs-X.Y.Z-java.gem && ruby -e "require %q{rbs}; puts [RUBY_ENGINE, RBS::VERSION].join(%q{ })"'
+```
+
+## Notes
+
+- Prereleases (`X.Y.Z.pre.N`) are only installed with `gem install rbs --pre`;
+  a plain `gem install rbs` is unaffected. On JRuby, `gem install rbs [--pre]`
+  resolves to the `-java` gem automatically.
+- The Dockerfile pins the WASI SDK / Chicory / ASM versions to match the
+  `wasm` and `jruby` CI workflows. Keep them in sync when bumping.

data/ext/rbs_extension/ast_translation.c

@@ -196,8 +196,8 @@ static VALUE rbs_intern_namespace(rbs_translation_context_t ctx, rbs_namespace_t
     return rb_funcallv(RBS_Namespace, intern_brackets(), 2, args);
 }
 
-static VALUE rbs_intern_type_name(VALUE namespace, VALUE name) {
-    VALUE args[2] = { namespace, name };
+static VALUE rbs_intern_type_name(VALUE type_namespace, VALUE name) {
+    VALUE args[2] = { type_namespace, name };
     return rb_funcallv(RBS_TypeName, intern_brackets(), 2, args);
 }
 

data/ext/rbs_extension/legacy_location.c

@@ -91,7 +91,7 @@ static rb_data_type_t location_type = {
     { rbs_loc_mark, (RUBY_DATA_FUNC) rbs_loc_free, rbs_loc_memsize },
     0,
     0,
-    RUBY_TYPED_FREE_IMMEDIATELY
+    RUBY_TYPED_FREE_IMMEDIATELY | RUBY_TYPED_WB_PROTECTED
 };
 
 static VALUE location_s_allocate(VALUE klass) {
@@ -114,10 +114,11 @@ static VALUE location_initialize(VALUE self, VALUE buffer, VALUE start_pos, VALU
     int end = FIX2INT(end_pos);
 
     *loc = (rbs_loc) {
-        .buffer = buffer,
+        .buffer = Qnil,
         .rg = (rbs_loc_range) { start, end },
         .children = NULL,
     };
+    RB_OBJ_WRITE(self, &loc->buffer, buffer);
 
     return Qnil;
 }
@@ -127,10 +128,11 @@ static VALUE location_initialize_copy(VALUE self, VALUE other) {
     rbs_loc *other_loc = rbs_check_location(other);
 
     *self_loc = (rbs_loc) {
-        .buffer = other_loc->buffer,
+        .buffer = Qnil,
         .rg = other_loc->rg,
         .children = NULL,
     };
+    RB_OBJ_WRITE(self, &self_loc->buffer, other_loc->buffer);
 
     if (other_loc->children != NULL) {
         rbs_loc_legacy_alloc_children(self_loc, other_loc->children->cap);
@@ -193,7 +195,8 @@ VALUE rbs_new_location(VALUE buffer, rbs_range_t rg) {
     rbs_loc *loc;
     VALUE obj = TypedData_Make_Struct(RBS_Location, rbs_loc, &location_type, loc);
 
-    rbs_loc_init(loc, buffer, (rbs_loc_range) { rg.start.char_pos, rg.end.char_pos });
+    rbs_loc_init(loc, Qnil, (rbs_loc_range) { rg.start.char_pos, rg.end.char_pos });
+    RB_OBJ_WRITE(obj, &loc->buffer, buffer);
 
     return obj;
 }
@@ -202,7 +205,8 @@ VALUE rbs_new_location2(VALUE buffer, int start_char, int end_char) {
     rbs_loc *loc;
     VALUE obj = TypedData_Make_Struct(RBS_Location, rbs_loc, &location_type, loc);
 
-    rbs_loc_init(loc, buffer, (rbs_loc_range) { .start = start_char, .end = end_char });
+    rbs_loc_init(loc, Qnil, (rbs_loc_range) { .start = start_char, .end = end_char });
+    RB_OBJ_WRITE(obj, &loc->buffer, buffer);
 
     return obj;
 }
@@ -211,7 +215,8 @@ static VALUE rbs_new_location_from_loc_range(VALUE buffer, rbs_loc_range rg) {
     rbs_loc *loc;
     VALUE obj = TypedData_Make_Struct(RBS_Location, rbs_loc, &location_type, loc);
 
-    rbs_loc_init(loc, buffer, rg);
+    rbs_loc_init(loc, Qnil, rg);
+    RB_OBJ_WRITE(obj, &loc->buffer, buffer);
 
     return obj;
 }

data/lib/rbs/parser_aux.rb

@@ -121,12 +121,14 @@ module RBS
 
     def self.parse_inline_leading_annotation(source, range, variables: [])
       buf = buffer(source)
-      _parse_inline_leading_annotation(buf, range.begin || 0, range.end || buf.last_position, variables)
+      byte_range = byte_range(range, buf.content)
+      _parse_inline_leading_annotation(buf, byte_range.begin || 0, byte_range.end || buf.content.bytesize, variables)
     end
 
     def self.parse_inline_trailing_annotation(source, range, variables: [])
       buf = buffer(source)
-      _parse_inline_trailing_annotation(buf, range.begin || 0, range.end || buf.last_position, variables)
+      byte_range = byte_range(range, buf.content)
+      _parse_inline_trailing_annotation(buf, byte_range.begin || 0, byte_range.end || buf.content.bytesize, variables)
     end
 
     def self.byte_range(char_range, content)