"No counters provided the source_hash for used function" when compiling with -Z instrument-coverage

[rajivshah3]

Code

Will try to put together a minimal example, but it's currently occurring with https://github.com/iotaledger/wallet.rs

<code>

Meta

rustc --version --verbose:

rustc 1.54.0-nightly (881c1ac40 2021-05-08)
binary: rustc
commit-hash: 881c1ac408d93bb7adaa3a51dabab9266e82eee8
commit-date: 2021-05-08
host: x86_64-apple-darwin
release: 1.54.0-nightly
LLVM version: 12.0.0

Error output

thread 'rustc' panicked at 'No counters provided the source_hash for used function: Instance { def: DropGlue(DefId(2:2347 ~ core[8495]::ptr::drop_in_place), Some([static generator@/Users/rajiv/.cargo/registry/src/gitpro.ttaallkk.top-1ecc6299db9ec823/tokio-1.5.0/src/sync/watch.rs:258:69: 272:6 for<'r, 's> {std::future::ResumeTy, &'r mut sync::watch::Receiver<()>, sync::notify::Notified<'s>, ()}])), substs: [[static generator@/Users/rajiv/.cargo/registry/src/gitpro.ttaallkk.top-1ecc6299db9ec823/tokio-1.5.0/src/sync/watch.rs:258:69: 272:6 for<'r, 's> {std::future::ResumeTy, &'r mut sync::watch::Receiver<()>, sync::notify::Notified<'s>, ()}]] }', compiler/rustc_codegen_ssa/src/coverageinfo/map.rs:147:9

Backtrace

thread 'rustc' panicked at 'No counters provided the source_hash for used function: Instance { def: DropGlue(DefId(2:2347 ~ core[8495]::ptr::drop_in_place), Some([static generator@/Users/rajiv/.cargo/registry/src/gitpro.ttaallkk.top-1ecc6299db9ec823/tokio-1.5.0/src/sync/watch.rs:258:69: 272:6 for<'r, 's> {std::future::ResumeTy, &'r mut sync::watch::Receiver<()>, sync::notify::Notified<'s>, ()}])), substs: [[static generator@/Users/rajiv/.cargo/registry/src/gitpro.ttaallkk.top-1ecc6299db9ec823/tokio-1.5.0/src/sync/watch.rs:258:69: 272:6 for<'r, 's> {std::future::ResumeTy, &'r mut sync::watch::Receiver<()>, sync::notify::Notified<'s>, ()}]] }', compiler/rustc_codegen_ssa/src/coverageinfo/map.rs:147:9
stack backtrace:
   0: _rust_begin_unwind
   1: std::panicking::begin_panic_fmt
   2: rustc_codegen_ssa::coverageinfo::map::FunctionCoverage::get_expressions_and_counter_regions
   3: rustc_codegen_llvm::coverageinfo::mapgen::finalize
   4: rustc_codegen_llvm::base::compile_codegen_unit::module_codegen
   5: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task
   6: rustc_codegen_llvm::base::compile_codegen_unit
   7: rustc_codegen_ssa::base::codegen_crate
   8: <rustc_codegen_llvm::LlvmCodegenBackend as rustc_codegen_ssa::traits::backend::CodegenBackend>::codegen_crate
   9: rustc_interface::passes::QueryContext::enter
  10: rustc_interface::queries::Queries::ongoing_codegen
  11: rustc_interface::queries::<impl rustc_interface::interface::Compiler>::enter
  12: rustc_span::with_source_map
  13: rustc_interface::interface::create_compiler_and_run
  14: scoped_tls::ScopedKey<T>::set
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose 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.54.0-nightly (881c1ac40 2021-05-08) running on x86_64-apple-darwin

note: compiler flags: -Z instrument-coverage -C embed-bitcode=no -C split-debuginfo=unpacked -C debuginfo=2 --crate-type lib

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

query stack during panic:
end of query stack

[ririsoft]

I have the same issue compiling tokio-util 0.6.6

OS: Windows 10.0.18363

❯ rustc +nightly --version --verbose
rustc 1.54.0-nightly (ca82264ec 2021-05-09)
binary: rustc
commit-hash: ca82264ec7556a6011b9d3f1b2fd4c7cd0bc8ae2
commit-date: 2021-05-09
host: x86_64-pc-windows-msvc
release: 1.54.0-nightly
LLVM version: 12.0.1

cargo +nightly build        
   Compiling tokio v1.5.0
   Compiling tokio-util v0.6.6
