jiebi/CodeConvo huggingface dataset:
Change:
<ins> // Copyright 2013 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. pub enum Foo<'a> { A, B(&'a str), } </ins>

Discussion:
Having a generic seems to be necessary to exhibit the bug. (Caused .)
Reproduced with . Nominating.
cc me
declining; just-a-bug
cc me; possibly addressed by patch to
This has been fixed, adding a test for it soon.

Nominating well defined.
This seems to be fixed.
Not quite: If you put on the inner module, it works. I think this is actually working as intended: the 'pub' on the item being re-exported is itself the indication of whether it can be seen from outside. Curiously, you can't use it locally (with no anywhere in the file) either. This feels not entirely well defined? Or else I'm not well informed enough to address it. Leaving open until we have Patrick around for subsequent triage.
My two cents: makes sense that a 'd item must be , since that means you don't have to search for a pub use. seems like ought to work though.
accepted for well-defined milestone
This is working now. I think my extraction of privacy from resolve has fixed this. Removing all tags and flagging as needstest.
Change:
<ins> // Copyright 2013 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. pub enum Foo<'a> { A, B(&'a str), } </ins>

Discussion:
With the following test code: You get an ICE:
Looks quite similar to , which is probably .
After updating for removal of and feature-gating of macros, I don't get ICE any more.
Almost certainly fixed by

This code: Causes the ICE cc
Also a similar, but different error:
I've also confirmed that if everything is defined in the same crate, it all compiles just fine.
This may be related to , although it's a different error message so I'm not sure of it.
This is not related to
I just ran into this myself. One interesting thing I found is that the error happens due to the empty variant. This compiles fine for me:
Appears to be fixed now, flagging as needstest.

