Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(resolve): not defined extern crate shadow_name #111761

Merged
merged 1 commit into from
May 23, 2023

Conversation

bvanjoi
Copy link
Contributor

@bvanjoi bvanjoi commented May 19, 2023

Fixes #109148

Why does #109148 panic?

When resolving use std::xx it enters visit_scopes from early_resolve_ident_in_lexical_scope, and iters twice during the loop:

iter scope break_result result
0 Module pointed to root binding pointed to Undetermined, so result is None scope changed to ExternPrelude
1 ExternPrelude binding pointed to std -

Then, the result of maybe_resolve_path is Module(std), so import.imported_module.set is executed.

Finally, during the finalize_import of use std::xx, resolve_path returns NonModule because Binding(Ident(std), Module(root)'s binding points to extern crate blah as std, which causes the assertion to fail at assert!(import.imported_module.get().is_none());.

Investigation

The question is why #[a] extern crate blah as std is not defined as a binding of std::xxx, which causes the iteration twice during visit_scopes when resolving std::xxx. Ideally, the value of break_result.is_some() should have been valid in the first iteration.

After debugging, I found that because #[a] extern crate blah as std had been dummied by placeholder during collect_invocations, so it had lost its attrs, span, etc..., so it will not be defined. However, expand_invoc added them back, then the next build_reduced_graph, #[a] extern crate blah as std would have been defined, so it makes the result of resolved_path unexpected, and the program panics.

Try to solve

I think there has two-way to solve this issue:

  • Expand invocations before the first resolve_imports during fully_expand_fragment. However, I do not think this is a good idea because it would mess up the current design.
  • As my PR described: do not define to extern crate blah as std during the second build_reduced_graph, which is very easy and more reasonable.

r? @petrochenkov

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels May 19, 2023
@petrochenkov
Copy link
Contributor

#[a] extern crate blah as std had been dummied by placeholder during collect_invocations, so it had lost its attrs, span, etc..., so it will not be defined.

This is just how expansion algorithm works, it turns not-yet-expanded macro calls (including attribute invocations) into dummy nodes, and then expands them into real nodes.
So if a node is dummy at some point it doesn't mean that it will not be defined, in many cases it will be defined, just a bit later, when the macro is expanded.

Cases like this is exactly why we have Undetermined resolution results, to deal with names that do not exist right now but may appear later.

@petrochenkov
Copy link
Contributor

I think there has two-way to solve this issue:

There's a third solution - remove the assert, it is not very important.

The assert already doesn't hold when ambiguity errors are reported (that's why it's wrapped into the if no_ambiguity { ... }) condition.

The "macro-expanded extern crate items cannot shadow names passed with --extern" error is also an ambiguity error, it's just reported in a different place than the errors from the if no_ambiguity { ... } condition so it's not accounted, but it will also break the assert condition.

Ideally we'd use something like

let no_ambiguity = self.ambiguity_errors.len() == prev_ambiguity_errors_len || that_specific_extern_crate_error_was_reported;

but the assert is not important enough for that_specific_extern_crate_error_was_reported to be kept as a separate flag.

@petrochenkov
Copy link
Contributor

petrochenkov commented May 22, 2023

Simplified reproduction without unresolved attributes and crates:

macro_rules! m {
    () => {
        extern crate core as std;
    }
}

m!();

use std::mem;

fn main() {}

Could you use it as the test?

@@ -873,6 +873,7 @@ impl<'a, 'b, 'tcx> BuildReducedGraphVisitor<'a, 'b, 'tcx> {
let msg = "macro-expanded `extern crate` items cannot \
shadow names passed with `--extern`";
self.r.tcx.sess.span_err(item.span, msg);
return;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, this is a good solution too.

Could you add a comment saying that this is an ambiguity error, but it's not registered in ambiguity_errors, and that triggers some asserts later on if the binding is added, so we don't add the binding.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's worth discussing the actual binding of use std::xxx.

When we add return here, std::xxx ultimately refers to prelude::std.

However, based on your comment, it seems that std::xxx will point to extern crate blash(I guess, but not entirely sure).

There might be a difference between these two resolutions, so in my opinion, we should determine which action is better first.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The choice is not that important because it only happens during failing compilation anyway.
The difference may only happen in some secondary diagnostics.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this case is migrated to regular ambiguity errors, then extern crate blah will be selected as a resolution, yes, because it's closer in scopes at the resolution point.
(This migration is probably a better long term solution, but it's a minor language change, so it's better done separately from fixing an ICE.)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the migration to regular ambiguity errors happens then this test case:

macro_rules! m {
    () => {
        extern crate core as std;
        
        use std::mem;
    }
}

m!();

fn main() {}

won't produce any errors.

@petrochenkov petrochenkov added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 22, 2023
@bvanjoi
Copy link
Contributor Author

bvanjoi commented May 23, 2023

@rustbot ready

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels May 23, 2023
@petrochenkov
Copy link
Contributor

@bors r+ rollup

@bors
Copy link
Contributor

bors commented May 23, 2023

📌 Commit c41b208 has been approved by petrochenkov

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 23, 2023
bors added a commit to rust-lang-ci/rust that referenced this pull request May 23, 2023
…iaskrgr

Rollup of 7 pull requests

Successful merges:

 - rust-lang#111427 ([rustdoc][JSON] Use exclusively externally tagged enums in the JSON representation)
 - rust-lang#111486 (Pretty-print inherent projections correctly)
 - rust-lang#111722 (Document stack-protector option)
 - rust-lang#111761 (fix(resolve): not defined `extern crate shadow_name`)
 - rust-lang#111845 (Update books)
 - rust-lang#111851 (CFI: Fix encode_region: unexpected ReEarlyBound(0, 'a))
 - rust-lang#111871 (Migrate GUI colors test to original CSS color format)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 37c9478 into rust-lang:master May 23, 2023
@rustbot rustbot added this to the 1.71.0 milestone May 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ICE assertion failed: import.imported_module.get().is_none() --edition=2021
4 participants