error: internal compiler error: unexpected panic: Failed to get crate data for crate21

[T0mstone]

Code

See here.

Meta

rustc --version --verbose:

rustc 1.52.1 (9bc8c42bb 2021-05-09)
binary: rustc
commit-hash: 9bc8c42bb2f19e745a63f3445f1ac248fb015e53
commit-date: 2021-05-09
host: x86_64-unknown-linux-gnu
release: 1.52.1
LLVM version: 12.0.0

This bug also persists in beta and nightly:

rustc 1.53.0-beta.2 (4bac69dd2 2021-05-07)
binary: rustc
commit-hash: 4bac69dd25089dd2f803f24de2225d84449b6220
commit-date: 2021-05-07
host: x86_64-unknown-linux-gnu
release: 1.53.0-beta.2
LLVM version: 12.0.0

rustc 1.54.0-nightly (8cf990c9b 2021-05-15)
binary: rustc
commit-hash: 8cf990c9b5c59f25c806fad9f4466f9d6509bbea
commit-date: 2021-05-15
host: x86_64-unknown-linux-gnu
release: 1.54.0-nightly
LLVM version: 12.0.1

Error output

thread 'rustc' panicked at 'Failed to get crate data for crate20', compiler/rustc_metadata/src/creader.rs:136:32
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

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.52.1 (9bc8c42bb 2021-05-09) running on x86_64-unknown-linux-gnu

note: compiler flags: -C embed-bitcode=no -C debuginfo=2 -C incremental --crate-type lib

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

query stack during panic:
end of query stack
error: could not compile `graphite-editor-core`

On different invokations the crate20 has also been crate21

Backtrace

stack backtrace:
   0: rust_begin_unwind
             at /rustc/9bc8c42bb2f19e745a63f3445f1ac248fb015e53/library/std/src/panicking.rs:493:5
   1: std::panicking::begin_panic_fmt
             at /rustc/9bc8c42bb2f19e745a63f3445f1ac248fb015e53/library/std/src/panicking.rs:435:5
   2: rustc_metadata::creader::CrateLoader::maybe_resolve_crate
   3: rustc_metadata::creader::CrateLoader::maybe_process_path_extern
   4: rustc_resolve::Resolver::extern_prelude_get
   5: rustc_resolve::macros::<impl rustc_resolve::Resolver>::early_resolve_ident_in_lexical_scope
   6: rustc_resolve::Resolver::resolve_path_with_ribs::{{closure}}
   7: rustc_resolve::Resolver::resolve_path_with_ribs
   8: rustc_resolve::imports::ImportResolver::resolve_imports
   9: rustc_resolve::macros::<impl rustc_expand::base::ResolverExpand for rustc_resolve::Resolver>::resolve_imports
  10: rustc_expand::expand::MacroExpander::fully_expand_fragment
  11: rustc_expand::expand::MacroExpander::expand_crate
  12: rustc_session::utils::<impl rustc_session::session::Session>::time
  13: rustc_interface::passes::configure_and_expand_inner
  14: rustc_interface::passes::configure_and_expand::{{closure}}
  15: rustc_data_structures::box_region::PinnedGenerator<I,A,R>::new
  16: rustc_interface::passes::configure_and_expand
  17: rustc_interface::queries::Queries::expansion
  18: rustc_interface::queries::<impl rustc_interface::interface::Compiler>::enter
  19: rustc_span::with_source_map
  20: rustc_interface::interface::create_compiler_and_run
  21: scoped_tls::ScopedKey<T>::set

[TrueDoctor]

This issue only occurs when compiling to wasm32-unknown-unknown. Steps to reproduce:
cd core/editor
cargo build --target wasm32-unknown-unknown

[jonas-schievink]

@rustbot ping cleanup

[rustbot]

Hey Cleanup Crew ICE-breakers! This bug has been identified as a good
"Cleanup ICE-breaking candidate". In case it's useful, here are some
instructions for tackling these sorts of bugs. Maybe take a look?
Thanks! <3

cc @AminArria @camelid @chrissimpkins @contrun @DutchGhost @elshize @h-michael @HallerPatrick @hdhoang @hellow554 @henryboisdequin @imtsuki @JamesPatrickGill @kanru @KarlK90 @LeSeulArtichaut @MAdrianMattocks @matheus-consoli @mental32 @nmccarty @Noah-Kennedy @pard68 @PeytonT @pierreN @Redblueflame @RobbieClarken @RobertoSnap @robjtede @SarthakSingh31 @shekohex @sinato @smmalis37 @steffahn @Stupremee @tamuhey @turboladen @woshilapin @yerke

[TrueDoctor]

@jonas-schievink I started a bisect today and can confirm the issue existed for at least 3 months, but could not got further back because we use some newer rust features I have to replace, please let me know if I can help with anything (I'll try to work on a "minimal" code sample)

[TrueDoctor]

I did some initial code reduction that lives in the ice-debugging branch.
I also ran cargo bisect-rustc -v --target wasm32-unknown-unknown --regress ice --start=2018-02-05 --end=2021-05-17 -- build --target wasm32-unknown-unknown
which confirmed that the error existed since at least nightly-2019-12-30. Before then I got the error:

error[E0432]: unresolved import `proc_macro`
  --> /home/dennis/build/Graphite/proc-macro/src/lib.rs:13:5
   |
13 | use proc_macro::TokenStream;
   |     ^^^^^^^^^^ help: a similar path exists: `syn::proc_macro`

error: aborting due to previous error

This is indeed peculiar, reduced the falty code to:
proc-macro/src/lib.rs

use proc_macro::TokenStream;

#[proc_macro_derive(ToDiscriminant)]
pub fn derive_discriminant(_: TokenStream) -> TokenStream {
    TokenStream::new()
}

#[proc_macro_derive(TransitiveChild)]
pub fn derive_transitive_child(_: TokenStream) -> TokenStream {
    TokenStream::new()
}

editor/src/lib.rs

pub use proc_macros::{ToDiscriminant, TransitiveChild};

This causes the error when executing cargo check --target wasm32-unknown-unknown

[jonas-schievink]

That's interesting, so this bug existed since 2019? Something must have changed that made it show up much more often then.

[jonas-schievink]

Not sure how to handle this further so I'll defer to the prioritization folks