jiebi/CodeConvo huggingface dataset:
Code change:
<!-- 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 searched nightlies: from nightly-2023-03-10 to nightly-2023-03-18 regressed nightly: nightly-2023-03-12 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: </details
We relate with during codegen when selecting an impl which now eagerly returns without constraining to anything wheras previously it would have been instantiated with . This then results in codegen returning an impl with in the substs from a query
output on beta/stable:
WG-prioritization assigning priority (). label -I-prioritize +P-medium

Related discussion:
text: <del> error[E0119]: conflicting implementations of trait `Copy` for type `S<_>` --> $DIR/bad-const-wf-doesnt-specialize.rs:9:1 </del> <ins> error: the constant `N` is not of type `usize` --> $DIR/bad-const-wf-doesnt-specialize.rs:8:29 </ins> | LL | impl<const N: i32> Copy for S<N> {} <del> | -------------------------------- first implementation here LL | impl<const M: usize> Copy for S<M> {} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `S<_>` </del> <ins> |                             ^^^^ | note: required by a bound in `S` --> $DIR/bad-const-wf-doesnt-specialize.rs:6:10 | LL | struct S<const L: usize>; |          ^^^^^^^^^^^^^^ required by this bound in `S` </ins> error: aborting due to previous error <del> For more information about this error, try `rustc --explain E0119`. </del>
Code change:
<!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
searched nightlies: from nightly-2023-02-17 to nightly-2023-03-18 regressed nightly: nightly-2023-02-21 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: </details
cc is this fixed by your branch?
No, it's not. The stacktrace does indeed contain but that's not the root cause of the problem. It just calls which ices (changing it to doesn't help either). The actual (?) bug is probably inside of the code I assume.
Ah, wait. If it's a bug to pass s to the type relating functions then it is the fault of and it should probably return early if a type . Edit: But it that case?
Hm, actually I think we should just fix the relate code instead.
Sure. I also feel like I've seen this ICE message pop up several times already on this issue tracker. I might be mistaken tho.
More minimal:
Reassigning to myself since the approach involving region erasure during selection we talked about fixes this issue (obviously) and since I'd like to integrate this into my PR to be able to write UI tests that exercise the bound region code used during IAT confirmation (otherwise we would never go past selection in those cases). claim label F-inherentassociatedtypes

Related discussion:
text: use rustc_infer::traits::ObligationCause; use rustc_middle::infer::unify_key::{ConstVariableOrigin, ConstVariableOriginKind}; use rustc_middle::middle::stability::AllowUnstable; <ins> use rustc_middle::ty::fold::FnMutDelegate; </ins> use rustc_middle::ty::subst::{self, GenericArgKind, InternalSubsts, SubstsRef}; use rustc_middle::ty::DynKind; use rustc_middle::ty::GenericParamDefKind;
Code change:
<!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
searched nightlies: from nightly-2023-02-17 to nightly-2023-03-18 regressed nightly: nightly-2023-02-21 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: </details
cc is this fixed by your branch?
No, it's not. The stacktrace does indeed contain but that's not the root cause of the problem. It just calls which ices (changing it to doesn't help either). The actual (?) bug is probably inside of the code I assume.
Ah, wait. If it's a bug to pass s to the type relating functions then it is the fault of and it should probably return early if a type . Edit: But it that case?
Hm, actually I think we should just fix the relate code instead.
Sure. I also feel like I've seen this ICE message pop up several times already on this issue tracker. I might be mistaken tho.
More minimal:
Reassigning to myself since the approach involving region erasure during selection we talked about fixes this issue (obviously) and since I'd like to integrate this into my PR to be able to write UI tests that exercise the bound region code used during IAT confirmation (otherwise we would never go past selection in those cases). claim label F-inherentassociatedtypes

Related discussion:
text: <ins> #![feature(inherent_associated_types, non_lifetime_binders, type_alias_impl_trait)] #![allow(incomplete_features)] struct Lexer<T>(T); impl Lexer<i32> { type Cursor = (); } type X = impl for<T> Fn() -> Lexer<T>::Cursor; //~ ERROR associated type `Cursor` not found for `Lexer<T>` in the current scope fn main() {} </ins>
Code change:
<!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
searched nightlies: from nightly-2023-02-17 to nightly-2023-03-18 regressed nightly: nightly-2023-02-21 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: </details
cc is this fixed by your branch?
No, it's not. The stacktrace does indeed contain but that's not the root cause of the problem. It just calls which ices (changing it to doesn't help either). The actual (?) bug is probably inside of the code I assume.
Ah, wait. If it's a bug to pass s to the type relating functions then it is the fault of and it should probably return early if a type . Edit: But it that case?
Hm, actually I think we should just fix the relate code instead.
Sure. I also feel like I've seen this ICE message pop up several times already on this issue tracker. I might be mistaken tho.
More minimal:
Reassigning to myself since the approach involving region erasure during selection we talked about fixes this issue (obviously) and since I'd like to integrate this into my PR to be able to write UI tests that exercise the bound region code used during IAT confirmation (otherwise we would never go past selection in those cases). claim label F-inherentassociatedtypes

Related discussion:
text: <ins> error[E0220]: associated type `Cursor` not found for `Lexer<T>` in the current scope --> $DIR/issue-109299-1.rs:10:40 | LL | struct Lexer<T>(T); | --------------- associated item `Cursor` not found for this struct ... LL | type X = impl for<T> Fn() -> Lexer<T>::Cursor; |                                        ^^^^^^ associated item not found in `Lexer<T>` | = note: the associated type was found for - `Lexer<i32>` error: aborting due to previous error For more information about this error, try `rustc --explain E0220`. </ins>
Code change:
<!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
searched nightlies: from nightly-2023-02-17 to nightly-2023-03-18 regressed nightly: nightly-2023-02-21 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: </details
cc is this fixed by your branch?
No, it's not. The stacktrace does indeed contain but that's not the root cause of the problem. It just calls which ices (changing it to doesn't help either). The actual (?) bug is probably inside of the code I assume.
Ah, wait. If it's a bug to pass s to the type relating functions then it is the fault of and it should probably return early if a type . Edit: But it that case?
Hm, actually I think we should just fix the relate code instead.
Sure. I also feel like I've seen this ICE message pop up several times already on this issue tracker. I might be mistaken tho.
More minimal:
Reassigning to myself since the approach involving region erasure during selection we talked about fixes this issue (obviously) and since I'd like to integrate this into my PR to be able to write UI tests that exercise the bound region code used during IAT confirmation (otherwise we would never go past selection in those cases). claim label F-inherentassociatedtypes

Related discussion:
text: <ins> #![feature(inherent_associated_types)] #![allow(incomplete_features)] struct Lexer<'d>(&'d ()); impl Lexer<'d> { //~ ERROR use of undeclared lifetime name `'d` type Cursor = (); } fn test(_: Lexer::Cursor) {} fn main() {} </ins>
Code change:
<!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
searched nightlies: from nightly-2023-02-17 to nightly-2023-03-18 regressed nightly: nightly-2023-02-21 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: </details
cc is this fixed by your branch?
No, it's not. The stacktrace does indeed contain but that's not the root cause of the problem. It just calls which ices (changing it to doesn't help either). The actual (?) bug is probably inside of the code I assume.
Ah, wait. If it's a bug to pass s to the type relating functions then it is the fault of and it should probably return early if a type . Edit: But it that case?
Hm, actually I think we should just fix the relate code instead.
Sure. I also feel like I've seen this ICE message pop up several times already on this issue tracker. I might be mistaken tho.
More minimal:
Reassigning to myself since the approach involving region erasure during selection we talked about fixes this issue (obviously) and since I'd like to integrate this into my PR to be able to write UI tests that exercise the bound region code used during IAT confirmation (otherwise we would never go past selection in those cases). claim label F-inherentassociatedtypes

Related discussion:
text: <ins> error[E0261]: use of undeclared lifetime name `'d` --> $DIR/issue-109299.rs:6:12 | LL | impl Lexer<'d> { |     -      ^^ undeclared lifetime |     | |     help: consider introducing lifetime `'d` here: `<'d>` error: aborting due to previous error For more information about this error, try `rustc --explain E0261`. </ins>
Code change:
Given Rustdoc does not escape the ASCII angle brackets for the generic argument list of the generic associated type projection leading to the following butchered HTML output: I've noticed this while working on rustdoc integration for in . It's possible that the refactoring PR will fix this (need to check) or at least make it more pleasant to fix. Assigning myself for now since I'm gonna fix this otherwise. claim label T-rustdoc A-rustdoc-ui F-genericassociatedtypes <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Copying my comment from : is requesting alternate formatting (i.e. plaintext), but in this branch of things, alternate formatting hasn't been requested by the caller. So this is likely emitting into an HTML context. If you change it to in your branch I'm guessing that will fix things.
Here's a live example: As it turns out, this bug does appear to be what's crashing rustdoc in . So I will wind up fixing it. But feel free to investigate and fix if you prefer not to wait.
This wound up being the fix:
On at least I cannot reproduce your fix that involves adding in branch (maybe that only works on your branch). In any case, the lines in are definitely the culprit. I've already fixed it that way in but I've now also opened a separate PR. Thanks for the live example!

Related discussion:
text: //        the ugliness comes from inlining across crates where //        everything comes in as a fully resolved QPath (hard to //        look at). <del> match href(trait_.def_id(), cx) { Ok((ref url, _, ref path)) if !f.alternate() => { write!( f, "<a class="associatedtype" href="{url}#{shortty}.{name}"  title="type {path}::{name}">{name}</a>{args}", url = url, shortty = ItemType::AssocType, name = assoc.name, path = join_with_double_colon(path), args = assoc.args.print(cx), )?; } _ => write!(f, "{}{:#}", assoc.name, assoc.args.print(cx))?, } Ok(()) </del> <ins> if !f.alternate() && let Ok((url, _, path)) = href(trait_.def_id(), cx) { write!( f, "<a class="associatedtype" href="{url}#{shortty}.{name}"  title="type {path}::{name}">{name}</a>", shortty = ItemType::AssocType, name = assoc.name, path = join_with_double_colon(&path), ) } else { write!(f, "{}", assoc.name) }?; // Carry `f.alternate()` into this display w/o branching manually. fmt::Display::fmt(&assoc.args.print(cx), f) </ins> } } }
Code change:
Given Rustdoc does not escape the ASCII angle brackets for the generic argument list of the generic associated type projection leading to the following butchered HTML output: I've noticed this while working on rustdoc integration for in . It's possible that the refactoring PR will fix this (need to check) or at least make it more pleasant to fix. Assigning myself for now since I'm gonna fix this otherwise. claim label T-rustdoc A-rustdoc-ui F-genericassociatedtypes <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Copying my comment from : is requesting alternate formatting (i.e. plaintext), but in this branch of things, alternate formatting hasn't been requested by the caller. So this is likely emitting into an HTML context. If you change it to in your branch I'm guessing that will fix things.
Here's a live example: As it turns out, this bug does appear to be what's crashing rustdoc in . So I will wind up fixing it. But feel free to investigate and fix if you prefer not to wait.
This wound up being the fix:
On at least I cannot reproduce your fix that involves adding in branch (maybe that only works on your branch). In any case, the lines in are definitely the culprit. I've already fixed it that way in but I've now also opened a separate PR. Thanks for the live example!

Related discussion:
text: <ins> // Make sure that we escape the arguments of the GAT projection even if we fail to compute // the href of the corresponding trait (in this case it is private). // Further, test that we also linkify the GAT arguments. // @has 'issue_109488/type.A.html' // @has - '//pre[@class="rust item-decl"]' '<S as Tr>::P<Option<i32>>' // @has - '//pre[@class="rust item-decl"]//a[@class="enum"]/@href' '{{channel}}/core/option/enum.Option.html' pub type A = <S as Tr>::P<Option<i32>>; /*private*/ trait Tr { type P<T>; } pub struct S; impl Tr for S { type P<T> = (); } </ins>
Code change:
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.

Related discussion:
text: use crate::builder::crate_description; use crate::builder::Cargo; <del> use crate::builder::{Builder, Kind, RunConfig, ShouldRun, Step}; </del> <ins> use crate::builder::{Builder, Kind, PathSet, RunConfig, ShouldRun, Step, TaskPath}; </ins> use crate::cache::{Interned, INTERNER}; use crate::config::{LlvmLibunwind, RustcLto, TargetSelection}; use crate::dist;
Code change:
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.

Related discussion:
text: 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;
Code change:
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.

Related discussion:
text: } fn make_run(run: RunConfig<'_>) { <ins> if needs_codegen_config(&run) { return; } </ins> for &backend in &run.builder.config.rust_codegen_backends { if backend == "llvm" { continue; // Already built as part of rustc