Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ICE index OOB in 1.59.0-beta.8 🚨 #94124

Closed
carols10cents opened this issue Feb 18, 2022 · 29 comments
Closed

ICE index OOB in 1.59.0-beta.8 🚨 #94124

carols10cents opened this issue Feb 18, 2022 · 29 comments
Labels
A-incr-comp Area: Incremental compilation C-bug Category: This is a bug. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Milestone

Comments

@carols10cents
Copy link
Member

carols10cents commented Feb 18, 2022

I know it's late in the release cycle and I know there were bugs similar to this in previous 1.59.0 betas, but I don't see any issues for this bug in beta 8, so this seems pretty high priority to me @rust-lang/compiler

Code

I'm working on some changes to https://github.com/influxdata/influxdb_iox. I ran a workspace level cargo check that succeeded, I made a few small changes, then I ran cargo test --test end_to_end and go tthis error.

Meta

rustc --version --verbose
rustc 1.59.0-beta.8 (1945ce657 2022-02-12)
binary: rustc
commit-hash: 1945ce6579506787e0b18f0a2ea03fdb4dfc81c7
commit-date: 2022-02-12
host: aarch64-apple-darwin
release: 1.59.0-beta.8
LLVM version: 13.0.0

Error output

thread 'rustc' panicked at 'index out of bounds: the len is 741 but the index is 767', compiler/rustc_query_impl/src/on_disk_cache.rs:726:18
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.59.0-beta.8 (1945ce657 2022-02-12) running on aarch64-apple-darwin

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

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

query stack during panic:
#0 [optimized_mir] optimizing MIR for `ingester::from_window_frame`
#1 [collect_and_partition_mono_items] collect_and_partition_mono_items
end of query stack
error: could not compile `predicate`
warning: build failed, waiting for other jobs to finish...
error: build failed
Backtrace

 RUST_BACKTRACE=1 cargo test --test end_to_end
   Compiling predicate v0.1.0 (/Users/carolnichols/rust/influxdb_iox/predicate)
   Compiling router v0.1.0 (/Users/carolnichols/rust/influxdb_iox/router)
