jiebi/CodeConvo huggingface dataset:
Change:
hir::GenericParamKind::Const { ty: hir_ty, default: _ } => { let ty = tcx.type_of(tcx.hir().local_def_id(param.hir_id)); <del> let err_ty_str; let mut is_ptr = true; let err = if tcx.features().adt_const_params { match ty.peel_refs().kind() { </del> <ins> if tcx.features().adt_const_params { let err = match ty.peel_refs().kind() { </ins> ty::FnPtr(_) => Some("function pointers"), ty::RawPtr(_) => Some("raw pointers"), _ => None, <ins> }; if let Some(unsupported_type) = err { tcx.sess.span_err( hir_ty.span, &format!( "using {} as const generic parameters is forbidden", unsupported_type ), ); } if traits::search_for_structural_match_violation(param.span, tcx, ty).is_some() { // We use the same error code in both branches, because this is really the same // issue: we just special-case the message for type parameters to make it // clearer. if let ty::Param(_) = ty.peel_refs().kind() { // Const parameters may not have type parameters as their types, // because we cannot be sure that the type parameter derives `PartialEq` // and `Eq` (just implementing them is not enough for `structural_match`). struct_span_err!( tcx.sess, hir_ty.span, E0741, "`{}` is not guaranteed to `#[derive(PartialEq, Eq)]`, so may not be  used as the type of a const parameter", ty, ) .span_label( hir_ty.span, format!("`{}` may not derive both `PartialEq` and `Eq`", ty), ) .note( "it is not currently possible to use a type parameter as the type of a  const parameter", ) .emit(); } else { struct_span_err!( tcx.sess, hir_ty.span, E0741, "`{}` must be annotated with `#[derive(PartialEq, Eq)]` to be used as  the type of a const parameter", ty, ) .span_label( hir_ty.span, format!("`{}` doesn't derive both `PartialEq` and `Eq`", ty), ) .emit(); } </ins> } } else { <del> match ty.kind() { </del> <ins> let err_ty_str; let mut is_ptr = true; let err = match ty.kind() { </ins> ty::Bool | ty::Char | ty::Int(_) | ty::Uint(_) | ty::Error(_) => None, ty::FnPtr(_) => Some("function pointers"), ty::RawPtr(_) => Some("raw pointers"),

Discussion:
Given the following code (): Rust gives a diagnostic suggesting deriving : However, adding leads the compiler to still give an error about not supporting this. A non-nightly compiler should not give the second error at all; it should only give the first, saying that the only supported types are integers, and . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
assigning this to project-const-generics, getting worked on in https://rust-
claim
To fix this issue, you can do the following steps: grep for "forbidden as the type of a const generic parameter" look at that function for a bit change it so that the second error isn't emitted on stable (probably actually change the control flow to start by branching on In case you are interested but need more help to fix this, feel free to reach out to me on
claim
Change:
/// will use it's *external name*, which will be a `RegionKind` /// variant that can be used in query responses such as /// `ReEarlyBound`. <ins> #[instrument(level = "debug", skip(self, infcx))] </ins> fn try_promote_type_test_subject( &self, infcx: &InferCtxt<'_, 'tcx>,

Discussion:
This code compiles after although it shouldn't: () This is similar to in that we're not taking into account placeholder regions when "promoting" type-tests from the closure to its caller: label T-types regression-from-stable-to-beta C-bug A-NLL I-unsound <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I guess it would be an easy fix claim
The unsoundness exploitation in can easily be adapted for this issue, so it is in fact a soundness issue:
issue touched in today's T-compiler meeting, . Will also be discussed tomorrow during the T-types meeting.
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Change:
kind: hir::GenericParamKind::Type { default: Some(ty), .. }, .. }) => vec![*ty], <ins> hir::Node::AnonConst(_) if let Some(const_param_id) = tcx.hir().opt_const_param_default_param_def_id(hir_id) && let hir::Node::GenericParam(hir::GenericParam { kind: hir::GenericParamKind::Const { ty, .. }, .. }) = tcx.hir_node_by_def_id(const_param_id) => { vec![*ty] } </ins> ref node => bug!("Unexpected node {:?}", node), }, WellFormedLoc::Param { function: _, param_idx } => {

Discussion:
<!-- [31mICE[0m: Rustc '-Zincremental-verify-ich=yes -Cincremental=<dir-Cdebuginfo=2' 'error: internal compiler error: Unexpected node AnonConst(AnonConst { hirid: HirId(DefId(0:3 ~ [9608]::Trait).5), defid: DefId(0:5 ~ [9608]::Trait::{constant}), body: BodyId { hirid: HirId(DefId(0:3 ~ [9608]::Trait).6) } })', 'error: internal compiler error: Unexpected node AnonConst(AnonConst { hirid: HirId(DefId(0:3 ~ [9608]::Trait).5), defid: DefId(0:5 ~ [9608]::Trait::{constant}), body: BodyId { hirid: HirId(DefId(0:3 ~ [9608]::Trait).6) } })' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. .

--<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: note: compiler flags: -Z incremental-verify-ich=yes -C incremental=[REDACTED] -C debuginfo=2 [diagnostichirwfcheck] performing HIR wf-checking for predicate at item [typeck] type-checking [checkmatch] match-checking [mirbuilt] building MIR for [mirconst] preparing for borrow checking [mirconstqualif] const checking [mirpromoted] promoting constants in MIR for [mirborrowck] borrow-checking [mirdropselaboratedandconstchecked] elaborating drops for [mirforctfe] caching mir of for CTFE [evaltoallocationraw] const-evaluating + checking [evaltovaltree] evaluating type-level constant [checkwellformed] checking that is well-formed [checkmodtypewf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This seeeems to bisect to :thinking: cc
Thanks Will take a look. claim
Reduced further:
the original (none reduced) one still ices :sweat_smile:
From what I can tell, it seems to have been fixed : Looks like I'm missing something
I have now opened PR to test the below original reproducer:
Sorry for causing the issue to be closed via the PR merge without asking you first. If you still believe the ICE is not fixed please reopen it.
Change:
<ins> error[E0223]: ambiguous associated type --> $DIR/issue-110052.rs:6:30 | LL |     for<'iter> dyn Validator<<&'iter I>::Item>:, |                              ^^^^^^^^^^^^^^^^ help: use the fully-qualified path: `<&'iter I as IntoIterator>::Item` error: aborting due to previous error For more information about this error, try `rustc --explain E0223`. </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
Regression in cc
Change:
None => { let rendered: Vec<&str> = msgs.iter().filter_map(|msg| msg["rendered"].as_str()).collect(); <ins> let non_json: Vec<&str> = stderr.lines().filter(|line| !line.starts_with('{')).collect(); </ins> Err(format!( <del> "did not find lint `{}` in output of example, got:n{}", </del> <ins> "did not find lint `{}` in output of example, got:n{}n{}", </ins> name, <ins> non_json.join("n"), </ins> rendered.join("n") ) .into())

Discussion:
I tried to build rust right after got merged and caught error:
cc
What command did you run?
Change:
/// [`ancestors`]: struct.Path.html#method.ancestors /// [`Path`]: struct.Path.html #[derive(Copy, Clone, Debug)] <del> #[unstable(feature = "path_ancestors", issue = "48581")] </del> <ins> #[stable(feature = "path_ancestors", since = "1.28.0")] </ins> pub struct Ancestors<'a> { next: Option<&'a Path>, } <del> #[unstable(feature = "path_ancestors", issue = "48581")] </del> <ins> #[stable(feature = "path_ancestors", since = "1.28.0")] </ins> impl<'a> Iterator for Ancestors<'a> { type Item = &'a Path;

Discussion:
Tracking issue for , and . Steps: [X] Implementation [X] Stabilization PR () Unresolved questions: [X] What is a good name? ? ?
cc
Change:
[62735]: https://github.com/rust-lang/rust/pull/62735/ [62766]: https://github.com/rust-lang/rust/pull/62766/ [62784]: https://github.com/rust-lang/rust/pull/62784/ <ins> [62592]: https://github.com/rust-lang/rust/pull/62592/ </ins> [62785]: https://github.com/rust-lang/rust/issues/62785/ [62814]: https://github.com/rust-lang/rust/pull/62814/ [62896]: https://github.com/rust-lang/rust/issues/62896/

Discussion:
I'll leave my story here because it shows how important the information can be: We recently upgraded from rustc 1.43 to 1.47 to build Firefox (we got stuck on 1.43 for a large number of complicated reasons, and would still be stuck if we hadn't found workarounds). Anyways, consequently, we've had a bunch of regressions, one of which was performance-related and I was bisecting it. The first thing I did was to compare each rust release, and it turned out the regression started between 1.44 and 1.45. So I went to the 1.45 release notes suspecting LLVM could have been involved and saw nothing there. Now, several hours later bisecting through nightlies (because PGO and LTO being involved, testing one version takes a while), the regression appears to have started between rustc 1.45.0-nightly ( 2020-05-21) and rustc 1.45.0-nightly ( 2020-05-20) So I take my git, type and lo and behold, there it is: I'm still waiting on the results actually confirming LLVM is involved (it likely is), but it would have saved me a lot of time if the LLVM upgrade had been mentioned (which it is for LLVM 11 in 1.47, BTW, but OTOH, now that I look, it appears the last upgrade mentioned is to LLVM 6 in 1.25...)
FWIW, the LLVM 11 upgrade in 1.47 got back a lot of the performance LLVM 10 lost:
Not for the testcase I'm bisecting, but that's OT.
I agree we should be mentioning this; thank you for noting it. I would be happy to accept a PR adding those in to the release notes (just 1.45 and 1.47, or more if you have the time).
Do you have an issue for that regression?
Will have when I have more information to feed into one.
Change:
//! ``` //! //! While many collections offer `iter()`, not all offer `iter_mut()`. For <del> //! example, mutating the keys of a [`HashSet<T>`] or [`HashMap<K, V>`] could //! put the collection into an inconsistent state if the key hashes change, so //! these collections only offer `iter()`. </del> <ins> //! example, mutating the keys of a [`HashSet<T>`] could put the collection //! into an inconsistent state if the key hashes change, so this collection //! only offers `iter()`. </ins> //! //! [`into_iter()`]: IntoIterator::into_iter //! [`HashSet<T>`]: ../../std/collections/struct.HashSet.html <del> //! [`HashMap<K, V>`]: ../../std/collections/struct.HashMap.html </del> //! //! # Adapters //!

Discussion:
HashMap clearly has itermut while HashSet does not. Docs should be changed to reflect this. I would be happy to do this, but as I have not contributed to Rust before, wanted to make sure I didn't miss something here.
I also realize that the key itself is reference as seen here but feel the wording here being updated is still valid.
I agree this wording should be updated. Perhaps "or " should just be removed.
are you still planning on making this change?
label +A-docs +E-easy
Change:
// harmless Ok(true) }, <del> _ => Err(format!("unrecognized builtin nonterminal `{}`", frag)) </del> <ins> _ => Err(format!("invalid fragment specifier `{}`", frag)) </ins> } } }

Discussion:
I work on Windows 8.1 64-bit, rustc version: BTW, the same ICE occurred for my but it did not print backtrace with and I don't know why.
Change:
if build.is_rust_llvm(target) { cargo.env("LLVM_RUSTLLVM", "1"); } <ins> if let Some(ref cfg_file) = build.flags.config { let cfg_path = t!(PathBuf::from(cfg_file).canonicalize()); cargo.env("CFG_LLVM_TOML", cfg_path.into_os_string()); } </ins> cargo.env("LLVM_CONFIG", build.llvm_config(target)); let target_config = build.config.target_config.get(target); if let Some(s) = target_config.and_then(|c| c.llvm_config.as_ref()) {

Discussion:
I got in my : but still seems to attempt using /usr/bin/llvm-config cc
I think that the actual behavior (from IRC) that happened here was that configuration change in , but the build script wasn't re-run. The build script should probably print out pointing at if it exists, passed through via rustbuild.
I think the build script doesn't point to with ; is it possible we could make this into an E-easy issue? I get the feeling that this would also make a decent intro into rustbuild.
Certainly! I think we'll need to pass the path of via an env var, but that shouldn't be too onerous to do in rustbuild either. If anyone's got any questions please feel free to ask!
I would like to work on this. Can I use the env var to pass the path of from ? Or or .
I think an env var would probably be the best approach. seems good, but that can be bikeshedded in the PR. Let us know if we can do anything to help!
Change:
version = "0.1.0" dependencies = [ "colored", <del> "compiletest_rs", </del> <ins> "compiletest_rs 0.7.0", </ins> "env_logger 0.8.1", "getrandom 0.2.0", "hex 0.4.2",

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great!
Change:
enum GetSafeTransmuteErrorAndReason { Silent, <ins> Default, </ins> Error { err_msg: String, safe_transmute_explanation: Option<String> }, }

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'not implemented: NormalizationFailure(Alias(Projection, AliasTy { args: [T/], defid: DefId(0:12 ~ a[cc78]::Aaa::Y), .. }), Type(Alias(Projection, AliasTy { args: [T/], defid: DefId(0:12 ~ a[cc78]::Aaa::Y), .. })))'', 'thread 'rustc' panicked at 'not implemented: NormalizationFailure(Alias(Projection, AliasTy { args: [T/], defid: DefId(0:12 ~ a[cc78]::Aaa::Y), .. }), Type(Alias(Projection, AliasTy { args: [T/], defid: DefId(0:12 ~ a[cc78]::Aaa::Y), .. })))'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [checkwellformed] checking that is well-formed [checkmodtypewf] checking that types are well-formed in top-level module --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regression in nightly-2024-08-22 seems to bisect to
Slightly more reduction:
(Note that this reduction should drop the feature gate, as this ICEs without the feature gate)
claim
Change:
for bound in self.tcx().item_bounds(alias_ty.def_id).instantiate(self.tcx(), alias_ty.args) { <ins> // HACK: On subsequent recursions, we only care about bounds that don't // share the same type as `self_ty`. This is because for truly rigid // projections, we will never be able to equate, e.g. `<T as Tr>::A` // with `<<T as Tr>::A as Tr>::A`. if in_parent_alias_type { match bound.kind().skip_binder() { ty::ClauseKind::Trait(tr) if tr.self_ty() == self_ty => continue, ty::ClauseKind::Projection(p) if p.self_ty() == self_ty => continue, _ => {} } } </ins> for_each(self, bound, idx)?; idx += 1; }

Discussion:
I tried this code: I expected to see this happen: It compiles quickly. Instead, this happened: It takes 10s to complete. Bisected to cc
Why did you title this "is broken"? It just takes longer to compile, or is it broken some other way? I'll look into the upcoming week.
Sorry, it just takes longer to compile.
WG-prioritization assigning priority (). label -I-prioritize +P-medium -regression-untriaged
On my machine (Apple M2 Pro), this test currently takes about 30 seconds. But if I enable , the compiler appears to consume 100% CPU forever. I'm not sure whether it's actually stuck, or just taking an incredibly long time, but I've never seen it finish with debug assertions enabled.
If I apply , the test finishes in about 45 seconds with debug assertions enabled, and about 3 seconds with them disabled.
Change:
| ty::FnPtr(..) ) } <del> // None of the possible types have lifetimes, so we can just compare // directly if a != b { </del> <ins> // The function pointer types can have lifetimes if !self.mir_assign_valid_types(a, b) { </ins> self.fail( location, format!("Cannot compare unequal types {:?} and {:?}", a, b),

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. --code from glacier / <!-- 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 case 
Probably caused by cc
Oops. That's my b, I'll have a PR up in 10 minutes
Change:
use util::nodemap::{DefIdMap, FnvHashMap}; use util::ppaux::Repr; <ins> mod impls; </ins> mod orphan; mod overlap; mod unsafety;

Discussion:
Compiling with works fine, definitely does not, though: And, if the bound in is removed, the code compiles fine with or without . So... somehow the test runner is causing a tuple of arity 3 specifically to be inferred to something completely ridiculous.
cc I guess?
points out that specifically having causes the problem.
cc me
FYI: discovered this problem while working on
Slightly more minimized:
contains: This causes the problem.
I'll take a look at it.
Oh, I see you tracked it down -- I thought it might be something like that. This is in fact something I was talking to about as a possible danger of the way we're treating builtin bounds right now, though in a different context.
In fact, I think that the for a tuple ought to be a coherence violation to begin with, actually.
(I think there was language about specifically this in the OIBIT RFC)
I agree with comments here and after a quick chat on IRC with him, we agreed that implementations of built-in traits (and likely default trait impls in the future) should be allowed just on and .
Change:
<ins> // assembly-output: emit-asm // ignore-tidy-linelength // revisions: nvptx64_nvidia_cuda // [nvptx64_nvidia_cuda] compile-flags: --target nvptx64-nvidia-cuda // [nvptx64_nvidia_cuda] needs-llvm-components: nvptx // Sanity-check that each target can produce assembly code. #![feature(no_core, lang_items)] #![no_std] #![no_core] #![crate_type = "lib"] #[lang = "sized"] trait Sized {} pub fn test() -> u8 { 42 } // CHECK: .version </ins>

Discussion:
(wrapped by hand to make the problem clear) The function pointer alignment is the same as our powerpc64-unknown-linux-gnu target, so the discrepancy must be in LLVM. While this is a tier 3 target, we are completely unable to generate code for it, so at some point this part of the target tier policy will become relevant (emphasis mine): If a tier 3 target stops meeting these requirements, or the target maintainers no longer have interest or time, or the target shows no signs of activity and has not built for some time, or removing the target would improve the quality of the Rust codebase, we may post a PR to remove it; any such PR will be CCed to the target maintainers (there are none, not even for the Tier 2 -gnu variant) (and potentially other people who have previously worked on the target), to check potential interest in improving the situation. I have trawled the issue tracker and I cannot find any evidence that this target is in use; all issues seem related to or the targets.
Does this also impact ppc64le? That's supported by Alpine, which uses musl. It looks like is the maintainer with musl. Not knowing anything about ppc, or very much about LLVM's data layouts, it looks like may be what broke this.
powerpc64le is not affected. Unfortunately looking at that diff I still can't figure out which of the targets is correct.
So I'm running into this in , the relevant code in LLVM is: () () We get rather than because of the musl-ness of the target. As far as I can tell, this would have been the case since , and the definition of hasn't changed . I think we just got this value wrong in .
Just as a side note – I am using it and I've hit this bug while building the current stable branch. Thank you for maintaining it.
Change:
<ins> // Copyright 2016 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. // Ensure that types that rely on obligations are autoderefed // correctly fn main() { let x : Vec<Box<Fn()>> = vec![Box::new(|| ())]; x[0]() } </ins>

Discussion:
This code works: As does placing it in an array: However, using a fails: Instead, it must be explicitly dereferenced: It's even more annoying for :
The fact that this works for arrays, but not Vec suggests that it's probably related to associated types. It's possible that wherever the coercion from to is done sees instead.
This doesn't seem to be fully resolved:
That may be instead.
Change:
| = note: `FnMut` closures only have access to their captured variables while they are executing... = note: ...therefore, they cannot allow references to captured variables to escape <ins> help: consider adding 'move' keyword before the nested closure | LL |         move || { |         ++++ </ins> error: aborting due to previous error

Discussion:
Given the following code: The current output is: The actually needed fix here is the following, which should ideally be recommended <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
slightly more minimal:
claim
I came up with a solution of printing an extra line of to give user a recommendation of fixing the error by adding 'move' keyword before the closure parameter of map(). The following is the output for the first testing code. Is this good enough? This is the output from the second testing code ():
Refined the fix with a verbose suggestion of where to add keyword. The output of the first test case is: The output of the second test case is: In addition, the fix will also add the suggestion for nested closure block like this test case: The output of the above test case is: