jiebi/CodeConvo huggingface dataset:
Code change:
// there's no need to do dep-graph tracking for any of it. tcx.dep_graph.assert_ignored(); <del> join( || encode_metadata_impl(tcx, path), || { if tcx.sess.threads() == 1 { return; } // Prefetch some queries used by metadata encoding. // This is not necessary for correctness, but is only done for performance reasons. // It can be removed if it turns out to cause trouble or be detrimental to performance. join(|| prefetch_mir(tcx), || tcx.exported_symbols(LOCAL_CRATE)); }, ); } </del> <ins> if tcx.sess.threads() != 1 { // Prefetch some queries used by metadata encoding. // This is not necessary for correctness, but is only done for performance reasons. // It can be removed if it turns out to cause trouble or be detrimental to performance. join(|| prefetch_mir(tcx), || tcx.exported_symbols(LOCAL_CRATE)); } </ins> <del> fn encode_metadata_impl(tcx: TyCtxt<'_>, path: &Path) { </del> let mut encoder = opaque::FileEncoder::new(path) .unwrap_or_else(|err| tcx.sess.emit_fatal(FailCreateFileEncoder { err })); encoder.emit_raw_bytes(METADATA_HEADER);

Related discussion:
text: <!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
another one
Code change:
// there's no need to do dep-graph tracking for any of it. tcx.dep_graph.assert_ignored(); <del> join( || encode_metadata_impl(tcx, path), || { if tcx.sess.threads() == 1 { return; } // Prefetch some queries used by metadata encoding. // This is not necessary for correctness, but is only done for performance reasons. // It can be removed if it turns out to cause trouble or be detrimental to performance. join(|| prefetch_mir(tcx), || tcx.exported_symbols(LOCAL_CRATE)); }, ); } </del> <ins> if tcx.sess.threads() != 1 { // Prefetch some queries used by metadata encoding. // This is not necessary for correctness, but is only done for performance reasons. // It can be removed if it turns out to cause trouble or be detrimental to performance. join(|| prefetch_mir(tcx), || tcx.exported_symbols(LOCAL_CRATE)); } </ins> <del> fn encode_metadata_impl(tcx: TyCtxt<'_>, path: &Path) { </del> let mut encoder = opaque::FileEncoder::new(path) .unwrap_or_else(|err| tcx.sess.emit_fatal(FailCreateFileEncoder { err })); encoder.emit_raw_bytes(METADATA_HEADER);

