Add compiler error E0523 long description and test

[MatthewPeterKelly]

This PR is one step towards addressing: #61137.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @jackh726 (or someone else) soon.

Please see the contribution instructions for more information.

[MatthewPeterKelly]

I'm somewhat stuck here because I'm not sure how to create a small self-contained test that defines and pulls in two different crates with the same name. Is there a way to "stub" out a fake crate for use in a test like this?

(thanks in advance for the help -- I'm relatively new to rust and trying to learn a bit by working through some simple issues)

[jackh726]

So, in ui tests, there is a way to mimic extra crates. (I don't remember if 'auxillary' files are separate crates or not.

For the rustc_error_codes file, I think it's just going to be "faking" it.

[MatthewPeterKelly]

there is a way to mimic extra crates

Would you be able to point me to an example or give me a keyword that I can search the repo for?

[jackh726]

https://rustc-dev-guide.rust-lang.org/tests/compiletest.html#building-auxiliary-crates

[MatthewPeterKelly]

Note: this PR is still an early draft -- it just adds some notes in the files that need to be changed, and provides a way for me to get some early feedback.

[MatthewPeterKelly]

@jackh726 -- Made a bit more progress, but still having trouble reproducing E0523. I was able to get the auxiliary file thing working though, so that's neat.

I did a bit of sleuthing to figure out where the compiler actually generates this error message. It is configured in compiler/rustc_metadata/src/errors.rs:

#[derive(Diagnostic)]
#[diag(metadata_symbol_conflicts_others, code = "E0523")]
pub struct SymbolConflictsOthers {
    #[primary_span]
    pub span: Span,
    pub crate_name: Symbol,
}

This is the instruction that tells the compiler to match some set of conditions to an actual error string, but I don't know enough about the compiler to reverse engineer how to reproduce those conditions (or exactly what they mean). Some more sleuthing shows that the actual error message text is produced in compiler/rustc_error_messages/locales/en-US/metadata.ftl:

metadata_symbol_conflicts_others =
    found two different crates with name `{$crate_name}` that are not distinguished by differing `-C metadata`. This will result in symbol conflicts between the two.

Any good ideas on how to reproduce E0523 in the UI test?

[MatthewPeterKelly]

These two crates both have the same "crate-name", so I was hoping that including both would trigger E0523.

I've tried various combinations of file names and crate names, but so far no luck hitting E0523. As written here, the compiler cannot find the fifty() function, which suggests to me that somehoe *_aux1 is overriding *_aux2 or something like that.

[MatthewPeterKelly]

This should be ambiguous, as two different crates have this name. Maybe it just accepts the first one that it finds and doesn't see the second?

[bors]

☔ The latest upstream changes (presumably #105940) made this pull request unmergeable. Please resolve the merge conflicts.

[Ezrashaw]

@MatthewPeterKelly Friendly ping, how are you going on this PR? Would you like some help? It'd be really nice to get this merged soon so that we can have all error codes documented and finally close #61137!

[MatthewPeterKelly]

@MatthewPeterKelly Friendly ping, how are you going on this PR? Would you like some help?

It would be great to get some help! I'm stuck on not being able to reproduce the error message. I tried to reverse engineer it from the compiler code (#100599 (review)), but got stuck there too.

Any chance that you know what I need to do to make the compiler produce E0523?

It'd be really nice to get this merged soon so that we can have all error codes documented and finally close #61137!

Wow - so many checked boxes on that list! Agreed. Let's get this PR merged.

[Ezrashaw]

@MatthewPeterKelly Right so here are my thoughts:

• Firstly, the error code is emitted here:
  compiler/rustc_metadata/src/creader.rs:362

fn verify_no_symbol_conflicts(&self, root: &CrateRoot) -> Result<(), CrateError> {
    // Check for (potential) conflicts with the local crate
    if self.sess.local_stable_crate_id() == root.stable_crate_id() {
        return Err(CrateError::SymbolConflictsCurrent(root.name()));
    }

    // Check for conflicts with any crate loaded so far
    for (_, other) in self.cstore.iter_crate_data() {
        // Same stable crate id but different SVH
        if other.stable_crate_id() == root.stable_crate_id() && other.hash() != root.hash() {
            return Err(CrateError::SymbolConflictsOthers(root.name()));
        }
    }

    Ok(())
}

(E0519 is related, I documented that but the SymbolConflictsOthers equivalent seems to yield E0464)

• I wonder if perhaps this error code is unreachable, I think you might get E0464 before this error. I don't want to jump the gun on this, so a team member's opinion would be good (cc @compiler-errors).
• If this is the case, then it would be great if you could remove the error code entirely:
  • Remove the code from compiler/rustc_metadata/src/creader.rs and the other place you identified in the comment.
  • You can keep your docs and mark them as no longer emitted (see here for an example off the top of my head). The doctest can remain, just make sure it's just compile_fail, not compile_fail,E0523.
  • You can also keep your UI test, just update it to copy from tests/ui/error-codes/E0464.rs.

Thanks for the hard work :)

[MatthewPeterKelly]

I wonder if perhaps this error code is unreachable, I think you might get E0464 before this error. I don't want to jump the gun on this, so a team member's opinion would be good (cc @compiler-errors).

I was wondering the same thing -- all of my attempts produced other error messages. I'll wait to hear back from @compiler-errors about whether E0523 is reachable, and if it isn't follow the steps you outlined above to "deprecate" this error.

[compiler-errors]

I also can't reproduce this error, but I know a lot less about the crate loading part of the compiler.

Regardless, if we are going to remove the error from the codebase, please replace it with a span_bug!() or delay_span_bug so we don't silently accept code that would've triggered this issue.

[MatthewPeterKelly]

I also can't reproduce this error, but I know a lot less about the crate loading part of the compiler.

Do you think we should go ahead with the "assume that E0523 is no longer emitted" plan (with your suggestion of the span_bug!() macro), or is there someone else that we should reach out to for guidance first?

[Ezrashaw]

@MatthewPeterKelly Yup, make it a span_bug.

[bors]

☔ The latest upstream changes (presumably #107220) made this pull request unmergeable. Please resolve the merge conflicts.

[MatthewPeterKelly]

Any ideas for how to pass in the correct span here?

[compiler-errors]

actually this could probably just be a bug!, there's no span associated with it.

[MatthewPeterKelly]

Thanks -- I swapped in a bug!() and that worked.

[Ezrashaw]

It'd be great if we could have a code example to show some code which previously produced this error here. You can just copy it from the E0523.md file.

Also a small nitpick: when you add a code example, the note explaining that this error has been merged into E0464 could be below the code example (I think that's more in line with how it's normally formatted).

[MatthewPeterKelly]

It'd be great if we could have a code example to show some code which previously produced this error here. You can just copy it from the E0523.md file.

Sure. I'm going to assume that you meant the E0464.rs file (based on an earlier comment), as E0523.md is this file and E0464.md doesn't include a code example.

when you add a code example, the note explaining that this error has been merged into E0464

Done! Let me know if I got the formatting right.

[MatthewPeterKelly]

@Ezrashaw -- I've updated the docs for E0523 to include an example that (we think) would have produced E0523 on an earlier version of the compiler,by copying the example from E0464. I noticed that the docs for E0464 were missing the example, so I added it there too (same exact example and description as E0523). Let me know if this makes sense.

Does it still make sense to have the E0523.rs and E0523.stderr files? I temporarily removed them as a quick check and all of the tests still passed (they're back in the PR now). They are a direct copy of E0464.rs/stderr, so I'm not sure that they are adding much value, now that E0523 is removed.

[Ezrashaw]

@MatthewPeterKelly Sorry for the slow reply.

It looks great, just one thing: could you move the code examples to be under the top-line text, without the paragraph in between. Other than that, and if @GuillaumeGomez is happy, then it's good to merge.

[compiler-errors]

One nit: Can you rebase and either squash this into a fewer number of commits, or at least drop that commit fb1ff0f696df1056e32991a6444ee969f93e5fd0 + its revert commit from the history? no need to keep it if it's being reverted later down the stack. It helps to declutter the history imo :)

[MatthewPeterKelly]

Ok - I think this is ready. I moved the code example as suggested by @Ezrashaw and did a squash rebase onto upstream/master. I also noticed that the code example was missing the compiler error message annotation, so I added that and removed E0464 from the list of documentation that does not include a code example.

[bors]

☔ The latest upstream changes (presumably #107679) made this pull request unmergeable. Please resolve the merge conflicts.

[GuillaumeGomez]

Since @compiler-errors already approved the compiler changes, then we can approve the PR. Thanks for working on this!

@bors r=compiler-errors,GuillaumeGomez rollup

[bors]

📌 Commit 2bcd4e2 has been approved by compiler-errors,GuillaumeGomez

It is now in the queue for this repository.

[jyn514]

hey, I managed to hit error E0523 😄

error: internal compiler error: compiler/rustc_metadata/src/creader.rs:352:17: Previously returned E0523 here. See https://github.com/rust-lang/rust/pull/100599 for additional discussion.root.name() = core.

thread 'rustc' panicked at 'Box<dyn Any>', /rustc/b955c8271da80a1af8a1d54c4e1bbdaf51b032e9/compiler/rustc_errors/src/lib.rs:1644:9
stack backtrace:
   0: std::panicking::begin_panic::<rustc_errors::ExplicitBug>
   1: std::panic::panic_any::<rustc_errors::ExplicitBug>
   2: <rustc_errors::HandlerInner>::bug::<&alloc::string::String>
   3: <rustc_errors::Handler>::bug::<&alloc::string::String>
   4: rustc_middle::util::bug::opt_span_bug_fmt::<rustc_span::span_encoding::Span>::{closure#0}
   5: rustc_middle::ty::context::tls::with_opt::<rustc_middle::util::bug::opt_span_bug_fmt<rustc_span::span_encoding::Span>::{closure#0}, !>::{closure#0}
   6: rustc_middle::ty::context::tls::with_context_opt::<rustc_middle::ty::context::tls::with_opt<rustc_middle::util::bug::opt_span_bug_fmt<rustc_span::span_encoding::Span>::{closure#0}, !>::{closure#0}, !>
   7: rustc_middle::util::bug::opt_span_bug_fmt::<rustc_span::span_encoding::Span>
   8: rustc_middle::util::bug::bug_fmt
   9: <rustc_metadata::creader::CrateLoader>::maybe_resolve_crate
  10: <rustc_metadata::creader::CrateLoader>::maybe_resolve_crate
  11: <rustc_metadata::creader::CrateLoader>::resolve_crate
  12: <rustc_metadata::creader::CrateLoader>::process_extern_crate
  13: <rustc_resolve::Resolver>::crate_loader::<core::option::Option<rustc_span::def_id::CrateNum>, <rustc_resolve::build_reduced_graph::BuildReducedGraphVisitor>::build_reduced_graph_for_extern_crate::{closure#0}>
  14: <rustc_resolve::build_reduced_graph::BuildReducedGraphVisitor as rustc_ast::visit::Visitor>::visit_item
  15: <rustc_resolve::Resolver as rustc_expand::base::ResolverExpand>::visit_ast_fragment_with_placeholders
  16: <rustc_expand::expand::MacroExpander>::fully_expand_fragment
  17: <rustc_expand::expand::MacroExpander>::expand_crate
  18: <rustc_session::session::Session>::time::<rustc_ast::ast::Crate, rustc_interface::passes::configure_and_expand::{closure#1}>
  19: rustc_interface::passes::resolver_for_lowering
  20: rustc_query_system::query::plumbing::try_execute_query::<rustc_query_impl::queries::resolver_for_lowering, rustc_query_impl::plumbing::QueryCtxt>
  21: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::resolver_for_lowering
  22: <rustc_middle::ty::context::GlobalCtxt>::enter::<rustc_driver_impl::run_compiler::{closure#1}::{closure#2}::{closure#2}, &rustc_data_structures::steal::Steal<(rustc_middle::ty::ResolverAstLowering, alloc::rc::Rc<rustc_ast::ast::Crate>)>>
  23: rustc_span::with_source_map::<core::result::Result<(), rustc_span::ErrorGuaranteed>, rustc_interface::interface::run_compiler<core::result::Result<(), rustc_span::ErrorGuaranteed>, rustc_driver_impl::run_compiler::{closure#1}>::{closure#0}::{closure#0}>
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.69.0-beta.1 (b955c8271 2023-03-06) running on x86_64-unknown-linux-gnu

note: compiler flags: -C opt-level=3 -C embed-bitcode=no -C debuginfo=0 -Z unstable-options -C incremental=[REDACTED] -C symbol-mangling-version=legacy -Z unstable-options -Z unstable-options -Z macro-backtrace -C link-args=-Wl,-z,origin -C link-args=-Wl,-rpath,$ORIGIN/../lib -C split-debuginfo=off -C prefer-dynamic -C llvm-args=-import-instr-limit=10 -Z inline-mir -C lto=off -Z crate-attr=doc(html_root_url="https://doc.rust-lang.org/nightly/") -Z panic_abort_tests -Z binary-dep-depinfo -Z force-unstable-if-unmarked

note: some of the compiler flags provided by cargo are hidden

query stack during panic:
#0 [resolver_for_lowering] getting the resolver for lowering
end of query stack
error: could not compile `alloc`

Reproduction steps:

1. Check out b3ee81a
2. Apply this diff (e.g. with git apply):

diff --git a/src/bootstrap/builder.rs b/src/bootstrap/builder.rs
index 608b4c4d245..0bf7f245518 100644
--- a/src/bootstrap/builder.rs
+++ b/src/bootstrap/builder.rs
@@ -2202,6 +2202,17 @@ pub struct Cargo {
 }
 
 impl Cargo {
+    /// NOTE: avoid this in favor of `builder.cargo` where possible.
+    pub fn from_cmd(command: Command, target: TargetSelection) -> Cargo {
+        let rustflags = Rustflags::new(target);
+        Cargo {
+            command,
+            rustdocflags: rustflags.clone(),
+            rustflags,
+            allow_features: String::new(),
+        }
+    }
+
     pub fn rustdocflag(&mut self, arg: &str) -> &mut Cargo {
         self.rustdocflags.arg(arg);
         self
diff --git a/src/bootstrap/test.rs b/src/bootstrap/test.rs
index 9540adea189..7c7e6100424 100644
--- a/src/bootstrap/test.rs
+++ b/src/bootstrap/test.rs
@@ -2035,7 +2035,7 @@ fn run(self, builder: &Builder<'_>) {
 ///
 /// Returns whether the test succeeded.
 fn run_cargo_test(
-    cargo: impl Into<Command>,
+    cargo: crate::builder::Cargo,
     libtest_args: &[&str],
     crates: &[Interned<String>],
     primary_crate: &str,
@@ -2051,7 +2051,7 @@ fn run_cargo_test(
 
 /// Given a `cargo test` subcommand, pass it the appropriate test flags given a `builder`.
 fn prepare_cargo_test(
-    cargo: impl Into<Command>,
+    mut cargo: crate::builder::Cargo,
     libtest_args: &[&str],
     crates: &[Interned<String>],
     primary_crate: &str,
@@ -2059,8 +2059,6 @@ fn prepare_cargo_test(
     target: TargetSelection,
     builder: &Builder<'_>,
 ) -> Command {
-    let mut cargo = cargo.into();
-
     // Pass in some standard flags then iterate over the graph we've discovered
     // in `cargo metadata` with the maps above and figure out what `-p`
     // arguments need to get passed.
@@ -2078,6 +2076,9 @@ fn prepare_cargo_test(
                 .unwrap_or_else(|| panic!("missing crate {primary_crate}"));
             if krate.has_lib {
                 cargo.arg("--lib");
+                if crates.iter().any(|c| c != "panic_abort") {
+                    cargo.rustflag("-Zpanic_abort_tests");
+                }
             }
             cargo.args(&["--bins", "--examples", "--tests", "--benches"]);
         }
@@ -2118,7 +2119,7 @@ fn prepare_cargo_test(
         );
     }
 
-    cargo
+    cargo.into()
 }
 
 #[derive(Debug, Clone, PartialEq, Eq, PartialOrd, Ord, Hash)]
@@ -2518,7 +2519,7 @@ fn run(self, builder: &Builder<'_>) {
         }
         // rustbuild tests are racy on directory creation so just run them one at a time.
         // Since there's not many this shouldn't be a problem.
-        run_cargo_test(cmd, &["--test-threads=1"], &[], "bootstrap", compiler, host, builder);
+        run_cargo_test(crate::builder::Cargo::from_cmd(cmd, host), &["--test-threads=1"], &[], "bootstrap", compiler, host, builder);
     }
 
     fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> {

3. Run x test --stage 0 --no-doc library/alloc.

[jyn514]

If it helps, I see --extern core=/home/jyn/src/rust3/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/libcore-999232a2b2133b8a.rlib in the arguments passed to rustc, and I think I have some bootstrap bug that recompiles unnecessarily because I see "Dirty alloc v0.0.0 (/home/jyn/src/rust3/library/alloc): the rustflags changed" just above the ICE.

[jyn514]

Some relevant debug logging:

INFO rustc_metadata::creader resolving crate `core`
INFO rustc_metadata::creader falling back to a load
INFO rustc_metadata::locator rlib reading metadata from: /home/jyn/src/rust3/build/x86_64-unknown-linux-gnu/stage0-std/x86_64
-unknown-linux-gnu/release/deps/libcore-999232a2b2133b8a.rlib
INFO rustc_metadata::creader register crate `core` (cnum = 1. private_dep = false)
INFO rustc_metadata::creader resolving dep crate core hash: `34298ac765912203` extra filename: `-999232a2b2133b8a`
INFO rustc_metadata::creader resolving crate `core`
INFO rustc_metadata::creader falling back to a load
INFO rustc_metadata::locator lib candidate: /home/jyn/src/rust3/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linu
x-gnu/release/deps/libcore-999232a2b2133b8a.rlib
INFO rustc_metadata::locator lib candidate: /home/jyn/src/rust3/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linu
x-gnu/release/deps/libcore-999232a2b2133b8a.rmeta
INFO rustc_metadata::locator lib candidate: /home/jyn/src/rust3/build/x86_64-unknown-linux-gnu/stage0-sysroot/lib/rustlib/x86
_64-unknown-linux-gnu/lib/libcore-999232a2b2133b8a.rlib
INFO rustc_metadata::locator rmeta reading metadata from: /home/jyn/src/rust3/build/x86_64-unknown-linux-gnu/stage0-std/x86_6
4-unknown-linux-gnu/release/deps/libcore-999232a2b2133b8a.rmeta
INFO rustc_metadata::locator Rejecting via hash: expected 34298ac765912203 got 028056f371feafa5
INFO rustc_metadata::locator metadata mismatch
INFO rustc_metadata::locator rlib reading metadata from: /home/jyn/src/rust3/build/x86_64-unknown-linux-gnu/stage0-sysroot/li
b/rustlib/x86_64-unknown-linux-gnu/lib/libcore-999232a2b2133b8a.rlib
INFO rustc_metadata::locator rlib reading metadata from: /home/jyn/src/rust3/build/x86_64-unknown-linux-gnu/stage0-std/x86_64
-unknown-linux-gnu/release/deps/libcore-999232a2b2133b8a.rlib
INFO rustc_metadata::locator Rejecting via hash: expected 34298ac765912203 got 028056f371feafa5
INFO rustc_metadata::locator metadata mismatch
INFO rustc_metadata::creader register crate `core` (cnum = 5. private_dep = false)
error: internal compiler error: compiler/rustc_metadata/src/creader.rs:352:17: Previously returned E0523 here. See https://github.com/rust-lang/rust/pull/100599 for additional discussion.root.name() = core.

From glancing at the error description, maybe this is a cargo bug and -Zpanic_abort_tests in RUSTFLAGS isn't being hashed?

[Ezrashaw]

@jyn514 Could you open an issue or a Zulip thread please (and ping me)? IIRC, the author did a lot of searching for cases and they had all moved to E0464 so this might be a cargo bug.

[jyn514]

@Ezrashaw https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/E0523.2C.20back.20from.20the.20grave.20.23100599