thread 'rustc' panicked at 'index out of bounds: the len is 741 but the index is 767', compiler/rustc_query_impl/src/on_disk_cache.rs:726:18
stack backtrace:
   0: _rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::panicking::panic_bounds_check
   3: <rustc_span::span_encoding::Span as rustc_serialize::serialize::Decodable<rustc_query_impl::on_disk_cache::CacheDecoder>>::decode
   4: <rustc_middle::ty::VariantDef as rustc_serialize::serialize::Decodable<rustc_query_impl::on_disk_cache::CacheDecoder>>::decode
   5: <rustc_query_impl::on_disk_cache::CacheDecoder as rustc_serialize::serialize::Decoder>::read_seq::<alloc::vec::Vec<rustc_middle::ty::VariantDef>, <alloc::vec::Vec<rustc_middle::ty::VariantDef> as rustc_serialize::serialize::Decodable<rustc_query_impl::on_disk_cache::CacheDecoder>>::decode::{closure#0}>
   6: <rustc_middle::ty::adt::AdtDef as rustc_serialize::serialize::Decodable<rustc_query_impl::on_disk_cache::CacheDecoder>>::decode
   7: <rustc_middle::ty::sty::TyKind as rustc_serialize::serialize::Decodable<rustc_query_impl::on_disk_cache::CacheDecoder>>::decode
   8: <&rustc_middle::ty::TyS as rustc_serialize::serialize::Decodable<rustc_query_impl::on_disk_cache::CacheDecoder>>::decode
   9: <rustc_query_impl::on_disk_cache::CacheDecoder as rustc_middle::ty::codec::TyDecoder>::cached_ty_for_shorthand::<<&rustc_middle::ty::TyS as rustc_serialize::serialize::Decodable<rustc_query_impl::on_disk_cache::CacheDecoder>>::decode::{closure#0}>
  10: <&rustc_middle::ty::TyS as rustc_serialize::serialize::Decodable<rustc_query_impl::on_disk_cache::CacheDecoder>>::decode
  11: <rustc_middle::ty::subst::GenericArg as rustc_serialize::serialize::Decodable<rustc_query_impl::on_disk_cache::CacheDecoder>>::decode
  12: <core::result::Result<rustc_middle::ty::subst::GenericArg, alloc::string::String> as rustc_middle::ty::context::InternIteratorElement<rustc_middle::ty::subst::GenericArg, &rustc_middle::ty::list::List<rustc_middle::ty::subst::GenericArg>>>::intern_with::<core::iter::adapters::map::Map<core::ops::range::Range<usize>, <&rustc_middle::ty::list::List<rustc_middle::ty::subst::GenericArg> as rustc_serialize::serialize::Decodable<rustc_query_impl::on_disk_cache::CacheDecoder>>::decode::{closure#0}>, <rustc_middle::ty::context::TyCtxt>::mk_substs<core::iter::adapters::map::Map<core::ops::range::Range<usize>, <&rustc_middle::ty::list::List<rustc_middle::ty::subst::GenericArg> as rustc_serialize::serialize::Decodable<rustc_query_impl::on_disk_cache::CacheDecoder>>::decode::{closure#0}>>::{closure#0}>
  13: <&rustc_middle::ty::list::List<rustc_middle::ty::subst::GenericArg> as rustc_serialize::serialize::Decodable<rustc_query_impl::on_disk_cache::CacheDecoder>>::decode
  14: <rustc_middle::ty::sty::TyKind as rustc_serialize::serialize::Decodable<rustc_query_impl::on_disk_cache::CacheDecoder>>::decode
  15: <&rustc_middle::ty::TyS as rustc_serialize::serialize::Decodable<rustc_query_impl::on_disk_cache::CacheDecoder>>::decode
  16: <rustc_middle::mir::Constant as rustc_serialize::serialize::Decodable<rustc_query_impl::on_disk_cache::CacheDecoder>>::decode
  17: <rustc_middle::mir::Operand as rustc_serialize::serialize::Decodable<rustc_query_impl::on_disk_cache::CacheDecoder>>::decode
  18: <rustc_middle::mir::terminator::Terminator as rustc_serialize::serialize::Decodable<rustc_query_impl::on_disk_cache::CacheDecoder>>::decode
  19: <rustc_query_impl::on_disk_cache::CacheDecoder as rustc_serialize::serialize::Decoder>::read_option::<core::option::Option<rustc_middle::mir::terminator::Terminator>, <core::option::Option<rustc_middle::mir::terminator::Terminator> as rustc_serialize::serialize::Decodable<rustc_query_impl::on_disk_cache::CacheDecoder>>::decode::{closure#0}>
  20: <rustc_middle::mir::BasicBlockData as rustc_serialize::serialize::Decodable<rustc_query_impl::on_disk_cache::CacheDecoder>>::decode
  21: <rustc_query_impl::on_disk_cache::CacheDecoder as rustc_serialize::serialize::Decoder>::read_seq::<alloc::vec::Vec<rustc_middle::mir::BasicBlockData>, <alloc::vec::Vec<rustc_middle::mir::BasicBlockData> as rustc_serialize::serialize::Decodable<rustc_query_impl::on_disk_cache::CacheDecoder>>::decode::{closure#0}>
  22: <rustc_query_impl::on_disk_cache::CacheDecoder as rustc_serialize::serialize::Decoder>::read_struct::<rustc_middle::mir::Body, <rustc_middle::mir::Body as rustc_serialize::serialize::Decodable<rustc_query_impl::on_disk_cache::CacheDecoder>>::decode::{closure#0}>
  23: <rustc_query_impl::on_disk_cache::OnDiskCache>::try_load_query_result::<&rustc_middle::mir::Body>
  24: rustc_query_system::query::plumbing::try_load_from_disk_and_cache_in_memory::<rustc_query_impl::plumbing::QueryCtxt, rustc_span::def_id::DefId, &rustc_middle::mir::Body>
  25: rustc_query_system::query::plumbing::try_execute_query::<rustc_query_impl::plumbing::QueryCtxt, rustc_query_system::query::caches::DefaultCache<rustc_span::def_id::DefId, &rustc_middle::mir::Body>>
  26: rustc_query_system::query::plumbing::get_query::<rustc_query_impl::queries::optimized_mir, rustc_query_impl::plumbing::QueryCtxt>
  27: <rustc_middle::ty::context::TyCtxt>::instance_mir
  28: rustc_monomorphize::collector::collect_neighbours
  29: rustc_monomorphize::collector::collect_items_rec
  30: rustc_monomorphize::collector::collect_items_rec
  31: rustc_monomorphize::collector::collect_items_rec
  32: rustc_monomorphize::collector::collect_items_rec
  33: rustc_monomorphize::collector::collect_items_rec
  34: rustc_monomorphize::collector::collect_items_rec
  35: rustc_monomorphize::collector::collect_items_rec
  36: rustc_monomorphize::collector::collect_items_rec
  37: rustc_monomorphize::collector::collect_items_rec
  38: rustc_monomorphize::collector::collect_items_rec
  39: rustc_monomorphize::collector::collect_items_rec
  40: rustc_monomorphize::collector::collect_items_rec
  41: rustc_monomorphize::collector::collect_items_rec
  42: rustc_monomorphize::collector::collect_items_rec
  43: rustc_monomorphize::collector::collect_items_rec
  44: rustc_monomorphize::collector::collect_items_rec
  45: rustc_monomorphize::collector::collect_items_rec
  46: rustc_monomorphize::collector::collect_items_rec
  47: rustc_monomorphize::collector::collect_items_rec
  48: rustc_monomorphize::collector::collect_items_rec
  49: <rustc_session::session::Session>::time::<(), rustc_monomorphize::collector::collect_crate_mono_items::{closure#1}>
  50: rustc_monomorphize::collector::collect_crate_mono_items
  51: rustc_monomorphize::partitioning::collect_and_partition_mono_items
  52: <rustc_query_system::dep_graph::graph::DepGraph<rustc_middle::dep_graph::dep_node::DepKind>>::with_task::<rustc_middle::ty::context::TyCtxt, (), (&std::collections::hash::set::HashSet<rustc_span::def_id::DefId, core::hash::BuildHasherDefault<rustc_hash::FxHasher>>, &[rustc_middle::mir::mono::CodegenUnit])>
  53: rustc_data_structures::stack::ensure_sufficient_stack::<((&std::collections::hash::set::HashSet<rustc_span::def_id::DefId, core::hash::BuildHasherDefault<rustc_hash::FxHasher>>, &[rustc_middle::mir::mono::CodegenUnit]), rustc_query_system::dep_graph::graph::DepNodeIndex), rustc_query_system::query::plumbing::execute_job<rustc_query_impl::plumbing::QueryCtxt, (), (&std::collections::hash::set::HashSet<rustc_span::def_id::DefId, core::hash::BuildHasherDefault<rustc_hash::FxHasher>>, &[rustc_middle::mir::mono::CodegenUnit])>::{closure#3}>
  54: rustc_query_system::query::plumbing::try_execute_query::<rustc_query_impl::plumbing::QueryCtxt, rustc_query_system::query::caches::DefaultCache<(), (&std::collections::hash::set::HashSet<rustc_span::def_id::DefId, core::hash::BuildHasherDefault<rustc_hash::FxHasher>>, &[rustc_middle::mir::mono::CodegenUnit])>>
  55: rustc_query_system::query::plumbing::force_query::<rustc_query_impl::queries::collect_and_partition_mono_items, rustc_query_impl::plumbing::QueryCtxt>
  56: rustc_query_impl::query_callbacks::collect_and_partition_mono_items::force_from_dep_node
  57: <rustc_middle::ty::context::TyCtxt as rustc_query_system::dep_graph::DepContext>::try_force_from_dep_node
  58: <rustc_query_system::dep_graph::graph::DepGraph<rustc_middle::dep_graph::dep_node::DepKind>>::try_mark_previous_green::<rustc_query_impl::plumbing::QueryCtxt>
  59: <rustc_query_system::dep_graph::graph::DepGraph<rustc_middle::dep_graph::dep_node::DepKind>>::try_mark_green::<rustc_query_impl::plumbing::QueryCtxt>
  60: 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)]>
  61: 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)]>>
  62: rustc_query_system::query::plumbing::get_query::<rustc_query_impl::queries::exported_symbols, rustc_query_impl::plumbing::QueryCtxt>
  63: <rustc_metadata::rmeta::encoder::EncodeContext>::encode_crate_root
  64: rustc_metadata::rmeta::encoder::encode_metadata_impl
  65: rustc_data_structures::sync::join::<rustc_metadata::rmeta::encoder::encode_metadata::{closure#0}, rustc_metadata::rmeta::encoder::encode_metadata::{closure#1}, rustc_metadata::rmeta::encoder::EncodedMetadata, ()>
  66: rustc_metadata::rmeta::encoder::encode_metadata
  67: <rustc_interface::queries::Queries>::ongoing_codegen
  68: <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>>
  69: 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}>
  70: rustc_interface::interface::create_compiler_and_run::<core::result::Result<(), rustc_errors::ErrorReported>, rustc_driver::run_compiler::{closure#1}>
  71: <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.

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-beta.8 (1945ce657 2022-02-12) running on aarch64-apple-darwin

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

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

query stack during panic:
#0 [optimized_mir] optimizing MIR for `ingester::from_window_frame`
#1 [collect_and_partition_mono_items] collect_and_partition_mono_items
#2 [exported_symbols] exported_symbols
end of query stack
error: could not compile `predicate`
warning: build failed, waiting for other jobs to finish...
error: build failed

@carols10cents carols10cents added I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. C-bug Category: This is a bug. labels Feb 18, 2022
@Mark-Simulacrum
Copy link
Member

I believe this is #93029

(also #93823, #93371, #93131, #93336)

Which is fixed in 1.60 by #92533 which didn't get backported, seems like intentionally.

@Aaron1011
Copy link
Member

That's correct. This ICE was exposed in the process of fixing a different incremental compilation ICE. Unfortunately, it seems that this new ICE occurs much more frequently than the old one.

Given the complexity of the incr comp system, I'd like to avoid backporting the fix unless absolutely necessary.

@carols10cents
Copy link
Member Author

How would you define "absolutely necessary" in this case? If I hit this ICE on beta, people are going to hit it on stable, no?

@estebank
Copy link
Contributor

Should we have a beta revert of this change while we work on master to fix it?

@Aaron1011
Copy link
Member

How would you define "absolutely necessary" in this case? If I hit this ICE on beta, people are going to hit it on stable, no?

@carols10cents: I'd want the ICE to be very frequent and disruptive if we're going to do a backport. Since the fingerprint check was enabled by default, there's been a large number of incremental bugs uncovered. I believe that the best way to deal with them is to let the fixes ride the release train, so that we have time to discover any new issues that might be revealed or caused by the fix. I don't think trying to rush fixes to the incremental compilation system is a good idea.

Should we have a beta revert of this change while we work on master to fix it?

@estebank This is already fixed in master by #92533. Even if it wasn't already fixed, this ICE was a pre-existing issue that was revealed by another fix to the incremental system. I don't think we should revert a (correct) just to temporarily hide a different ICE.

@carols10cents
Copy link
Member Author

carols10cents commented Feb 18, 2022

@Aaron1011 The last time we let incremental compilation bugs ride the train to stable, the team discovered that hardly anyone uses beta to develop with, so beta isn't actually representative of frequency on stable. Has anything changed since then?

Also, last time, incremental compilation had to be disabled by default for a number of stable releases. Is that an acceptable possible outcome again?

@Aaron1011
Copy link
Member

The last time we let incremental compilation bugs ride the train to stable,

If you're referring to the time when we had to disable incremental compilation, then that was a special case - enabling the fingerprint checks caused a large number of distinct incr comp bugs to start producing ICEs. Since then, we've let fixes for individual incremental comp bugs ride the train to stable. I don't think that the frequency of this ICE is especially high compared to any of those other issues (e.g. #85868)

In general, I think that beta backports for incremental compilation bugs should be a last resort, not something that we do automatically. @carols10cents Have you hit this bug multiple times on beta?

@carols10cents
Copy link
Member Author

In general, I think that beta backports for incremental compilation bugs should be a last resort, not something that we do automatically. @carols10cents Have you hit this bug multiple times on beta?

Not yet. It seems strange to me to actually get early warning of a problem on beta and then deliberately choose to ignore it. Isn't catching problems early the reason beta exists?

I actually switched to 1.59 beta over 1.58 stable because I was hitting incremental compilation bugs a disruptive number of times there. I've only been on beta.8 for a few days. Certainly seems like given so few people use beta, that if anyone experiences and reports an issue with beta, that it could potentially represent a large number of stable users.

@Aaron1011
Copy link
Member

Not yet. It seems strange to me to actually get early warning of a problem on beta and then deliberately choose to ignore it. Isn't catching problems early the reason beta exists?

Yes, but the PR we would be backporting is really a distinct, unrelated change. There are really two PRs that we would need to backport to fully fix the ICE that you're seeing: #93095 and #93095. Backporting those PRs would fix a known ICE on beta, but it would mean that we would lose out on some of the normal testing that those two PRs would get via riding the release train.

We've been making steady progress at fixing incremental compilation bugs. If we discover that a particular bugfix PR introduces new issues, then I think it's reasonable to consider backporting (or reverting on beta). However, if the PR exposes an existing bug, then I don't think we should rush through an unrelated change that could potentially introduce new bugs.

@Urgau
Copy link
Member

Urgau commented Feb 18, 2022

Not sure if that helps but during the last 2/3 days I encountered multiple times (at least 10 times, sometimes in a row) this bug when I was hacking on rustc. The only solution was to do a ./x.py clean and a full rebuild.

@oli-obk
Copy link
Contributor

oli-obk commented Feb 19, 2022

We could consider making a commit directly on beta that removes all the stable hash project attributes. This is entirely risk free (I don't see how it could possibly cause problems to stop ignoring spans during stable hashing) and only makes incremental perf worse by a few percent, while also fixing the bug.

@michaelwoerister
Copy link
Member

michaelwoerister commented Feb 21, 2022

I think we should do something here. If this is an ICE that shows up multiple times a day in people's regular workflow, it will give the impression of being a severe bug.

We could consider making a commit directly on beta that removes all the stable hash project attributes. This is entirely risk free [...]

I agree that a performance hit (even a big one) is acceptable if it allows us to prevent the compiler from ICEing frequently. @oli-obk's proposed mitigation should work -- but it would still be good to have a few days of focused testing.

How flexible are we around moving the release by a little bit?

@Mark-Simulacrum
Copy link
Member

Release is Thursday, I don't think we should move it at this point. We can backport (or only land) patches into it up until ~Wednesday evening in the worst case.

@estebank
Copy link
Contributor

@pnkfelix, @wesleywiser, @rust-lang/compiler, I agree with @oli-obk's proposed stop-gap solution for this fingerprinting issue that seems to be prevalent enough in beta to be concerning (at least to me). I believe that we should get a patch ready and backported before tuesday (outside of our weekly backport evaluation schedule). I believe that this should be possible if we have someone in the team with the spare cycles to do this.

@Mark-Simulacrum Mark-Simulacrum added this to the 1.59.0 milestone Feb 21, 2022
@michaelwoerister
Copy link
Member

I created a commit that applies the mitigation here: https://github.com/michaelwoerister/rust/tree/mitigate-issue-94124. Local testing is still running.

I (or someone else) can turn this into a pull request later today. But I think we need to first OK this with the compiler team leads, as @estebank suggests. It would also be good to get the opinion of at least @Aaron1011 and @cjgillot on whether the mitigation is indeed safe enough.

@wesleywiser
Copy link
Member

If this is an ICE that shows up multiple times a day in people's regular workflow, it will give the impression of being a severe bug.

Yeah, I totally agree with @michaelwoerister's point here. I would rather we proactively decide to take this perf hit now than have to decide if we should do something in a .1 patch in a few days.

Thanks for reporting @carols10cents!

@michaelwoerister
Copy link
Member

Hm, I'm getting lots of linker errors in incr. comp. tests with that applied. I seem to remember that there was a problem with spans making their way into symbol name hashes...

@michaelwoerister
Copy link
Member

It looks like we also need to backport #92278 for the mitigation to work. Otherwise spans become part of the symbol hash due to a bug in the stable hash caching infrastructure.

@Aaron1011
Copy link
Member

It looks like we also need to backport #92278 for the mitigation to work. Otherwise spans become part of the symbol hash due to a bug in the stable hash caching infrastructure.

This is exactly the kind of thing that I was worried about. @oli-obk has thought that just hashing more spans would be entirely risk free (and I didn't see any obvious issues when they suggested it). However, this turned out to be incorrect due to the fact that the incremental compilation logic is so tightly couples to other parts of the compiler (symbol hashing, in this case).

I think incremental compilation is already insufficiently tested, and the tests we do have in src/test/incremental don't really cover the large-scale patterns of edits that users make in practice. Performing even less testing by making some changes skip ahead in the release train, and potentially introducing different bugs into beta due to running some unusual subset of the changes in master, seems like a step in the wrong direction.

I recognize the disruption that incremental compilation bugs cause to users workflows. I'm not sure what the right solution is here (disabling incr comp like we did a while back seems pretty extreme), but I don't think we should try to paper over these bugs by backporting a solution that (by definition) will have even less testing than the current implementation

michaelwoerister added a commit to michaelwoerister/rust that referenced this issue Feb 21, 2022
incremental compilation related ICEs as reported in rust-lang#94124 for Rust 1.59.
@michaelwoerister
Copy link
Member

The "solution" at https://github.com/michaelwoerister/rust/tree/mitigate-issue-94124 now passes tests for me locally. I added the commits from #92278 and had to disable a few incr. comp. tests because fingerprints depend on source locations in more cases -- so that was expected.

However, I also had to disable one test because it now failed consistently with an "unstable fingerprint" assertion -- which of course makes you really wonder if the cure isn't worse than the disease here.

I agree with @Aaron1011's statement that merging almost untested changes to incr. comp. into stable is not a good idea -- and the findings above only seem to confirm that. I had hoped we'd get a lucky break here but it doesn't look like it.

I still think it's not an option to let this bug make it into stable as is. Are there other things we can do? Make the compiler deal with the error more gracefully maybe?

@pnkfelix
Copy link
Member

pnkfelix commented Feb 21, 2022

So: my current take is this:

  • We should not release with incr-comp on by default with ICE's that have messaging like the one in this bug. Its not an acceptable end-user experience.
  • Talking about this with @oli-obk and @estebank , one suggestion is to change all the indexing operations within compiler/rustc_query_impl/src/on_disk_cache.rs to use .get(...).expect(MSG) where MSG gives advice on how to workaround the issue.
  • @oli-obk also suggested that we might be able to add catch_unwind's to the incremental operations and catch all panics of this nature.

In any case, my attitude is that we might consider messaging changes alone, if we can get it done in time.

If we cannot get the messaging changes done in time, or if they end up being broader/too risky for whatever reason, then I'm inclined to disable incr-comp by default for the 1.59.0 release.

cc @rust-lang/compiler @rust-lang/release

@Mark-Simulacrum
Copy link
Member

Rather than switching indexing, since the ICE message already has CLI options, we can likely use that to give a better error message. That said, I am not personally convinced an error message is of much help here - ultimately, my understanding is the best we can offer is a "cargo clean" suggestion, right?

We should probably schedule some time to discuss incremental testing and/or policy in general here - my impression is we're basically going to flip flop every N release cycles with the current state, though steadily reducing the amount of bugs.

@pnkfelix
Copy link
Member

That said, I am not personally convinced an error message is of much help here - ultimately, my understanding is the best we can offer is a "cargo clean" suggestion, right?

We can tell them to cargo clean to work-around the immediate error.

We might also tell them to disable incremental-compilation entirely (though then that setting might stay in their codebase forever, even after the bugs are fixed, so its not the greatest option; this is a case where a version-conditional setting in the Cargo.toml might provide a better long term experience to address that scenario).

The more I talk about this, the more my gut veers towards "disable incr-comp by default for this release."

We should probably schedule some time to discuss incremental testing and/or policy in general here - my impression is we're basically going to flip flop every N release cycles with the current state, though steadily reducing the amount of bugs.

I agree we should schedule some time for this.

I do wonder: if the number of incr-comp bugs goes down over time, we might expect the time N between flip-off-cycles to increase over time, and that might be an acceptable state of affairs? (As long as the time to flip back on is a small constant, that is...)

@michaelwoerister
Copy link
Member

I think turning it off by default and adding a message in the release notes is an acceptable option.

@Mark-Simulacrum
Copy link
Member

I've posted the initial stable artifacts build (#94224) with incremental soft-disabled; we can of course iterate on the exact language there and likely a section for the blog post also makes sense. cc @tmandry on the latter, or maybe someone here wants to draft something up.

We have time until ~Wednesday to rebuild artifacts with a different patch, of course, but I want a set of artifacts we could release and this seems like the safest set.

bors added a commit to rust-lang-ci/rust that referenced this issue Feb 22, 2022
…imulacrum

[stable] 1.59.0 release

This adds in a few backports:

*  Destabilise entry_insert rust-lang#94105
*  Update compiler_builtins to fix duplicate symbols in armv7-linux-androideabi rlib rust-lang#93436

This also includes a fresh commit replicating the 1.52.1 patch soft-disabling incremental for 1.59, in light of discussion on rust-lang#94124. This hasn't yet been fully approved but I think is the likely way things will go, so preparing the first round of stable artifacts with that in mind.

r? `@Mark-Simulacrum`
@matthiaskrgr matthiaskrgr added the A-incr-comp Area: Incremental compilation label Feb 22, 2022
@philipcraig
Copy link
Contributor

Hi everyone, this bug in beta is so prevalent that lots of tests in https://github.com/google/autocxx/blob/main/integration-tests/tests/integration_test.rs have had to be disabled for beta builds. Incremental compiles fail crazily often, and it is breaking the integration tests that use beta channel on the CI, always with this same compile panic.

If the beta channel gets promoted to stable in this state, it will look like a major compilation regression for many rustc users, and will have to be urgently patched in a .1 release post-promotion

@pnkfelix
Copy link
Member

If the beta channel gets promoted to stable in this state, it will look like a major compilation regression for many rustc users, and will have to be urgently patched in a .1 release post-promotion

Just to assuage concerns of anyone following along here: We are not letting the beta channel get promoted to stable in the state described here.

As noted by @Mark-Simulacrum above, we have now "soft-disabled" incremental on 1.59.0-stable.

This means that people won't run into this bug unless they jump through the necessary hoops to re-enable incremental compilation

wip-sync pushed a commit to NetBSD/pkgsrc-wip that referenced this issue Mar 2, 2022
Pkgsrc changes:
 * Bump available bootstraps to 1.58.1.
 * Adjust one patch (and checksum) so that it still applies.

Upstream changes:

Version 1.59.0 (2022-02-24)
==========================

Language
--------

- [Stabilize default arguments for const generics][90207]
- [Stabilize destructuring assignment][90521]
- [Relax private in public lint on generic bounds and where clauses
  of trait impls][90586]
- [Stabilize asm! and global_asm! for x86, x86_64, ARM, Aarch64,
  and RISC-V][91728]

Compiler
--------

- [Stabilize new symbol mangling format, leaving it opt-in
  (-Csymbol-mangling-version=v0)][90128]
- [Emit LLVM optimization remarks when enabled with `-Cremark`][90833]
- [Fix sparc64 ABI for aggregates with floating point members][91003]
- [Warn when a `#[test]`-like built-in attribute macro is present
  multiple times.][91172]
- [Add support for riscv64gc-unknown-freebsd][91284]
- [Stabilize `-Z emit-future-incompat` as `--json future-incompat`][91535]
- [Soft disable incremental compilation][94124]

This release disables incremental compilation, unless the user has explicitly
opted in via the newly added RUSTC_FORCE_INCREMENTAL=1 environment variable.
This is due to a known and relatively frequently occurring bug in incremental
compilation, which causes builds to issue internal compiler errors. This
particular bug is already fixed on nightly, but that fix has not yet rolled out
to stable and is deemed too risky for a direct stable backport.

As always, we encourage users to test with nightly and report bugs so that we
can track failures and fix issues earlier.

See [94124] for more details.

[94124]: rust-lang/rust#94124

Libraries
---------

- [Remove unnecessary bounds for some Hash{Map,Set} methods][91593]

Stabilized APIs
---------------

- [`std::thread::available_parallelism`][available_parallelism]
- [`Result::copied`][result-copied]
- [`Result::cloned`][result-cloned]
- [`arch::asm!`][asm]
- [`arch::global_asm!`][global_asm]
- [`ops::ControlFlow::is_break`][is_break]
- [`ops::ControlFlow::is_continue`][is_continue]
- [`TryFrom<char> for u8`][try_from_char_u8]
- [`char::TryFromCharError`][try_from_char_err]
  implementing `Clone`, `Debug`, `Display`, `PartialEq`, `Copy`, `Eq`, `Error`
- [`iter::zip`][zip]
- [`NonZeroU8::is_power_of_two`][is_power_of_two8]
- [`NonZeroU16::is_power_of_two`][is_power_of_two16]
- [`NonZeroU32::is_power_of_two`][is_power_of_two32]
- [`NonZeroU64::is_power_of_two`][is_power_of_two64]
- [`NonZeroU128::is_power_of_two`][is_power_of_two128]
- [`DoubleEndedIterator for ToLowercase`][lowercase]
- [`DoubleEndedIterator for ToUppercase`][uppercase]
- [`TryFrom<&mut [T]> for [T; N]`][tryfrom_ref_arr]
- [`UnwindSafe for Once`][unwindsafe_once]
- [`RefUnwindSafe for Once`][refunwindsafe_once]
- [armv8 neon intrinsics for aarch64][stdarch/1266]

Const-stable:

- [`mem::MaybeUninit::as_ptr`][muninit_ptr]
- [`mem::MaybeUninit::assume_init`][muninit_init]
- [`mem::MaybeUninit::assume_init_ref`][muninit_init_ref]
- [`ffi::CStr::from_bytes_with_nul_unchecked`][cstr_from_bytes]

Cargo
-----

- [Stabilize the `strip` profile option][cargo/10088]
- [Stabilize future-incompat-report][cargo/10165]
- [Support abbreviating `--release` as `-r`][cargo/10133]
- [Support `term.quiet` configuration][cargo/10152]
- [Remove `--host` from cargo {publish,search,login}][cargo/10145]

Compatibility Notes
-------------------

- [Refactor weak symbols in std::sys::unix][90846]
  This may add new, versioned, symbols when building with a newer glibc, as the
  standard library uses weak linkage rather than dynamically attempting to load
  certain symbols at runtime.
- [Deprecate crate_type and crate_name nested inside `#![cfg_attr]`][83744]
  This adds a future compatibility lint to supporting the use of cfg_attr
  wrapping either crate_type or crate_name specification within Rust files;
  it is recommended that users migrate to setting the equivalent command line
  flags.
- [Remove effect of `#[no_link]` attribute on name resolution][92034]
  This may expose new names, leading to conflicts with preexisting names in a
  given namespace and a compilation failure.
- [Cargo will document libraries before binaries.][cargo/10172]
- [Respect doc=false in dependencies, not just the root crate][cargo/10201]
- [Weaken guarantee around advancing underlying iterators in zip][83791]
- [Make split_inclusive() on an empty slice yield an empty output][89825]
- [Update std::env::temp_dir to use GetTempPath2 on Windows when
  available.][89999]
- [unreachable! was updated to match other formatting macro behavior
  on Rust 2021][92137]

Internal Changes
----------------

These changes provide no direct user facing benefits, but represent significant
improvements to the internals and overall performance of rustc
and related tools.

- [Fix many cases of normalization-related ICEs][91255]
- [Replace dominators algorithm with simple Lengauer-Tarjan][85013]
- [Store liveness in interval sets for region inference][90637]

- [Remove `in_band_lifetimes` from the compiler and standard library,
  in preparation for removing this unstable feature.][91867]

[91867]: rust-lang/rust#91867
[83744]: rust-lang/rust#83744
[83791]: rust-lang/rust#83791
[85013]: rust-lang/rust#85013
[89825]: rust-lang/rust#89825
[89999]: rust-lang/rust#89999
[90128]: rust-lang/rust#90128
[90207]: rust-lang/rust#90207
[90521]: rust-lang/rust#90521
[90586]: rust-lang/rust#90586
[90637]: rust-lang/rust#90637
[90833]: rust-lang/rust#90833
[90846]: rust-lang/rust#90846
[91003]: rust-lang/rust#91003
[91172]: rust-lang/rust#91172
[91255]: rust-lang/rust#91255
[91284]: rust-lang/rust#91284
[91535]: rust-lang/rust#91535
[91593]: rust-lang/rust#91593
[91728]: rust-lang/rust#91728
[91878]: rust-lang/rust#91878
[91896]: rust-lang/rust#91896
[91926]: rust-lang/rust#91926
[91984]: rust-lang/rust#91984
[92020]: rust-lang/rust#92020
[92034]: rust-lang/rust#92034
[92483]: rust-lang/rust#92483
[cargo/10088]: rust-lang/cargo#10088
[cargo/10133]: rust-lang/cargo#10133
[cargo/10145]: rust-lang/cargo#10145
[cargo/10152]: rust-lang/cargo#10152
[cargo/10165]: rust-lang/cargo#10165
[cargo/10172]: rust-lang/cargo#10172
[cargo/10201]: rust-lang/cargo#10201
[cargo/10269]: rust-lang/cargo#10269

[cstr_from_bytes]: https://doc.rust-lang.org/stable/std/ffi/struct.CStr.html#method.from_bytes_with_nul_unchecked
[muninit_ptr]: https://doc.rust-lang.org/stable/std/mem/union.MaybeUninit.html#method.as_ptr
[muninit_init]: https://doc.rust-lang.org/stable/std/mem/union.MaybeUninit.html#method.assume_init
[muninit_init_ref]: https://doc.rust-lang.org/stable/std/mem/union.MaybeUninit.html#method.assume_init_ref
[unwindsafe_once]: https://doc.rust-lang.org/stable/std/sync/struct.Once.html#impl-UnwindSafe
[refunwindsafe_once]: https://doc.rust-lang.org/stable/std/sync/struct.Once.html#impl-RefUnwindSafe
[tryfrom_ref_arr]: https://doc.rust-lang.org/stable/std/convert/trait.TryFrom.html#impl-TryFrom%3C%26%27_%20mut%20%5BT%5D%3E
[lowercase]: https://doc.rust-lang.org/stable/std/char/struct.ToLowercase.html#impl-DoubleEndedIterator
[uppercase]: https://doc.rust-lang.org/stable/std/char/struct.ToUppercase.html#impl-DoubleEndedIterator
[try_from_char_err]: https://doc.rust-lang.org/stable/std/char/struct.TryFromCharError.html
[available_parallelism]: https://doc.rust-lang.org/stable/std/thread/fn.available_parallelism.html
[result-copied]: https://doc.rust-lang.org/stable/std/result/enum.Result.html#method.copied
[result-cloned]: https://doc.rust-lang.org/stable/std/result/enum.Result.html#method.cloned
[asm]: https://doc.rust-lang.org/stable/core/arch/macro.asm.html
[global_asm]: https://doc.rust-lang.org/stable/core/arch/macro.global_asm.html
[is_break]: https://doc.rust-lang.org/stable/std/ops/enum.ControlFlow.html#method.is_break
[is_continue]: https://doc.rust-lang.org/stable/std/ops/enum.ControlFlow.html#method.is_continue
[try_from_char_u8]: https://doc.rust-lang.org/stable/std/primitive.char.html#impl-TryFrom%3Cchar%3E
[zip]: https://doc.rust-lang.org/stable/std/iter/fn.zip.html
[is_power_of_two8]: https://doc.rust-lang.org/stable/core/num/struct.NonZeroU8.html#method.is_power_of_two
[is_power_of_two16]: https://doc.rust-lang.org/stable/core/num/struct.NonZeroU16.html#method.is_power_of_two
[is_power_of_two32]: https://doc.rust-lang.org/stable/core/num/struct.NonZeroU32.html#method.is_power_of_two
[is_power_of_two64]: https://doc.rust-lang.org/stable/core/num/struct.NonZeroU64.html#method.is_power_of_two
[is_power_of_two128]: https://doc.rust-lang.org/stable/core/num/struct.NonZeroU128.html#method.is_power_of_two
[stdarch/1266]: rust-lang/stdarch#1266
netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this issue Apr 15, 2022
Pkgsrc changes:
 * Bump available bootstraps to 1.58.1.
 * Adjust one patch (and checksum) so that it still applies.

Upstream changes:

Version 1.59.0 (2022-02-24)
==========================

Language
--------

- [Stabilize default arguments for const generics][90207]
- [Stabilize destructuring assignment][90521]
- [Relax private in public lint on generic bounds and where clauses
  of trait impls][90586]
- [Stabilize asm! and global_asm! for x86, x86_64, ARM, Aarch64,
  and RISC-V][91728]

Compiler
--------

- [Stabilize new symbol mangling format, leaving it opt-in
  (-Csymbol-mangling-version=v0)][90128]
- [Emit LLVM optimization remarks when enabled with `-Cremark`][90833]
- [Fix sparc64 ABI for aggregates with floating point members][91003]
- [Warn when a `#[test]`-like built-in attribute macro is present
  multiple times.][91172]
- [Add support for riscv64gc-unknown-freebsd][91284]
- [Stabilize `-Z emit-future-incompat` as `--json future-incompat`][91535]
- [Soft disable incremental compilation][94124]

This release disables incremental compilation, unless the user has explicitly
opted in via the newly added RUSTC_FORCE_INCREMENTAL=1 environment variable.
This is due to a known and relatively frequently occurring bug in incremental
compilation, which causes builds to issue internal compiler errors. This
particular bug is already fixed on nightly, but that fix has not yet rolled out
to stable and is deemed too risky for a direct stable backport.

As always, we encourage users to test with nightly and report bugs so that we
can track failures and fix issues earlier.

See [94124] for more details.

[94124]: rust-lang/rust#94124

Libraries
---------

- [Remove unnecessary bounds for some Hash{Map,Set} methods][91593]

Stabilized APIs
---------------

- [`std::thread::available_parallelism`][available_parallelism]
- [`Result::copied`][result-copied]
- [`Result::cloned`][result-cloned]
- [`arch::asm!`][asm]
- [`arch::global_asm!`][global_asm]
- [`ops::ControlFlow::is_break`][is_break]
- [`ops::ControlFlow::is_continue`][is_continue]
- [`TryFrom<char> for u8`][try_from_char_u8]
- [`char::TryFromCharError`][try_from_char_err]
  implementing `Clone`, `Debug`, `Display`, `PartialEq`, `Copy`, `Eq`, `Error`
- [`iter::zip`][zip]
- [`NonZeroU8::is_power_of_two`][is_power_of_two8]
- [`NonZeroU16::is_power_of_two`][is_power_of_two16]
- [`NonZeroU32::is_power_of_two`][is_power_of_two32]
- [`NonZeroU64::is_power_of_two`][is_power_of_two64]
- [`NonZeroU128::is_power_of_two`][is_power_of_two128]
- [`DoubleEndedIterator for ToLowercase`][lowercase]
- [`DoubleEndedIterator for ToUppercase`][uppercase]
- [`TryFrom<&mut [T]> for [T; N]`][tryfrom_ref_arr]
- [`UnwindSafe for Once`][unwindsafe_once]
- [`RefUnwindSafe for Once`][refunwindsafe_once]
- [armv8 neon intrinsics for aarch64][stdarch/1266]

Const-stable:

- [`mem::MaybeUninit::as_ptr`][muninit_ptr]
- [`mem::MaybeUninit::assume_init`][muninit_init]
- [`mem::MaybeUninit::assume_init_ref`][muninit_init_ref]
- [`ffi::CStr::from_bytes_with_nul_unchecked`][cstr_from_bytes]

Cargo
-----

- [Stabilize the `strip` profile option][cargo/10088]
- [Stabilize future-incompat-report][cargo/10165]
- [Support abbreviating `--release` as `-r`][cargo/10133]
- [Support `term.quiet` configuration][cargo/10152]
- [Remove `--host` from cargo {publish,search,login}][cargo/10145]

Compatibility Notes
-------------------

- [Refactor weak symbols in std::sys::unix][90846]
  This may add new, versioned, symbols when building with a newer glibc, as the
  standard library uses weak linkage rather than dynamically attempting to load
  certain symbols at runtime.
- [Deprecate crate_type and crate_name nested inside `#![cfg_attr]`][83744]
  This adds a future compatibility lint to supporting the use of cfg_attr
  wrapping either crate_type or crate_name specification within Rust files;
  it is recommended that users migrate to setting the equivalent command line
  flags.
- [Remove effect of `#[no_link]` attribute on name resolution][92034]
  This may expose new names, leading to conflicts with preexisting names in a
  given namespace and a compilation failure.
- [Cargo will document libraries before binaries.][cargo/10172]
- [Respect doc=false in dependencies, not just the root crate][cargo/10201]
- [Weaken guarantee around advancing underlying iterators in zip][83791]
- [Make split_inclusive() on an empty slice yield an empty output][89825]
- [Update std::env::temp_dir to use GetTempPath2 on Windows when
  available.][89999]
- [unreachable! was updated to match other formatting macro behavior
  on Rust 2021][92137]

Internal Changes
----------------

These changes provide no direct user facing benefits, but represent significant
improvements to the internals and overall performance of rustc
and related tools.

- [Fix many cases of normalization-related ICEs][91255]
- [Replace dominators algorithm with simple Lengauer-Tarjan][85013]
- [Store liveness in interval sets for region inference][90637]

- [Remove `in_band_lifetimes` from the compiler and standard library,
  in preparation for removing this unstable feature.][91867]

[91867]: rust-lang/rust#91867
[83744]: rust-lang/rust#83744
[83791]: rust-lang/rust#83791
[85013]: rust-lang/rust#85013
[89825]: rust-lang/rust#89825
[89999]: rust-lang/rust#89999
[90128]: rust-lang/rust#90128
[90207]: rust-lang/rust#90207
[90521]: rust-lang/rust#90521
[90586]: rust-lang/rust#90586
[90637]: rust-lang/rust#90637
[90833]: rust-lang/rust#90833
[90846]: rust-lang/rust#90846
[91003]: rust-lang/rust#91003
[91172]: rust-lang/rust#91172
[91255]: rust-lang/rust#91255
[91284]: rust-lang/rust#91284
[91535]: rust-lang/rust#91535
[91593]: rust-lang/rust#91593
[91728]: rust-lang/rust#91728
[91878]: rust-lang/rust#91878
[91896]: rust-lang/rust#91896
[91926]: rust-lang/rust#91926
[91984]: rust-lang/rust#91984
[92020]: rust-lang/rust#92020
[92034]: rust-lang/rust#92034
[92483]: rust-lang/rust#92483
[cargo/10088]: rust-lang/cargo#10088
[cargo/10133]: rust-lang/cargo#10133
[cargo/10145]: rust-lang/cargo#10145
[cargo/10152]: rust-lang/cargo#10152
[cargo/10165]: rust-lang/cargo#10165
[cargo/10172]: rust-lang/cargo#10172
[cargo/10201]: rust-lang/cargo#10201
[cargo/10269]: rust-lang/cargo#10269

[cstr_from_bytes]: https://doc.rust-lang.org/stable/std/ffi/struct.CStr.html#method.from_bytes_with_nul_unchecked
[muninit_ptr]: https://doc.rust-lang.org/stable/std/mem/union.MaybeUninit.html#method.as_ptr
[muninit_init]: https://doc.rust-lang.org/stable/std/mem/union.MaybeUninit.html#method.assume_init
[muninit_init_ref]: https://doc.rust-lang.org/stable/std/mem/union.MaybeUninit.html#method.assume_init_ref
[unwindsafe_once]: https://doc.rust-lang.org/stable/std/sync/struct.Once.html#impl-UnwindSafe
[refunwindsafe_once]: https://doc.rust-lang.org/stable/std/sync/struct.Once.html#impl-RefUnwindSafe
[tryfrom_ref_arr]: https://doc.rust-lang.org/stable/std/convert/trait.TryFrom.html#impl-TryFrom%3C%26%27_%20mut%20%5BT%5D%3E
[lowercase]: https://doc.rust-lang.org/stable/std/char/struct.ToLowercase.html#impl-DoubleEndedIterator
[uppercase]: https://doc.rust-lang.org/stable/std/char/struct.ToUppercase.html#impl-DoubleEndedIterator
[try_from_char_err]: https://doc.rust-lang.org/stable/std/char/struct.TryFromCharError.html
[available_parallelism]: https://doc.rust-lang.org/stable/std/thread/fn.available_parallelism.html
[result-copied]: https://doc.rust-lang.org/stable/std/result/enum.Result.html#method.copied
[result-cloned]: https://doc.rust-lang.org/stable/std/result/enum.Result.html#method.cloned
[asm]: https://doc.rust-lang.org/stable/core/arch/macro.asm.html
[global_asm]: https://doc.rust-lang.org/stable/core/arch/macro.global_asm.html
[is_break]: https://doc.rust-lang.org/stable/std/ops/enum.ControlFlow.html#method.is_break
[is_continue]: https://doc.rust-lang.org/stable/std/ops/enum.ControlFlow.html#method.is_continue
[try_from_char_u8]: https://doc.rust-lang.org/stable/std/primitive.char.html#impl-TryFrom%3Cchar%3E
[zip]: https://doc.rust-lang.org/stable/std/iter/fn.zip.html
[is_power_of_two8]: https://doc.rust-lang.org/stable/core/num/struct.NonZeroU8.html#method.is_power_of_two
[is_power_of_two16]: https://doc.rust-lang.org/stable/core/num/struct.NonZeroU16.html#method.is_power_of_two
[is_power_of_two32]: https://doc.rust-lang.org/stable/core/num/struct.NonZeroU32.html#method.is_power_of_two
[is_power_of_two64]: https://doc.rust-lang.org/stable/core/num/struct.NonZeroU64.html#method.is_power_of_two
[is_power_of_two128]: https://doc.rust-lang.org/stable/core/num/struct.NonZeroU128.html#method.is_power_of_two
[stdarch/1266]: rust-lang/stdarch#1266
@workingjubilee
Copy link
Member

I believe that since these mitigations were deployed in the short-term and since these problems were resolved in the long term, we can close this as one more chapter in Rust's intriguing history?

@philipcraig
Copy link
Contributor

I believe that since these mitigations were deployed in the short-term and since these problems were resolved in the long term, we can close this as one more chapter in Rust's intriguing history?

Agreed.

@tmandry tmandry closed this as completed Mar 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-incr-comp Area: Incremental compilation C-bug Category: This is a bug. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests