Use a custom URI class to handle source location comments

[vinistock]

Motivation

We are currently relying on regexes and string substitutions to find the right paths for gems. This is not reliable and has proven to not find the right paths.

Implementation

This PR introduces a custom URI object to handle the source:// scheme. This makes it easier to validate the consistency of the URI and we can use a similar object on the Ruby LSP to do the inverse operation of parsing it.

It also improves the detection of default gem paths, by using Gemfile::GemSpec, which already has the mechanisms to figure out these paths for us.

The format of source URIs is now:

source://tapioca/1.2.3/lib/foo.rb#13
^ scheme
         ^ gem name
                 ^ gem version (optional)
                       ^ path
                                  ^ line number

Tests

Updated existing tests.

[st0012]

I think it may be too much effort but are we able to have a test for the BUNDLER_HOME scenario?

[paracycle]

I am not sure if I understand why we are doing more breakdowns here. Isn't it the case that if I have foo-1.2.3 as a dependency, that it should be referenced in the RBI file as foo-1.2.3? Do we care if I suddenly change my Bundler setup so that it installs foo to the bundle path? If so, why do we care?

[vinistock]

@paracycle while testing this on Core, I realized that we have a mix of both. Some gems are installed under Bundler.home and others are installed under Bundle.bundle_path.

If this information is not present somehow in the source location comments, the Ruby LSP has no way of figuring out where the appropriate path is.

I have no clue why we have gems on both locations though. If you have more context on why this could be, let me know.

[paracycle]

If this information is not present somehow in the source location comments, the Ruby LSP has no way of figuring out where the appropriate path is.

LSP can search in both locations?

[vinistock]

Is that better though? That means that instead of processing that ahead of time in Tapioca, we'll need to search on both when serving the request.

[paracycle]

Is that better though? That means that instead of processing that ahead of time in Tapioca, we'll need to search on both when serving the request.

Yes, I think it is better. IMO, this mechanism should be open to the gem moving from one valid place to another, and as long as the gem is the same version, we should still be able to locate it without an error.

So, encoding a lot of information on the generation side is not the best way to go, the client should be able to look things up on consumption side. After all, that's exactly what happens with Ruby tools, they all resolve a gem reference by looking it up in various place the gem could be.

[paracycle]

This is looking really good but I still have a few comments.

[dirceu]

Code looks good to me. Questions for my own understanding:

1. Is ruby-lsp the only client that currently consumes those source location comments?
2. Given that Tapioca usually doesn't regenerate RBIs unless you change the version of a gem, does that mean that ruby-lsp will have to support multiple formats of source location comments?

[vinistock]

@dirceu Yeah, for now the Ruby LSP is the only consumer of the source location comments. However, Sorbet could also consume them to include them as a location on go to definition.

What do you mean by multiple formats?

[dirceu]

@vinistock I meant source://tapioca/1.2.3/lib/foo.rb#13 vs source://tapioca-1.2.3/lib/foo.rb#13 for example (which is I believe the current format in main). The format did change slightly right?

[vinistock]

@dirceu yes, we changed the format to source://gem_name/version/path/file.rb#line_number. This allows us to use the custom URI class to properly parse the components. With the dashes, it's hard to tell if the dash is a part of the gem name or just the dash separating the version number.