Still on nightly?

[frederikhors]

In a new project (and I still don't know what causes it) I'm having issues with cargo-clif that tells me: "Please fix this using cargo clean".

I think this is due to the usage in my VSCode of Rust Analyzer with all the default settings; maybe they're stepping on each other's toes in the target folder.

In fact cargo clean works, well temporarily until this happens again.

So the question: is there still a long time to wait to get cargo-clif working with stable instead of nightly?

Maybe this is a reason.

[frederikhors]

I'm using cargo-clif version:

cargo 1.70.0-nightly (4a3c588b1 2023-03-14)

I'll try latest dev release now.

[bjorn3]

I'm having issues with cargo-clif that tells me: "Please fix this using cargo clean".

You mean an internal compiler error? What is the full message?

is there still a long time to wait to get cargo-clif working with stable instead of nightly?

Yes. To get it to stable it will first have to be distributed with rustc on nightly (which I'm still working on) and after that at some point in the future when cg_clif is stable enough I could ask for it to be distributed on stable too. If that is accepted it will take another 6-12 weeks for the change to actually land on stable. I have no clue what the requirements would be to promote a codegen backend to stable. I don't think anyone knows right now as no new codegen backend has been added to stable rustc. To the best of my knowledge cg_clif has been the first non-LLVM backend that is actually usable. With cg_gcc being the second. (not counting rust-gpu which came between the two I believe as it is limited by spir-v limitations and only runs code on the gpu which adds limitations anyway)

[frederikhors]

What is the full message?

A lot of strings! I mean it burns all the buffer of my shell and the initial message is gone most of the times.

I'll write here ASAP if I can copy something useful.

[bjorn3]

If the ICE happens within cg_clif itself, PrintOnPanic prints a couple of things. One of these things is the full MIR of the function it is compiling. This can be very large. You could try commenting out https://github.com/bjorn3/rustc_codegen_cranelift/blob/fd4e1d55ea209dcdef728ef0a2d3a9541c25da16/src/base.rs#L37-L44 to see if that reduces verbosity.

[frederikhors]

I'm using the compiled exe. Anyway with latest dev in release the error hasn't appeared (yet).

[frederikhors]

Unfortunately the error is still here but I got it!

The below is the version without MIR (because it's too long and because it contains corporate info).

Compiling project_name v0.1.0 (C:\projects\project_name\src\crates\project_name)
error: internal compiler error: encountered incremental compilation error with exported_symbols(common[f0a3])
  |
  = help: This is a known issue with the compiler. Run `cargo clean -p project_name` 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(common[f0a3]): [(Generic(DefId(2:5761 ~ core[235d]::iter::adapters::fuse::{impl#2}::fold), [std::iter::Map<std::iter::Inspect<std::str::SplitWhitespace<'_>, ...........TOO LONG AND PRIVATE INFO HERE............. SymbolExportInfo { level: Rust, kind: Text, used: false })]', /rustc/17c11672167827b0dd92c88ef69f24346d1286dd\compiler\rustc_query_system\src\query\plumbing.rs:710:9
stack backtrace:
   0:     0x7ffd2bcf6a72 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h91f604f4ffa5801e
   1:     0x7ffd2bd34eab - core::fmt::write::hab634a7da6eda80f
   2:     0x7ffd2bcebe1a - <std::io::IoSliceMut as core::fmt::Debug>::fmt::hd4d7057f831cdf36
   3:     0x7ffd2bcf67bb - std::sys::common::alloc::realloc_fallback::h0462ecd6e4895a2b
   4:     0x7ffd2bcfa14a - std::panicking::default_hook::h11dda33d25b1c293
   5:     0x7ffd2bcf9db0 - std::panicking::default_hook::h11dda33d25b1c293
   6:     0x7ffd17a3b57e - rustc_driver_impl[80e6611556be2cef]::describe_lints
   7:     0x7ffd2bcfaa5f - std::panicking::rust_panic_with_hook::hbdafd2453062d848
   8:     0x7ffd2bcfa7be - <std::panicking::begin_panic_handler::StrPanicPayload as core::panic::BoxMeUp>::get::h65d2be1af01a551c
   9:     0x7ffd2bcf7719 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h91f604f4ffa5801e
  10:     0x7ffd2bcfa4d0 - rust_begin_unwind
  11:     0x7ffd2bd68ed5 - core::panicking::panic_fmt::hef645f8ef8eec178
  12:     0x7ffd198ae031 - <&[rustc_ast[c03cc9997dba8755]::ast::Attribute] as rustc_serialize[d95a6b06eb86861e]::serialize::Decodable<rustc_query_impl[d3aba5db8cad4e9d]::on_disk_cache::CacheDecoder>>::decode
  13:     0x7ffd15d26679 - <rustc_const_eval[5bc5628c60c7bc7b]::transform::check_consts::qualifs::CustomEq as rustc_const_eval[5bc5628c60c7bc7b]::transform::check_consts::qualifs::Qualif>::in_adt_inherently
  14:     0x7ffd15cc1e41 - <rustc_const_eval[5bc5628c60c7bc7b]::transform::check_consts::qualifs::CustomEq as rustc_const_eval[5bc5628c60c7bc7b]::transform::check_consts::qualifs::Qualif>::in_adt_inherently
  15:     0x7ffd15df0a2f - <&[rustc_span[e1ca11e9f2e7f58d]::symbol::Ident] as rustc_serialize[d95a6b06eb86861e]::serialize::Decodable<rustc_query_impl[d3aba5db8cad4e9d]::on_disk_cache::CacheDecoder>>::decode
  16:     0x7ffd15d648c9 - <rustc_query_impl[d3aba5db8cad4e9d]::Queries as rustc_middle[99c60881b72579c1]::ty::query::QueryEngine>::try_mark_green
  17:     0x7ffd174b3f21 - <rustc_span[e1ca11e9f2e7f58d]::symbol::Symbol as rustc_serialize[d95a6b06eb86861e]::serialize::Encodable<rustc_query_impl[d3aba5db8cad4e9d]::on_disk_cache::CacheEncoder>>::encode
  18:     0x7ffd1975220c - <rustc_mir_dataflow[14c115b8f4dc7204]::value_analysis::TrackElem as core[6789f58c749a42cb]::fmt::Debug>::fmt
  19:     0x7ffd19845ae0 - <&[rustc_ast[c03cc9997dba8755]::ast::Attribute] as rustc_serialize[d95a6b06eb86861e]::serialize::Decodable<rustc_query_impl[d3aba5db8cad4e9d]::on_disk_cache::CacheDecoder>>::decode
  20:     0x7ffd19742340 - <rustc_mir_dataflow[14c115b8f4dc7204]::value_analysis::TrackElem as core[6789f58c749a42cb]::fmt::Debug>::fmt
  21:     0x7ffd15e3a9eb - <&[rustc_span[e1ca11e9f2e7f58d]::symbol::Ident] as rustc_serialize[d95a6b06eb86861e]::serialize::Decodable<rustc_query_impl[d3aba5db8cad4e9d]::on_disk_cache::CacheDecoder>>::decode
  22:     0x7ffd15d613d1 - <rustc_query_impl[d3aba5db8cad4e9d]::Queries as rustc_middle[99c60881b72579c1]::ty::query::QueryEngine>::try_mark_green
  23:     0x7ffd15e5ee2b - rustc_codegen_ssa[27da7f5ed493f53f]::back::symbol_export::crates_export_threshold
  24:     0x7ffd15daff6b - <&[rustc_span[e1ca11e9f2e7f58d]::symbol::Ident] as rustc_serialize[d95a6b06eb86861e]::serialize::Decodable<rustc_query_impl[d3aba5db8cad4e9d]::on_disk_cache::CacheDecoder>>::decode
  25:     0x7ffd15d09e99 - <rustc_const_eval[5bc5628c60c7bc7b]::transform::check_consts::qualifs::CustomEq as rustc_const_eval[5bc5628c60c7bc7b]::transform::check_consts::qualifs::Qualif>::in_adt_inherently
  26:     0x7ffd15e41e0e - <&[rustc_span[e1ca11e9f2e7f58d]::symbol::Ident] as rustc_serialize[d95a6b06eb86861e]::serialize::Decodable<rustc_query_impl[d3aba5db8cad4e9d]::on_disk_cache::CacheDecoder>>::decode
  27:     0x7ffd15d61564 - <rustc_query_impl[d3aba5db8cad4e9d]::Queries as rustc_middle[99c60881b72579c1]::ty::query::QueryEngine>::try_mark_green
  28:     0x7ffd15e5f0ae - rustc_codegen_ssa[27da7f5ed493f53f]::back::symbol_export::crates_export_threshold
  29:     0x7ffd15dae05f - <&[rustc_span[e1ca11e9f2e7f58d]::symbol::Ident] as rustc_serialize[d95a6b06eb86861e]::serialize::Decodable<rustc_query_impl[d3aba5db8cad4e9d]::on_disk_cache::CacheDecoder>>::decode
  30:     0x7ffd15cf180a - <rustc_const_eval[5bc5628c60c7bc7b]::transform::check_consts::qualifs::CustomEq as rustc_const_eval[5bc5628c60c7bc7b]::transform::check_consts::qualifs::Qualif>::in_adt_inherently
  31:     0x7ffd15e23b8a - <&[rustc_span[e1ca11e9f2e7f58d]::symbol::Ident] as rustc_serialize[d95a6b06eb86861e]::serialize::Decodable<rustc_query_impl[d3aba5db8cad4e9d]::on_disk_cache::CacheDecoder>>::decode
  32:     0x7ffd15d616e3 - <rustc_query_impl[d3aba5db8cad4e9d]::Queries as rustc_middle[99c60881b72579c1]::ty::query::QueryEngine>::try_mark_green
  33:     0x7ffd179394c2 - <rustc_middle[99c60881b72579c1]::ty::instance::Instance>::upstream_monomorphization
  34:     0x7ffd16dc54e4 - <rustc_monomorphize[dc9d36c49badf87d]::collector::MirNeighborCollector as rustc_middle[99c60881b72579c1]::mir::visit::Visitor>::visit_constant
  35:     0x7ffd16dc1815 - <rustc_monomorphize[dc9d36c49badf87d]::collector::MirNeighborCollector as rustc_middle[99c60881b72579c1]::mir::visit::Visitor>::visit_operand
  36:     0x7ffd15a76b57 - <rustc_hir_analysis[838648b11bdaf06b]::check::region::RegionResolutionVisitor as rustc_hir[9ac1ca697d999d0a]::intravisit::Visitor>::visit_pat
  37:     0x7ffd15a7e632 - <rustc_monomorphize[dc9d36c49badf87d]::partitioning::default::DefaultPartitioning as rustc_monomorphize[dc9d36c49badf87d]::partitioning::Partitioner>::merge_codegen_units
  38:     0x7ffd15a7c7c6 - <rustc_monomorphize[dc9d36c49badf87d]::partitioning::default::DefaultPartitioning as rustc_monomorphize[dc9d36c49badf87d]::partitioning::Partitioner>::merge_codegen_units
  39:     0x7ffd15a787fa - <rustc_hir_analysis[838648b11bdaf06b]::check::region::RegionResolutionVisitor as rustc_hir[9ac1ca697d999d0a]::intravisit::Visitor>::visit_pat
  40:     0x7ffd15d2cae5 - <rustc_const_eval[5bc5628c60c7bc7b]::transform::check_consts::qualifs::CustomEq as rustc_const_eval[5bc5628c60c7bc7b]::transform::check_consts::qualifs::Qualif>::in_adt_inherently
  41:     0x7ffd15da78e8 - <&[rustc_span[e1ca11e9f2e7f58d]::symbol::Ident] as rustc_serialize[d95a6b06eb86861e]::serialize::Decodable<rustc_query_impl[d3aba5db8cad4e9d]::on_disk_cache::CacheDecoder>>::decode
  42:     0x7ffd15d0b8c7 - <rustc_const_eval[5bc5628c60c7bc7b]::transform::check_consts::qualifs::CustomEq as rustc_const_eval[5bc5628c60c7bc7b]::transform::check_consts::qualifs::Qualif>::in_adt_inherently
  43:     0x7ffd15e43c02 - <&[rustc_span[e1ca11e9f2e7f58d]::symbol::Ident] as rustc_serialize[d95a6b06eb86861e]::serialize::Decodable<rustc_query_impl[d3aba5db8cad4e9d]::on_disk_cache::CacheDecoder>>::decode
  44:     0x7ffd19887d96 - <&[rustc_ast[c03cc9997dba8755]::ast::Attribute] as rustc_serialize[d95a6b06eb86861e]::serialize::Decodable<rustc_query_impl[d3aba5db8cad4e9d]::on_disk_cache::CacheDecoder>>::decode
  45:     0x7ffd1977349b - <rustc_query_impl[d3aba5db8cad4e9d]::on_disk_cache::CacheEncoder as rustc_serialize[d95a6b06eb86861e]::serialize::Encoder>::emit_char
  46:     0x7ffd174115f9 - <rustc_span[e1ca11e9f2e7f58d]::symbol::Symbol as rustc_serialize[d95a6b06eb86861e]::serialize::Encodable<rustc_query_impl[d3aba5db8cad4e9d]::on_disk_cache::CacheEncoder>>::encode
  47:     0x7ffd17411343 - <rustc_span[e1ca11e9f2e7f58d]::symbol::Symbol as rustc_serialize[d95a6b06eb86861e]::serialize::Encodable<rustc_query_impl[d3aba5db8cad4e9d]::on_disk_cache::CacheEncoder>>::encode
  48:     0x7ffd15cc1db4 - <rustc_const_eval[5bc5628c60c7bc7b]::transform::check_consts::qualifs::CustomEq as rustc_const_eval[5bc5628c60c7bc7b]::transform::check_consts::qualifs::Qualif>::in_adt_inherently
  49:     0x7ffd15df0a2f - <&[rustc_span[e1ca11e9f2e7f58d]::symbol::Ident] as rustc_serialize[d95a6b06eb86861e]::serialize::Decodable<rustc_query_impl[d3aba5db8cad4e9d]::on_disk_cache::CacheDecoder>>::decode
  50:     0x7ffd15d648c9 - <rustc_query_impl[d3aba5db8cad4e9d]::Queries as rustc_middle[99c60881b72579c1]::ty::query::QueryEngine>::try_mark_green
  51:     0x7ffd1750d789 - <rustc_metadata[cb606c6922b3bfdd]::creader::CStore>::from_tcx
  52:     0x7ffd15f001d5 - rustc_metadata[cb606c6922b3bfdd]::rmeta::encoder::encode_metadata
  53:     0x7ffd15f3a15f - <(rustc_span[e1ca11e9f2e7f58d]::def_id::CrateNum, rustc_middle[99c60881b72579c1]::ty::fast_reject::SimplifiedType) as rustc_metadata[cb606c6922b3bfdd]::rmeta::decoder::cstore_impl::IntoArgs>::into_args
  54:     0x7ffd15eff63c - rustc_metadata[cb606c6922b3bfdd]::rmeta::encoder::encode_metadata
  55:     0x7ffd15f03636 - rustc_metadata[cb606c6922b3bfdd]::fs::encode_and_write_metadata
  56:     0x7ffd152b9ad3 - rustc_interface[acb21b123d0ba37]::passes::start_codegen
  57:     0x7ffd152ac34d - <rustc_interface[acb21b123d0ba37]::queries::Linker>::link
  58:     0x7ffd152a80c5 - <rustc_interface[acb21b123d0ba37]::queries::Queries>::ongoing_codegen
  59:     0x7ffd152753fd - <rustc_middle[99c60881b72579c1]::ty::SymbolName as core[6789f58c749a42cb]::fmt::Display>::fmt
  60:     0x7ffd1527432d - <rustc_middle[99c60881b72579c1]::ty::SymbolName as core[6789f58c749a42cb]::fmt::Display>::fmt
  61:     0x7ffd15268573 - rustc_driver_impl[80e6611556be2cef]::main
  62:     0x7ffd15272c93 - rustc_driver_impl[80e6611556be2cef]::args::arg_expand_all
  63:     0x7ffd2bd0c91c - std::sys::windows::thread::Thread::new::hc271a03890a34556
  64:     0x7ffd7e747614 - BaseThreadInitThunk
  65:     0x7ffd7f6226a1 - RtlUserThreadStart

error: 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.70.0-nightly (17c116721 2023-03-29) running on x86_64-pc-windows-msvc

note: compiler flags: --crate-type lib -C embed-bitcode=no -C debuginfo=2 -C incremental=[REDACTED] -C panic=abort -Z panic-abort-tests -Z codegen-rust=C:\temp\cg_clif\bin\rustc_codegen_cranelift.dll

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

query stack during panic:
#0 [exported_symbols] collecting exported symbols for crate `16`
#1 [upstream_monomorphizations] collecting available upstream monomorphizations
#2 [upstream_monomorphizations_for] collecting available upstream monomorphizations for `core::ptr::drop_in_place`
#3 [upstream_drop_glue_for] available upstream drop-glue for `[async_graphql::look_ahead::Lookahead<'_>]`
#4 [collect_and_partition_mono_items] collect_and_partition_mono_items
#5 [exported_symbols] collecting exported symbols for crate `0`
end of query stack
error: internal compiler error: re-entrant incremental verify failure, suppressing message

there was a panic while trying to force a dep node
try_mark_green dep node stack:
#0 exported_symbols(project_name[fb04])
end of try_mark_green dep node stack
error: could not compile `project_name` (lib) due to 2 previous errors
[Finished running. Exit status: 0]

[bjorn3]

Maybe this is caused by --sysroot being untracked for incremental compilation? This is the only flag cargo-clif passes which isn't tracked. It looks like cargo doesn't pass RUSTFLAGS when running rustc -vV to determine which rustc is used. This means that it will happily compile a crate with cg_llvm (when rust-analyzer does cargo check) and reuse the incr comp cache for cg_clif (when you do cargo-clif build) This shouldn't happen one way or another because cg_llvm and cg_clif put different object files in the incr comp cache which may or may not work with the other backend. That shouldn't cause this exact issue though. For this specific issue I think the differing --sysroot argument not being tracked may be the real issue.

The proper fix if this is indeed caused by mixing cg_llvm and cg_clif would be to ensure that cargo doesn't share anything between the two. One way I can think of is to set the __CARGO_DEFAULT_LIB_METADATA env var to some value in cargo-clif. Could you try if doing when calling cargo-clif (but not for rust-analyzer) fixes the issue for you? If so I can make a change to set it in cargo-clif by default.

[frederikhors]

I think I don't quite understand what to do...

Anyway the error is gone now and is not happening anymore since then (and I know it's just a few minutes but I finished those changes and moved on to something else).

As soon as it comes out again I will try to do what you ask. But can you specify better what you want me to try?

[bjorn3]

My suggestion was to do export __CARGO_DEFAULT_LIB_METADATA=foo in the terminal from which you run cargo-clif. This should prevent cargo from sharing the incremental compilation cache between cargo-clif and the cargo check run by rust-analyzer.

[frederikhors]

Literally export __CARGO_DEFAULT_LIB_METADATA=foo? foo?

[frederikhors]

I don't know what __CARGO_DEFAULT_LIB_METADATA means...

[bjorn3]

Literally export __CARGO_DEFAULT_LIB_METADATA=foo? foo?

Yes. Any value would work. It just needs to be set to something.

I don't know what __CARGO_DEFAULT_LIB_METADATA means...

It is an environment variable read by cargo. Cargo adds the value you give it to a hash that is used to prevent different versions of the same crate or the same crate compiled by different rustc versions from conflicting with each other. It starts with __ as it is an unstable feature, but that shouldn't as if this is indeed a fix, I will add it to cargo-clif itself and update it if it ever changes.

[frederikhors]

I'll let you know ASAP.

[bjorn3]

Let's leave this issue open to track adding a fix on the cg_clif side if __CARGO_DEFAULT_LIB_METADATA works.

[frederikhors]

The error is still happening randomly. Can you release a new dev version with this change?

[bjorn3]

You mean it is still happening if you set __CARGO_DEFAULT_LIB_METADATA or if you don't set it?

[bjorn3]

Once CI finishes https://github.com/bjorn3/rustc_codegen_cranelift/actions/runs/4689583092 should have a precompiled cg_clif with the change to set __CARGO_DEFAULT_LIB_METADATA in cargo-clif by default.

[frederikhors]

You mean it is still happening if you set __CARGO_DEFAULT_LIB_METADATA or if you don't set it?

Sorry I didn't set that var (I forgot you told me).

The release for https://github.com/bjorn3/rustc_codegen_cranelift/actions/runs/4689583092 is skipped, why?

[bjorn3]

This commit is on the staging branch rather than the master branch. Only commits to the master branch create a release. You can download the artifacts that would be included in the release directly from this page if you scroll down.

[frederikhors]

Sorry you're right! I'm bursted! I'm trying...

[frederikhors]

I tried with cargo 1.70.0-nightly (0e474cfd7 2023-03-31) (from that build) but the error is still there:

[A LOT OF TEXT HERE]

error: 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.70.0-nightly (af06dce64 2023-04-08) running on x86_64-pc-windows-msvc

note: compiler flags: --crate-type lib -C embed-bitcode=no -C debuginfo=2 -C incremental=[REDACTED] -C panic=abort -Z panic-abort-tests -Z codegen-backend=C:\cg_clif\bin\rustc_codegen_cranelift.dll

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

query stack during panic:
#0 [exported_symbols] collecting exported symbols for crate `16`
#1 [upstream_monomorphizations] collecting available upstream monomorphizations
#2 [upstream_monomorphizations_for] collecting available upstream monomorphizations for `alloc::sync::Arc::<T>::new`
#3 [collect_and_partition_mono_items] collect_and_partition_mono_items
#4 [exported_symbols] collecting exported symbols for crate `0`
end of query stack
there was a panic while trying to force a dep node
try_mark_green dep node stack:
#0 exported_symbols(project_crate[7a4d])
end of try_mark_green dep node stack
error: could not compile `project_crate` (lib) due to previous error

Is there a way I can help you understand what is going on?

[bjorn3]

Can you try setting "rust-analyzer.server.extraEnv": { "CARGO_TARGET_DIR": "target-ra" } in your vscode config to make rust-analyzer use the target-ra directory instead of target and then do cargo clean? If it still happens when you do this, the issue is definitively not caused by mixing cg_clif and cg_llvm. If that fixes it, you can try removing this config again and setting "rust-analyzer.cargo.buildScripts.useRustcWrapper": false instead to see if it could be a bad interaction with rust-analyzer's rustc wrapper.

[frederikhors]

I think VSCode is not responsible for the problem.

I noticed it happens when I re-generate my code using a (corporate) generator.

The flow is this:

1. the (development) app is started using watchexec that restart the app each time there is a change on a file

2. the app is started with cargo-clif watch -x run

3. the file generator is launched and it (unfortunately) re-writes each (.rs) file of the project again (even if it's the same content as before)

4. the error with cargo-clif is here now

I tought it was VSCode but it happens also if I close VSCode.

Do you have an idea now?

[bjorn3]

This doesn't happen when using nightly rustc without cg_clif? (make sure to cargo clean first just in case) And did you do cargo clean once before cargo-clif watch -x run to ensure nothing is left over from a previous build with vscode running?

I can't think of anything in cg_clif that could cause this, so I'm trying to isolate what program is responsible for this.

[bjorn3]

Also could you please try passing -Zincremental-verify-ich=yes to rustc using RUSTFLAGS after cleaning the build cache. This can catch unstable fingerprints right when then happen in some cases rather than when the incremental cache is used on the next compilation.

[frederikhors]

Ok I have some news:

First: I'm executing cargo clean before everything, everytime.

1. The issue is there without VSCode at all (never opened on the project after cargo clean).

2. The issue is reproducible everytime I generate code (the same files, no changes, but each file is overwritten during the watch).

3. I tried with cargo watch -x run" (no cargo-clif, just cargo) and the error is there!

So I think cargo-clif is not the guilty one, right?

Do you have an idea?

[bjorn3]

So I think cargo-clif is not the guilty one, right?

Looks like it.

Do you have an idea?

Not really. I would suggest opening an issue on https://github.com/rust-lang/rust. The project on which you hit this closed source, right? Can you try reducing it to something you can share? It doesn't have to be as minimal as possible. Just something that allows others to reproduce the bug. If not, opening an issue would still be fine, but it may be harder to find the root cause and thus take longer before it is fixed.

In any case as workaround I think you can disable incremental compilation. This makes compilation slower, but should at least allow you to work without having to do cargo clean -p project_name every time. You can disable incremental compilation by either setting the CARGO_INCREMENTAL env var to 0, or by setting incremental = false in the [profile.dev] section of Cargo.toml.

[frederikhors]

Thank you very much!