To replicate: (Original report follows:) I had code like this: This causes rustc to spin forever. Here's the interesting part of the stack trace:
In my attempt to replicate the bug (on a Mac OS machine), this appears to ICE now rather than hang.
(The fact that it ICE's now rather than diverges is probably thanks to )
Reproduced with
This was fixed at some point, the error message is now: which is exactly what one would expect! Flagging as needstest.
Change:
<ins> // Test for absence of validation mismatch ICE in #65394 #![feature(rustc_attrs)] #[rustc_mir(borrowck_graphviz_postflow="hello.dot")] const _: Vec<i32> = { let mut x = Vec::<i32>::new(); let r = &mut x; //~ ERROR references in constants may only refer to immutable values let y = x; y }; fn main() {} </ins>

Discussion:
Offending snippet using : The code shouldn't build, as per the first few errors below, but currently on nightly it also causes the compiler to panic. It does not panic on stable or beta. Version: 1.40.0-nightly (2019-10-12 ) Playground: Quite possibly a duplicate of just buried inside the macro expansion but I'm not familiar enough with Rust compiler internals to make that determination.
cc
I've to the following: A mutable reference is required in all variants of this, so this particular mismatch does not represent a true backwards compatibility hazard: Creating a reference that would allow mutation is forbidden in all contexts. We could simply stop triggering the mismatch ICE when both lists contain the same error. The underlying issue, however, is that is being too conservative once again. As soon as a mutable reference is taken to , we use type-based qualification instead of looking at the qualif which gets cleared when is moved from. Increasing the precision here would require a dataflow analysis. This would get checked first whenever was queried (much like how we currently check first). I believe this will be necessary when we do allow in contexts, otherwise writing code would be quite painful. I could hack together a solution for this particular case that doesn't require another dataflow analysis. Basically, during validation, we could keep track of which s have been moved out of in the current basic block and use that as a conservative approximation of . This would fail if the local was moved from in one basic block and then dropped in a successor of that block. It seems relatively hard to write rust code that gets translated to that MIR, however. For example, the following does not do it, but I think it should be possible.
cc
Checking for moves in the same block fails pretty often. I've implemented the first fix described above, but we probably want to use a analysis in the long term.
triage: P-medium. Assigning to . Removing nomination label.
Change:
pub backend: Interned<String>, } <ins> fn needs_codegen_config(run: &RunConfig<'_>) -> bool { let mut needs_codegen_cfg = false; for path_set in &run.paths { needs_codegen_cfg = match path_set { PathSet::Set(set) => set.iter().any(|p| is_codegen_cfg_needed(p, run)), PathSet::Suite(suite) => is_codegen_cfg_needed(&suite, run), } } needs_codegen_cfg } const CODEGEN_BACKEND_PREFIX: &str = "rustc_codegen_"; fn is_codegen_cfg_needed(path: &TaskPath, run: &RunConfig<'_>) -> bool { if path.path.to_str().unwrap().contains(&CODEGEN_BACKEND_PREFIX) { let mut needs_codegen_backend_config = true; for &backend in &run.builder.config.rust_codegen_backends { if path .path .to_str() .unwrap() .ends_with(&(CODEGEN_BACKEND_PREFIX.to_owned() + &backend)) { needs_codegen_backend_config = false; } } if needs_codegen_backend_config { run.builder.info( "Warning: no codegen-backends config matched the requested path to build a codegen backend.  Help: add backend to codegen-backends in config.toml.", ); return true; } } return false; } </ins> impl Step for CodegenBackend { type Output = (); const ONLY_HOSTS: bool = true;

Discussion:
I tried this code: I expected this to happen: Bootstrap builds cranelift, since I named it explicitly. Instead, this happened: Nothing, since I didn't have cranelift configured in : At a minimum, I would expect this to give an error or warning that I need to configure codegen-backends. It would be even nicer if we could treat as only controlling the defaults, instead of as a hard-off switch, like how works. That should be possible to do by looking at the we're passed. cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
The first element in codegen-backends is used as default backend. In addition even if the CodegenBackend step were to directly use the passed in paths, assembling the toolchain did still only add the backends in codegen-backends to the sysroot. Having path specifiers for one step affect another step doesn't feel right. For check builds I do agree this is an improvement. Although I personally actually use this behavior to have build all backends, not just cranelift (by enabling all in codegen-backends) It did be nice to have a replacement for this. In addition for at the very least a warning makes sense.
Does it make sense to separate cgclif and cggcc into different steps in that case? cc
That doesn't have any effect on if specifying a backend as path will add it to the sysroot.
Change:
1|       |// Regression test for issue #98833. <del> 2|       |// compile-flags: -Zinline-mir </del> <ins> 2|       |// compile-flags: -Zinline-mir -Cdebug-assertions=off </ins> 3|       | 4|      1|fn main() { 5|      1|    println!("{}", live::<false>()); <del> 6|      1|} 7|       | 8|       |#[inline] 9|      1|fn live<const B: bool>() -> u32 { 10|      1|    if B { 11|      0|        dead() 12|       |    } else { 13|      1|        0 14|       |    } 15|      1|} 16|       | 17|       |#[inline] 18|      0|fn dead() -> u32 { 19|      0|    42 20|      0|} </del> <ins> 6|      1| 7|      1|    let f = |x: bool| { 8|       |        debug_assert!( 9|       |            x 10|       |        ); 11|      1|    }; 12|      1|    f(false); 13|      1|} 14|       | 15|       |#[inline] 16|      1|fn live<const B: bool>() -> u32 { 17|      1|    if B { 18|      0|        dead() 19|       |    } else { 20|      1|        0 21|       |    } 22|      1|} 23|       | 24|       |#[inline] 25|      0|fn dead() -> u32 { 26|      0|    42 27|      0|} </ins>

Discussion:
This can be seen here: To reproduce:
Last passing run was so this regressed between 2022-06-30 and 2022-07-02.
Minimized a reproducer. : : Execution:
label regression-untriaged
Bisection says searched nightlies: from nightly-2022-06-29 to nightly-2022-07-03 regressed nightly: nightly-2022-07-03 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsSo,
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Unfortunately while this fixes the minimal reproducer, it doesn't fix the full case. Would you prefer I file a new bug, or should this one be re-opened? To reproduce:
It's not very minimized, but slightly better. : : Empty
searched nightlies: from nightly-2022-07-07 to nightly-2022-07-22 regressed nightly: nightly-2022-07-09 searched commits: from to regressed commit:
Interesting, I had assumed based on the matching panic message that it'd have the same regressing commit.
Happy to report that with the latest nightly we're back to green on nightly. Thanks much
Thanks the first fix was enough for Suricata :-)
Thanks so much, pydantic-core has been pinned to but is not back on nightly.
Change:
}; let origin = TypeVariableOrigin { kind: TypeVariableOriginKind::TypeInference, span }; <del> let trait_def_id = proj.trait_def_id(self.tcx); </del> // Make `Self` be equivalent to the type of the call chain // expression we're looking at now, so that we can tell what // for example `Iterator::Item` is at this point in the chain. <del> let args = GenericArgs::for_item(self.tcx, trait_def_id, |param, _| { match param.kind { ty::GenericParamDefKind::Type { .. } => { if param.index == 0 { return prev_ty.into(); } } ty::GenericParamDefKind::Lifetime | ty::GenericParamDefKind::Const { .. } => {} </del> <ins> let args = GenericArgs::for_item(self.tcx, proj.def_id, |param, _| { if param.index == 0 { debug_assert_matches!(param.kind, ty::GenericParamDefKind::Type { .. }); return prev_ty.into(); </ins> } self.var_for_def(span, param) }); // This will hold the resolved type of the associated type, if the // current expression implements the trait that associated type is // in. For example, this would be what `Iterator::Item` is here. <del> let ty_var = self.infcx.next_ty_var(origin); </del> <ins> let ty = self.infcx.next_ty_var(origin); </ins> // This corresponds to `<ExprTy as Iterator>::Item = _`. let projection = ty::Binder::dummy(ty::PredicateKind::Clause( ty::ClauseKind::Projection(ty::ProjectionPredicate { projection_ty: ty::AliasTy::new(self.tcx, proj.def_id, args), <del> term: ty_var.into(), </del> <ins> term: ty.into(), </ins> }), )); let body_def_id = self.tcx.hir().enclosing_body_owner(body_id);

