Sanitize version from source location

[vinistock]

Motivation

Including the gem versions in source location comments causes a lot of churn in RBIs every time there are gem upgrades. We can use a special string VERSION and let the Ruby LSP figure out the versions itself.

Implementation

Just started sanitizing the version numbers for VERSION and re-generated the RBIs. This branch is based on #1094.

Tests

Adapted the existing tests.

[st0012]

Maybe we can also mention that having -VERSION will make ruby-lsp easier to substitute it with the actual version for path restoration?
I think currently it's not clear on why we keep this if the reader doesn't know how we'll use the source comment.

[rafaelfranca]

Suggested change

	# version is always between a hyphen at the end of the gem name and the `/lib` folder
	# version is always between a hyphen at the end of the gem name and the `/lib` folder.

[paracycle]

I really don't like the fact that we are adding a VERSION string to the source URI. I think the problem here is that we are not treating the source: protocol as a URI scheme and we have never defined it properly. So far, we've been approaching it adhoc and have been assembling and parsing it using string operations instead of URI operations, which is generally asking for trouble.

I would suggest the following:

source://[gem_name][@version]/<path>[#<line_number>]

as the URI scheme where [] sections are always optional, and <> sections are mandatory.

So, here are the different cases we can encode with this:

1. Implicit gem name and version: source:///some/path/to/file.rb#42
2. Explicit gem name and implicit gem version: source://my_popular_gem/some/path/to/file.rb#42
3. Explicit gem name and version: source://[email protected]/some/path/to/file.rb#42
4. Link to file with unknown line number: source://[email protected]/some/path/to/file.rb

Moreover, we should be able to write a URI::Generic subclass to do the building/parsing of these source URIs.

[vinistock]

I love the idea. Do we then need another scheme for Ruby lib paths?

[paracycle]

Do we then need another scheme for Ruby lib paths?

I think not. IMO, we are confounding where the gem is installed with where inside the gem this code is coming from. We want to encode the latter and leave it up to the client to resolve where the specified gem/version should be found.

For example, it could be the case that on my system I have the gem [email protected] installed in the Ruby lib path, but on a colleague's machine [email protected] is installed by Bundler/Rubygems to the gem path (imagine the colleague is using an older Ruby that bundles with [email protected] and [email protected] was a dependency in the lockfile).

It should be the responsibility of the client to resolve [email protected] to a path on disk and to then resolve the path relative to that location.

[vinistock]

Sorry, I wasn't clear. I'm not talking about where the gem is installed.

I mean when methods are defined not inside a gem, but inside the Ruby standard library. Like in this test, where Mutex_m method locations are in the Ruby path - not inside any gems.

Those files are inside RbConfig::CONFIG["rubylibdir"] and not Bundler.bundle_path, so we need some way of differentiating between gems and the stdlib.

[paracycle]

yes, I know, and that is still a gem: https://github.com/ruby/mutex_m

$ gem list

*** LOCAL GEMS ***

aasm (5.2.0)
abbrev (default: 0.1.0)
actioncable (7.0.3, 7.0.2.4, 7.0.2.3, 6.1.5, 6.1.4.6)
...
mutex_m (default: 0.1.1)
...

[vinistock]

So, is your suggestion to do source://mutex.rb#12 and let the client figure out where it is?

[paracycle]

More like source://[email protected]/mutex_m.rb#12, but yeah. Since, like I said in my comment above, on another machine the 0.1.1 version of the mutex_m gem can be installed in the normal gem path.

[vinistock]

I'll combine the work of this PR into #1094.