Fixes regression caused by enum and struct callpaths.

[esdrubal]

Description

The issue is that struct or enum can be imported with different callpaths depending the module they are imported from.

For instance we could have a struct with callpath
my_script::data_structures::SomeStruct in a module and in another module as my_script::eq_impls::data_structures::SomeStruct. This makes callpaths unreliable to compare declarations.

Closes #3998

Reopens #418

Disables tests multiple_enums_with_the_same_name and multiple_structs_with_the_same_name because they relied in callpath comparisons to work.

Checklist

• I have linked to any relevant issues.
• I have commented my code, particularly in hard-to-understand areas.
• I have updated the documentation where relevant (API docs, the reference, and the Sway book).
• I have added tests that prove my fix is effective or that my feature works.
• I have added (or requested a maintainer to add) the necessary Breaking* or New Feature labels where relevant.
• I have done my best to ensure that my PR adheres to the Fuel Labs Code Review Standards.
• I have requested a review from the relevant team or maintainers.

[mohammadfawaz]

Thanks for the quick fix @esdrubal

Is the issue here that the call path used in type unification does not always refer to actual struct/enum declaration? I would have assumed that there is a unique path for the struct/enum declaration. Where is the other path coming from? Is it from the impl trait block?

[emilyaherbert]

Hi @esdrubal, I think what you are saying is that even though two TypeInfo::Enums may point to the same type syntactically, relying on the call paths inside TypeInfo::Enum is unreliable as these can be relative call paths? Do I have this right?

If so, you might be interested in taking a look at #3744, among other things this PR changes TypeInfo::Enum and others to remove the call path field and instead use DeclIds directly. That would be a fix to this problem.

CC @mohammadfawaz

[mohammadfawaz]

Hi @esdrubal, I think what you are saying is that even though two TypeInfo::Enums may point to the same type syntactically, relying on the call paths inside TypeInfo::Enum is unreliable as these can be relative call paths? Do I have this right?

If so, you might be interested in taking a look at #3744, among other things this PR changes TypeInfo::Enum and others to remove the call path field and instead use DeclIds directly. That would be a fix to this problem.

CC @mohammadfawaz

Oh excellent. In that case, I suggest we merge this PR to fix the regression until #3744 is complete.

[emilyaherbert]

One of the temporary approaches we could take would be to add "unimplemented" compile errors for using types with a call path. i.e. the case defined here #1644. But if my hunch is right, then this unimplemented error will catch the case in #418, thereby disallowing any syntax like module0::Thing::new(), which is a breaking change and undesirable.

I can think of some temporary hacks to prevent #418, but I'm more inclined to block that bug behind #3744 instead. Approving this patch right now though.

[esdrubal]

I think what you are saying is that even though two TypeInfo::Enums may point to the same type syntactically, relying on the call paths inside TypeInfo::Enum is unreliable as these can be relative call paths? Do I have this right?

Yes that's exactly the problem. If we have two modules A and B using an enum in module C, in module A we will have the enum declaration with call path my_script::A::C::MyEnum and in module B we will have the enum declaration with call path my_script::B::C::MyEnum. Then the unifier fails when using call paths.