derive breaks "ambiguous name" diagnostic if there is a level of indirection

[pr2502]

Hello. I've noticed a strange behaviour where rust-analyzer and rustc would disagree what was wrong with my code. Turns out neither of them were right, I've had an "ambiguous name" problem however both rustc and rust-analyzer resolved the type anyway and they chose a different type to disambiguate into.

I've managed to make this minimal reproduction.
I can either remove the derives or remove the indirection through the c module and the problem will go away.

I expected to get a "Foo is ambiguous" error, instead i get an error for one of the usages of Foo which doesn't match the resolved type of Foo.

As a side-note, at least for rustc the resolved type seems to be dependent on the lexical order of the module/type definitions (not reexports), if that helps at all.

I get the same result on both nightly and stable, locally and on the playground. I found these issues #56593 and #62769 which sound similar but the problem there seems to be the opposite - "type doesn't resolve when it should" (in the presence of derive) instead of here "type resolves when it shouldn't".

[estebank]

A quick check in godbolt seems to show that this is not a regression.

CC @petrochenkov who might be interested in this.

[petrochenkov]

This looks like a same issue as #56593 linked above, or at least it has the same underlying reasons.
Glob imports from a module are not always properly updated when a macro is expanded in that module.

[estebank]

Closing as duplicate, copying the text to a comment on the other thread.