Related discussion:
text: I just tried out the new parallelization feature of the compiler and it randomly panicked because a deadlock was detected. I tried a couple of times and could not reproduce it unfortunately. : <details<summary<strongBacktrace</strong</summary<p</p</details
Could you provide the minimal example causes the ICE?
The project I compiled was huge and I was not able to consistently reproduce it so reducing my case to a minimal example might take forever. Buy I noticed the issue you linked already contains a fairly small example code so it's probably alright to close my ticket since it seems to be a duplicate of that other ticket anyway.
Can you reproduce this bug using the latest nightly version to get the new error output?
Yes. It appears to be the same issue (albeit while compiling a different dependency but that probably doesn't matter):
BTW with the latest nightly the compiler always and immediately panics and produces multiple back traces. version: nightly-aarch64-apple-darwin unchanged - rustc 1.76.0-nightly ( 2023-12-05) <details<summarycompiler error</summary</details
It would be fixed by
Code change:
// there's no need to do dep-graph tracking for any of it. tcx.dep_graph.assert_ignored(); <del> join( || encode_metadata_impl(tcx, path), || { if tcx.sess.threads() == 1 { return; } // Prefetch some queries used by metadata encoding. // This is not necessary for correctness, but is only done for performance reasons. // It can be removed if it turns out to cause trouble or be detrimental to performance. join(|| prefetch_mir(tcx), || tcx.exported_symbols(LOCAL_CRATE)); }, ); } </del> <ins> if tcx.sess.threads() != 1 { // Prefetch some queries used by metadata encoding. // This is not necessary for correctness, but is only done for performance reasons. // It can be removed if it turns out to cause trouble or be detrimental to performance. join(|| prefetch_mir(tcx), || tcx.exported_symbols(LOCAL_CRATE)); } </ins> <del> fn encode_metadata_impl(tcx: TyCtxt<'_>, path: &Path) { </del> let mut encoder = opaque::FileEncoder::new(path) .unwrap_or_else(|err| tcx.sess.emit_fatal(FailCreateFileEncoder { err })); encoder.emit_raw_bytes(METADATA_HEADER);

Related discussion:
text: <!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --I have tried to measure on a 32 core machine and got this ice after several tries. Steps to reproduce: I have got it 2 times in a row, so it should be reproducible. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --:
searched nightlies: from nightly-2023-11-03 to nightly-2023-11-09 regressed nightly: nightly-2023-11-07 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
modify labels: +A-parallel-queries
modify labels: +WG-compiler-parallel
Can you reproduce this bug using the latest nightly version to get the new error output?
I can build rustc from the sources if you need to check something.
That's all right. It's a same error with other issues
Code change:
pub struct Zip<A, B> { a: A, b: B, <del> // index and len are only used by the specialized version of zip </del> <ins> // index, len and a_len are only used by the specialized version of zip </ins> index: usize, len: usize, <ins> a_len: usize, </ins> } impl<A: Iterator, B: Iterator> Zip<A, B> { pub(in crate::iter) fn new(a: A, b: B) -> Zip<A, B> {

Related discussion:
text: Here is called for potential side effects until , ignoring however that it could have already been called in with those indexes. that demonstrates how this can be exploited to get two mutable references to the same data and cause an use-after-free bug.
Assigning as part of the .
The gift that keeps on giving Maybe it is time to get rid of as it exists today and replace it with a ? One that imposes the additional requirement on the caller that it must bring the iterator back into a safe state after it is done iterating. The upside would be eliminating a lot of code in and enabling the same optimization for and similar sources. While the downside would be that external iteration (i.e. loops and manual calls to ) would cease to benefit from optimizations and only internal iteration methods (including ) would continue to do so.
I don't know, I feel like that would just make more complex to upheld the invariants. IMO a good improvement over the current would be separating forward and backward iteration, this way it becomes easier to keep track of the state and I think would also make it possible to implement them for
I don't see how separating the forward and backward state would help with a drop implementation. The issue is that the source () currently does not have access to that state, instead the consumer drives the iteration by direct access through and never informs the source about it.
It would help because it allows the source iterator to keep track of its state by updating it when the method is called. Anyway, looks like someone already and it resulted in worse optimizations, but maybe LLVM got better in the meantime, or maybe that implementation could have been better. Anyway I don't think this is the right place to discuss this, a topic on zulip would probably be better.
https://rust-
Code change:
<ins> // run-pass // compile-flags: -C opt-level=1 // Make sure LLVM does not miscompile this match. fn main() { enum Bits { None = 0x00, Low = 0x40, High = 0x80, Both = 0xC0, } let value = Box::new(0x40u8); let mut out = Box::new(0u8); let bits = match *value { 0x00 => Bits::None, 0x40 => Bits::Low, 0x80 => Bits::High, 0xC0 => Bits::Both, _ => return, }; match bits { Bits::None | Bits::Low => { *out = 1; } _ => (), } assert_eq!(*out, 1); } </ins>

Related discussion:
text: Minimized from : This issue was introduced in the build, and so it is likely to be a result of the upgrade to LLVM 17 ().
I have bisected the LLVM pass to the pass on main. I'm trying to get a diff of before/after so I can start tracking down the exact location of the incorrect optimization.
The optimization transforms this switch lookup which appears to correspond to the : with only the calculation of and changing from: to: with the rest of the IR remaining unchanged. The transform of appears to be okay ( by 64 -by 6). The transform of introduces the issue because although the instruction is marked as , is equal to which is negative in the signed representation and so subtracting 128 does cause signed underflow.
The IR output from rustc without any optimization passes outputs is: Which appears correct to me. This suggests that the is being introduced in a later optimization pass. I'll continue bisecting when I get a chance.
Looks like this instruction is being generated by a pass that's run before the pass. Before : Which is correct. So the real errant pass is , it just doesn't cause incorrect x86 to be emitted until a later pass.
Looks like this issue is known and a fix is in progress upstream at
Code change:
<ins> // check-pass use std::ops::Deref; struct Data { boxed: Box<&'static i32> } impl Data { fn use_data(&self, user: impl for <'a> FnOnce(<Box<&'a i32> as Deref>::Target)) { user(*self.boxed) } } fn main() {} </ins>

Related discussion:
text: <!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --This code compiles correctly: However, this code does not: The only change was effectively replacing with . My understanding is that these are supposed to be equivalent as it is . The exact compile error is as follows: The error also occurs on the Nightly compiler.
We currently do not normalize projections if they contain unbound variables (stuff which is introduced using a qualifier, in your example). This means that we never actually see that is equal to . cc but I don't think we can do much about cases like this for now.
Is this the same underlying issue as and possibly
I think has a similar cause. is caused by something different, probably related to
Using trait objects instead of has the same issue
Came up with another interesting version. This will fail to typecheck: Replacing the header of foo with this will successfully typecheck: Might be useful for diffing.
Fixed by . Not going to close this because this is a simple example that didn't ICE, but still failed to compile.
Code change:
<ins> // check-pass use std::ops::Deref; struct Data { boxed: Box<&'static i32> } impl Data { fn use_data(&self, user: impl for <'a> FnOnce(<Box<&'a i32> as Deref>::Target)) { user(*self.boxed) } } fn main() {} </ins>

Related discussion:
text: I believe this should successfully compile, but it currently fails claiming that vec's iterator isn't ExactSizeIterator: Things compile correctly if the bounds are changed to rather than .
It does seem like it should compile... cc
Another instance of this from : fails with
do you know of a workaround for this bug? It's currently blocking me and I'm not entirely sure how else to structure my code.
The only workaround I know of is to remove the lifetime parameter Steven Fackler
I believe this issue I ran in to might be related - . I was trying to put a bound on an associated type from two different types and require them to be , but Rust always just wanted to assume the types must be the same. By creating a separate trait that is implemented without relying on an HRTB, and then using the HRTB around that trait, it did compile. I'm fairly sure this is a bug. rustc ought to still be able to resolve what the associated type actually is and then evaluate traits on that. It seems like it's trying to look for implementations on a hypothetical associated type black box rather than the real type it points to.
Another example, when trying to bind :
Ran into this in one of my own projects, and used this odd workaround (suggested on satck overflow):
Another variation of this issue (as far as I can tell): Fails with:
I just ran into this (): I get the following error on latest stable (1.52.1): The workaround in my case was to pull out the associated type into a type parameter, and require that it be invariant w.r.t. the universally quantified lifetime parameter ():
Fixed by , marking as needs-test because wasn't an ICE and a simple enough example I'd like to have a test for.
This bug might not be completely fixed. Here is another test case that still fails on nightly and beta: EDIT: Made the case a bit smaller:
is the smallest example I can find: This below works: While this doesn't: Can you confirm that the second case works in your PR as well?
is still not fixed on latest nightly. cc EDIT: I suspect that this example is some form of .
Another bug of this kind:
Code change:
type Wub = !; //~ ERROR type is experimental } <ins> fn look_ma_no_feature_gate<F: FnOnce() -> !>() {} //~ ERROR type is experimental fn tadam(f: &dyn Fn() -> !) {} //~ ERROR type is experimental fn panic() -> ! { panic!(); } fn toudoum() -> impl Fn() -> ! { //~ ERROR type is experimental panic } </ins> fn main() { }

Related discussion:
text: I tried this code: I expected to see this happen: “error[E0658]: the type is experimental” Instead, this happened: Successful compilation, as long as I'm using a nightly compiler, but the error when on stable 1.75. This is incorrect because nightly features should always require attributes on nightly (until they're stabilized, which hasn't happened yet for ). <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: label +F-never_type +requires-nightly
searched nightlies: from nightly-2023-11-11 to nightly-2024-02-01 regressed nightly: nightly-2024-01-27 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsThen, bisecting Manually verified that reverting (as ) restored the error. cc
Not sure to understand why fixing the visitor implementation introduced this bug. Maybe it highlighted a limitation? Gonna check.
Ok I think I know why: implementation of the not calling the equivalent function. Checking where it is used.
WG-prioritization assigning priority (). label -I-prioritize +P-high
Fix was already approved in . Waiting for CI to be unlocked.
Code change:
//! are elements, and once they've all been exhausted, will return `None` to //! indicate that iteration is finished. Individual iterators may choose to //! resume iteration, and so calling [`next`] again may or may not eventually <del> //! start returning `Some(Item)` again at some point. </del> <ins> //! start returning `Some(Item)` again at some point (for example, see [`TryIter`]). </ins> //! //! [`Iterator`]'s full definition includes a number of other methods as well, //! but they are default methods, built on top of [`next`], and so you get

Related discussion:
text: If the wrapped iterator implements then blindly delegates to it. The underlying iterator may know its exact size but return spurious results anyway, on which will stop iterating even though the source knows that there are elements left to iterate, meaning will indicate that there are elements left but never return them. The behavior was introduced in but didn't see any discussion.
Implementations of have soundness implications, thus marking as . That being said, the documentation for is fairly exact in its wording that the first means "end of iteration".
Hm, seeing as is not an unsafe trait, I would not expect code to be able to rely on it for soundness? Maybe we do so internally for std types though...
Unsafe code can't rely on correctness (there's for that). The length of an iterator is defined as the number of items yielded before it returns None, so Fuse's implementation is correct.
Oh my bad, I was confusing it with TrustedLen.
Ok, makes sense. But I will be pedantic here since I prefer documentation to have slightly more formal flavor. docs: The module documentation: Now resume can be interpreted as continuing the the previous iteration instead of starting a new iteration (conceptually a new iteration would require a new iterator then). Under this interpretation should report the complete length of all iteration including possible resumptions which must be known when claiming exact sizing knowledge. The documentation could use a more precise definition of what an iteration is and that resumption is really considered a new iteration.
Code change:
<ins> goto: file://|DOC_PATH|/test_docs/type.SomeType.html assert-all: (".top-block .docblock p", {"font-weight": "400"}) </ins>

Related discussion:
text: : Local docs: ! But has the same issue: Probably caused by: ()
It seems like this css rule: applies to this element: !. Before () this rule wouldn't have applied because it would've been contrained by instead of .
This also had some other side-effects here: ! The search results have top/bottom margins compared to the previous styling.
The second issue was fixed in I'm checking for the first one, unless you want to send a PR?
Hmm, sorry I didn't/don't have much time to dig into this more. I couldn't think of an immediate fix for this because it kinda looked non-trivial (to me) :/
Don't worry, I'll send a fix in the next hours then.
Code change:
use crate::cache::{Interned, INTERNER}; use crate::cc_detect::{ndk_compiler, Language}; use crate::channel::{self, GitInfo}; <ins> use crate::compile::CODEGEN_BACKEND_PREFIX; </ins> pub use crate::flags::Subcommand; use crate::flags::{Color, Flags, Warnings}; use crate::util::{exe, output, t};

Related discussion:
text: I tried this code: I expected to see this happen: An error saying that is invalid and should be instead. Instead, this happened: <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --HEAD is branched from <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Code change:
// Ignore the notification. None } else { <del> print!( "failed to decode compiler output as json: line: {}noutput: {}", line, output ); panic!() </del> <ins> // This function is called for both compiler and non-compiler output, // so if the line isn't recognized as JSON from the compiler then // just print it as-is. Some(format!("{line}n")) </ins> } } else { // preserve non-JSON lines, such as ICEs

Related discussion:
text: When a process unexpectedly fails/succeeds, compiletest will often print a full dump of its stdout and stderr for diagnostic purposes. When this happens, calls into , which has special handling for lines starting with . It tries to parse the line as JSON in one of a few known compiler-specific formats, in order to replace it with a more human-friendly message. If the line doesn't match any of those formats (or isn't valid JSON), the extractor code will panic, instead of just printing the line as-is. This is awkward in cases where we actually wanted to print the line as-is anyway, because now the error messages are less helpful. label +A-compiletest
The obvious solution (just make it not panic) is complicated by the fact that is called in multiple places, so it's harder to know whether the error is load-bearing in one of those cases.
Code change:
//      'Deprecated$' #[deprecated] pub struct W; <ins> // @matches deprecated/struct.X.html '//*[@class="stab deprecated"]'  //      'Deprecated: shorthand reason$' #[deprecated = "shorthand reason"] pub struct X; </ins>

