Found unstable fingerprints for exported_symbols with custom target

[iliakonnov]

First of all, this is known issue (unstable fingerprints, #84970), I'm just adding another case.

Code

1. Create minimal no_std application. See smallest no_std for example.

   Code

   #![no_main]
   #![no_std]
   #![feature(lang_items)]
   
   use core::panic::PanicInfo;
   
   #[panic_handler]
   fn panic(_panic: &PanicInfo<'_>) -> ! {
       loop {}
   }
   
   #[lang = "eh_personality"]
   extern "C" fn eh_personality() {}
   

   Details

2. Create custom target specification based on built-in x86_64-unknown-none:

   rustc -Z unstable-options --print target-spec-json --target x86_64-unknown-none > x86_64-custom.json
   sed -i 's/"is-builtin": true/"is-builtin": false/' x86_64-custom.json
   

3. cargo build --target x86_64-custom.json -Zbuild-std=core

4. Change "panic-behaviour": "abort" to "panic-behaviour": "unwind" in x86_64-custom.json

5. cargo build --target x86_64-custom.json -Zbuild-std=core will fail

Note: I have a minimal repository with all these steps done

Meta

rustc 1.59.0-nightly (83b15bfe1 2021-12-28)
binary: rustc
commit-hash: 83b15bfe1c15f325bc186ebfe3691b729ed59f2b
commit-date: 2021-12-28
host: x86_64-unknown-linux-gnu
release: 1.59.0-nightly
LLVM version: 13.0.0

Error output

I've omitted part of error since it is enormous. Full log available here.

error: internal compiler error: encountered incremental compilation error with exported_symbols(core[32cd])
  |
  = help: This is a known issue with the compiler. Run `cargo clean -p minimal` or `cargo clean` to allow your project to compile
  = note: Please follow the instructions below to create a bug report with the provided information
  = note: See <https://github.com/rust-lang/rust/issues/84970> for more information

thread 'rustc' panicked at 'Found unstable fingerprints for exported_symbols(core[32cd]): [ …omitted… ]', compiler/rustc_query_system/src/query/plumbing.rs:675:9
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.59.0-nightly (83b15bfe1 2021-12-28) running on x86_64-unknown-linux-gnu
note: compiler flags: -Z unstable-options -C embed-bitcode=no -C debuginfo=2 -C incremental --crate-type bin
note: some of the compiler flags provided by cargo are hidden

query stack during panic:
#0 [exported_symbols] exported_symbols
end of query stack
error: could not compile `minimal` due to previous error

Caused by:
  process didn't exit successfully: `rustc --crate-name minimal --edition=2018 src/main.rs --error-format=json --json=diagnostic-rendered-ansi,future-incompat --crate-type bin --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 -C metadata=17370ef95f3ae4d6 -C extra-filename=-17370ef95f3ae4d6 --out-dir /home/ilia/Documents/asos/minimal/target/x86_64-custom/debug/deps --target /home/ilia/Documents/asos/minimal/x86_64-custom.json -C incremental=/home/ilia/Documents/asos/minimal/target/x86_64-custom/debug/incremental -L dependency=/home/ilia/Documents/asos/minimal/target/x86_64-custom/debug/deps -L dependency=/home/ilia/Documents/asos/minimal/target/debug/deps --extern 'noprelude:compiler_builtins=/home/ilia/Documents/asos/minimal/target/x86_64-custom/debug/deps/libcompiler_builtins-253f3d368d5adfbe.rlib' --extern 'noprelude:core=/home/ilia/Documents/asos/minimal/target/x86_64-custom/debug/deps/libcore-3e5d30ea51ef9363.rlib' -Z unstable-options` (exit status: 101)

Backtrace

stack backtrace:
   0: rust_begin_unwind
             at /rustc/83b15bfe1c15f325bc186ebfe3691b729ed59f2b/library/std/src/panicking.rs:498:5
   1: core::panicking::panic_fmt
             at /rustc/83b15bfe1c15f325bc186ebfe3691b729ed59f2b/library/core/src/panicking.rs:107:14
   2: rustc_query_system::query::plumbing::incremental_verify_ich_cold
   3: rustc_query_system::query::plumbing::incremental_verify_ich::<rustc_query_impl::plumbing::QueryCtxt, rustc_span::def_id::CrateNum, &[(rustc_middle::middle::exported_symbols::ExportedSymbol, rustc_middle::middle::exported_symbols::SymbolExportLevel)]>
   4: rustc_query_system::query::plumbing::try_load_from_disk_and_cache_in_memory::<rustc_query_impl::plumbing::QueryCtxt, rustc_span::def_id::CrateNum, &[(rustc_middle::middle::exported_symbols::ExportedSymbol, rustc_middle::middle::exported_symbols::SymbolExportLevel)]>
   5: rustc_query_system::query::plumbing::try_execute_query::<rustc_query_impl::plumbing::QueryCtxt, rustc_query_system::query::caches::DefaultCache<rustc_span::def_id::CrateNum, &[(rustc_middle::middle::exported_symbols::ExportedSymbol, rustc_middle::middle::exported_symbols::SymbolExportLevel)]>>
   6: rustc_query_system::query::plumbing::get_query::<rustc_query_impl::queries::exported_symbols, rustc_query_impl::plumbing::QueryCtxt>
   7: rustc_codegen_ssa::back::linker::exported_symbols
   8: <core::iter::adapters::map::Map<core::slice::iter::Iter<rustc_session::config::CrateType>, <rustc_codegen_ssa::CrateInfo>::new::{closure#0}> as core::iter::traits::iterator::Iterator>::fold::<(), core::iter::traits::iterator::Iterator::for_each::call<(rustc_session::config::CrateType, alloc::vec::Vec<alloc::string::String>), <hashbrown::map::HashMap<rustc_session::config::CrateType, alloc::vec::Vec<alloc::string::String>, core::hash::BuildHasherDefault<rustc_hash::FxHasher>> as core::iter::traits::collect::Extend<(rustc_session::config::CrateType, alloc::vec::Vec<alloc::string::String>)>>::extend<core::iter::adapters::map::Map<core::slice::iter::Iter<rustc_session::config::CrateType>, <rustc_codegen_ssa::CrateInfo>::new::{closure#0}>>::{closure#0}>::{closure#0}>
   9: <rustc_codegen_ssa::CrateInfo>::new
  10: rustc_codegen_ssa::back::write::start_async_codegen::<rustc_codegen_llvm::LlvmCodegenBackend>
  11: <rustc_codegen_llvm::LlvmCodegenBackend as rustc_codegen_ssa::traits::backend::CodegenBackend>::codegen_crate
  12: <rustc_session::session::Session>::time::<alloc::boxed::Box<dyn core::any::Any>, rustc_interface::passes::start_codegen::{closure#0}>
  13: <rustc_interface::queries::Queries>::ongoing_codegen
  14: <rustc_interface::interface::Compiler>::enter::<rustc_driver::run_compiler::{closure#1}::{closure#2}, core::result::Result<core::option::Option<rustc_interface::queries::Linker>, rustc_errors::ErrorReported>>
  15: rustc_span::with_source_map::<core::result::Result<(), rustc_errors::ErrorReported>, rustc_interface::interface::create_compiler_and_run<core::result::Result<(), rustc_errors::ErrorReported>, rustc_driver::run_compiler::{closure#1}>::{closure#1}>
  16: rustc_interface::interface::create_compiler_and_run::<core::result::Result<(), rustc_errors::ErrorReported>, rustc_driver::run_compiler::{closure#1}>
  17: <scoped_tls::ScopedKey<rustc_span::SessionGlobals>>::set::<rustc_interface::util::setup_callbacks_and_run_in_thread_pool_with_globals<rustc_interface::interface::run_compiler<core::result::Result<(), rustc_errors::ErrorReported>, rustc_driver::run_compiler::{closure#1}>::{closure#0}, core::result::Result<(), rustc_errors::ErrorReported>>::{closure#0}::{closure#0}, core::result::Result<(), rustc_errors::ErrorReported>>
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

This requires nightly since it uses -Zbuild-std=core which is not stable
@rustbot requires-nightly A-incr-comp

[Aaron1011]

When a custom target triple is in use, we only hash the path to the JSON file, not the actual contents:

rust/compiler/rustc_target/src/spec/mod.rs

Lines 2364 to 2369 in 78fd0f6

	/// Either a target triple string or a path to a JSON file.
	#[derive(PartialEq, Clone, Debug, Hash, Encodable, Decodable)]
	pub enum TargetTriple {
	TargetTriple(String),
	TargetPath(PathBuf),
	}

Since custom targets are (as far as I know) permanently unstable, I don't think this urgently needs a fix. If you're working on a custom target, you can run cargo clean for now after modifying the target spec.

[bjorn3]

As of #98225 the Hash impl now looks at the file contents instead of the file path. @iliakonnov have you seen this in the past couple of months?

[bjorn3]

I'm going to assume that this was fixed by #98225. Feel free to re-open if you see it again.