Question:
I'm seeing an internal compiler error on the following input (found by ): The error happens on , , and .
I'm looking into this! But mostly as a learning exercise. Spent ~4 hours exploring typeck & error handling today to see why this exact combination of things triggers an error. My friend and I will probably have a solution at some point, but it might be a few weeks from now. If anyone has a good & quick solution, or if it is deemed high-priority, then feel free to ignore me.
~According to , this regressed between 2019-07-30 and 2019-07-31. Unfortunately, seems to be incapable of narrowing it down to a commit because that was more than 167 days ago.~ EDIT: gave me a misleading result. This error is at least as old as .
This error started happening in cc
The ICE goes away if I apply this patch: (Though I'd guess that making this change would cause us to regress on the problems that fixed.)
This change fixes the ICE and avoids regressing on : I'm unsure whether this respects the intended meaning of , though.
on a very cursory look that patch looks reasonable.
has some additional relevant context.
Unfortunately, the patch that I proposed above fails on this modification of :
triage: P-high. Removing nomination. Added regression stable-to-stable tag.
I think I found a way to resolve this without regressing on . The point of this PR is to not emit an error if it might be invalid to the user. But there are errors in context still. The patch I propose is this: This does pass every UI test. I'll open a PR so this can be discussed more easely.

ty_span: Span, ) { if variant.recovered { <ins> self.set_tainted_by_errors(); </ins> return; } let mut err = self.type_error_struct_with_diag(


Question:
I'm seeing an internal compiler error on the following input (found by ): The error happens on , , and .
I'm looking into this! But mostly as a learning exercise. Spent ~4 hours exploring typeck & error handling today to see why this exact combination of things triggers an error. My friend and I will probably have a solution at some point, but it might be a few weeks from now. If anyone has a good & quick solution, or if it is deemed high-priority, then feel free to ignore me.
~According to , this regressed between 2019-07-30 and 2019-07-31. Unfortunately, seems to be incapable of narrowing it down to a commit because that was more than 167 days ago.~ EDIT: gave me a misleading result. This error is at least as old as .
This error started happening in cc
The ICE goes away if I apply this patch: (Though I'd guess that making this change would cause us to regress on the problems that fixed.)
This change fixes the ICE and avoids regressing on : I'm unsure whether this respects the intended meaning of , though.
on a very cursory look that patch looks reasonable.
has some additional relevant context.
Unfortunately, the patch that I proposed above fails on this modification of :
triage: P-high. Removing nomination. Added regression stable-to-stable tag.
I think I found a way to resolve this without regressing on . The point of this PR is to not emit an error if it might be invalid to the user. But there are errors in context still. The patch I propose is this: This does pass every UI test. I'll open a PR so this can be discussed more easely.

<ins> // Regression test for #69378: no type for node after struct parse recovery struct Foo { 0: u8 } //~ ERROR expected identifier fn test(f: Foo) { Foo{foo: 4, ..f}; } fn main() {} </ins>


Question:
I'm seeing an internal compiler error on the following input (found by ): The error happens on , , and .
I'm looking into this! But mostly as a learning exercise. Spent ~4 hours exploring typeck & error handling today to see why this exact combination of things triggers an error. My friend and I will probably have a solution at some point, but it might be a few weeks from now. If anyone has a good & quick solution, or if it is deemed high-priority, then feel free to ignore me.
~According to , this regressed between 2019-07-30 and 2019-07-31. Unfortunately, seems to be incapable of narrowing it down to a commit because that was more than 167 days ago.~ EDIT: gave me a misleading result. This error is at least as old as .
This error started happening in cc
The ICE goes away if I apply this patch: (Though I'd guess that making this change would cause us to regress on the problems that fixed.)
This change fixes the ICE and avoids regressing on : I'm unsure whether this respects the intended meaning of , though.
on a very cursory look that patch looks reasonable.
has some additional relevant context.
Unfortunately, the patch that I proposed above fails on this modification of :
triage: P-high. Removing nomination. Added regression stable-to-stable tag.
I think I found a way to resolve this without regressing on . The point of this PR is to not emit an error if it might be invalid to the user. But there are errors in context still. The patch I propose is this: This does pass every UI test. I'll open a PR so this can be discussed more easely.

<ins> error: expected identifier, found `0` --> $DIR/issue-69378-ice-on-invalid-type-node-after-recovery.rs:3:14 | LL | struct Foo { 0: u8 } |              ^ expected identifier error: aborting due to previous error </ins>


Question: Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver 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! And nominating for compiler team prioritization.

[[package]] name = "git2" <del> version = "0.11.0" </del> <ins> version = "0.12.0" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "77519ef7c5beee314d0804d4534f01e0f9e8d9acdee2b7a48627e590b27e0ec4" </del> <ins> checksum = "26e07ef27260a78f7e8d218ebac2c72f2c4db50493741b190b6e8eade1da7c68" </ins> dependencies = [ "bitflags", "libc",


Question: Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver 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! And nominating for compiler team prioritization.

[[package]] name = "git2-curl" <del> version = "0.12.0" </del> <ins> version = "0.13.0" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "d2559abb1d87d27668d31bd868a000f0e2e0065d10e78961b62da95d7a7f1cc7" </del> <ins> checksum = "af1754ec4170e7dcaf9bb43743bb16eddb8d827b2e0291deb6f220a6e16fe46a" </ins> dependencies = [ "curl", "git2",


Question: Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver 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! And nominating for compiler team prioritization.

[[package]] name = "libgit2-sys" <del> version = "0.10.0" </del> <ins> version = "0.11.0+0.99.0" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "d9ec6bca50549d34a392611dde775123086acbd994e3fff64954777ce2dc2e51" </del> <ins> checksum = "4d5d1459353d397a029fb18862166338de938e6be976606bd056cf8f1a912ecf" </ins> dependencies = [ "cc", "libc",


Question: Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver 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! And nominating for compiler team prioritization.

<del> Subproject commit e57bd02999c9f40d52116e0beca7d1dccb0643de </del> <ins> Subproject commit bda50510d1daf6e9c53ad6ccf603da6e0fa8103f </ins>


Question: Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver 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! And nominating for compiler team prioritization.

<del> Subproject commit fc5d0cc583cb1cd35d58fdb7f3e0cfa12dccd6c0 </del> <ins> Subproject commit 8b7f7e667268921c278af94ae30a61e87a22b22b </ins>


Question:
<!-- 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. --The setup under which this occurs is somewhat complicated, but I'll try to reduce it as much as I can and update this issue with details. But basically it's using the latest nightly rustc and running on the latest code (, rev ). <!-- 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. --: (See full output in the backtrace details below) <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Also to note: so far this has happened 2/2 times today. It didn't happen yesterday (which presumably was running using a slightly-older rustc and checking slightly-older glean code).
Re-running the command: in the proper directory on the machine in question reproduces the error. The file it's complaining about () exists and doesn't appear corrupted.
Running the command over and over changes which crate it errors out on. In the initial run it was erroring out on but on subsequent runs it changes to , , etc.
If I remove the bit then it works fine. So seems related to the save-analysis code. /cc
I'm able to reproduce this in a local environment as well. Minimal steps so far (on a Ubuntu 18.04 VM) I ran with and the specific invocation that's reliably reproducing the failure is: (Obviously your paths may vary) Also note that this does NOT happen with (which installs a rustc built on 2020-03-09) so it's a regression between rustc version and rustc version .
Rust regression range:
If you're unable to repro or need more detail feel free to let me know. Otherwise for now I'm leaving this with you (i.e. rust developers) to dig into.
I have the very same crush with rustc 1.43.0-nightly ( 2020-03-11) on both of Mac and WSL2/Ubuntu, every time Rust language Server starts up in VSCode. No problem in rustc 1.43.0-nightly ( 2020-03-01). ### Error message:
I used to narrow the range to ...
Therefore regression from , cc
cc
I'd say this is a pre-existing save-analysis bug that was exposed by . should handle source files missing, which might require to return .
Same here:
Actually, this doesn't have to fail at all either, it's just hardcoded to non-external files: Before checking for the source, it would need to do this: And then something like this to handle both local and external sources: EDIT: nevermind about that last part, it's already.
So what are next steps here? I don't know what rustc's policy is with respect to regressions, is the regressing patch author responsible for fixing the regression?
Downgrading to fixes the issues in the vscode plugin for now.
Sorry, I'll go implement now. EDIT: up at .
I'm not sure why the original reproduction seemed so daunting, it triggered the bug as expected. I was also able to reproduce it on the problem crate itself: and it succeeds with this (which is my local build including ): also gets past the ICEs, but I can't easily do a full build because build scripts failed.
Thank you for the fix! At the moment using rustup to pull a nightly still gives me an older nightly (due to newer ones missing various components) but once I can get a nightly with the fix I'll report back whether or not it solved my original issue.
Confirmed the fix by forcing a nightly update. Thanks!
I am running into this / similar issue when is used as dependency: versions Here is the simple reproducible test case
Never mind I see now that version I have is . If I I do force update it works.

source_file: Lrc<rustc_span::SourceFile>, override_span: Option<Span>, ) -> Self { <del> if source_file.src.is_none() { </del> <ins> // Make sure external source is loaded first, before accessing it. // While this can't show up during normal parsing, `retokenize` may // be called with a source file from an external crate. sess.source_map().ensure_source_file_source_present(source_file.clone()); // FIXME(eddyb) use `Lrc<str>` or similar to avoid cloning the `String`. let src = if let Some(src) = &source_file.src { src.clone() } else if let Some(src) = source_file.external_src.borrow().get_source() { src.clone() } else { </ins> sess.span_diagnostic .bug(&format!("cannot lex `source_file` without source: {}", source_file.name)); <del> } let src = (*source_file.src.as_ref().unwrap()).clone(); </del> <ins> }; </ins> StringReader { sess,


Question:
<!-- 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. --The setup under which this occurs is somewhat complicated, but I'll try to reduce it as much as I can and update this issue with details. But basically it's using the latest nightly rustc and running on the latest code (, rev ). <!-- 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. --: (See full output in the backtrace details below) <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Also to note: so far this has happened 2/2 times today. It didn't happen yesterday (which presumably was running using a slightly-older rustc and checking slightly-older glean code).
Re-running the command: in the proper directory on the machine in question reproduces the error. The file it's complaining about () exists and doesn't appear corrupted.
Running the command over and over changes which crate it errors out on. In the initial run it was erroring out on but on subsequent runs it changes to , , etc.
If I remove the bit then it works fine. So seems related to the save-analysis code. /cc
I'm able to reproduce this in a local environment as well. Minimal steps so far (on a Ubuntu 18.04 VM) I ran with and the specific invocation that's reliably reproducing the failure is: (Obviously your paths may vary) Also note that this does NOT happen with (which installs a rustc built on 2020-03-09) so it's a regression between rustc version and rustc version .
Rust regression range:
If you're unable to repro or need more detail feel free to let me know. Otherwise for now I'm leaving this with you (i.e. rust developers) to dig into.
I have the very same crush with rustc 1.43.0-nightly ( 2020-03-11) on both of Mac and WSL2/Ubuntu, every time Rust language Server starts up in VSCode. No problem in rustc 1.43.0-nightly ( 2020-03-01). ### Error message:
I used to narrow the range to ...
Therefore regression from , cc
cc
I'd say this is a pre-existing save-analysis bug that was exposed by . should handle source files missing, which might require to return .
Same here:
Actually, this doesn't have to fail at all either, it's just hardcoded to non-external files: Before checking for the source, it would need to do this: And then something like this to handle both local and external sources: EDIT: nevermind about that last part, it's already.
So what are next steps here? I don't know what rustc's policy is with respect to regressions, is the regressing patch author responsible for fixing the regression?
Downgrading to fixes the issues in the vscode plugin for now.
Sorry, I'll go implement now. EDIT: up at .
I'm not sure why the original reproduction seemed so daunting, it triggered the bug as expected. I was also able to reproduce it on the problem crate itself: and it succeeds with this (which is my local build including ): also gets past the ICEs, but I can't easily do a full build because build scripts failed.
Thank you for the fix! At the moment using rustup to pull a nightly still gives me an older nightly (due to newer ones missing various components) but once I can get a nightly with the fix I'll report back whether or not it solved my original issue.
Confirmed the fix by forcing a nightly update. Thanks!
I am running into this / similar issue when is used as dependency: versions Here is the simple reproducible test case
Never mind I see now that version I have is . If I I do force update it works.

#[derive(PartialEq, Eq, Clone, Debug)] pub enum ExternalSourceKind { /// The external source has been loaded already. <del> Present(String), </del> <ins> Present(Lrc<String>), </ins> /// No attempt has been made to load the external source. AbsentOk, /// A failed attempt has been made to load the external source.


Question:
<!-- 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. --The setup under which this occurs is somewhat complicated, but I'll try to reduce it as much as I can and update this issue with details. But basically it's using the latest nightly rustc and running on the latest code (, rev ). <!-- 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. --: (See full output in the backtrace details below) <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Also to note: so far this has happened 2/2 times today. It didn't happen yesterday (which presumably was running using a slightly-older rustc and checking slightly-older glean code).
Re-running the command: in the proper directory on the machine in question reproduces the error. The file it's complaining about () exists and doesn't appear corrupted.
Running the command over and over changes which crate it errors out on. In the initial run it was erroring out on but on subsequent runs it changes to , , etc.
If I remove the bit then it works fine. So seems related to the save-analysis code. /cc
I'm able to reproduce this in a local environment as well. Minimal steps so far (on a Ubuntu 18.04 VM) I ran with and the specific invocation that's reliably reproducing the failure is: (Obviously your paths may vary) Also note that this does NOT happen with (which installs a rustc built on 2020-03-09) so it's a regression between rustc version and rustc version .
Rust regression range:
If you're unable to repro or need more detail feel free to let me know. Otherwise for now I'm leaving this with you (i.e. rust developers) to dig into.
I have the very same crush with rustc 1.43.0-nightly ( 2020-03-11) on both of Mac and WSL2/Ubuntu, every time Rust language Server starts up in VSCode. No problem in rustc 1.43.0-nightly ( 2020-03-01). ### Error message:
I used to narrow the range to ...
Therefore regression from , cc
cc
I'd say this is a pre-existing save-analysis bug that was exposed by . should handle source files missing, which might require to return .
Same here:
Actually, this doesn't have to fail at all either, it's just hardcoded to non-external files: Before checking for the source, it would need to do this: And then something like this to handle both local and external sources: EDIT: nevermind about that last part, it's already.
So what are next steps here? I don't know what rustc's policy is with respect to regressions, is the regressing patch author responsible for fixing the regression?
Downgrading to fixes the issues in the vscode plugin for now.
Sorry, I'll go implement now. EDIT: up at .
I'm not sure why the original reproduction seemed so daunting, it triggered the bug as expected. I was also able to reproduce it on the problem crate itself: and it succeeds with this (which is my local build including ): also gets past the ICEs, but I can't easily do a full build because build scripts failed.
Thank you for the fix! At the moment using rustup to pull a nightly still gives me an older nightly (due to newer ones missing various components) but once I can get a nightly with the fix I'll report back whether or not it solved my original issue.
Confirmed the fix by forcing a nightly update. Thanks!
I am running into this / similar issue when is used as dependency: versions Here is the simple reproducible test case
Never mind I see now that version I have is . If I I do force update it works.

} } <del> pub fn get_source(&self) -> Option<&str> { </del> <ins> pub fn get_source(&self) -> Option<&Lrc<String>> { </ins> match self { ExternalSource::Foreign { kind: ExternalSourceKind::Present(ref src), .. } => Some(src), _ => None,


Question:
<!-- 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. --The setup under which this occurs is somewhat complicated, but I'll try to reduce it as much as I can and update this issue with details. But basically it's using the latest nightly rustc and running on the latest code (, rev ). <!-- 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. --: (See full output in the backtrace details below) <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Also to note: so far this has happened 2/2 times today. It didn't happen yesterday (which presumably was running using a slightly-older rustc and checking slightly-older glean code).
Re-running the command: in the proper directory on the machine in question reproduces the error. The file it's complaining about () exists and doesn't appear corrupted.
Running the command over and over changes which crate it errors out on. In the initial run it was erroring out on but on subsequent runs it changes to , , etc.
If I remove the bit then it works fine. So seems related to the save-analysis code. /cc
I'm able to reproduce this in a local environment as well. Minimal steps so far (on a Ubuntu 18.04 VM) I ran with and the specific invocation that's reliably reproducing the failure is: (Obviously your paths may vary) Also note that this does NOT happen with (which installs a rustc built on 2020-03-09) so it's a regression between rustc version and rustc version .
Rust regression range:
If you're unable to repro or need more detail feel free to let me know. Otherwise for now I'm leaving this with you (i.e. rust developers) to dig into.
I have the very same crush with rustc 1.43.0-nightly ( 2020-03-11) on both of Mac and WSL2/Ubuntu, every time Rust language Server starts up in VSCode. No problem in rustc 1.43.0-nightly ( 2020-03-01). ### Error message:
I used to narrow the range to ...
Therefore regression from , cc
cc
I'd say this is a pre-existing save-analysis bug that was exposed by . should handle source files missing, which might require to return .
Same here:
Actually, this doesn't have to fail at all either, it's just hardcoded to non-external files: Before checking for the source, it would need to do this: And then something like this to handle both local and external sources: EDIT: nevermind about that last part, it's already.
So what are next steps here? I don't know what rustc's policy is with respect to regressions, is the regressing patch author responsible for fixing the regression?
Downgrading to fixes the issues in the vscode plugin for now.
Sorry, I'll go implement now. EDIT: up at .
I'm not sure why the original reproduction seemed so daunting, it triggered the bug as expected. I was also able to reproduce it on the problem crate itself: and it succeeds with this (which is my local build including ): also gets past the ICEs, but I can't easily do a full build because build scripts failed.
Thank you for the fix! At the moment using rustup to pull a nightly still gives me an older nightly (due to newer ones missing various components) but once I can get a nightly with the fix I'll report back whether or not it solved my original issue.
Confirmed the fix by forcing a nightly update. Thanks!
I am running into this / similar issue when is used as dependency: versions Here is the simple reproducible test case
Never mind I see now that version I have is . If I I do force update it works.

hasher.write(src.as_bytes()); if hasher.finish::<u128>() == self.src_hash { <del> *src_kind = ExternalSourceKind::Present(src); </del> <ins> *src_kind = ExternalSourceKind::Present(Lrc::new(src)); </ins> return true; } } else {


Question:
: <details<summary<strongBacktrace</strong</summary<p</p</details
It doesn't require feature flag.
I am currently working on this
my first idea was to fix this ICE locally by offsetting in line 1318 for each wrongly placed const param. This only moves the error further back. I currently think that it would be best to actually fix the param order if order fails. Is this a good approach? And how should this be done, as is used in , which only receives an immutable reference to .
I think the right fix for this would be to make sure we can handle generic parameters in any order — there's no technical reason the parameters should be in a fixed order; it's just historical. This would involve doing what you started with, and fixing each problem in turn. However, I don't know how many things still rely on this order, so it could be an involved task. For a shorter-term fix, we could just make sure that generics are sorted if they're in the wrong order. We could probably do this in and sort the before creating the . This might be more pragmatic, though we should leave a to address later if we do this. Thanks for looking into this

} } <ins> /// Checks that generic parameters are in the correct order, /// which is lifetimes, then types and then consts. (`<'a, T, const N: usize>`) </ins> fn validate_generic_param_order<'a>( sess: &Session, handler: &rustc_errors::Handler,


Question:
: <details<summary<strongBacktrace</strong</summary<p</p</details
It doesn't require feature flag.
I am currently working on this
my first idea was to fix this ICE locally by offsetting in line 1318 for each wrongly placed const param. This only moves the error further back. I currently think that it would be best to actually fix the param order if order fails. Is this a good approach? And how should this be done, as is used in , which only receives an immutable reference to .
I think the right fix for this would be to make sure we can handle generic parameters in any order — there's no technical reason the parameters should be in a fixed order; it's just historical. This would involve doing what you started with, and fixing each problem in turn. However, I don't know how many things still rely on this order, so it could be an involved task. For a shorter-term fix, we could just make sure that generics are sorted if they're in the wrong order. We could probably do this in and sort the before creating the . This might be more pragmatic, though we should leave a to address later if we do this. Thanks for looking into this

// Now create the real type and const parameters. let type_start = own_start - has_self as u32 + params.len() as u32; let mut i = 0; <del> params.extend(ast_generics.params.iter().filter_map(|param| { let kind = match param.kind { GenericParamKind::Type { ref default, synthetic, .. } => { if !allow_defaults && default.is_some() { if !tcx.features().default_type_parameter_fallback { tcx.struct_span_lint_hir( lint::builtin::INVALID_TYPE_PARAM_DEFAULT, param.hir_id, param.span, |lint| { lint.build( "defaults for type parameters are only allowed in  `struct`, `enum`, `type`, or `trait` definitions.", ) .emit(); }, ); } } ty::GenericParamDefKind::Type { has_default: default.is_some(), object_lifetime_default: object_lifetime_defaults .as_ref() .map_or(rl::Set1::Empty, |o| o[i]), synthetic, </del> <ins> // FIXME(const_generics): a few places in the compiler expect generic params // to be in the order lifetimes, then type params, then const params. // // To prevent internal errors in case const parameters are supplied before // type parameters we first add all type params, then all const params. params.extend(ast_generics.params.iter().filter_map(|param| { if let GenericParamKind::Type { ref default, synthetic, .. } = param.kind { if !allow_defaults && default.is_some() { if !tcx.features().default_type_parameter_fallback { tcx.struct_span_lint_hir( lint::builtin::INVALID_TYPE_PARAM_DEFAULT, param.hir_id, param.span, |lint| { lint.build( "defaults for type parameters are only allowed in  `struct`, `enum`, `type`, or `trait` definitions.", ) .emit(); }, ); </ins> } } <del> GenericParamKind::Const { .. } => ty::GenericParamDefKind::Const, _ => return None, }; let param_def = ty::GenericParamDef { index: type_start + i as u32, name: param.name.ident().name, def_id: tcx.hir().local_def_id(param.hir_id), pure_wrt_drop: param.pure_wrt_drop, kind, }; i += 1; Some(param_def) </del> <ins> let kind = ty::GenericParamDefKind::Type { has_default: default.is_some(), object_lifetime_default: object_lifetime_defaults .as_ref() .map_or(rl::Set1::Empty, |o| o[i]), synthetic, }; let param_def = ty::GenericParamDef { index: type_start + i as u32, name: param.name.ident().name, def_id: tcx.hir().local_def_id(param.hir_id), pure_wrt_drop: param.pure_wrt_drop, kind, }; i += 1; Some(param_def) } else { None } })); params.extend(ast_generics.params.iter().filter_map(|param| { if let GenericParamKind::Const { .. } = param.kind { let param_def = ty::GenericParamDef { index: type_start + i as u32, name: param.name.ident().name, def_id: tcx.hir().local_def_id(param.hir_id), pure_wrt_drop: param.pure_wrt_drop, kind: ty::GenericParamDefKind::Const, }; i += 1; Some(param_def) } else { None } </ins> })); // provide junk type parameter defs - the only place that


Question:
: <details<summary<strongBacktrace</strong</summary<p</p</details
It doesn't require feature flag.
I am currently working on this
my first idea was to fix this ICE locally by offsetting in line 1318 for each wrongly placed const param. This only moves the error further back. I currently think that it would be best to actually fix the param order if order fails. Is this a good approach? And how should this be done, as is used in , which only receives an immutable reference to .
I think the right fix for this would be to make sure we can handle generic parameters in any order — there's no technical reason the parameters should be in a fixed order; it's just historical. This would involve doing what you started with, and fixing each problem in turn. However, I don't know how many things still rely on this order, so it could be an involved task. For a shorter-term fix, we could just make sure that generics are sorted if they're in the wrong order. We could probably do this in and sort the before creating the . This might be more pragmatic, though we should leave a to address later if we do this. Thanks for looking into this

<ins> #![feature(const_generics)] //~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash struct Bad<const N: usize, T> { //~ ERROR type parameters must be declared prior arr: [u8; { N }], another: T, } fn main() { } </ins>


Question:
: <details<summary<strongBacktrace</strong</summary<p</p</details
It doesn't require feature flag.
I am currently working on this
my first idea was to fix this ICE locally by offsetting in line 1318 for each wrongly placed const param. This only moves the error further back. I currently think that it would be best to actually fix the param order if order fails. Is this a good approach? And how should this be done, as is used in , which only receives an immutable reference to .
I think the right fix for this would be to make sure we can handle generic parameters in any order — there's no technical reason the parameters should be in a fixed order; it's just historical. This would involve doing what you started with, and fixing each problem in turn. However, I don't know how many things still rely on this order, so it could be an involved task. For a shorter-term fix, we could just make sure that generics are sorted if they're in the wrong order. We could probably do this in and sort the before creating the . This might be more pragmatic, though we should leave a to address later if we do this. Thanks for looking into this

<ins> error: type parameters must be declared prior to const parameters --> $DIR/argument_order.rs:4:28 | LL | struct Bad<const N: usize, T> { |           -----------------^- help: reorder the parameters: lifetimes, then types, then consts: `<T, const N: usize>` warning: the feature `const_generics` is incomplete and may cause the compiler to crash --> $DIR/argument_order.rs:1:12 | LL | #![feature(const_generics)] |            ^^^^^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default error: aborting due to previous error </ins>


Question:
Doctest test names have changed due to . Doc comments that pass through a macro defined in another crate now seem to report a different span. /// assert!(true); /// running with previously looked like this: Now the test names look like this: Frankly, neither are particularly great. It would be nice if the test name used the span from where the macro was invoked, not where it was defined.
I think this also affects normal backtraces :( Just got this rather unuseful backtrace while bootstrapping: full:
cc
What you're describing is entirely in the opposite direction, is the old (and arguably bad) kind of that's impossible to get anymore. I've hidden your comment to focus on the reported issue.
That makes sense, we have a way to get the outermost invocation, that is used by / and : We'd just need to use this in .
cc
cc
Removed label, left nomination for to decide about this issue.
Well, using what suggested seems like the best thing to do.

// The collapse-docs pass won't combine sugared/raw doc attributes, or included files with // anything else, this will combine them for us. if let Some(doc) = attrs.collapsed_doc_value() { <del> self.collector.set_position(attrs.span.unwrap_or(DUMMY_SP)); </del> <ins> // Use the outermost invocation, so that doctest names come from where the docs were written. let span = attrs .span .map(|span| span.ctxt().outer_expn().expansion_cause().unwrap_or(span)) .unwrap_or(DUMMY_SP); self.collector.set_position(span); </ins> markdown::find_testable_code( &doc, self.collector,


Question:
Doctest test names have changed due to . Doc comments that pass through a macro defined in another crate now seem to report a different span. /// assert!(true); /// running with previously looked like this: Now the test names look like this: Frankly, neither are particularly great. It would be nice if the test name used the span from where the macro was invoked, not where it was defined.
I think this also affects normal backtraces :( Just got this rather unuseful backtrace while bootstrapping: full:
cc
What you're describing is entirely in the opposite direction, is the old (and arguably bad) kind of that's impossible to get anymore. I've hidden your comment to focus on the reported issue.
That makes sense, we have a way to get the outermost invocation, that is used by / and : We'd just need to use this in .
cc
cc
Removed label, left nomination for to decide about this issue.
Well, using what suggested seems like the best thing to do.

<ins> #[macro_export] macro_rules! attrs_on_struct { ( $( #[$attr:meta] )* ) => { $( #[$attr] )* pub struct ExpandedStruct; } } </ins>


Question:
Doctest test names have changed due to . Doc comments that pass through a macro defined in another crate now seem to report a different span. /// assert!(true); /// running with previously looked like this: Now the test names look like this: Frankly, neither are particularly great. It would be nice if the test name used the span from where the macro was invoked, not where it was defined.
I think this also affects normal backtraces :( Just got this rather unuseful backtrace while bootstrapping: full:
cc
What you're describing is entirely in the opposite direction, is the old (and arguably bad) kind of that's impossible to get anymore. I've hidden your comment to focus on the reported issue.
That makes sense, we have a way to get the outermost invocation, that is used by / and : We'd just need to use this in .
cc
cc
Removed label, left nomination for to decide about this issue.
Well, using what suggested seems like the best thing to do.

<ins> // edition:2018 // aux-build:extern_macros.rs </ins> // compile-flags:--test --test-args=--test-threads=1 // normalize-stdout-test: "src/test/rustdoc-ui" -> "$$DIR" // check-pass


Question:
Doctest test names have changed due to . Doc comments that pass through a macro defined in another crate now seem to report a different span. /// assert!(true); /// running with previously looked like this: Now the test names look like this: Frankly, neither are particularly great. It would be nice if the test name used the span from where the macro was invoked, not where it was defined.
I think this also affects normal backtraces :( Just got this rather unuseful backtrace while bootstrapping: full:
cc
What you're describing is entirely in the opposite direction, is the old (and arguably bad) kind of that's impossible to get anymore. I've hidden your comment to focus on the reported issue.
That makes sense, we have a way to get the outermost invocation, that is used by / and : We'd just need to use this in .
cc
cc
Removed label, left nomination for to decide about this issue.
Well, using what suggested seems like the best thing to do.

//! assert_eq!(1 + 1, 2); //! ``` <ins> extern crate extern_macros as macros; use macros::attrs_on_struct; </ins> pub mod foo { /// ```


Question:
Doctest test names have changed due to . Doc comments that pass through a macro defined in another crate now seem to report a different span. /// assert!(true); /// running with previously looked like this: Now the test names look like this: Frankly, neither are particularly great. It would be nice if the test name used the span from where the macro was invoked, not where it was defined.
I think this also affects normal backtraces :( Just got this rather unuseful backtrace while bootstrapping: full:
cc
What you're describing is entirely in the opposite direction, is the old (and arguably bad) kind of that's impossible to get anymore. I've hidden your comment to focus on the reported issue.
That makes sense, we have a way to get the outermost invocation, that is used by / and : We'd just need to use this in .
cc
cc
Removed label, left nomination for to decide about this issue.
Well, using what suggested seems like the best thing to do.

/// ``` pub fn bar() {} } <ins> attrs_on_struct! { /// ``` /// assert!(true); /// ``` } </ins>


Question:
Doctest test names have changed due to . Doc comments that pass through a macro defined in another crate now seem to report a different span. /// assert!(true); /// running with previously looked like this: Now the test names look like this: Frankly, neither are particularly great. It would be nice if the test name used the span from where the macro was invoked, not where it was defined.
I think this also affects normal backtraces :( Just got this rather unuseful backtrace while bootstrapping: full:
cc
What you're describing is entirely in the opposite direction, is the old (and arguably bad) kind of that's impossible to get anymore. I've hidden your comment to focus on the reported issue.
That makes sense, we have a way to get the outermost invocation, that is used by / and : We'd just need to use this in .
cc
cc
Removed label, left nomination for to decide about this issue.
Well, using what suggested seems like the best thing to do.

<del> running 2 tests test $DIR/doctest-output.rs - (line 5) ... ok test $DIR/doctest-output.rs - foo::bar (line 11) ... ok </del> <ins> running 3 tests test $DIR/doctest-output.rs - (line 7) ... ok test $DIR/doctest-output.rs - ExpandedStruct (line 23) ... ok test $DIR/doctest-output.rs - foo::bar (line 17) ... ok </ins> <del> test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out </del> <ins> test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out </ins>


Question:
Doctest test names have changed due to . Doc comments that pass through a macro defined in another crate now seem to report a different span. /// assert!(true); /// running with previously looked like this: Now the test names look like this: Frankly, neither are particularly great. It would be nice if the test name used the span from where the macro was invoked, not where it was defined.
I think this also affects normal backtraces :( Just got this rather unuseful backtrace while bootstrapping: full:
cc
What you're describing is entirely in the opposite direction, is the old (and arguably bad) kind of that's impossible to get anymore. I've hidden your comment to focus on the reported issue.
That makes sense, we have a way to get the outermost invocation, that is used by / and : We'd just need to use this in .
cc
cc
Removed label, left nomination for to decide about this issue.
Well, using what suggested seems like the best thing to do.

} /// Configuration for compiletest <del> #[derive(Clone)] </del> <ins> #[derive(Debug, Clone)] </ins> pub struct Config { /// `true` to to overwrite stderr/stdout files instead of complaining about changes in output. pub bless: bool,


Question:
Doctest test names have changed due to . Doc comments that pass through a macro defined in another crate now seem to report a different span. /// assert!(true); /// running with previously looked like this: Now the test names look like this: Frankly, neither are particularly great. It would be nice if the test name used the span from where the macro was invoked, not where it was defined.
I think this also affects normal backtraces :( Just got this rather unuseful backtrace while bootstrapping: full:
cc
What you're describing is entirely in the opposite direction, is the old (and arguably bad) kind of that's impossible to get anymore. I've hidden your comment to focus on the reported issue.
That makes sense, we have a way to get the outermost invocation, that is used by / and : We'd just need to use this in .
cc
cc
Removed label, left nomination for to decide about this issue.
Well, using what suggested seems like the best thing to do.

emit_metadata: EmitMetadata, allow_unused: AllowUnused, ) -> Command { <del> let is_rustdoc = self.is_rustdoc(); </del> <ins> let is_aux = input_file.components().map(|c| c.as_os_str()).any(|c| c == "auxiliary"); let is_rustdoc = self.is_rustdoc() && !is_aux; </ins> let mut rustc = if !is_rustdoc { Command::new(&self.config.rustc_path) } else {


Question:
Doctest test names have changed due to . Doc comments that pass through a macro defined in another crate now seem to report a different span. /// assert!(true); /// running with previously looked like this: Now the test names look like this: Frankly, neither are particularly great. It would be nice if the test name used the span from where the macro was invoked, not where it was defined.
I think this also affects normal backtraces :( Just got this rather unuseful backtrace while bootstrapping: full:
cc
What you're describing is entirely in the opposite direction, is the old (and arguably bad) kind of that's impossible to get anymore. I've hidden your comment to focus on the reported issue.
That makes sense, we have a way to get the outermost invocation, that is used by / and : We'd just need to use this in .
cc
cc
Removed label, left nomination for to decide about this issue.
Well, using what suggested seems like the best thing to do.

} } <ins> #[derive(Debug)] </ins> enum TargetLocation { ThisFile(PathBuf), ThisDirectory(PathBuf),


Question:
gives: My guess is that this has the same underlying cause as , but this one doesn't involve associated consts or arrays at all, so it might be different still.
This appears to be due to a bad interaction between and associated type projections involving lifetimes. When we normalize the function signature during type-checking, we project to . We then convert back to the 'generic' region for , which is . However, this is a distinct early bound region, different from the in (changing the regions to not all be called in the example makes this clearer). This causes issues during , since we've essentially pulled a region out of thin air. This issue doesn't seem to come up for type parameters ( with lifetimes replaced with types). I'm not sure if this is because our handling of type parameters is correct for this kind of projection, or if we need a more complicated example to break things.
The ICE no longer happens with the latest nightly (note that the playground's nightly isn't the latest). That was removed by . Marked as E-needs-test.

<ins> // Regression test for https://github.com/rust-lang/rust/issues/56445#issuecomment-629426939 // check-pass #![crate_type = "lib"] use std::marker::PhantomData; pub struct S<'a> { pub m1: PhantomData<&'a u8>, pub m2: [u8; S::size()], } impl<'a> S<'a> { pub const fn size() -> usize { 1 } pub fn new() -> Self { Self { m1: PhantomData, m2: [0; Self::size()], } } } </ins>


Question:
gives: My guess is that this has the same underlying cause as , but this one doesn't involve associated consts or arrays at all, so it might be different still.
This appears to be due to a bad interaction between and associated type projections involving lifetimes. When we normalize the function signature during type-checking, we project to . We then convert back to the 'generic' region for , which is . However, this is a distinct early bound region, different from the in (changing the regions to not all be called in the example makes this clearer). This causes issues during , since we've essentially pulled a region out of thin air. This issue doesn't seem to come up for type parameters ( with lifetimes replaced with types). I'm not sure if this is because our handling of type parameters is correct for this kind of projection, or if we need a more complicated example to break things.
The ICE no longer happens with the latest nightly (note that the playground's nightly isn't the latest). That was removed by . Marked as E-needs-test.

<ins> // check-pass pub struct A<'a>(&'a ()); impl<'a> A<'a> { const N: usize = 68; pub fn foo(&self) { let _b = [0; Self::N]; } } fn main() {} </ins>


Question:
gives: My guess is that this has the same underlying cause as , but this one doesn't involve associated consts or arrays at all, so it might be different still.
This appears to be due to a bad interaction between and associated type projections involving lifetimes. When we normalize the function signature during type-checking, we project to . We then convert back to the 'generic' region for , which is . However, this is a distinct early bound region, different from the in (changing the regions to not all be called in the example makes this clearer). This causes issues during , since we've essentially pulled a region out of thin air. This issue doesn't seem to come up for type parameters ( with lifetimes replaced with types). I'm not sure if this is because our handling of type parameters is correct for this kind of projection, or if we need a more complicated example to break things.
The ICE no longer happens with the latest nightly (note that the playground's nightly isn't the latest). That was removed by . Marked as E-needs-test.

<ins> #![feature(impl_trait_in_bindings)] #![allow(incomplete_features)] fn main() { const C: impl Copy = 0; match C { C | _ => {} //~ ERROR: opaque types cannot be used in patterns } } </ins>


Question:
gives: My guess is that this has the same underlying cause as , but this one doesn't involve associated consts or arrays at all, so it might be different still.
This appears to be due to a bad interaction between and associated type projections involving lifetimes. When we normalize the function signature during type-checking, we project to . We then convert back to the 'generic' region for , which is . However, this is a distinct early bound region, different from the in (changing the regions to not all be called in the example makes this clearer). This causes issues during , since we've essentially pulled a region out of thin air. This issue doesn't seem to come up for type parameters ( with lifetimes replaced with types). I'm not sure if this is because our handling of type parameters is correct for this kind of projection, or if we need a more complicated example to break things.
The ICE no longer happens with the latest nightly (note that the playground's nightly isn't the latest). That was removed by . Marked as E-needs-test.

<ins> error: opaque types cannot be used in patterns --> $DIR/issue-71042-opaquely-typed-constant-used-in-pattern.rs:7:9 | LL |         C | _ => {} |         ^ error: aborting due to previous error </ins>


Question:
gives: My guess is that this has the same underlying cause as , but this one doesn't involve associated consts or arrays at all, so it might be different still.
This appears to be due to a bad interaction between and associated type projections involving lifetimes. When we normalize the function signature during type-checking, we project to . We then convert back to the 'generic' region for , which is . However, this is a distinct early bound region, different from the in (changing the regions to not all be called in the example makes this clearer). This causes issues during , since we've essentially pulled a region out of thin air. This issue doesn't seem to come up for type parameters ( with lifetimes replaced with types). I'm not sure if this is because our handling of type parameters is correct for this kind of projection, or if we need a more complicated example to break things.
The ICE no longer happens with the latest nightly (note that the playground's nightly isn't the latest). That was removed by . Marked as E-needs-test.

<ins> // check-pass #![feature(type_alias_impl_trait)] pub type Successors<'a> = impl Iterator<Item = &'a ()>; pub fn f<'a>() -> Successors<'a> { None.into_iter() } pub trait Tr { type Item; } impl<'a> Tr for &'a () { type Item = Successors<'a>; } pub fn kazusa<'a>() -> <&'a () as Tr>::Item { None.into_iter() } fn main() {} </ins>


Question:
<!-- 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 was writing some generic code over vectors using the under-construction feature of const generics, and had a circular chain of super-traits that required me to cast the Self type to the trait as can be seen in the supertrait requirement. I believe that is causing the MIR error. I think this may be related to but it is subtly different so I'm putting the issue up regardless. <!-- 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. --: I updated my rust version on nightly right before I ran this so hopefully it is up to date: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
minimized: claim
Looks like maybe constants in trait paths don't get their type correctly? cc
Initially I thought this was about bounds but no, this also fails: ()
I believe this code is responsible: And the problem is that this doesn't handle associated types which need the same treatment:
Alternatively, instead of using to get the , maybe we could use the olution from the segment we found the const parameter in? I believe nowadays we have per-segment resolutions, which would avoid breaking GATs in the future. Actually, I expect is also broken, let's try it... Yupp: () EDIT: took a second look and that is in a , which has to be resolved by the body of , which means it's as bad as the method call form (which I just ). Maybe we should disallow passing explicit generic args to methods for now? Since I have no idea how one would figure out the expected type.
If you look at this later btw, my comment above () still isn't addressed, but I haven't made an issue yet about it.

// figure out which generic parameter it corresponds to and return // the relevant type. let generics = match path.res { <del> Res::Def(DefKind::Ctor(..), def_id) => { </del> <ins> Res::Def(DefKind::Ctor(..), def_id) | Res::Def(DefKind::AssocTy, def_id) => { </ins> tcx.generics_of(tcx.parent(def_id).unwrap()) } Res::Def(_, def_id) => tcx.generics_of(def_id), <del> Res::Err => return tcx.types.err, </del> res => { tcx.sess.delay_span_bug( DUMMY_SP, <del> &format!("unexpected const parent path def {:?}", res,), </del> <ins> &format!( "unexpected const parent path def, parent: {:?}, def: {:?}", parent_node, res ), </ins> ); return tcx.types.err; }


Question:
<!-- 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 was writing some generic code over vectors using the under-construction feature of const generics, and had a circular chain of super-traits that required me to cast the Self type to the trait as can be seen in the supertrait requirement. I believe that is causing the MIR error. I think this may be related to but it is subtly different so I'm putting the issue up regardless. <!-- 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. --: I updated my rust version on nightly right before I ran this so hopefully it is up to date: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
minimized: claim
Looks like maybe constants in trait paths don't get their type correctly? cc
Initially I thought this was about bounds but no, this also fails: ()
I believe this code is responsible: And the problem is that this doesn't handle associated types which need the same treatment:
Alternatively, instead of using to get the , maybe we could use the olution from the segment we found the const parameter in? I believe nowadays we have per-segment resolutions, which would avoid breaking GATs in the future. Actually, I expect is also broken, let's try it... Yupp: () EDIT: took a second look and that is in a , which has to be resolved by the body of , which means it's as bad as the method call form (which I just ). Maybe we should disallow passing explicit generic args to methods for now? Since I have no idea how one would figure out the expected type.
If you look at this later btw, my comment above () still isn't addressed, but I haven't made an issue yet about it.

.map(|param| tcx.type_of(param.def_id)) // This is no generic parameter associated with the arg. This is // probably from an extra arg where one is not needed. <del> .unwrap_or(tcx.types.err) </del> <ins> .unwrap_or_else(|| { tcx.sess.delay_span_bug( DUMMY_SP, &format!( "missing generic parameter for `AnonConst`, parent {:?}", parent_node ), ); tcx.types.err }) </ins> } else { tcx.sess.delay_span_bug( DUMMY_SP,


Question:
<!-- 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 was writing some generic code over vectors using the under-construction feature of const generics, and had a circular chain of super-traits that required me to cast the Self type to the trait as can be seen in the supertrait requirement. I believe that is causing the MIR error. I think this may be related to but it is subtly different so I'm putting the issue up regardless. <!-- 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. --: I updated my rust version on nightly right before I ran this so hopefully it is up to date: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
minimized: claim
Looks like maybe constants in trait paths don't get their type correctly? cc
Initially I thought this was about bounds but no, this also fails: ()
I believe this code is responsible: And the problem is that this doesn't handle associated types which need the same treatment:
Alternatively, instead of using to get the , maybe we could use the olution from the segment we found the const parameter in? I believe nowadays we have per-segment resolutions, which would avoid breaking GATs in the future. Actually, I expect is also broken, let's try it... Yupp: () EDIT: took a second look and that is in a , which has to be resolved by the body of , which means it's as bad as the method call form (which I just ). Maybe we should disallow passing explicit generic args to methods for now? Since I have no idea how one would figure out the expected type.
If you look at this later btw, my comment above () still isn't addressed, but I haven't made an issue yet about it.

<ins> // check-pass #![feature(const_generics)] //~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash pub struct Tuple; pub trait Trait<const I: usize> { type Input: From<<Self as Trait<I>>::Input>; } fn main() {} </ins>


Question:
<!-- 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 was writing some generic code over vectors using the under-construction feature of const generics, and had a circular chain of super-traits that required me to cast the Self type to the trait as can be seen in the supertrait requirement. I believe that is causing the MIR error. I think this may be related to but it is subtly different so I'm putting the issue up regardless. <!-- 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. --: I updated my rust version on nightly right before I ran this so hopefully it is up to date: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
minimized: claim
Looks like maybe constants in trait paths don't get their type correctly? cc
Initially I thought this was about bounds but no, this also fails: ()
I believe this code is responsible: And the problem is that this doesn't handle associated types which need the same treatment:
Alternatively, instead of using to get the , maybe we could use the olution from the segment we found the const parameter in? I believe nowadays we have per-segment resolutions, which would avoid breaking GATs in the future. Actually, I expect is also broken, let's try it... Yupp: () EDIT: took a second look and that is in a , which has to be resolved by the body of , which means it's as bad as the method call form (which I just ). Maybe we should disallow passing explicit generic args to methods for now? Since I have no idea how one would figure out the expected type.
If you look at this later btw, my comment above () still isn't addressed, but I haven't made an issue yet about it.

<ins> warning: the feature `const_generics` is incomplete and may cause the compiler to crash --> $DIR/issue-66906.rs:3:12 | LL | #![feature(const_generics)] |            ^^^^^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default </ins>


Question:
<!-- 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 was writing some generic code over vectors using the under-construction feature of const generics, and had a circular chain of super-traits that required me to cast the Self type to the trait as can be seen in the supertrait requirement. I believe that is causing the MIR error. I think this may be related to but it is subtly different so I'm putting the issue up regardless. <!-- 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. --: I updated my rust version on nightly right before I ran this so hopefully it is up to date: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
minimized: claim
Looks like maybe constants in trait paths don't get their type correctly? cc
Initially I thought this was about bounds but no, this also fails: ()
I believe this code is responsible: And the problem is that this doesn't handle associated types which need the same treatment:
Alternatively, instead of using to get the , maybe we could use the olution from the segment we found the const parameter in? I believe nowadays we have per-segment resolutions, which would avoid breaking GATs in the future. Actually, I expect is also broken, let's try it... Yupp: () EDIT: took a second look and that is in a , which has to be resolved by the body of , which means it's as bad as the method call form (which I just ). Maybe we should disallow passing explicit generic args to methods for now? Since I have no idea how one would figure out the expected type.
If you look at this later btw, my comment above () still isn't addressed, but I haven't made an issue yet about it.

<ins> // check-pass #![feature(const_generics)] //~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash pub trait Trait<const N: usize>: From<<Self as Trait<N>>::Item> { type Item; } fn main() {} </ins>


Question:
<!-- 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 was writing some generic code over vectors using the under-construction feature of const generics, and had a circular chain of super-traits that required me to cast the Self type to the trait as can be seen in the supertrait requirement. I believe that is causing the MIR error. I think this may be related to but it is subtly different so I'm putting the issue up regardless. <!-- 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. --: I updated my rust version on nightly right before I ran this so hopefully it is up to date: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
minimized: claim
Looks like maybe constants in trait paths don't get their type correctly? cc
Initially I thought this was about bounds but no, this also fails: ()
I believe this code is responsible: And the problem is that this doesn't handle associated types which need the same treatment:
Alternatively, instead of using to get the , maybe we could use the olution from the segment we found the const parameter in? I believe nowadays we have per-segment resolutions, which would avoid breaking GATs in the future. Actually, I expect is also broken, let's try it... Yupp: () EDIT: took a second look and that is in a , which has to be resolved by the body of , which means it's as bad as the method call form (which I just ). Maybe we should disallow passing explicit generic args to methods for now? Since I have no idea how one would figure out the expected type.
If you look at this later btw, my comment above () still isn't addressed, but I haven't made an issue yet about it.

<ins> warning: the feature `const_generics` is incomplete and may cause the compiler to crash --> $DIR/issue-70167.rs:3:12 | LL | #![feature(const_generics)] |            ^^^^^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default </ins>


Question:
In a recent PR I made a change to unify the wording of multiple privacy errors, but : used to be This one change needs to be reversed while keeping the rest.
Hi! Could I give this issue a shot?
I am sorry I forgot to claim the issue
No worries :-)

span: Span,            // span of the field pattern, e.g., `x: 0` def: &'tcx ty::AdtDef, // definition of the struct or enum field: &'tcx ty::FieldDef, <ins> in_update_syntax: bool, </ins> ) { // definition of the field let ident = Ident::new(kw::Invalid, use_ctxt); let current_hir = self.current_item; let def_id = self.tcx.adjust_ident_and_get_scope(ident, def.did, current_hir).1; if !def.is_enum() && !field.vis.is_accessible_from(def_id, self.tcx) { <ins> let label = if in_update_syntax { format!("field `{}` is private", field.ident) } else { "private field".to_string() }; </ins> struct_span_err!( self.tcx.sess, span,


Question:
In a recent PR I made a change to unify the wording of multiple privacy errors, but : used to be This one change needs to be reversed while keeping the rest.
Hi! Could I give this issue a shot?
I am sorry I forgot to claim the issue
No worries :-)

def.variant_descr(), self.tcx.def_path_str(def.did) ) <del> .span_label(span, "private field") </del> <ins> .span_label(span, label) </ins> .emit(); } }


Question:
In a recent PR I made a change to unify the wording of multiple privacy errors, but : used to be This one change needs to be reversed while keeping the rest.
Hi! Could I give this issue a shot?
I am sorry I forgot to claim the issue
No worries :-)

Some(field) => (field.ident.span, field.span), None => (base.span, base.span), }; <del> self.check_field(use_ctxt, span, adt, variant_field); </del> <ins> self.check_field(use_ctxt, span, adt, variant_field, true); </ins> } } else { for field in fields { let use_ctxt = field.ident.span; let index = self.tcx.field_index(field.hir_id, self.tables); <del> self.check_field(use_ctxt, field.span, adt, &variant.fields[index]); </del> <ins> self.check_field(use_ctxt, field.span, adt, &variant.fields[index], false); </ins> } } }


Question:
In a recent PR I made a change to unify the wording of multiple privacy errors, but : used to be This one change needs to be reversed while keeping the rest.
Hi! Could I give this issue a shot?
I am sorry I forgot to claim the issue
No worries :-)

for field in fields { let use_ctxt = field.ident.span; let index = self.tcx.field_index(field.hir_id, self.tables); <del> self.check_field(use_ctxt, field.span, adt, &variant.fields[index]); </del> <ins> self.check_field(use_ctxt, field.span, adt, &variant.fields[index], false); </ins> } } _ => {}


Question:
In a recent PR I made a change to unify the wording of multiple privacy errors, but : used to be This one change needs to be reversed while keeping the rest.
Hi! Could I give this issue a shot?
I am sorry I forgot to claim the issue
No worries :-)

--> $DIR/functional-struct-update-respects-privacy.rs:28:49 | LL |     let s_2 = foo::S { b: format!("ess two"), ..s_1 }; // FRU ... <del> |                                                 ^^^ private field </del> <ins> |                                                 ^^^ field `secret_uid` is private </ins> error: aborting due to previous error


Question:
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! And nominating for compiler team prioritization.
Removing nomination, as part of pre-triage we are looking anyways into tool breakage.

<del> Subproject commit aaa16a5f4b8caabf8e044e6dd1c48330dfb7900d </del> <ins> Subproject commit 0d0a457c8b1750e82f19527b18b313f3514633f0 </ins>


Question:
const-prop checks statics for whether they contain relocations, and if they do, it refuses to read from them. It is not clear why that happens. Cc
I just realized the condition is , so maybe the allocation in question was not even mutable but had relocations in it. I am testing that now. I do not understand the argument given in the code for why relocations are a problem: If the memory behind that pointer is mutable, we will notice that when that allocation is being accessed. Why do we have to bail out so early? Is it because the hook used to only be called for statics, not all global allocations?
Also the mystery about why validation is even happening is answered here: I think I understand why, conservatively, this does validation... can this ever fail? Validation is quite picky about the kinds of errors in expects can happen, and with const-prop having a machine that bails out early on many operations, that could be a problem. The reason validation is so picky is to make sure we get good errors, which const-prop does not care about (the errors are not shown to the user), but it re-uses the same machinery.
Okay so the actual problem turned out to be relocations. There is no bug here, we can reject all reads from mutable globals (phew). What remains open is why we check for the presence of relocations at all. you that I mentioned above, would be great if you could explain it a bit more. :)
: But I'm not quite sure why...
Basically I want to avoid the following (assume it compiles with more boilerplate) from optimizing to Since we can't ever know what users are up to with their code, the presence of relocations was the easiest way to avoid any kind of troubles there. Furthermore, assuming we just forbid raw pointers from being derefed in const prop, we'd still have problems with the following getting const propped:: I want to prevent const prop from creating any kind of mutable global memory that we may end up pointing to. While we can probably devise a smart scheme, right now it seems better to just forbid any relocations.
that sounds to me like an indirect way to do the check that we can now do much more reliably and directly: This is done for all accesses to globals (things stored in ). So if a constant global points to a mutable one, the check will fire when the mutable global actually gets accessed.
that's true. Makes more sense to handle the first case like that.
But how does that help with the second example I gave?
The second example does not involve any global though? So nothing we do in that hook will have any effect? I am confused.^^
The problem is that it would magically create a global if we used const prop here. Basically the same problems apply that we have with promotion (except that it's not a problem if we regress optimizations as they aren't "stable")
But again, what does the hook have to do with that? It won't prevent creation of that global, just access to it. I also cannot imagine how const-prop could do anything in your example... doesn't have a known value. And in a case like it would be entirely okay to replace by . Of course with it would not be okay, but then that is exactly the same as using mutable references -- and it has nothing to do with globals. So I fail to see the relevance of any of this for the discussion at hand.
I'm not worried about . I'm worried about const propping into , so is eliminated entirely. optimized to I'm not sure how we're supposed to prevent this without banning relocations in propagated constants.
I don't see why we would even try to do that, that seems like a really odd transformation? And certainly, if any code is responsible for getting things like that right, it's the code that constructs new constants, not the code that reads from existing constants? You still didn't explain how the prevents anything like that. It prevents reading from constants that have relocation, but you keep talking about constructing new constants that have relocations. My confusion remains: what does anything you say have to do with what the issue is about, namely ?
Ah, that's where the confusion comes from. Let's start with a code example again: If we const prop the at some point (or construct your own lockfree datastructure that doesn't use any intrinsics), we have now changed behaviour because we never read the runtime value of (0) but instead the initializer value (42).
(Sorry for the double-post, GH keeps submitting comments for me way before I am done. Probably some silly trigger-happy shortcut.) Indeed, that would be a problem. And that problem is caught by which would reject any read from a mutable global allocation such as . Which additional problem necessitates the additional check that follows next?
Oh. I see now. Yea, we don't need the second check, any later const prop will do the mutability check and bail out, no matter the number and kind of indirections. We can remove the check
That's what I thought, thanks. :)

_memory_extra: &(), _alloc_id: AllocId, allocation: &Allocation<Self::PointerTag, Self::AllocExtra>, <del> static_def_id: Option<DefId>, </del> <ins> _static_def_id: Option<DefId>, </ins> is_write: bool, ) -> InterpResult<'tcx> { if is_write { throw_machine_stop_str!("can't write to global"); } <del> // If the static allocation is mutable or if it has relocations (it may be legal to mutate // the memory behind that in the future), then we can't const prop it. </del> <ins> // If the static allocation is mutable, then we can't const prop it as its content // might be different at runtime. </ins> if allocation.mutability == Mutability::Mut { <del> throw_machine_stop_str!("can't eval mutable globals in ConstProp"); } if static_def_id.is_some() && allocation.relocations().len() > 0 { throw_machine_stop_str!("can't eval statics with pointers in ConstProp"); </del> <ins> throw_machine_stop_str!("can't access mutable globals in ConstProp"); </ins> } Ok(())


Question:
Should the following code be accepted? if so, we probably also want to accept the following: cc
So,how would the following be handled? That is (passing an identifier as a const argument).
should be equal to imo. rn literals which are in both the type and the value namespace are always used as type params though (see ). So this would fail to compile even if we get to work.

fn visit_generics(&mut self, generics: &'a Generics) { let mut prev_ty_default = None; for param in &generics.params { <del> if let GenericParamKind::Type { ref default, .. } = param.kind { if default.is_some() { </del> <ins> match param.kind { GenericParamKind::Lifetime => (), GenericParamKind::Type { default: Some(_), .. } => { </ins> prev_ty_default = Some(param.ident.span); <del> } else if let Some(span) = prev_ty_default { self.err_handler() .span_err(span, "type parameters with a default must be trailing"); break; </del> <ins> } GenericParamKind::Type { .. } | GenericParamKind::Const { .. } => { if let Some(span) = prev_ty_default { let mut err = self.err_handler().struct_span_err( span, "type parameters with a default must be trailing", ); if matches!(param.kind, GenericParamKind::Const { .. }) { err.note( "using type defaults and const parameters  in the same parameter list is currently not permitted", ); } err.emit(); break; } </ins> } } }


Question:
Should the following code be accepted? if so, we probably also want to accept the following: cc
So,how would the following be handled? That is (passing an identifier as a const argument).
should be equal to imo. rn literals which are in both the type and the value namespace are always used as type params though (see ). So this would fail to compile even if we get to work.

<ins> #![feature(const_generics)] //~ WARN the feature `const_generics` is incomplete struct A<T = u32, const N: usize> { //~^ ERROR type parameters with a default must be trailing arg: T, } fn main() {} </ins>


Question:
Should the following code be accepted? if so, we probably also want to accept the following: cc
So,how would the following be handled? That is (passing an identifier as a const argument).
should be equal to imo. rn literals which are in both the type and the value namespace are always used as type params though (see ). So this would fail to compile even if we get to work.

<ins> error: type parameters with a default must be trailing --> $DIR/wrong-order.rs:3:10 | LL | struct A<T = u32, const N: usize> { |          ^ | = note: using type defaults and const parameters in the same parameter list is currently not permitted warning: the feature `const_generics` is incomplete and may not be safe to use and/or cause compiler crashes --> $DIR/wrong-order.rs:1:12 | LL | #![feature(const_generics)] |            ^^^^^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default = note: see issue #44580 <https://github.com/rust-lang/rust/issues/44580> for more information error: aborting due to previous error; 1 warning emitted </ins>


Question:
I tried this code: I expected the code to fail to compile with a cycle error. Instead, it compiled and ran,printing the value of . I was able to verify that this bug happens for the 1.42.0 stable, 1.43-beta.5, and 1.44.0-nightly(2020-04-11 ) versions. Trying this code in it errors up to 1.36.0,and doesn't error anymore from 1.37.0 onwards.
cc
narrowed to the following: Auto merge of - petrochenkov:builtout, r=eddyb Auto merge of - luca-barbieri:optimize-refcell-borrow, r=RalfJung Auto merge of - Centril:rollup-, r=Centril Auto merge of - petrochenkov:rpass, r=Centril Possibly ?
Weaponized soundness hole (using as a foundation): ==
cc
oopsie yeah... is probably where this started. But that is crucial to fix The problem is that "reading from a ZST" isn't actually doing anything. Here's the MIR for : So there actually is a that loads from this static (I didn't expect that). But in Miri, a ZST load just checks that the address is in-bounds; no actual access to the underlying memory happens so there is no cycle error.
Assigning as and removing .

// We can still be zero-sized in this branch, in which case we have to // return `None`. <del> if size.bytes() == 0 { None } else { Some(ptr) } </del> <ins> if size.bytes() == 0 { // We may be reading from a static. // In order to ensure that `static FOO: Type = FOO;` causes a cycle error // instead of magically pulling *any* ZST value from the ether, we need to // actually access the referenced allocation. The caller is likely // to short-circuit on `None`, so we trigger the access here to // make sure it happens. self.get_raw(ptr.alloc_id)?; None } else { Some(ptr) } </ins> } }) }


Question:
I tried this code: I expected the code to fail to compile with a cycle error. Instead, it compiled and ran,printing the value of . I was able to verify that this bug happens for the 1.42.0 stable, 1.43-beta.5, and 1.44.0-nightly(2020-04-11 ) versions. Trying this code in it errors up to 1.36.0,and doesn't error anymore from 1.37.0 onwards.
cc
narrowed to the following: Auto merge of - petrochenkov:builtout, r=eddyb Auto merge of - luca-barbieri:optimize-refcell-borrow, r=RalfJung Auto merge of - Centril:rollup-, r=Centril Auto merge of - petrochenkov:rpass, r=Centril Possibly ?
Weaponized soundness hole (using as a foundation): ==
cc
oopsie yeah... is probably where this started. But that is crucial to fix The problem is that "reading from a ZST" isn't actually doing anything. Here's the MIR for : So there actually is a that loads from this static (I didn't expect that). But in Miri, a ZST load just checks that the address is in-bounds; no actual access to the underlying memory happens so there is no cycle error.
Assigning as and removing .

} }; <ins> let alloc = self.memory.get_raw(ptr.alloc_id)?; </ins> match mplace.layout.abi { Abi::Scalar(..) => { <del> let scalar = self.memory.get_raw(ptr.alloc_id)?.read_scalar( self, ptr, mplace.layout.size, )?; </del> <ins> let scalar = alloc.read_scalar(self, ptr, mplace.layout.size)?; </ins> Ok(Some(ImmTy { imm: scalar.into(), layout: mplace.layout })) } Abi::ScalarPair(ref a, ref b) => {


Question:
I tried this code: I expected the code to fail to compile with a cycle error. Instead, it compiled and ran,printing the value of . I was able to verify that this bug happens for the 1.42.0 stable, 1.43-beta.5, and 1.44.0-nightly(2020-04-11 ) versions. Trying this code in it errors up to 1.36.0,and doesn't error anymore from 1.37.0 onwards.
cc
narrowed to the following: Auto merge of - petrochenkov:builtout, r=eddyb Auto merge of - luca-barbieri:optimize-refcell-borrow, r=RalfJung Auto merge of - Centril:rollup-, r=Centril Auto merge of - petrochenkov:rpass, r=Centril Possibly ?
Weaponized soundness hole (using as a foundation): ==
cc
oopsie yeah... is probably where this started. But that is crucial to fix The problem is that "reading from a ZST" isn't actually doing anything. Here's the MIR for : So there actually is a that loads from this static (I didn't expect that). But in Miri, a ZST load just checks that the address is in-bounds; no actual access to the underlying memory happens so there is no cycle error.
Assigning as and removing .

let b_offset = a_size.align_to(b.align(self).abi); assert!(b_offset.bytes() > 0); // we later use the offset to tell apart the fields let b_ptr = ptr.offset(b_offset, self)?; <del> let a_val = self.memory.get_raw(ptr.alloc_id)?.read_scalar(self, a_ptr, a_size)?; let b_val = self.memory.get_raw(ptr.alloc_id)?.read_scalar(self, b_ptr, b_size)?; </del> <ins> let a_val = alloc.read_scalar(self, a_ptr, a_size)?; let b_val = alloc.read_scalar(self, b_ptr, b_size)?; </ins> Ok(Some(ImmTy { imm: Immediate::ScalarPair(a_val, b_val), layout: mplace.layout })) } _ => Ok(None),


Question:
I tried this code: I expected the code to fail to compile with a cycle error. Instead, it compiled and ran,printing the value of . I was able to verify that this bug happens for the 1.42.0 stable, 1.43-beta.5, and 1.44.0-nightly(2020-04-11 ) versions. Trying this code in it errors up to 1.36.0,and doesn't error anymore from 1.37.0 onwards.
cc
narrowed to the following: Auto merge of - petrochenkov:builtout, r=eddyb Auto merge of - luca-barbieri:optimize-refcell-borrow, r=RalfJung Auto merge of - Centril:rollup-, r=Centril Auto merge of - petrochenkov:rpass, r=Centril Possibly ?
Weaponized soundness hole (using as a foundation): ==
cc
oopsie yeah... is probably where this started. But that is crucial to fix The problem is that "reading from a ZST" isn't actually doing anything. Here's the MIR for : So there actually is a that loads from this static (I didn't expect that). But in Miri, a ZST load just checks that the address is in-bounds; no actual access to the underlying memory happens so there is no cycle error.
Assigning as and removing .

<del> // build-pass </del> <ins> // This test ensures that we do not allow ZST statics to initialize themselves without ever // actually creating a value of that type. This is important, as the ZST may have private fields // that users can reasonably expect to only get initialized by their own code. Thus unsafe code // can depend on this fact and will thus do unsound things when it is violated. // See https://github.com/rust-lang/rust/issues/71078 for more details. </ins> <del> static FOO: () = FOO; </del> <ins> static FOO: () = FOO; //~ cycle detected when const-evaluating `FOO` </ins> fn main() { FOO


Question:
I tried this code: I expected the code to fail to compile with a cycle error. Instead, it compiled and ran,printing the value of . I was able to verify that this bug happens for the 1.42.0 stable, 1.43-beta.5, and 1.44.0-nightly(2020-04-11 ) versions. Trying this code in it errors up to 1.36.0,and doesn't error anymore from 1.37.0 onwards.
cc
narrowed to the following: Auto merge of - petrochenkov:builtout, r=eddyb Auto merge of - luca-barbieri:optimize-refcell-borrow, r=RalfJung Auto merge of - Centril:rollup-, r=Centril Auto merge of - petrochenkov:rpass, r=Centril Possibly ?
Weaponized soundness hole (using as a foundation): ==
cc
oopsie yeah... is probably where this started. But that is crucial to fix The problem is that "reading from a ZST" isn't actually doing anything. Here's the MIR for : So there actually is a that loads from this static (I didn't expect that). But in Miri, a ZST load just checks that the address is in-bounds; no actual access to the underlying memory happens so there is no cycle error.
Assigning as and removing .

<ins> error[E0391]: cycle detected when const-evaluating `FOO` --> $DIR/recursive-zst-static.rs:7:18 | LL | static FOO: () = FOO; |                  ^^^ | note: ...which requires const-evaluating `FOO`... --> $DIR/recursive-zst-static.rs:7:1 | LL | static FOO: () = FOO; | ^^^^^^^^^^^^^^^^^^^^^ = note: ...which again requires const-evaluating `FOO`, completing the cycle note: cycle used when const-evaluating + checking `FOO` --> $DIR/recursive-zst-static.rs:7:1 | LL | static FOO: () = FOO; | ^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0391`. </ins>


Question:
The JSON for is broken because the for attributes serializes to nothing. An empty library produces the following: The important bit which is clearly not valid JSON. It looks like the  serialization was removed in . I'm not sure what a solution is here. I'm guessing AST serialization is used elsewhere, where this field isn't needed. I'm not too familiar with , so I'm not sure if it has something equivalent to . cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Looks like the encoding/decoding change from needs to be reverted. Reverting should be ok because and don't do anything anyway (at least when inlined) during metadata encoding and decoding. The change is trivial, so marking this as E-easy, but if it's not done until the weekend I'll submit the PR myself.
claim

} impl rustc_serialize::Encodable for AttrId { <del> fn encode<S: Encoder>(&self, _: &mut S) -> Result<(), S::Error> { Ok(()) </del> <ins> fn encode<S: Encoder>(&self, s: &mut S) -> Result<(), S::Error> { s.emit_unit() </ins> } } impl rustc_serialize::Decodable for AttrId { <del> fn decode<D: Decoder>(_: &mut D) -> Result<AttrId, D::Error> { Ok(crate::attr::mk_attr_id()) </del> <ins> fn decode<D: Decoder>(d: &mut D) -> Result<AttrId, D::Error> { d.read_nil().map(|_| crate::attr::mk_attr_id()) </ins> } }


Question:
The JSON for is broken because the for attributes serializes to nothing. An empty library produces the following: The important bit which is clearly not valid JSON. It looks like the  serialization was removed in . I'm not sure what a solution is here. I'm guessing AST serialization is used elsewhere, where this field isn't needed. I'm not too familiar with , so I'm not sure if it has something equivalent to . cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Looks like the encoding/decoding change from needs to be reverted. Reverting should be ok because and don't do anything anyway (at least when inlined) during metadata encoding and decoding. The change is trivial, so marking this as E-easy, but if it's not done until the weekend I'll submit the PR myself.
claim

<ins> // Check that AST json printing works. #![crate_type = "lib"] // check-pass // compile-flags: -Zast-json-noexpand // normalize-stdout-test ":d+" -> ":0" // Only include a single item to reduce how often the test output needs // updating. extern crate core; </ins>


Question:
The JSON for is broken because the for attributes serializes to nothing. An empty library produces the following: The important bit which is clearly not valid JSON. It looks like the  serialization was removed in . I'm not sure what a solution is here. I'm guessing AST serialization is used elsewhere, where this field isn't needed. I'm not too familiar with , so I'm not sure if it has something equivalent to . cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Looks like the encoding/decoding change from needs to be reverted. Reverting should be ok because and don't do anything anyway (at least when inlined) during metadata encoding and decoding. The change is trivial, so marking this as E-easy, but if it's not done until the weekend I'll submit the PR myself.
claim


Question:
The JSON for is broken because the for attributes serializes to nothing. An empty library produces the following: The important bit which is clearly not valid JSON. It looks like the  serialization was removed in . I'm not sure what a solution is here. I'm guessing AST serialization is used elsewhere, where this field isn't needed. I'm not too familiar with , so I'm not sure if it has something equivalent to . cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Looks like the encoding/decoding change from needs to be reverted. Reverting should be ok because and don't do anything anyway (at least when inlined) during metadata encoding and decoding. The change is trivial, so marking this as E-easy, but if it's not done until the weekend I'll submit the PR myself.
claim

// Check that AST json printing works. <ins> #![crate_type = "lib"] </ins> // check-pass <del> // compile-flags: -Zast-json-noexpand </del> <ins> // compile-flags: -Zast-json </ins> // normalize-stdout-test ":d+" -> ":0" // Only include a single item to reduce how often the test output needs


Question:
The JSON for is broken because the for attributes serializes to nothing. An empty library produces the following: The important bit which is clearly not valid JSON. It looks like the  serialization was removed in . I'm not sure what a solution is here. I'm guessing AST serialization is used elsewhere, where this field isn't needed. I'm not too familiar with , so I'm not sure if it has something equivalent to . cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Looks like the encoding/decoding change from needs to be reverted. Reverting should be ok because and don't do anything anyway (at least when inlined) during metadata encoding and decoding. The change is trivial, so marking this as E-easy, but if it's not done until the weekend I'll submit the PR myself.
claim


Question:
When calling in a fn that expects we currently emit: We should check whether and suggest the removal of the call. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
feel free to reach out either on this ticket or on a PR, but be warned that this has the potential to be quite involved. It is a great introduction to how some parts of fit together though.
I've been looking into this for a while now, and my idea was to: Check if there a .into() call, check if the type of self was T and finally check if the argument of the function was Into<T. However I cannot figure how to get the type of Self. As far as my understanding goes, rustc hasn't yet inferred the type.
You can query the in-progress type table with the for the expression. You're gonna have an with a . From the first argument in that variant you can take the first element and get the expression for in . Then you can use the for that expression to do I do not know if we will have populated 's type by then, but if we have, then that will give you the type of . Then, if you're in an you can use to see if the inferred type for can be coerced to in the original example. I know this is a bit vague, but for this is inherently exploratory work :)
Hi, are you still working on this issue
No, feel free to claim it if you want
release-assignment

if let Node::Expr(expr) = tcx.hir_node(arg_hir_id) && let Some(typeck_results) = &self.typeck_results { <ins> if let hir::Expr { kind: hir::ExprKind::MethodCall(_, rcvr, _, _), .. } = expr && let Some(ty) = typeck_results.node_type_opt(rcvr.hir_id) && let Some(failed_pred) = failed_pred.to_opt_poly_trait_pred() && let pred = failed_pred.map_bound(|pred| pred.with_self_ty(tcx, ty)) && self.predicate_must_hold_modulo_regions(&Obligation::misc( tcx, expr.span, body_id, param_env, pred, )) { err.span_suggestion_verbose( expr.span.with_lo(rcvr.span.hi()), format!( "consider removing this method call, as the receiver has type `{ty}` and  `{pred}` trivially holds", ), "", Applicability::MaybeIncorrect, ); } </ins> if let hir::Expr { kind: hir::ExprKind::Block(block, _), .. } = expr { let inner_expr = expr.peel_blocks(); let ty = typeck_results


Question:
When calling in a fn that expects we currently emit: We should check whether and suggest the removal of the call. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
feel free to reach out either on this ticket or on a PR, but be warned that this has the potential to be quite involved. It is a great introduction to how some parts of fit together though.
I've been looking into this for a while now, and my idea was to: Check if there a .into() call, check if the type of self was T and finally check if the argument of the function was Into<T. However I cannot figure how to get the type of Self. As far as my understanding goes, rustc hasn't yet inferred the type.
You can query the in-progress type table with the for the expression. You're gonna have an with a . From the first argument in that variant you can take the first element and get the expression for in . Then you can use the for that expression to do I do not know if we will have populated 's type by then, but if we have, then that will give you the type of . Then, if you're in an you can use to see if the inferred type for can be coerced to in the original example. I know this is a bit vague, but for this is inherently exploratory work :)
Hi, are you still working on this issue
No, feel free to claim it if you want
release-assignment

} } <del> if let Node::Expr(expr) = tcx.hir_node(call_hir_id) { </del> <ins> if let Node::Expr(expr) = call_node { </ins> if let hir::ExprKind::Call(hir::Expr { span, .. }, _) | hir::ExprKind::MethodCall( hir::PathSegment { ident: Ident { span, .. }, .. },


Question:
When calling in a fn that expects we currently emit: We should check whether and suggest the removal of the call. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
feel free to reach out either on this ticket or on a PR, but be warned that this has the potential to be quite involved. It is a great introduction to how some parts of fit together though.
I've been looking into this for a while now, and my idea was to: Check if there a .into() call, check if the type of self was T and finally check if the argument of the function was Into<T. However I cannot figure how to get the type of Self. As far as my understanding goes, rustc hasn't yet inferred the type.
You can query the in-progress type table with the for the expression. You're gonna have an with a . From the first argument in that variant you can take the first element and get the expression for in . Then you can use the for that expression to do I do not know if we will have populated 's type by then, but if we have, then that will give you the type of . Then, if you're in an you can use to see if the inferred type for can be coerced to in the original example. I know this is a bit vague, but for this is inherently exploratory work :)
Hi, are you still working on this issue
No, feel free to claim it if you want
release-assignment

| note: required by a bound in `File::open` --> $SRC_DIR/std/src/fs.rs:LL:COL <ins> help: consider removing this method call, as the receiver has type `&Path` and `&Path: AsRef<Path>` trivially holds | LL -             let mut f = File::open(path.to_str())?; LL +             let mut f = File::open(path)?; | </ins> error: aborting due to 1 previous error


Question:
When calling in a fn that expects we currently emit: We should check whether and suggest the removal of the call. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
feel free to reach out either on this ticket or on a PR, but be warned that this has the potential to be quite involved. It is a great introduction to how some parts of fit together though.
I've been looking into this for a while now, and my idea was to: Check if there a .into() call, check if the type of self was T and finally check if the argument of the function was Into<T. However I cannot figure how to get the type of Self. As far as my understanding goes, rustc hasn't yet inferred the type.
You can query the in-progress type table with the for the expression. You're gonna have an with a . From the first argument in that variant you can take the first element and get the expression for in . Then you can use the for that expression to do I do not know if we will have populated 's type by then, but if we have, then that will give you the type of . Then, if you're in an you can use to see if the inferred type for can be coerced to in the original example. I know this is a bit vague, but for this is inherently exploratory work :)
Hi, are you still working on this issue
No, feel free to claim it if you want
release-assignment

| LL | fn check_bound<T:Copy>(_: T) {} |                  ^^^^ required by this bound in `check_bound` <ins> help: consider removing this method call, as the receiver has type `&'static str` and `&'static str: Copy` trivially holds | LL -     check_bound("nocopy".to_string()); LL +     check_bound("nocopy"); | </ins> error: aborting due to 1 previous error