Follow aliases when they are used in mixins or parent classes

[vinistock]

When a constant alias is used in a mixin operation or a parent class, we need to follow the alias to figure out what namespace it points to.

[vinistock]

• Include RBS paths when indexing workspace #609
• Add integrity check for owner relationships #592
• Avoid creating singleton classes for non-namespace targets #623
• Auto promote when creating constants inside namespace #622
• Fix corner cases of re-opening aliases #621
• Follow aliases when they are used in mixins or parent classes #620 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[vinistock]

Merge activity

• Mar 4, 8:32 PM UTC: A user started a stack merge that includes this pull request via Graphite.
• Mar 4, 8:32 PM UTC: @vinistock merged this pull request with Graphite.

[Morriar]

I'm wondering if we should set context.partial = true here when resolve_to_namespace returns None because the alias target isn't resolved yet (as opposed to being a non-namespace constant).

What would happen with this test?

  #[test]
  fn include_via_alias_when_target_resolves_later() {
      let mut context = GraphTest::new();
      context.index_uri("file:///a.rb", {
          r"
          AliasedModule = SomeModule

          class Foo
            include AliasedModule
          end

          module SomeModule
          end
          "
      });
      context.resolve();

      assert_ancestors_eq!(context, "Foo", ["SomeModule", "Foo", "Object"]);
  }

[vinistock]

This specific example already works as we figure out what the alias points to. I prototyped making the ancestors partial in this case, but I'm not 100% sure it's worth it to be honest.

Making the ancestors partial means we enqueue retries for linearization, which in the case of an unresolved alias will never complete and only slows down resolution.

Also, it makes the code a bit more complicated because partial ancestors store a NameId, so then we need to follow aliases to trace back what NameId are associated with them.

Considering that we will add a diagnostic pointing to the fact that the alias was not successfully resolved, I would vote to not do this. At least not for now.