thread 'rustc' panicked at 'No counters provided the source_hash for used function: Instance { def: DropGlue(DefId(2:2347 ~ core[d23b]::ptr::drop_in_place), Some([static generator@tokio::sync::Semaphore::acquire_owned::{closure#0} for<'r, 's> {std::future::ResumeTy, std::sync::Arc<tokio::sync::Semaphore>, tokio::sync::Semaphore, &'r tokio::sync::batch_semaphore::Semaphore, tokio::sync::batch_semaphore::Semaphore, u32, tokio::sync::batch_semaphore::Acquire<'s>, ()}])), substs: [[static generator@tokio::sync::Semaphore::acquire_owned::{closure#0} for<'r, 's> {std::future::ResumeTy, std::sync::Arc<tokio::sync::Semaphore>, tokio::sync::Semaphore, &'r tokio::sync::batch_semaphore::Semaphore, tokio::sync::batch_semaphore::Semaphore, u32, tokio::sync::batch_semaphore::Acquire<'s>, ()}]] }', compiler\rustc_codegen_ssa\src\coverageinfo\map.rs:147:9

Backtrace

stack backtrace:
   0:     0x7ffd960b5d2e - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h65f771762210e3e5
   1:     0x7ffd960de84c - core::fmt::write::h3d73561f801c6731
   2:     0x7ffd960a9888 - <std::io::IoSlice as core::fmt::Debug>::fmt::h6fd08a0ca4059bc8
   3:     0x7ffd960b9de2 - std::panicking::take_hook::ha49dee799706a2d8
   4:     0x7ffd960b98d4 - std::panicking::take_hook::ha49dee799706a2d8
   5:     0x7ffd7303be57 - rustc_driver::report_ice::h85377e4dc53c89a8
   6:     0x7ffd960ba5c5 - std::panicking::rust_panic_with_hook::h9e7cc259d68b1de2
   7:     0x7ffd960ba1a1 - rust_begin_unwind
   8:     0x7ffd960b667f - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h65f771762210e3e5
   9:     0x7ffd960ba0f9 - rust_begin_unwind
  10:     0x7ffd9611201c - std::panicking::begin_panic_fmt::h6be4566f1d66379f
  11:     0x7ffd765a9140 - rustc_codegen_ssa::coverageinfo::map::FunctionCoverage::get_expressions_and_counter_regions::h5459bf7c73688deb
  12:     0x7ffd73256072 - <rustc_codegen_llvm::llvm_::ObjectFile as core::ops::drop::Drop>::drop::hfb1ea7ee5c5da4b8
  13:     0x7ffd73302a75 - <rustc_codegen_llvm::base::ValueIter as core::iter::traits::iterator::Iterator>::next::ha01d740fab69f46b
  14:     0x7ffd732ba777 - <rustc_codegen_llvm::back::lto::ThinLTOKeysMap as core::fmt::Debug>::fmt::hc8b79cef3f320fc8
  15:     0x7ffd73302211 - <rustc_codegen_llvm::base::ValueIter as core::iter::traits::iterator::Iterator>::next::ha01d740fab69f46b
  16:     0x7ffd732b406e - <rustc_codegen_llvm::LlvmCodegenBackend as rustc_codegen_ssa::traits::backend::CodegenBackend>::codegen_crate::h1fc5f21611e540fb
  17:     0x7ffd731761a2 - rustc_interface::passes::BoxedResolver::to_resolver_outputs::hd59e13590b9f5648
  18:     0x7ffd7318ec56 - rustc_interface::queries::Queries::ongoing_codegen::h7c88f490e7bc85a6
  19:     0x7ffd73046627 - rustc_driver::pretty::print_after_hir_lowering::h7bca709356dc8324
  20:     0x7ffd7303eb6c - <rustc_driver::Compilation as core::fmt::Debug>::fmt::hf06cd1d1b5fda44d
  21:     0x7ffd73047906 - rustc_driver::pretty::print_after_hir_lowering::h7bca709356dc8324
  22:     0x7ffd7306d9f4 - <rustc_span::symbol::SymbolStr as core::fmt::Display>::fmt::h2eaf6a8c0589bd7e
  23:     0x7ffd730702bf - <rustc_span::symbol::SymbolStr as core::fmt::Display>::fmt::h2eaf6a8c0589bd7e
  24:     0x7ffd7307a8fd - <rustc_span::symbol::SymbolStr as core::fmt::Display>::fmt::h2eaf6a8c0589bd7e
  25:     0x7ffd960c7f8a - std::sys::windows::thread::Thread::new::h35832c8baf769397
  26:     0x7ffdfc8f7c24 - BaseThreadInitThunk
  27:     0x7ffdfd40d721 - RtlUserThreadStart

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.54.0-nightly (ca82264ec 2021-05-09) running on x86_64-pc-windows-msvc