Discussion:
<!-- 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. --issue appeared when going from 1 -2, was able to fix it by adding 3 <!-- 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
I've only skimmed the code but this is very likely due to the diagnostic method constructing a projection, more precisely an , with created for the trait item, not the associated type (with (pseudo) ), so we're missing the own generic arguments for the GAT.
Change:
(&ty::Adt(def1, sub1), &ty::Adt(def2, sub2)) => { let did1 = def1.did(); let did2 = def2.did(); <del> let sub_no_defaults_1 = self.tcx.generics_of(did1).own_args_no_defaults(self.tcx, sub1); let sub_no_defaults_2 = self.tcx.generics_of(did2).own_args_no_defaults(self.tcx, sub2); </del> <ins> let generics1 = self.tcx.generics_of(did1); let generics2 = self.tcx.generics_of(did2); let non_default_after_default = generics1 .check_concrete_type_after_default(self.tcx, sub1) || generics2.check_concrete_type_after_default(self.tcx, sub2); let sub_no_defaults_1 = if non_default_after_default { generics1.own_args(sub1) } else { generics1.own_args_no_defaults(self.tcx, sub1) }; let sub_no_defaults_2 = if non_default_after_default { generics2.own_args(sub2) } else { generics2.own_args_no_defaults(self.tcx, sub2) }; </ins> let mut values = (DiagStyledString::new(), DiagStyledString::new()); let path1 = self.tcx.def_path_str(did1); let path2 = self.tcx.def_path_str(did2);

Discussion:
or The current error message does not tell me the mismatch is in rather than in . It is also inconsistent with the error message I would get if has without the default types. When removing the default for the first parameter (which is not the mismatched one) like this: the error message is clearer: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
debug!(?normalized_inputs_and_output); <del> for u in ty::UniverseIndex::ROOT..=infcx.universe() { constraints.universe_causes.insert(u, UniverseInfo::other()); } </del> let mut borrowck_context = BorrowCheckContext { universal_regions, location_table,

Discussion:
<!-- 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. --Does not happen with this callback: <!-- 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. --: </p</details
The code snippet is incomplete: is there a repository available that we could try, to reproduce the error? If not, could you at least add the full function? Thanks!
Rust use tungstenite::handshake::server::{Response, ErrorResponse}; fn acceptconnection(stream: TcpStream, config: rustls::server::ServerConfig) -Result<Socket{ let mut conn = rustls::server::ServerConnection::new(std::sync::Arc::new(()))?; let tlsstream = rustls::StreamOwned::new(conn, stream.tryclone()?); if let Ok(ws) = match tungstenite::accepthdrwithconfig(tlsstream, -std::result::Result<Response, ErrorResponse{ let callback = -std::result::Result<tungstenite::handshake::server::Response, tungstenite::handshake::server::ErrorResponse{ dbg!(&req); dbg!(&res); Ok(res) }; if let Ok(ws) = match tungstenite::accepthdrwithconfig(tlsstream, callback, None) { Err(HandshakeError::Interrupted(midhandshake)) ={ info!( "Handshake interrupted with peer {} - waiting to try again.", peer_addr ); Ok(Socket::Interrupted(midhandshake)) } Err(e) ={ error!("Error accepting secure websocket connection: {e}"); Err(e)? } Ok(ws) =Ok(Socket::SecureWebSocket(ws)), } } }
This is still incomplete and doesn't parse. Do you have a repository where the issue can be reproduced?
No repo. You can make it parse pretty easily. I am not a rustc expert but I believe the issue was with the callback.
Here's a small (but not minimal yet) working repro: and with that we can finally bisect, to : probably that (no need to ping anyone here) I'll minimize next to remove this dependency and create an MCVE.
removed:
Probably not yet an MCVE and could be further simplified, but getting close.

62 error -1.63 error + ice
WG-prioritization assigning priority (). label -I-prioritize +P-medium -E-needs-mcve
Change:
<ins> // error-pattern: this file contains an unclosed delimiter // error-pattern: expected value, found struct `R` struct R { } struct S { x: [u8; R </ins>

Discussion:
This malformed code () hangs the compiler: Found by fuzzing with a . must be defined as a named-field struct (not a tuple struct or unit struct), although it can have 0 fields. must be the last token to produce the hang: No opening brace (note that braces are required for literals of named-field structs) No closing delimiters Not even a comment If I understand correctly, the hang occurs in LateResolutionVisitor, with never finishing (while calling various functions such as and ) This also hangs. I'm guessing it's the same bug. : with: <details</summary<p</p</detailsregressed nightly: nightly-2022-10-21 regressed commit: (PR ) label +regression-from-stable-to-nightly +I-hang <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
I can not reproduce it with latest code, did I missed anything?
Great cactch Confirmed the error is only triggered by commit: The root cause is I changed the edge corner case in : We think won't return a span which outside of source file, so is a valid one, then will always return a valid span, and we get from when reaching the end of source. So, there is a loop in previous , which will run infinitely loop: Lucky, my another PR merged at last day, this PR refactored this function:
Verif, I no longer get a hang after rollup Do you want to add one or two of these as tests?
Yes, we'd better add a testcase for it. I'm thinking whether we sould in when reaching to the end of source, so that may get an error.
This testcase seems not easy to be : If so, the trigger point will do not exist,
label -I-prioritize
There's an alternative kind of annotation for patterns that should work for this case:
Change:
<ins> // unit-test: GVN // compile-flags: -O // EMIT_MIR_FOR_EACH_PANIC_STRATEGY // skip-filecheck #![feature(never_type)] #[derive(Copy, Clone)] pub enum E { A(!, u32), } pub union U { i: u32, e: E, } // EMIT_MIR gvn_uninhabited.f.GVN.diff pub const fn f() -> u32 { let E::A(_, i) = unsafe { (&U { i: 0 }).e }; i } fn main() {} </ins>

Discussion:
<!-- 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
seem like options that when paired together would cause issues... At first glance, I'm actually not sure why this is filed as a bug.
I agree. Nobody should be testing , I don't know why those passes are even in the codebase. But this is a bug. I've found this in real code with a much smaller set of flags: And this bisects to Bisected by hand, there's no nightly with that PR yet. Don't know where Matthias got that toolchain.
Afaict likes to do ICE testing against master
We just hit this on Fuchsia as well. I think we should revert the PR until we fix this issue and reland it.
Another one with
Also here's a list of files from the rustc repo that all seem to trigger the problem in one way or another
Looks like there is one more issue in GVN ():
There is no basis for the assumption that interpreter will never downcast to an uninhabited variant:
nice example! That assert was as an experiment to see if we ever hit that codepath, and it seems like the answer is yes. It should thus be removed, with a suitable const-eval test case.
I wonder if that code shouldn't have a read somewhere though... it is conceptually a match after all. Still, the assertion should go: That adds test, but not the others.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
_ if codegen_results.crate_info.profiler_runtime == Some(cnum) => { add_static_crate::<B>(cmd, sess, codegen_results, tmpdir, crate_type, cnum); } <del> _ if codegen_results.crate_info.sanitizer_runtime == Some(cnum) => { </del> <ins> _ if codegen_results.crate_info.sanitizer_runtime == Some(cnum) && crate_type == config::CrateType::Executable => { // Link the sanitizer runtimes only if we are actually producing an executable </ins> link_sanitizer_runtime::<B>(cmd, sess, codegen_results, tmpdir, cnum); } // compiler-builtins are always placed last to ensure that they're

Discussion:
I've noticed today that apparently Rust adds sanitizer runtimes such as the ASan runtime during linking and I found this runtime inside a static archive. As far as I know, these runtimes should not be part of static archives or DSOs, they should only be linked when creating an executable. Adding them to DSOs causes two runtimes to exist when loading the DSO into an ASan binary (we had this problem longer ago in mozilla-central and it was fixed in Clang, see [1]). Adding the runtime to static archives causes linker problems when linking the archive to a C++ binary built with ASan because Clang will add the ASan runtime a second time when linking the executable. For some reason this worked before (maybe if the runtimes used are exactly identical the linker will deduplicate them) but today during building with Rust nightly I got duplicate symbol errors indicating two conflicting ASan RTs. From what I can tell, Rust should not link these runtimes except if it is producing an executable. The respective code is called here independent of : [1]
See also
I'm reopening this because the fix I made is not complete. There is a second place where we inject the sanitizer runtime and that is the function in . It even explicitly attaches the runtime to static libraries. This is a one-line fix but afterwards the test fails. This test failure is expected because the test itself is incorrect as well. I will make another PR that has the fix and also changes the test to include a negative-check for the runtime in staticlibs.
This was fixed in & .
Change:
<del> // check-pass </del> <ins> // build-pass </ins> // compile-flags: -Cdebuginfo=2 // fixes issue #94149

Discussion:
<!-- 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. --for example: <!-- 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. --: rustc needs to be built with debug assertions!! <!-- 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 --
might be related to
Probably related to (or in the same spirit) -- debuginfo code may not account for non-ZST allocator on .
Actually mentioning that issue, it gives me a probable fix. claim