Files
rust/compiler
Matthias Krüger 98f6e9644b Rollup merge of #112495 - bvanjoi:fix-109153, r=petrochenkov
fix(resolve): update shadowed_glob more precision

- Fixes #109153
- Fixes #109962

## Why does it panic?

We use #109153 as an illustration.

The process of `resolve_imports` is:

| Iter | resolve     | resolution of **`(Mod(root), Ident(bar) in type ns)`** |
| -    | -           | -      |
| 0 | `use foo::*`   | `binding` -> foo::bar, `shallowed_glob` -> `None` |
| 1 | `use bar::bar` | `binding` -> foo::bar::bar, `shallowed_glob` -> foo::bar    |
| 2 | `use bar::*`   | `binding` -> foo::bar::bar, `shallowed_glob` -> foo::bar::bar::bar |

So during `finalize_import`, the `root::bar` in `use bar::bar` had been pointed to `foo::bar::bar::bar`, which is different from the `initial_module` valued of `foo::bar`, therefore, the panic had been triggered.

## Try to solve it

~I think #109153 should check-pass rather than throw an ambiguous error. Following this idea, there are two ways to solve this problem:~

~1. Give up the `initial_module` and update `import.imported_module` after each resolution update. However, I think this method may have too much impact.~
~2. Do not update the `shadowed_glob` when it is defined.~

~To be honest, I am not sure if this is the right way to solve this ICE. Perhaps there is a better resolution.~

Edit: we had made the `resolution.shadowed_glob` update more detailed.

r? `@petrochenkov`
2023-06-14 06:25:48 +02:00
..
2023-05-02 10:45:16 -07:00
2023-06-05 16:01:09 +02:00
2023-06-03 09:44:30 +08:00
2023-06-12 11:58:40 +02:00
2023-05-26 15:18:54 -04:00
2023-04-10 17:24:23 +09:00
2023-04-10 22:02:52 +02:00
2023-05-26 18:55:02 +01:00