note: compiler flags: -Z instrument-coverage -C embed-bitcode=no -C debuginfo=2 --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 `tokio-util`

[philippgl]

The issue #85213 has some minimal code. (And I think, its a duplicate)

It first occurs with the nightly-2021-05-08-x86_64-unknown-linux-gnu toolchain. nightly-2021-05-07-x86_64-unknown-linux-gnu still works. I am unsure how to specify the version number correctly, but this is what rustup tells me. (text copied from my comment in the other issue)

If someone wants to do the git bisect:
good: 676ee14, bad: 770792f

[richkadel]

This is a duplicate of known issue reported here: #85081 and the change that caused it was reverted. The next nightly should resolve the problem.

[ririsoft]

I confirm the bug is fixed with

❯ rustc +nightly --version --verbose
rustc 1.54.0-nightly (3e99439f4 2021-05-17)
binary: rustc
commit-hash: 3e99439f4dacc8ba0d2ca48d221694362d587927
commit-date: 2021-05-17
host: x86_64-pc-windows-msvc
release: 1.54.0-nightly
LLVM version: 12.0.1

Thanks a lot @richkadel for all your work here !

However I now have a linking with link.exe failed: exit code: 1227 issue:

libregex_syntax-2f26d769a1c70068.rlib(regex_syntax-2f26d769a1c70068.regex_syntax.dktc813v-cgu.8.rcgu.o) : fatal error LNK1227: conflicting 
weak extern definition for '_RNvYpNtNtNtCseoqqqEklHuS_12regex_syntax3ast7visitor7Visitor10visit_postB9_'.  New default '.weak._RNvYpNtNtNtCseoqqqEklHuS_12regex_syntax3ast7visitor7Visitor10visit_postB9_.default._RINvMNtNtCs93I3MPx9COt_4core3ptr9const_ptrPNtNtNtCseoqqqEklHuS_12regex_syntax3ast5parse10ClassState4castuEBL_' conflicts with old default '.weak._RNvYpNtNtNtCseoqqqEklHuS_12regex_syntax3ast7visitor7Visitor10visit_postB9_.default._RINvMNtCs93I3MPx9COt_4core6optionINtB3_6OptionINtNtNtB5_3ptr8non_null7NonNullhEE5ok_orNtNtB5_5alloc10AllocErrorECseoqqqEklHuS_12regex_syntax' in libregex_syntax-2f26d769a1c70068.rlib(regex_syntax-2f26d769a1c70068.regex_syntax.dktc813v-cgu.6.rcgu.o)

It only raises when compiling with RUSTFLAGS = "-Z instrument-coverage".

❯ cargo +nightly tree -i regex-syntax
regex-syntax v0.6.25
├── regex v1.5.4
│   └── tracing-subscriber v0.2.18
│       └── proximum v0.1.0 (C:\Users\cdadhemar\Documents\Code\proximum)
└── regex-automata v0.1.9
    └── matchers v0.0.1
        └── tracing-subscriber v0.2.18 (*)

Do you believe this deserve a dedicated bug report or I am doing something wrong here (should use another linker on windows ?), please ?

[richkadel]

@ririsoft - That is definitely a different bug report.

I don't know what that's about. You might try compiling with one of the -Zinstrument-coverage=<value> options, to disable generating coverage for dead code. I don't know if it will make a difference, but I do use weak linkage when creating the function stubs for dead code.

Whatever your results, please report them in a separate issue along with your description above.

Thanks!

[richkadel]

@rajivshah3 - You should be able to confirm with the latest nightly that this issue is fixed. Thanks!

[rajivshah3]

Yep, fixed! Thanks so much @richkadel!

[ririsoft]

@ririsoft - That is definitely a different bug report.

I don't know what that's about. You might try compiling with one of the -Zinstrument-coverage=<value> options, to disable generating coverage for dead code. I don't know if it will make a difference, but I do use weak linkage when creating the function stubs for dead code.

Whatever your results, please report them in a separate issue along with your description above.

Thanks!

Thank you @richkadel, #85461 opened.