Related discussion:
text: Look for example to It is deprecated, and in source code there is hint what should be used instead: but in generated html documentation there is no hint about
isn't the correct syntax for the attribute. It should be . You can see it work: . This isn't a rustdoc issue. It's an issue with rustc that it doesn't reject .
Code change:
<ins> error[E0277]: the trait bound `*mut (): Trait<'_>` is not satisfied --> $DIR/issue-101623.rs:21:21 | LL |     Trait::do_stuff({ fun(&mut *inner) }); |     --------------- ^^----------------^^ |     |               | |     |               the trait `Trait<'_>` is not implemented for `*mut ()` |     required by a bound introduced by this call | = help: the trait `Trait<'a>` is implemented for `()` error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>

Related discussion:
text: I tried this code: searched nightlies: from nightly-2022-08-18 to nightly-2022-09-09 regressed nightly: nightly-2022-08-23 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </details<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --
Regression introduced in:
This block around is crucial to trigger the ICE.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Code change:
} } } // Visit everything, but enum variants have their own levels. hir::ItemKind::Enum(ref def, _) => { if item_level.is_some() { self.reach(item.def_id, item_level).generics().predicates(); } <del> let enum_level = self.get(item.def_id); </del> for variant in def.variants { <del> let variant_level = self.update_with_hir_id(variant.id, enum_level); </del> <ins> let variant_level = self.get(self.tcx.hir().local_def_id(variant.id)); </ins> if variant_level.is_some() { <del> if let Some(ctor_id) = variant.data.ctor_hir_id() { self.update_with_hir_id(ctor_id, variant_level); } </del> for field in variant.data.fields() { self.reach(self.tcx.hir().local_def_id(field.hir_id), variant_level) .ty();

Related discussion:
text: EDIT (ehuss) Reproduction: Clone <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
We are seeing this too on rustc 1.60.0-nightly ( 2022-01-10) running on aarch64-apple-darwin
label +I-prioritize
cc This seems to have regressed starting with .
I'm taking a look
I can reproduce and I did find some differences in the access level table. seems to be missing when it's supposed to be Reachable in the good version. I'll investigate further Updates: Actually, the whole Impl seems to be missing. It should be marked as Reachable but is not even there. claim
Marking as , as .
Same on Mac, on x86_64-apple-darwin as well, same toolchain version (rustc 1.60.0-nightly ( 2022-01-10))
As an update for those watching: currently, the best workaround is to use an older nightly. The good news is that a fix PR is open (), with people working on getting it in shape to be merged.