Question:
ing a value of an empty enum is valid, however ing a reference to a value of an empty enum produces . I tried this code (): I expected to see this happen: The code should compile with no issue, and the function should never actually execute because has no variants and thus cannot be instantiated. Instead, this happened: The bug exists on 1.47.0 and 1.49.0-nightly (2020-10-18 ) running on the playground. I first found this bug on 1.46.0. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is currently working as intended, but maybe we should say so in the diagnostic
Why is this the intended behavior? I find it notably surprising because I can usually replace with , and the commiler takes care to insert (de)references magically. This would be an exception.
I don't recall, but you might be able to find some of the old discussions
I was just reading some discussion on the exhaustive_patterns issue: IIUC, the reason that (where is an uninhabited type) is considered inhabited is because unsafe code can construct an -reference to an uninhabited type (e.g. with or ). I don't know enough to be sure though.
Though unsafe code can also construct an uninhabited without using references; e.g.: () Output: Errors: So maybe what I said in is not correct?
I think the difference is that creating a value of type like you did is Undefined Behavior, but creating a isn't. Try running your code using the MIRI tool (available on the playground under Tools), it usually tells you when you do UB
Indeed, transmuting to didn't make Miri report UB (though attempting to print the value did) but transmuting to did.
Nice. Indeed dereferencing a reference to unintialized memory is also UB. Instructions to fix this: add a test case named after this issue in the folder find where the error message is emitted (somewhere in ) check when the type is and the subtype is uninhabited (which you can test using ) in the above case, add a note to the error message, saying something like "references are always considered inhabited". I'm not sure if we want to mention why. maybe add some related positive and negative tests to make sure we only emit the new note when relevant maybe test and handle cases like as well? modify labels: +E-easy +E-mentor
On the contrary, constructing a which does not reference a valid is instant UB . A value of type is just as invalid as a value of type .
Oh shoot, I understood the opposite. Then I've misunderstood what says in their blog post: Maybe that post is old and things have changed since? Or maybe unintialized memory does not count as an invalid value?
The rules for validity of reference are not finally decided yet, but still being discussed at rust-lang/unsafe-code-guidelines. To not preempt the conclusion of this discussion, the docs declare as much UB as is possible -- we can always relax UB later, but introducing more UB is a breaking change.
Ok, I understand that if we want to have the option to relax this later, then we can't have the compiler rely on it. So we must treat as inhabited. Otherwise we would accept the following but it would become unsound if we relax the UB: So should stay as it currently is and my are still the way to go.
claim
Thanks for taking this on ! Feel free to ask me questions here or on .
Thanks for the warm welcome :) I do have questions, but I already made a preliminary commit to check if I'm going in the right direction: (edited because I missed a file) Is that ok, or is it better if I ask questions before committing, or just make a PR and adapt it?
That commit looks like what we want yes :) Go ahead and make a PR, it's easier to comment on specific bits of the code
For those who (like me) find this after googling "references are always considered inhabited" (the compiler's help message), the current discussion on this topic is happening in
I've a comment here: Which suggests that we consider making it UB to construct such a reference, so that this macro code doesn't confusingly start breaking for empty enums:

<ins> enum A {} //~^ NOTE `A` defined here fn f(a: &A) { match a {} //~^ ERROR non-exhaustive patterns: type `&A` is non-empty //~| NOTE the matched value is of type `&A` //~| NOTE references are always considered inhabited } fn main() {} </ins>


Question:
ing a value of an empty enum is valid, however ing a reference to a value of an empty enum produces . I tried this code (): I expected to see this happen: The code should compile with no issue, and the function should never actually execute because has no variants and thus cannot be instantiated. Instead, this happened: The bug exists on 1.47.0 and 1.49.0-nightly (2020-10-18 ) running on the playground. I first found this bug on 1.46.0. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is currently working as intended, but maybe we should say so in the diagnostic
Why is this the intended behavior? I find it notably surprising because I can usually replace with , and the commiler takes care to insert (de)references magically. This would be an exception.
I don't recall, but you might be able to find some of the old discussions
I was just reading some discussion on the exhaustive_patterns issue: IIUC, the reason that (where is an uninhabited type) is considered inhabited is because unsafe code can construct an -reference to an uninhabited type (e.g. with or ). I don't know enough to be sure though.
Though unsafe code can also construct an uninhabited without using references; e.g.: () Output: Errors: So maybe what I said in is not correct?
I think the difference is that creating a value of type like you did is Undefined Behavior, but creating a isn't. Try running your code using the MIRI tool (available on the playground under Tools), it usually tells you when you do UB
Indeed, transmuting to didn't make Miri report UB (though attempting to print the value did) but transmuting to did.
Nice. Indeed dereferencing a reference to unintialized memory is also UB. Instructions to fix this: add a test case named after this issue in the folder find where the error message is emitted (somewhere in ) check when the type is and the subtype is uninhabited (which you can test using ) in the above case, add a note to the error message, saying something like "references are always considered inhabited". I'm not sure if we want to mention why. maybe add some related positive and negative tests to make sure we only emit the new note when relevant maybe test and handle cases like as well? modify labels: +E-easy +E-mentor
On the contrary, constructing a which does not reference a valid is instant UB . A value of type is just as invalid as a value of type .
Oh shoot, I understood the opposite. Then I've misunderstood what says in their blog post: Maybe that post is old and things have changed since? Or maybe unintialized memory does not count as an invalid value?
The rules for validity of reference are not finally decided yet, but still being discussed at rust-lang/unsafe-code-guidelines. To not preempt the conclusion of this discussion, the docs declare as much UB as is possible -- we can always relax UB later, but introducing more UB is a breaking change.
Ok, I understand that if we want to have the option to relax this later, then we can't have the compiler rely on it. So we must treat as inhabited. Otherwise we would accept the following but it would become unsound if we relax the UB: So should stay as it currently is and my are still the way to go.
claim
Thanks for taking this on ! Feel free to ask me questions here or on .
Thanks for the warm welcome :) I do have questions, but I already made a preliminary commit to check if I'm going in the right direction: (edited because I missed a file) Is that ok, or is it better if I ask questions before committing, or just make a PR and adapt it?
That commit looks like what we want yes :) Go ahead and make a PR, it's easier to comment on specific bits of the code
For those who (like me) find this after googling "references are always considered inhabited" (the compiler's help message), the current discussion on this topic is happening in
I've a comment here: Which suggests that we consider making it UB to construct such a reference, so that this macro code doesn't confusingly start breaking for empty enums:

<ins> error[E0004]: non-exhaustive patterns: type `&A` is non-empty --> $DIR/issue-78123-non-exhaustive-reference.rs:5:11 | LL | enum A {} | --------- `A` defined here ... LL |     match a {} |           ^ | = help: ensure that all possible cases are being handled, possibly by adding wildcards or more match arms = note: the matched value is of type `&A` = note: references are always considered inhabited error: aborting due to previous error For more information about this error, try `rustc --explain E0004`. </ins>


Question:
ing a value of an empty enum is valid, however ing a reference to a value of an empty enum produces . I tried this code (): I expected to see this happen: The code should compile with no issue, and the function should never actually execute because has no variants and thus cannot be instantiated. Instead, this happened: The bug exists on 1.47.0 and 1.49.0-nightly (2020-10-18 ) running on the playground. I first found this bug on 1.46.0. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is currently working as intended, but maybe we should say so in the diagnostic
Why is this the intended behavior? I find it notably surprising because I can usually replace with , and the commiler takes care to insert (de)references magically. This would be an exception.
I don't recall, but you might be able to find some of the old discussions
I was just reading some discussion on the exhaustive_patterns issue: IIUC, the reason that (where is an uninhabited type) is considered inhabited is because unsafe code can construct an -reference to an uninhabited type (e.g. with or ). I don't know enough to be sure though.
Though unsafe code can also construct an uninhabited without using references; e.g.: () Output: Errors: So maybe what I said in is not correct?
I think the difference is that creating a value of type like you did is Undefined Behavior, but creating a isn't. Try running your code using the MIRI tool (available on the playground under Tools), it usually tells you when you do UB
Indeed, transmuting to didn't make Miri report UB (though attempting to print the value did) but transmuting to did.
Nice. Indeed dereferencing a reference to unintialized memory is also UB. Instructions to fix this: add a test case named after this issue in the folder find where the error message is emitted (somewhere in ) check when the type is and the subtype is uninhabited (which you can test using ) in the above case, add a note to the error message, saying something like "references are always considered inhabited". I'm not sure if we want to mention why. maybe add some related positive and negative tests to make sure we only emit the new note when relevant maybe test and handle cases like as well? modify labels: +E-easy +E-mentor
On the contrary, constructing a which does not reference a valid is instant UB . A value of type is just as invalid as a value of type .
Oh shoot, I understood the opposite. Then I've misunderstood what says in their blog post: Maybe that post is old and things have changed since? Or maybe unintialized memory does not count as an invalid value?
The rules for validity of reference are not finally decided yet, but still being discussed at rust-lang/unsafe-code-guidelines. To not preempt the conclusion of this discussion, the docs declare as much UB as is possible -- we can always relax UB later, but introducing more UB is a breaking change.
Ok, I understand that if we want to have the option to relax this later, then we can't have the compiler rely on it. So we must treat as inhabited. Otherwise we would accept the following but it would become unsound if we relax the UB: So should stay as it currently is and my are still the way to go.
claim
Thanks for taking this on ! Feel free to ask me questions here or on .
Thanks for the warm welcome :) I do have questions, but I already made a preliminary commit to check if I'm going in the right direction: (edited because I missed a file) Is that ok, or is it better if I ask questions before committing, or just make a PR and adapt it?
That commit looks like what we want yes :) Go ahead and make a PR, it's easier to comment on specific bits of the code
For those who (like me) find this after googling "references are always considered inhabited" (the compiler's help message), the current discussion on this topic is happening in
I've a comment here: Which suggests that we consider making it UB to construct such a reference, so that this macro code doesn't confusingly start breaking for empty enums:

| = help: ensure that all possible cases are being handled, possibly by adding wildcards or more match arms = note: the matched value is of type `&Void` <ins> = note: references are always considered inhabited </ins> error[E0004]: non-exhaustive patterns: type `(Void,)` is non-empty --> $DIR/uninhabited-matches-feature-gated.rs:18:19


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. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailsThis is the most minimal example I could find, it needs tokio with the features "macro" and "sync". While this error occured on Nightly I could also reproduce this on stable (as far back as on 1.39, didn't test beyond that because my build started failing because of other reasons) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is very reminiscent of (await in if guard in match statement)
MCVE: Yeah, very .
Thank you for reducing this further. Totally forgot that I could just declare my own async function this way! But I do understand correctly that the linked example is just related, not the same? (Since it's still occuring in latest nightly and the linked issue seemes to be already fixed)
Yeah, just related - my immediate guess is this is some case that was missed in the fix for that issue. The difference appears to be that is used in a index expression after the await instead of some other way.
Another example: Any usage of in the if guard after the that does not cause to be autorefed (like just from the MCVE would) appears to trigger the ICE.
claim
Assigning as and removing .

// The type table might not have information for this expression // if it is in a malformed scope. (#66387) if let Some(ty) = self.fcx.typeck_results.borrow().expr_ty_opt(expr) { <ins> if guard_borrowing_from_pattern { // Match guards create references to all the bindings in the pattern that are used // in the guard, e.g. `y if is_even(y) => ...` becomes `is_even(*r_y)` where `r_y` // is a reference to `y`, so we must record a reference to the type of the binding. let tcx = self.fcx.tcx; let ref_ty = tcx.mk_ref( // Use `ReErased` as `resolve_interior` is going to replace all the regions anyway. tcx.mk_region(ty::RegionKind::ReErased), ty::TypeAndMut { ty, mutbl: hir::Mutability::Not }, ); self.record(ref_ty, scope, Some(expr), expr.span, guard_borrowing_from_pattern); } </ins> self.record(ty, scope, Some(expr), expr.span, guard_borrowing_from_pattern); } else { self.fcx.tcx.sess.delay_span_bug(expr.span, "no type for node");


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. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailsThis is the most minimal example I could find, it needs tokio with the features "macro" and "sync". While this error occured on Nightly I could also reproduce this on stable (as far back as on 1.39, didn't test beyond that because my build started failing because of other reasons) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is very reminiscent of (await in if guard in match statement)
MCVE: Yeah, very .
Thank you for reducing this further. Totally forgot that I could just declare my own async function this way! But I do understand correctly that the linked example is just related, not the same? (Since it's still occuring in latest nightly and the linked issue seemes to be already fixed)
Yeah, just related - my immediate guess is this is some case that was missed in the fix for that issue. The difference appears to be that is used in a index expression after the await instead of some other way.
Another example: Any usage of in the if guard after the that does not cause to be autorefed (like just from the MCVE would) appears to trigger the ICE.
claim
Assigning as and removing .

<del> // check-pass </del> <ins> // build-pass </ins> // edition:2018 // This test is derived from


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. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailsThis is the most minimal example I could find, it needs tokio with the features "macro" and "sync". While this error occured on Nightly I could also reproduce this on stable (as far back as on 1.39, didn't test beyond that because my build started failing because of other reasons) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is very reminiscent of (await in if guard in match statement)
MCVE: Yeah, very .
Thank you for reducing this further. Totally forgot that I could just declare my own async function this way! But I do understand correctly that the linked example is just related, not the same? (Since it's still occuring in latest nightly and the linked issue seemes to be already fixed)
Yeah, just related - my immediate guess is this is some case that was missed in the fix for that issue. The difference appears to be that is used in a index expression after the await instead of some other way.
Another example: Any usage of in the if guard after the that does not cause to be autorefed (like just from the MCVE would) appears to trigger the ICE.
claim
Assigning as and removing .

// of the underlying generator. async fn f() -> u8 { 1 } <ins> async fn foo() -> [bool; 10] { [false; 10] } </ins> pub async fn g(x: u8) { match x {


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. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailsThis is the most minimal example I could find, it needs tokio with the features "macro" and "sync". While this error occured on Nightly I could also reproduce this on stable (as far back as on 1.39, didn't test beyond that because my build started failing because of other reasons) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is very reminiscent of (await in if guard in match statement)
MCVE: Yeah, very .
Thank you for reducing this further. Totally forgot that I could just declare my own async function this way! But I do understand correctly that the linked example is just related, not the same? (Since it's still occuring in latest nightly and the linked issue seemes to be already fixed)
Yeah, just related - my immediate guess is this is some case that was missed in the fix for that issue. The difference appears to be that is used in a index expression after the await instead of some other way.
Another example: Any usage of in the if guard after the that does not cause to be autorefed (like just from the MCVE would) appears to trigger the ICE.
claim
Assigning as and removing .

} } <ins> // #78366: check the reference to the binding is recorded even if the binding is not autorefed async fn h(x: usize) { match x { y if foo().await[y] => (), _ => (), } } async fn i(x: u8) { match x { y if f().await == y + 1 => (), _ => (), } } </ins> fn main() { let _ = g(10); <ins> let _ = h(9); let _ = i(8); </ins> }


Question:
For example: There are two issues here: actually helpful? All the code runs in the same thread with the same name, so it doesn't add any more info 's no space between the output and the header, so it's hard to read the logs. cc
I believe the crate, which is using, provides methods for and when constructing its layer, so it should be possible to turn this off. I believe the missing space is probably a bug in that crate, so I'd . It's possible this was the intended formatting, you'd probably need to ask to be sure.
Thanks, I'll do that :)

.with_indent_lines(true) .with_ansi(true) .with_targets(true) <del> .with_thread_ids(true) .with_thread_names(true) </del> .with_wraparound(10) .with_verbose_exit(true) .with_verbose_entry(true) .with_indent_amount(2); <ins> #[cfg(parallel_compiler)] let layer = layer.with_thread_ids(true).with_thread_names(true); </ins> use tracing_subscriber::layer::SubscriberExt; let subscriber = tracing_subscriber::Registry::default().with(filter).with(layer);


Question:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see this happen: no warning. Instead, this happened: ~The attribute is actually applied correctly, otherwise we would get undefined symbol error.~ Also, the extern variable is clearly declared as static, so the warning does not really make sense. Edit: it seems that the code also works without the attribute. So is the attribute actually not needed? Anyway, the warning about is confusing. This problem occurred in our embedded project , where the static global variables are used to provide references to linker symbols. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Rust 1.47 stable. Haven't tried newer nightly. : modify labels: +regression-from-stable-to-nightly -regression-untriaged <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
No, this is working correctly. does nothing on extern items, which already do not get mangled, even without the attribute.
OK, sorry for not understanding the behavior of on extern items.
So maybe this should not be marked as regression, this is just a confusing but indeed correct warning message. Is there a way to remove the labels?
claim

Target::Field | Target::Arm | Target::MacroDef => { self.inline_attr_str_error_with_macro_def(hir_id, attr, "no_mangle"); } <ins> // FIXME: #[no_mangle] was previously allowed on non-functions/statics, this should be an error // The error should specify that the item that is wrong is specifically a *foreign* fn/static // otherwise the error seems odd Target::ForeignFn | Target::ForeignStatic => { let foreign_item_kind = match target { Target::ForeignFn => "function", Target::ForeignStatic => "static", _ => unreachable!(), }; self.tcx.struct_span_lint_hir(UNUSED_ATTRIBUTES, hir_id, attr.span, |lint| { lint.build(&format!( "`#[no_mangle]` has no effect on a foreign {}", foreign_item_kind )) .warn( "this was previously accepted by the compiler but is  being phased out; it will become a hard error in  a future release!", ) .span_label(*span, format!("foreign {}", foreign_item_kind)) .note("symbol names in extern blocks are not mangled") .span_suggestion( attr.span, "remove this attribute", String::new(), Applicability::MachineApplicable, ) .emit(); }); } </ins> _ => { // FIXME: #[no_mangle] was previously allowed on non-functions/statics and some // crates used this, so only emit a warning.


Question:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see this happen: no warning. Instead, this happened: ~The attribute is actually applied correctly, otherwise we would get undefined symbol error.~ Also, the extern variable is clearly declared as static, so the warning does not really make sense. Edit: it seems that the code also works without the attribute. So is the attribute actually not needed? Anyway, the warning about is confusing. This problem occurred in our embedded project , where the static global variables are used to provide references to linker symbols. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Rust 1.47 stable. Haven't tried newer nightly. : modify labels: +regression-from-stable-to-nightly -regression-untriaged <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
No, this is working correctly. does nothing on extern items, which already do not get mangled, even without the attribute.
OK, sorry for not understanding the behavior of on extern items.
So maybe this should not be marked as regression, this is just a confusing but indeed correct warning message. Is there a way to remove the labels?
claim

<ins> #![warn(unused_attributes)] // Tests that placing the #[no_mangle] attribute on a foreign fn or static emits // a specialized warning. // The previous warning only talks about a "function or static" but foreign fns/statics // are also not allowed to have #[no_mangle] // build-pass extern "C" { #[no_mangle] //~^ WARNING `#[no_mangle]` has no effect on a foreign static //~^^ WARNING this was previously accepted by the compiler pub static FOO: u8; #[no_mangle] //~^ WARNING `#[no_mangle]` has no effect on a foreign function //~^^ WARNING this was previously accepted by the compiler pub fn bar(); } fn no_new_warn() { // Should emit the generic "not a function or static" warning #[no_mangle] //~^ WARNING attribute should be applied to a free function, impl method or static //~^^ WARNING this was previously accepted by the compiler let x = 0_u8; } fn main() {} </ins>


Question:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see this happen: no warning. Instead, this happened: ~The attribute is actually applied correctly, otherwise we would get undefined symbol error.~ Also, the extern variable is clearly declared as static, so the warning does not really make sense. Edit: it seems that the code also works without the attribute. So is the attribute actually not needed? Anyway, the warning about is confusing. This problem occurred in our embedded project , where the static global variables are used to provide references to linker symbols. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Rust 1.47 stable. Haven't tried newer nightly. : modify labels: +regression-from-stable-to-nightly -regression-untriaged <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
No, this is working correctly. does nothing on extern items, which already do not get mangled, even without the attribute.
OK, sorry for not understanding the behavior of on extern items.
So maybe this should not be marked as regression, this is just a confusing but indeed correct warning message. Is there a way to remove the labels?
claim

<ins> warning: attribute should be applied to a free function, impl method or static --> $DIR/extern-no-mangle.rs:24:5 | LL |     #[no_mangle] |     ^^^^^^^^^^^^ ... LL |     let x = 0_u8; |     ------------- not a free function, impl method or static | note: the lint level is defined here --> $DIR/extern-no-mangle.rs:1:9 | LL | #![warn(unused_attributes)] |         ^^^^^^^^^^^^^^^^^ = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! warning: `#[no_mangle]` has no effect on a foreign static --> $DIR/extern-no-mangle.rs:11:5 | LL |     #[no_mangle] |     ^^^^^^^^^^^^ help: remove this attribute ... LL |     pub static FOO: u8; |     ------------------- foreign static | = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: symbol names in extern blocks are not mangled warning: `#[no_mangle]` has no effect on a foreign function --> $DIR/extern-no-mangle.rs:16:5 | LL |     #[no_mangle] |     ^^^^^^^^^^^^ help: remove this attribute ... LL |     pub fn bar(); |     ------------- foreign function | = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: symbol names in extern blocks are not mangled warning: 3 warnings emitted </ins>


Question:
Adding the follow method as part of a benchmark to which exercises results in the following assembly (extracted with objdump): The ghidra decompile for the same function (comments are mine): Note the useless loop. The number of loop iterations (or rather the pointer increments) is needed to calculate the new length of the output . LLVM already manages to hoist but then it fails to eliminate the now-useless loop. The issue does not occur if one uses instead, which always results in length == 0. I tried several variations of the loop (e.g. replacing with a simple ) but it generally results in the same or worse assembly. Note: The assembly looks somewhat different if I but the decrementing loop without side-effect is still there. I assume the differences are due to LTO or some other compiler settings. Tested on commit 2020-11-21 22:46 modify labels: +I-slow
It looks like this can be solved with more ~dakka~ passes. On godbolt it can be made loop-free by adding And branchless with Using as starting point requires the same passes to be to achieve these results, i.e. it does not provide a better baseline. I failed to reproduce this improvement locally but that might be due to argument escaping issues when attempting to put the space-separated list into
Surprisingly targeting a current CPU results in only one extra pass needed to achieve the loop-free result:
Inserting one loop deletion pass directly into also results in the branchless version without having to change target-cpu or adding additional other passes. So I assume that the other passes are only needed due to the way that works.
It looks like that this removed on nightly now. On nightly: On stable:
That's only true for types because I implemented a specialization for that purpose. The suboptimal assembly still exists for types not implementing Copy, e.g. newtypes. I'll update my initial post.
Something that was is that this case also fails for - i.e. with the specialization - is when the wrapper type is
Seems to work in the other direction weirdly is optimised away, whilst is not
Is there a case here that still doesn't optimize? It looks like all the existing godbolt links do.
Looks good, I'll update the existing codegen test.

// ignore-debug: the debug assertions get in the way // compile-flags: -O -Z merge-functions=disabled <ins> // min-llvm-version: 16 </ins> #![crate_type = "lib"] // Ensure that trivial casts of vec elements are O(1) pub struct Wrapper<T>(T); <ins> // previously repr(C) caused the optimization to fail </ins> #[repr(C)] pub struct Foo { a: u64,


Question:
Adding the follow method as part of a benchmark to which exercises results in the following assembly (extracted with objdump): The ghidra decompile for the same function (comments are mine): Note the useless loop. The number of loop iterations (or rather the pointer increments) is needed to calculate the new length of the output . LLVM already manages to hoist but then it fails to eliminate the now-useless loop. The issue does not occur if one uses instead, which always results in length == 0. I tried several variations of the loop (e.g. replacing with a simple ) but it generally results in the same or worse assembly. Note: The assembly looks somewhat different if I but the decrementing loop without side-effect is still there. I assume the differences are due to LTO or some other compiler settings. Tested on commit 2020-11-21 22:46 modify labels: +I-slow
It looks like this can be solved with more ~dakka~ passes. On godbolt it can be made loop-free by adding And branchless with Using as starting point requires the same passes to be to achieve these results, i.e. it does not provide a better baseline. I failed to reproduce this improvement locally but that might be due to argument escaping issues when attempting to put the space-separated list into
Surprisingly targeting a current CPU results in only one extra pass needed to achieve the loop-free result:
Inserting one loop deletion pass directly into also results in the branchless version without having to change target-cpu or adding additional other passes. So I assume that the other passes are only needed due to the way that works.
It looks like that this removed on nightly now. On nightly: On stable:
That's only true for types because I implemented a specialization for that purpose. The suboptimal assembly still exists for types not implementing Copy, e.g. newtypes. I'll update my initial post.
Something that was is that this case also fails for - i.e. with the specialization - is when the wrapper type is
Seems to work in the other direction weirdly is optimised away, whilst is not
Is there a case here that still doesn't optimize? It looks like all the existing godbolt links do.
Looks good, I'll update the existing codegen test.

d: u64, } <del> // Going from an aggregate struct to another type currently requires Copy to // enable the TrustedRandomAccess specialization. Without it optimizations do not yet // reliably recognize the loops as noop for repr(C) or non-Copy structs. </del> <ins> // implementing Copy exercises the TrustedRandomAccess specialization inside the in-place // specialization </ins> #[derive(Copy, Clone)] pub struct Bar { a: u64,


Question:
Adding the follow method as part of a benchmark to which exercises results in the following assembly (extracted with objdump): The ghidra decompile for the same function (comments are mine): Note the useless loop. The number of loop iterations (or rather the pointer increments) is needed to calculate the new length of the output . LLVM already manages to hoist but then it fails to eliminate the now-useless loop. The issue does not occur if one uses instead, which always results in length == 0. I tried several variations of the loop (e.g. replacing with a simple ) but it generally results in the same or worse assembly. Note: The assembly looks somewhat different if I but the decrementing loop without side-effect is still there. I assume the differences are due to LTO or some other compiler settings. Tested on commit 2020-11-21 22:46 modify labels: +I-slow
It looks like this can be solved with more ~dakka~ passes. On godbolt it can be made loop-free by adding And branchless with Using as starting point requires the same passes to be to achieve these results, i.e. it does not provide a better baseline. I failed to reproduce this improvement locally but that might be due to argument escaping issues when attempting to put the space-separated list into
Surprisingly targeting a current CPU results in only one extra pass needed to achieve the loop-free result:
Inserting one loop deletion pass directly into also results in the branchless version without having to change target-cpu or adding additional other passes. So I assume that the other passes are only needed due to the way that works.
It looks like that this removed on nightly now. On nightly: On stable:
That's only true for types because I implemented a specialization for that purpose. The suboptimal assembly still exists for types not implementing Copy, e.g. newtypes. I'll update my initial post.
Something that was is that this case also fails for - i.e. with the specialization - is when the wrapper type is
Seems to work in the other direction weirdly is optimised away, whilst is not
Is there a case here that still doesn't optimize? It looks like all the existing godbolt links do.
Looks good, I'll update the existing codegen test.

d: u64, } <ins> // this exercises the try-fold codepath pub struct Baz { a: u64, b: u64, c: u64, d: u64, } </ins> // CHECK-LABEL: @vec_iterator_cast_primitive #[no_mangle] pub fn vec_iterator_cast_primitive(vec: Vec<i8>) -> Vec<u8> {


Question:
Adding the follow method as part of a benchmark to which exercises results in the following assembly (extracted with objdump): The ghidra decompile for the same function (comments are mine): Note the useless loop. The number of loop iterations (or rather the pointer increments) is needed to calculate the new length of the output . LLVM already manages to hoist but then it fails to eliminate the now-useless loop. The issue does not occur if one uses instead, which always results in length == 0. I tried several variations of the loop (e.g. replacing with a simple ) but it generally results in the same or worse assembly. Note: The assembly looks somewhat different if I but the decrementing loop without side-effect is still there. I assume the differences are due to LTO or some other compiler settings. Tested on commit 2020-11-21 22:46 modify labels: +I-slow
It looks like this can be solved with more ~dakka~ passes. On godbolt it can be made loop-free by adding And branchless with Using as starting point requires the same passes to be to achieve these results, i.e. it does not provide a better baseline. I failed to reproduce this improvement locally but that might be due to argument escaping issues when attempting to put the space-separated list into
Surprisingly targeting a current CPU results in only one extra pass needed to achieve the loop-free result:
Inserting one loop deletion pass directly into also results in the branchless version without having to change target-cpu or adding additional other passes. So I assume that the other passes are only needed due to the way that works.
It looks like that this removed on nightly now. On nightly: On stable:
That's only true for types because I implemented a specialization for that purpose. The suboptimal assembly still exists for types not implementing Copy, e.g. newtypes. I'll update my initial post.
Something that was is that this case also fails for - i.e. with the specialization - is when the wrapper type is
Seems to work in the other direction weirdly is optimised away, whilst is not
Is there a case here that still doesn't optimize? It looks like all the existing godbolt links do.
Looks good, I'll update the existing codegen test.

// CHECK-LABEL: @vec_iterator_cast_aggregate #[no_mangle] pub fn vec_iterator_cast_aggregate(vec: Vec<[u64; 4]>) -> Vec<Foo> { <del> // FIXME These checks should be the same as other functions. // CHECK-NOT: @__rust_alloc // CHECK-NOT: @__rust_alloc </del> <ins> // CHECK-NOT: loop // CHECK-NOT: call </ins> vec.into_iter().map(|e| unsafe { std::mem::transmute(e) }).collect() } <del> // CHECK-LABEL: @vec_iterator_cast_deaggregate </del> <ins> // CHECK-LABEL: @vec_iterator_cast_deaggregate_tra </ins> #[no_mangle] <del> pub fn vec_iterator_cast_deaggregate(vec: Vec<Bar>) -> Vec<[u64; 4]> { // FIXME These checks should be the same as other functions. // CHECK-NOT: @__rust_alloc // CHECK-NOT: @__rust_alloc </del> <ins> pub fn vec_iterator_cast_deaggregate_tra(vec: Vec<Bar>) -> Vec<[u64; 4]> { // CHECK-NOT: loop // CHECK-NOT: call // Safety: For the purpose of this test we assume that Bar layout matches [u64; 4]. // This currently is not guaranteed for repr(Rust) types, but it happens to work here and // the UCG may add additional guarantees for homogenous types in the future that would make this // correct. vec.into_iter().map(|e| unsafe { std::mem::transmute(e) }).collect() } // CHECK-LABEL: @vec_iterator_cast_deaggregate_fold #[no_mangle] pub fn vec_iterator_cast_deaggregate_fold(vec: Vec<Baz>) -> Vec<[u64; 4]> { // CHECK-NOT: loop // CHECK-NOT: call </ins> // Safety: For the purpose of this test we assume that Bar layout matches [u64; 4]. // This currently is not guaranteed for repr(Rust) types, but it happens to work here and


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. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
It doesn't fixed in rustc 1.52.0-nightly ( 2021-02-14) link to playground : <details<summary<strongBacktrace</strong</summary<p</p</details
i dont think the fix was merged by then. it works in 1.52.0-nightly 2021-02-16 :)

ty::Adt(def, _) => format!("{} `{}`", def.descr(), tcx.def_path_str(def.did)).into(), ty::Foreign(def_id) => format!("extern type `{}`", tcx.def_path_str(def_id)).into(), ty::Array(t, n) => { <ins> if t.is_simple_ty() { return format!("array `{}`", self).into(); } </ins> let n = tcx.lift(n).unwrap(); <del> match n.try_eval_usize(tcx, ty::ParamEnv::empty()) { _ if t.is_simple_ty() => format!("array `{}`", self).into(), Some(n) => format!("array of {} element{}", n, pluralize!(n)).into(), None => "array".into(), </del> <ins> if let ty::ConstKind::Value(v) = n.val { if let Some(n) = v.try_to_machine_usize(tcx) { return format!("array of {} element{}", n, pluralize!(n)).into(); } </ins> } <ins> "array".into() </ins> } ty::Slice(ty) if ty.is_simple_ty() => format!("slice `{}`", self).into(), ty::Slice(_) => "slice".into(),


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. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
It doesn't fixed in rustc 1.52.0-nightly ( 2021-02-14) link to playground : <details<summary<strongBacktrace</strong</summary<p</p</details
i dont think the fix was merged by then. it works in 1.52.0-nightly 2021-02-16 :)

tcx: TyCtxt<'tcx>, key: ty::ParamEnvAnd<'tcx, GlobalId<'tcx>>, ) -> ::rustc_middle::mir::interpret::EvalToConstValueResult<'tcx> { <del> // see comment in const_eval_raw_provider for what we're doing here </del> <ins> // see comment in eval_to_allocation_raw_provider for what we're doing here </ins> if key.param_env.reveal() == Reveal::All { let mut key = key; key.param_env = key.param_env.with_user_facing();


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. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
It doesn't fixed in rustc 1.52.0-nightly ( 2021-02-14) link to playground : <details<summary<strongBacktrace</strong</summary<p</p</details
i dont think the fix was merged by then. it works in 1.52.0-nightly 2021-02-16 :)

<ins> #![feature(const_generics, const_evaluatable_checked)] #![allow(incomplete_features)] // This test is a minimized reproduction for #79518 where // during error handling for the type mismatch we would try // to evaluate std::mem::size_of::<Self::Assoc> causing an ICE trait Foo { type Assoc: PartialEq; const AssocInstance: Self::Assoc; fn foo() where [(); std::mem::size_of::<Self::Assoc>()]: , { Self::AssocInstance == [(); std::mem::size_of::<Self::Assoc>()]; //~^ Error: mismatched types } } 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. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
It doesn't fixed in rustc 1.52.0-nightly ( 2021-02-14) link to playground : <details<summary<strongBacktrace</strong</summary<p</p</details
i dont think the fix was merged by then. it works in 1.52.0-nightly 2021-02-16 :)

<ins> error[E0308]: mismatched types --> $DIR/issue-79518-default_trait_method_normalization.rs:16:32 | LL |         Self::AssocInstance == [(); std::mem::size_of::<Self::Assoc>()]; |                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected associated type, found array `[(); _]` | = note: expected associated type `<Self as Foo>::Assoc` found array `[(); _]` = help: consider constraining the associated type `<Self as Foo>::Assoc` to `[(); _]` or calling a method that returns `<Self as Foo>::Assoc` = note: for more information, visit https://doc.rust-lang.org/book/ch19-03-advanced-traits.html error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>


Question:
I tried this code: This should give a suggestion to reorder the keywords to , something like: Right now it gives this error, which is not very helpful: Tested on 1.48.0 and 1.50.0-nightly (2020-12-03 ) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Releasing assignment as I'm not really sure how to fix this at the moment. release-assignment
This could be handled directly in the parser code which generates the above diagnostic.
claim

*self = snapshot; Err(err) } <ins> /// Get the diagnostics for the cases where `move async` is found. /// /// `move_async_span` starts at the 'm' of the move keyword and ends with the 'c' of the async keyword pub(super) fn incorrect_move_async_order_found( &self, move_async_span: Span, ) -> DiagnosticBuilder<'a> { let mut err = self.struct_span_err(move_async_span, "the order of `move` and `async` is incorrect"); err.span_suggestion_verbose( move_async_span, "try switching the order", "async move".to_owned(), Applicability::MaybeIncorrect, ); err } </ins> }


Question:
I tried this code: This should give a suggestion to reorder the keywords to , something like: Right now it gives this error, which is not very helpful: Tested on 1.48.0 and 1.50.0-nightly (2020-12-03 ) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Releasing assignment as I'm not really sure how to fix this at the moment. release-assignment
This could be handled directly in the parser code which generates the above diagnostic.
claim

self.sess.gated_spans.gate(sym::async_closure, span); } <del> let capture_clause = self.parse_capture_clause(); </del> <ins> let capture_clause = self.parse_capture_clause()?; </ins> let decl = self.parse_fn_block_decl()?; let decl_hi = self.prev_token.span; let body = match decl.output {


Question:
I tried this code: This should give a suggestion to reorder the keywords to , something like: Right now it gives this error, which is not very helpful: Tested on 1.48.0 and 1.50.0-nightly (2020-12-03 ) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Releasing assignment as I'm not really sure how to fix this at the moment. release-assignment
This could be handled directly in the parser code which generates the above diagnostic.
claim

} /// Parses an optional `move` prefix to a closure-like construct. <del> fn parse_capture_clause(&mut self) -> CaptureBy { if self.eat_keyword(kw::Move) { CaptureBy::Value } else { CaptureBy::Ref } </del> <ins> fn parse_capture_clause(&mut self) -> PResult<'a, CaptureBy> { if self.eat_keyword(kw::Move) { // Check for `move async` and recover if self.check_keyword(kw::Async) { let move_async_span = self.token.span.with_lo(self.prev_token.span.data().lo); Err(self.incorrect_move_async_order_found(move_async_span)) } else { Ok(CaptureBy::Value) } } else { Ok(CaptureBy::Ref) } </ins> } /// Parses the `|arg, arg|` header of a closure.


Question:
I tried this code: This should give a suggestion to reorder the keywords to , something like: Right now it gives this error, which is not very helpful: Tested on 1.48.0 and 1.50.0-nightly (2020-12-03 ) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Releasing assignment as I'm not really sure how to fix this at the moment. release-assignment
This could be handled directly in the parser code which generates the above diagnostic.
claim

fn parse_async_block(&mut self, mut attrs: AttrVec) -> PResult<'a, P<Expr>> { let lo = self.token.span; self.expect_keyword(kw::Async)?; <del> let capture_clause = self.parse_capture_clause(); </del> <ins> let capture_clause = self.parse_capture_clause()?; </ins> let (iattrs, body) = self.parse_inner_attrs_and_block()?; attrs.extend(iattrs); let kind = ExprKind::Async(capture_clause, DUMMY_NODE_ID, body);


Question:
I tried this code: This should give a suggestion to reorder the keywords to , something like: Right now it gives this error, which is not very helpful: Tested on 1.48.0 and 1.50.0-nightly (2020-12-03 ) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Releasing assignment as I'm not really sure how to fix this at the moment. release-assignment
This could be handled directly in the parser code which generates the above diagnostic.
claim

<ins> // run-rustfix // edition:2018 // Regression test for issue 79694 fn main() { let _ = async move { }; //~ ERROR 7:13: 7:23: the order of `move` and `async` is incorrect } </ins>


Question:
I tried this code: This should give a suggestion to reorder the keywords to , something like: Right now it gives this error, which is not very helpful: Tested on 1.48.0 and 1.50.0-nightly (2020-12-03 ) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Releasing assignment as I'm not really sure how to fix this at the moment. release-assignment
This could be handled directly in the parser code which generates the above diagnostic.
claim

<ins> // run-rustfix // edition:2018 // Regression test for issue 79694 fn main() { let _ = move async { }; //~ ERROR 7:13: 7:23: the order of `move` and `async` is incorrect } </ins>


Question:
I tried this code: This should give a suggestion to reorder the keywords to , something like: Right now it gives this error, which is not very helpful: Tested on 1.48.0 and 1.50.0-nightly (2020-12-03 ) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Releasing assignment as I'm not really sure how to fix this at the moment. release-assignment
This could be handled directly in the parser code which generates the above diagnostic.
claim

<ins> error: the order of `move` and `async` is incorrect --> $DIR/incorrect-move-async-order-issue-79694.rs:7:13 | LL |     let _ = move async { }; |             ^^^^^^^^^^ | help: try switching the order | LL |     let _ = async move { }; |             ^^^^^^^^^^ error: aborting due to previous error </ins>


Question:
(Edit: Actually, being an inherent fn doesn't matter. It happens with top-level fns too.) This prints the diagnostic: The suggestion in the last line is not valid syntax (). It also emits malformed syntax if the first parameter is a or parameter. The diagnostic becomes well-formed if any of the following is done: The first parameter is changed to instead ofThe fn is not an async fn. In either case, the diagnostic correctly says: Happens on both nightly: ... and stable:
This should hopefully be a fairly straightforward patch to the diagnostics code that generates the suggestion.

let pred = trait_ref.without_const().to_predicate(tcx).to_string(); let pred = pred.replace(&impl_trait_str, &type_param_name); let mut sugg = vec![ <ins> // Find the last of the generic parameters contained within the span of // the generics </ins> match generics .params .iter() <del> .filter(|p| match p.kind { hir::GenericParamKind::Type { synthetic: Some(hir::SyntheticTyParamKind::ImplTrait), .. } => false, _ => true, }) .last() </del> <ins> .map(|p| p.bounds_span().unwrap_or(p.span)) .filter(|&span| generics.span.contains(span) && span.desugaring_kind().is_none()) .max_by_key(|span| span.hi()) </ins> { // `fn foo(t: impl Trait)` //        ^ suggest `<T: Trait>` here None => (generics.span, format!("<{}>", type_param)), // `fn foo<A>(t: impl Trait)` //        ^^^ suggest `<A, T: Trait>` here <del> Some(param) => ( param.bounds_span().unwrap_or(param.span).shrink_to_hi(), format!(", {}", type_param), ), </del> <ins> Some(span) => (span.shrink_to_hi(), format!(", {}", type_param)), </ins> }, // `fn foo(t: impl Trait)` //                       ^ suggest `where <T as Trait>::A: Bound`


Question:
(Edit: Actually, being an inherent fn doesn't matter. It happens with top-level fns too.) This prints the diagnostic: The suggestion in the last line is not valid syntax (). It also emits malformed syntax if the first parameter is a or parameter. The diagnostic becomes well-formed if any of the following is done: The first parameter is changed to instead ofThe fn is not an async fn. In either case, the diagnostic correctly says: Happens on both nightly: ... and stable:
This should hopefully be a fairly straightforward patch to the diagnostics code that generates the suggestion.

} } <ins> #[rustfmt::skip] fn baw<>(constraints: impl Iterator) { for constraint in constraints { qux(constraint); //~^ ERROR `<impl Iterator as Iterator>::Item` doesn't implement `Debug` } } </ins> fn qux(_: impl std::fmt::Debug) {} fn main() {}


Question:
(Edit: Actually, being an inherent fn doesn't matter. It happens with top-level fns too.) This prints the diagnostic: The suggestion in the last line is not valid syntax (). It also emits malformed syntax if the first parameter is a or parameter. The diagnostic becomes well-formed if any of the following is done: The first parameter is changed to instead ofThe fn is not an async fn. In either case, the diagnostic correctly says: Happens on both nightly: ... and stable:
This should hopefully be a fairly straightforward patch to the diagnostics code that generates the suggestion.

LL | fn bak<I: Iterator + std::fmt::Debug>(constraints: I) where <I as Iterator>::Item: Debug { |       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^              ^  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ <del> error: aborting due to 5 previous errors </del> <ins> error[E0277]: `<impl Iterator as Iterator>::Item` doesn't implement `Debug` --> $DIR/impl-trait-with-missing-bounds.rs:45:13 | LL |         qux(constraint); |             ^^^^^^^^^^ `<impl Iterator as Iterator>::Item` cannot be formatted using `{:?}` because it doesn't implement `Debug` ... LL | fn qux(_: impl std::fmt::Debug) {} |                --------------- required by this bound in `qux` | = help: the trait `Debug` is not implemented for `<impl Iterator as Iterator>::Item` help: introduce a type parameter with a trait bound instead of using `impl Trait` | LL | fn baw<I: Iterator>(constraints: I) where <I as Iterator>::Item: Debug { |       ^^^^^^^^^^^^^              ^  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to 6 previous errors </ins> For more information about this error, try `rustc --explain E0277`.


Question:
(Edit: Actually, being an inherent fn doesn't matter. It happens with top-level fns too.) This prints the diagnostic: The suggestion in the last line is not valid syntax (). It also emits malformed syntax if the first parameter is a or parameter. The diagnostic becomes well-formed if any of the following is done: The first parameter is changed to instead ofThe fn is not an async fn. In either case, the diagnostic correctly says: Happens on both nightly: ... and stable:
This should hopefully be a fairly straightforward patch to the diagnostics code that generates the suggestion.

<ins> // Regression test: if we suggest replacing an `impl Trait` argument to an async // fn with a named type parameter in order to add bounds, the suggested function // signature should be well-formed. // // edition:2018 trait Foo { type Bar; fn bar(&self) -> Self::Bar; } async fn run(_: &(), foo: impl Foo) -> std::io::Result<()> { let bar = foo.bar(); assert_is_send(&bar); //~^ ERROR: `<impl Foo as Foo>::Bar` cannot be sent between threads safely Ok(()) } // Test our handling of cases where there is a generic parameter list in the // source, but only synthetic generic parameters async fn run2< >(_: &(), foo: impl Foo) -> std::io::Result<()> { let bar = foo.bar(); assert_is_send(&bar); //~^ ERROR: `<impl Foo as Foo>::Bar` cannot be sent between threads safely Ok(()) } fn assert_is_send<T: Send>(_: &T) {} fn main() {} </ins>


Question:
(Edit: Actually, being an inherent fn doesn't matter. It happens with top-level fns too.) This prints the diagnostic: The suggestion in the last line is not valid syntax (). It also emits malformed syntax if the first parameter is a or parameter. The diagnostic becomes well-formed if any of the following is done: The first parameter is changed to instead ofThe fn is not an async fn. In either case, the diagnostic correctly says: Happens on both nightly: ... and stable:
This should hopefully be a fairly straightforward patch to the diagnostics code that generates the suggestion.

<ins> error[E0277]: `<impl Foo as Foo>::Bar` cannot be sent between threads safely --> $DIR/issue-79843-impl-trait-with-missing-bounds-on-async-fn.rs:14:20 | LL |     assert_is_send(&bar); |                    ^^^^ `<impl Foo as Foo>::Bar` cannot be sent between threads safely ... LL | fn assert_is_send<T: Send>(_: &T) {} |                      ---- required by this bound in `assert_is_send` | = help: the trait `Send` is not implemented for `<impl Foo as Foo>::Bar` help: introduce a type parameter with a trait bound instead of using `impl Trait` | LL | async fn run<F: Foo>(_: &(), foo: F) -> std::io::Result<()> where <F as Foo>::Bar: Send { |             ^^^^^^^^              ^                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^ error[E0277]: `<impl Foo as Foo>::Bar` cannot be sent between threads safely --> $DIR/issue-79843-impl-trait-with-missing-bounds-on-async-fn.rs:24:20 | LL |     assert_is_send(&bar); |                    ^^^^ `<impl Foo as Foo>::Bar` cannot be sent between threads safely ... LL | fn assert_is_send<T: Send>(_: &T) {} |                      ---- required by this bound in `assert_is_send` | = help: the trait `Send` is not implemented for `<impl Foo as Foo>::Bar` help: introduce a type parameter with a trait bound instead of using `impl Trait` | LL | async fn run2<F: Foo>(_: &(), foo: F) -> std::io::Result<()> where <F as Foo>::Bar: Send { |              ^^^^^^^^              ^                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0277`. </ins>


Question:
Unclear on the extent to which these are the same problem: https://crater- https://crater- cc
The error looks like an old bug that was fixed by
only lists 0.1.0 so we should probably nag about a point release one more time :)
Whoops, looks like I half-fixed it. One of my dependencies is too strict. It does look like the same error so probably not a regression...
cc
and I both feel unclear about this: Is this a Rust regression or a regression in a library that was then picked up by Crater?
This is a regression in the Rust compiler.
The error seems to me like fallout from implementing . I'm guessing the issue is that it's expecting a block but immediately gets a literal. Not sure how this is supposed to behave though. Reposting the error here:
But I'm not quite sure; the span seems potentially wrong.
ping cleanup would be nice to get an MCVE
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Somewhat minimized (): On stable, it produces a bunch of semantic errors (which make sense since I removed a lot of type definitions), but on beta it produces:
Assigning as and removing .
Much more minimized: () Errors:
Here's the code again: I think the issue is that on beta the compiler thinks the in the macro invocation is starting an expression because of the new feature – thus it thinks it's using the first rule in the macro. But then when doing macro expansion, it realizes that it's actually not a valid expression because it's missing braces. On stable this is not an issue because the compiler never thinks that is starting an expression. I think the fix might be to not treat as the start of an expression if it is not immediately followed by braces. See the original PR: . cc who has been implementing
My bisection is in line with my diagnosis: searched nightlies: from nightly-2020-10-15 to nightly-2020-10-19 regressed nightly: nightly-2020-10-18 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-apple-darwin Reproduce with: </details
I'm going to try working on this. If I get stuck I'll release my assignment since this is P-high!
So I'm trying to figure out which code is the culprit here. The PR is the one that introduced the regression, but looking at its changes I don't know if it's actual the underlying cause. I think the issue might be in the macro expansion code, but I'm not familiar with it at all. Since this issue is P-critical and potentially a release blocker, I'm going to release my assignment so that someone more experienced can take it over. Though I'm happy to help if there's some way to do that!
Actually, I just noticed that petrochenkov responded to my message asking for help finding the code
This should be fixed on the next nightly.
Reopening to track beta fix.
Should be backported to beta as part of
I think this can be closed as has been merged?

token.can_begin_expr() // This exception is here for backwards compatibility. && !token.is_keyword(kw::Let) <ins> // This exception is here for backwards compatibility. && !token.is_keyword(kw::Const) </ins> } NonterminalKind::Ty => token.can_begin_type(), NonterminalKind::Ident => get_macro_ident(token).is_some(),


Question:
Unclear on the extent to which these are the same problem: https://crater- https://crater- cc
The error looks like an old bug that was fixed by
only lists 0.1.0 so we should probably nag about a point release one more time :)
Whoops, looks like I half-fixed it. One of my dependencies is too strict. It does look like the same error so probably not a regression...
cc
and I both feel unclear about this: Is this a Rust regression or a regression in a library that was then picked up by Crater?
This is a regression in the Rust compiler.
The error seems to me like fallout from implementing . I'm guessing the issue is that it's expecting a block but immediately gets a literal. Not sure how this is supposed to behave though. Reposting the error here:
But I'm not quite sure; the span seems potentially wrong.
ping cleanup would be nice to get an MCVE
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Somewhat minimized (): On stable, it produces a bunch of semantic errors (which make sense since I removed a lot of type definitions), but on beta it produces:
Assigning as and removing .
Much more minimized: () Errors:
Here's the code again: I think the issue is that on beta the compiler thinks the in the macro invocation is starting an expression because of the new feature – thus it thinks it's using the first rule in the macro. But then when doing macro expansion, it realizes that it's actually not a valid expression because it's missing braces. On stable this is not an issue because the compiler never thinks that is starting an expression. I think the fix might be to not treat as the start of an expression if it is not immediately followed by braces. See the original PR: . cc who has been implementing
My bisection is in line with my diagnosis: searched nightlies: from nightly-2020-10-15 to nightly-2020-10-19 regressed nightly: nightly-2020-10-18 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-apple-darwin Reproduce with: </details
I'm going to try working on this. If I get stuck I'll release my assignment since this is P-high!
So I'm trying to figure out which code is the culprit here. The PR is the one that introduced the regression, but looking at its changes I don't know if it's actual the underlying cause. I think the issue might be in the macro expansion code, but I'm not familiar with it at all. Since this issue is P-critical and potentially a release blocker, I'm going to release my assignment so that someone more experienced can take it over. Though I'm happy to help if there's some way to do that!
Actually, I just noticed that petrochenkov responded to my message asking for help finding the code
This should be fixed on the next nightly.
Reopening to track beta fix.
Should be backported to beta as part of
I think this can be closed as has been merged?

<ins> // check-pass macro_rules! exp { (const $n:expr) => { $n }; } macro_rules! stmt { (exp $e:expr) => { $e }; (exp $($t:tt)+) => { exp!($($t)+) }; } fn main() { stmt!(exp const 1); } </ins>


Question:
The rustdoc search results page has three tabs of results: "In Names", "In Parameters", and "In Return Types". In my browser with the default theme, the selected tab heading is drawn in black on black. !
modify labels +T-rustdoc +A-rustdoc-ui +regression-from-stable-to-nightly
Yes, I've been having this too. You beat me to reporting this bug and ; thank you for making good reports!
I did some bisection and it seems the most likely cause is .
Ah, I think I know what the issue is.
Labeled as P-medium since I made the fix and it's in the bors queue.

} #titles > button:hover, #titles > button.selected { <ins> background-color: #ffffff; </ins> border-top-color: #0089ff; <del> background-color: #353535; </del> } #titles > button > div.count {


Question:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --<!-- The steps to reproduce the bug. --(The actual target doesn't seem to matter, the feature just requires that we pass a argument.) The following error occurs: I think this issue occurs because already landed, while the cargo-side revert in did not. So this issue will likely go away after the next cargo update. I still decided to open this issue in case other people encounter the same problem. <!-- 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. --:
Cc for
This will be fixed by .

] [[package]] <ins> name = "cargo-credential" version = "0.1.0" [[package]] name = "cargo-credential-1password" version = "0.1.0" dependencies = [ "cargo-credential", "serde", "serde_json", ] [[package]] name = "cargo-credential-macos-keychain" version = "0.1.0" dependencies = [ "cargo-credential", "security-framework", ] [[package]] name = "cargo-credential-wincred" version = "0.1.0" dependencies = [ "cargo-credential", "winapi 0.3.9", ] [[package]] </ins> name = "cargo-miri" version = "0.1.0" dependencies = [


Question:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --<!-- The steps to reproduce the bug. --(The actual target doesn't seem to matter, the feature just requires that we pass a argument.) The following error occurs: I think this issue occurs because already landed, while the cargo-side revert in did not. So this issue will likely go away after the next cargo update. I still decided to open this issue in case other people encounter the same problem. <!-- 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. --:
Cc for
This will be fixed by .

checksum = "d29ab0c6d3fc0ee92fe66e2d99f700eab17a8d57d1c1d3b748380fb20baa78cd" [[package]] <ins> name = "security-framework" version = "2.0.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "c1759c2e3c8580017a484a7ac56d3abc5a6c1feadf88db2f3633f12ae4268c69" dependencies = [ "bitflags", "core-foundation", "core-foundation-sys", "libc", "security-framework-sys", ] [[package]] name = "security-framework-sys" version = "2.0.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "f99b9d5e26d2a71633cc4f2ebae7cc9f874044e0c351a27e17892d76dce5678b" dependencies = [ "core-foundation-sys", "libc", ] [[package]] </ins> name = "semver" version = "0.9.0" source = "registry+https://github.com/rust-lang/crates.io-index"


Question:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --<!-- The steps to reproduce the bug. --(The actual target doesn't seem to matter, the feature just requires that we pass a argument.) The following error occurs: I think this issue occurs because already landed, while the cargo-side revert in did not. So this issue will likely go away after the next cargo update. I still decided to open this issue in case other people encounter the same problem. <!-- 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. --:
Cc for
This will be fixed by .

[[package]] name = "serde" <del> version = "1.0.115" </del> <ins> version = "1.0.118" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "e54c9a88f2da7238af84b5101443f0c0d0a3bbdc455e34a5c9497b1903ed55d5" </del> <ins> checksum = "06c64263859d87aa2eb554587e2d23183398d617427327cf2b3d0ed8c69e4800" </ins> dependencies = [ "serde_derive", ] [[package]] name = "serde_derive" <del> version = "1.0.115" </del> <ins> version = "1.0.118" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "609feed1d0a73cc36a0182a840a9b37b4a82f0b1150369f0536a9e3f2a31dc48" </del> <ins> checksum = "c84d3526699cd55261af4b941e4e725444df67aa4f9e6a3564f18030d12672df" </ins> dependencies = [ "proc-macro2", "quote",


Question:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --<!-- The steps to reproduce the bug. --(The actual target doesn't seem to matter, the feature just requires that we pass a argument.) The following error occurs: I think this issue occurs because already landed, while the cargo-side revert in did not. So this issue will likely go away after the next cargo update. I still decided to open this issue in case other people encounter the same problem. <!-- 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. --:
Cc for
This will be fixed by .

"src/tools/rust-installer", "src/tools/rust-demangler", "src/tools/cargo", <ins> "src/tools/cargo/crates/credential/cargo-credential-1password", "src/tools/cargo/crates/credential/cargo-credential-macos-keychain", "src/tools/cargo/crates/credential/cargo-credential-wincred", </ins> "src/tools/rustdoc", "src/tools/rls", "src/tools/rustfmt",


Question:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --<!-- The steps to reproduce the bug. --(The actual target doesn't seem to matter, the feature just requires that we pass a argument.) The following error occurs: I think this issue occurs because already landed, while the cargo-side revert in did not. So this issue will likely go away after the next cargo update. I still decided to open this issue in case other people encounter the same problem. <!-- 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. --:
Cc for
This will be fixed by .

builder.create_dir(&image.join("etc/bash_completion.d")); let cargo = builder.ensure(tool::Cargo { compiler, target }); builder.install(&cargo, &image.join("bin"), 0o755); <ins> for dirent in fs::read_dir(cargo.parent().unwrap()).expect("read_dir") { let dirent = dirent.expect("read dir entry"); if dirent.file_name().to_str().expect("utf8").starts_with("cargo-credential-") { builder.install(&dirent.path(), &image.join("libexec"), 0o755); } } </ins> for man in t!(etc.join("man").read_dir()) { let man = t!(man); builder.install(&man.path(), &image.join("share/man/man1"), 0o644);


Question:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --<!-- The steps to reproduce the bug. --(The actual target doesn't seem to matter, the feature just requires that we pass a argument.) The following error occurs: I think this issue occurs because already landed, while the cargo-side revert in did not. So this issue will likely go away after the next cargo update. I still decided to open this issue in case other people encounter the same problem. <!-- 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. --:
Cc for
This will be fixed by .

} fn run(self, builder: &Builder<'_>) -> PathBuf { <del> builder </del> <ins> let cargo_bin_path = builder </ins> .ensure(ToolBuild { compiler: self.compiler, target: self.target,


Question:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --<!-- The steps to reproduce the bug. --(The actual target doesn't seem to matter, the feature just requires that we pass a argument.) The following error occurs: I think this issue occurs because already landed, while the cargo-side revert in did not. So this issue will likely go away after the next cargo update. I still decided to open this issue in case other people encounter the same problem. <!-- 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. --:
Cc for
This will be fixed by .

source_type: SourceType::Submodule, extra_features: Vec::new(), }) <del> .expect("expected to build -- essential tool") </del> <ins> .expect("expected to build -- essential tool"); let build_cred = |name, path| { // These credential helpers are currently experimental. // Any build failures will be ignored. let _ = builder.ensure(ToolBuild { compiler: self.compiler, target: self.target, tool: name, mode: Mode::ToolRustc, path, is_optional_tool: true, source_type: SourceType::Submodule, extra_features: Vec::new(), }); }; if self.target.contains("windows") { build_cred( "cargo-credential-wincred", "src/tools/cargo/crates/credential/cargo-credential-wincred", ); } if self.target.contains("apple-darwin") { build_cred( "cargo-credential-macos-keychain", "src/tools/cargo/crates/credential/cargo-credential-macos-keychain", ); } build_cred( "cargo-credential-1password", "src/tools/cargo/crates/credential/cargo-credential-1password", ); cargo_bin_path </ins> } }


Question:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --<!-- The steps to reproduce the bug. --(The actual target doesn't seem to matter, the feature just requires that we pass a argument.) The following error occurs: I think this issue occurs because already landed, while the cargo-side revert in did not. So this issue will likely go away after the next cargo update. I still decided to open this issue in case other people encounter the same problem. <!-- 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. --:
Cc for
This will be fixed by .

<del> Subproject commit d274fcf862b89264fa2c6b917b15230705257317 </del> <ins> Subproject commit a3c2627fbc2f5391c65ba45ab53b81bf71fa323c </ins>


Question:
I haven't been able to minimize this yet. The similar, already resolved, bug report doesn't seem to help - changing the 's return signature from to the full definition doesn't help here. The bug is also present in the nightly build (). <details<summary<strongBacktrace</strong</summary<p</p</details
:
Note the error goes away if you add , or if you change to . So I think the bug is that the trait bound is not being checked. cc
Triage: no change
No longe crashes with master toolchain
Crashing again after
This is also a compiles -ice regression
This never should have passed. Removing regression label; this can remain open to track the ICE.
no longer produces an ICE as of rust 1.81.0

<ins> // check-pass #![allow(unreachable_code, unused)] use std::marker::PhantomData; struct FsmBuilder<TFsm> { _fsm: PhantomData<TFsm>, } impl<TFsm> FsmBuilder<TFsm> { fn state(&mut self) -> FsmStateBuilder<TFsm> { todo!() } } struct FsmStateBuilder<TFsm> { _state: PhantomData<TFsm>, } impl<TFsm> FsmStateBuilder<TFsm> { fn on_entry<TAction: Fn(&mut StateContext<'_, TFsm>)>(&self, _action: TAction) {} } trait Fsm { type Context; } struct StateContext<'a, TFsm: Fsm> { context: &'a mut TFsm::Context, } fn main() { let mut builder: FsmBuilder<usize> = todo!(); builder.state().on_entry(|_| {}); } </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. --code from <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailsThis happens since cc
Oh my, I'll fix that now. The syntax is gated but evidently the flag can still reach into the parts which were not completed yet. Update: Ah but I misread the code, this is actually using const generics defaults. They're not done yet, ICE-ing is expected until the feature is completed in . how did you hit that ? Were you trying to use const generics defaults or did the ICE come up unexpectedly ? I can open a PR that will do nothing here instead of ICE-ing.
I made a small program that executes rustc on all the rust files with different flags and filters the ICEs. The file showed up as previously unknown crash.
On nightly-2020-12-31 (commit ), I get a parse error with the code you provided:
Yes, the PR was merged ~7 hours ago, it's not in nightly yet.
Ah, things move fast :) How did you get a build with the commit then? Did you use ?
There are inofficial "master" builds released for every merge commit in the repo (the latest one is then promoted to "nightly" once at some point of the day) You can install them with and run something like or afterwards.
Oh, I forgot about RTIM
will remove the ICE so that only the appears

s.print_type_bounds(":", &param.bounds); if let Some(ref _default) = default { // FIXME(const_generics_defaults): print the `default` value here <del> todo!(); </del> } } }


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. --code from <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailsThis happens since cc
Oh my, I'll fix that now. The syntax is gated but evidently the flag can still reach into the parts which were not completed yet. Update: Ah but I misread the code, this is actually using const generics defaults. They're not done yet, ICE-ing is expected until the feature is completed in . how did you hit that ? Were you trying to use const generics defaults or did the ICE come up unexpectedly ? I can open a PR that will do nothing here instead of ICE-ing.
I made a small program that executes rustc on all the rust files with different flags and filters the ICEs. The file showed up as previously unknown crash.
On nightly-2020-12-31 (commit ), I get a parse error with the code you provided:
Yes, the PR was merged ~7 hours ago, it's not in nightly yet.
Ah, things move fast :) How did you get a build with the commit then? Did you use ?
There are inofficial "master" builds released for every merge commit in the repo (the latest one is then promoted to "nightly" once at some point of the day) You can install them with and run something like or afterwards.
Oh, I forgot about RTIM
will remove the ICE so that only the appears

self.print_type(ty); if let Some(ref _default) = default { // FIXME(const_generics_defaults): print the `default` value here <del> todo!(); </del> } } }


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. --code from <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailsThis happens since cc
Oh my, I'll fix that now. The syntax is gated but evidently the flag can still reach into the parts which were not completed yet. Update: Ah but I misread the code, this is actually using const generics defaults. They're not done yet, ICE-ing is expected until the feature is completed in . how did you hit that ? Were you trying to use const generics defaults or did the ICE come up unexpectedly ? I can open a PR that will do nothing here instead of ICE-ing.
I made a small program that executes rustc on all the rust files with different flags and filters the ICEs. The file showed up as previously unknown crash.
On nightly-2020-12-31 (commit ), I get a parse error with the code you provided:
Yes, the PR was merged ~7 hours ago, it's not in nightly yet.
Ah, things move fast :) How did you get a build with the commit then? Did you use ?
There are inofficial "master" builds released for every merge commit in the repo (the latest one is then promoted to "nightly" once at some point of the day) You can install them with and run something like or afterwards.
Oh, I forgot about RTIM
will remove the ICE so that only the appears

param_text.push_str(&ty_to_string(&ty)); if let Some(ref _default) = default { // FIXME(const_generics_defaults): push the `default` value here <del> todo!(); </del> } } if !param.bounds.is_empty() {


Question:
The "Notable traits" popup for [] shows notable traits for when it should show (or at least ): ! Note that this happens for other functions on . Another example is [] which shows when it should show . I'm not 100% sure this is a bug, but the behavior is definitely confusing: I'm not sure what the notable traits popup is referring to when it references an type parameter ( doesn't even appear in the file that is defined in...). []: []:
I think this is a duplicate of
Hmm, that seems possible. Wow, that issue is so old: it refers to ! Off-topic: is there a way to see what the docs from then look like?
Yes, you can manually type the version number in the URL:
Thanks! I forgot about that. However, I meant for the docs pre-1.0. Do you know of any way to view those?
Followup: 0.11.0 is the earliest version I could find docs for:

<ins> //! Test case for [#80737]. //! //! A SomeTrait that is implemented for `&mut T where T: SomeTrait` //! should not be marked as "notable" for return values that do not //! have bounds on the trait itself. //! //! [#80737]: https://github.com/rust-lang/rust/issues/80737 #![feature(rustdoc_internals)] #![no_std] #[doc(primitive = "reference")] /// Some useless docs, wouhou! /// /// We need to put this in here, because notable traits /// that are implemented on foreign types don't show up. mod reference {} // @has doc_notable_trait_mut_t_is_not_an_iterator/fn.fn_no_matches.html // @!has - '//code[@class="content"]' 'Iterator' pub fn fn_no_matches<'a, T: 'a>() -> &'a mut T { panic!() } </ins>


Question:
A code attached below used to compile with rustc 1.48 (stable) and stopped to work with 1.49 (stable). Two thing help to make the code compile: 1) comment out 2) explicitly deref . To compile code below one need to add to dependencies. Maybe this is due to some conflict between ArcSwap instance method and Access load method? I tried this code: I expected to see this happen: It should compile properly (it worked with rustc version 1.48 and earlier versions as well). Instead, this happened: I got compilation error It most recently worked on: Rust 1.48 :
searched nightlies: from nightly-2020-10-01 to nightly-2020-11-14 regressed nightly: nightly-2020-10-07 searched commits: from to regressed commit: () <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Assigning as discussed as part of the and removing .
:
The examples now print actionable feedback for the user, in the form of errors complaining about multiple applicable impl's. For example, the now prints: So I think this might just need a regression test. label: E-needs-test

<ins> #![allow(unreachable_code)] use std::marker::PhantomData; use std::ops::Deref; use std::sync::Arc; pub struct Guard<T> { _phantom: PhantomData<T>, } impl<T> Deref for Guard<T> { type Target = T; fn deref(&self) -> &T { unimplemented!() } } pub struct DirectDeref<T>(T); impl<T> Deref for DirectDeref<Arc<T>> { type Target = T; fn deref(&self) -> &T { unimplemented!() } } pub trait Access<T> { type Guard: Deref<Target = T>; fn load(&self) -> Self::Guard { unimplemented!() } } impl<T, A: Access<T>, P: Deref<Target = A>> Access<T> for P { //~^ NOTE: required for `Arc<ArcSwapAny<Arc<usize>>>` to implement `Access<_>` type Guard = A::Guard; } impl<T> Access<T> for ArcSwapAny<T> { //~^ NOTE: multiple `impl`s satisfying `ArcSwapAny<Arc<usize>>: Access<_>` found type Guard = Guard<T>; } impl<T> Access<T> for ArcSwapAny<Arc<T>> { type Guard = DirectDeref<Arc<T>>; } pub struct ArcSwapAny<T> { _phantom_arc: PhantomData<T>, } pub fn foo() { let s: Arc<ArcSwapAny<Arc<usize>>> = unimplemented!(); let guard: Guard<Arc<usize>> = s.load(); //~^ ERROR: type annotations needed //~| HELP: try using a fully qualified path to specify the expected types } fn main() {} </ins>


Question:
A code attached below used to compile with rustc 1.48 (stable) and stopped to work with 1.49 (stable). Two thing help to make the code compile: 1) comment out 2) explicitly deref . To compile code below one need to add to dependencies. Maybe this is due to some conflict between ArcSwap instance method and Access load method? I tried this code: I expected to see this happen: It should compile properly (it worked with rustc version 1.48 and earlier versions as well). Instead, this happened: I got compilation error It most recently worked on: Rust 1.48 :
searched nightlies: from nightly-2020-10-01 to nightly-2020-11-14 regressed nightly: nightly-2020-10-07 searched commits: from to regressed commit: () <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Assigning as discussed as part of the and removing .
:
The examples now print actionable feedback for the user, in the form of errors complaining about multiple applicable impl's. For example, the now prints: So I think this might just need a regression test. label: E-needs-test

<ins> error[E0283]: type annotations needed --> $DIR/issue-80816.rs:49:38 | LL |     let guard: Guard<Arc<usize>> = s.load(); |                                      ^^^^ | note: multiple `impl`s satisfying `ArcSwapAny<Arc<usize>>: Access<_>` found --> $DIR/issue-80816.rs:35:1 | LL | impl<T> Access<T> for ArcSwapAny<T> { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ... LL | impl<T> Access<T> for ArcSwapAny<Arc<T>> { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ note: required for `Arc<ArcSwapAny<Arc<usize>>>` to implement `Access<_>` --> $DIR/issue-80816.rs:31:45 | LL | impl<T, A: Access<T>, P: Deref<Target = A>> Access<T> for P { |                                             ^^^^^^^^^     ^ help: try using a fully qualified path to specify the expected types | LL |     let guard: Guard<Arc<usize>> = <Arc<ArcSwapAny<Arc<usize>>> as Access<T>>::load(&s); |                                    ++++++++++++++++++++++++++++++++++++++++++++++++++ ~ error: aborting due to previous error For more information about this error, try `rustc --explain E0283`. </ins>


Question:
See below:
Reduced to only use the task proc-macro: It seems important, that Foo isn't defined, if I define a , the ICE goes away.
searched nightlies: from nightly-2020-06-01 to nightly-2021-01-01 regressed nightly: nightly-2020-10-27 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsI'm pretty sure that isn't at fault here, but instead it just uncovers the problem.
MCVE:
Panic location:

fn source_info(&self, cx: &CodegenCx<'ll, 'tcx>) -> Option<SourceInfo<'ll>> { match self { VariantInfo::Generator { def_id, variant_index, .. } => { <del> let span = cx.tcx.generator_layout(*def_id).variant_source_info[*variant_index].span; </del> <ins> let span = cx.tcx.generator_layout(*def_id).unwrap().variant_source_info [*variant_index] .span; </ins> if !span.is_dummy() { let loc = cx.lookup_debug_loc(span.lo()); return Some(SourceInfo {


Question:
See below:
Reduced to only use the task proc-macro: It seems important, that Foo isn't defined, if I define a , the ICE goes away.
searched nightlies: from nightly-2020-06-01 to nightly-2021-01-01 regressed nightly: nightly-2020-10-27 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsI'm pretty sure that isn't at fault here, but instead it just uncovers the problem.
MCVE:
Panic location:

) -> Result<&'tcx Layout, LayoutError<'tcx>> { use SavedLocalEligibility::*; let tcx = self.tcx; let subst_field = |ty: Ty<'tcx>| ty.subst(tcx, substs); <del> let info = tcx.generator_layout(def_id); </del> <ins> let info = match tcx.generator_layout(def_id) { None => return Err(LayoutError::Unknown(ty)), Some(info) => info, }; </ins> let (ineligible_locals, assignments) = self.generator_saved_local_eligibility(&info); // Build a prefix layout, including "promoting" all ineligible


Question:
See below:
Reduced to only use the task proc-macro: It seems important, that Foo isn't defined, if I define a , the ICE goes away.
searched nightlies: from nightly-2020-06-01 to nightly-2021-01-01 regressed nightly: nightly-2020-10-27 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsI'm pretty sure that isn't at fault here, but instead it just uncovers the problem.
MCVE:
Panic location:

self.trait_def(trait_def_id).has_auto_impl } <del> pub fn generator_layout(self, def_id: DefId) -> &'tcx GeneratorLayout<'tcx> { self.optimized_mir(def_id).generator_layout.as_ref().unwrap() </del> <ins> /// Returns layout of a generator. Layout might be unavailable if the /// generator is tainted by errors. pub fn generator_layout(self, def_id: DefId) -> Option<&'tcx GeneratorLayout<'tcx>> { self.optimized_mir(def_id).generator_layout.as_ref() </ins> } /// Given the `DefId` of an impl, returns the `DefId` of the trait it implements.


Question:
See below:
Reduced to only use the task proc-macro: It seems important, that Foo isn't defined, if I define a , the ICE goes away.
searched nightlies: from nightly-2020-06-01 to nightly-2021-01-01 regressed nightly: nightly-2020-10-27 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsI'm pretty sure that isn't at fault here, but instead it just uncovers the problem.
MCVE:
Panic location:

#[inline] pub fn variant_range(&self, def_id: DefId, tcx: TyCtxt<'tcx>) -> Range<VariantIdx> { // FIXME requires optimized MIR <del> let num_variants = tcx.generator_layout(def_id).variant_fields.len(); </del> <ins> let num_variants = tcx.generator_layout(def_id).unwrap().variant_fields.len(); </ins> VariantIdx::new(0)..VariantIdx::new(num_variants) }


Question:
See below:
Reduced to only use the task proc-macro: It seems important, that Foo isn't defined, if I define a , the ICE goes away.
searched nightlies: from nightly-2020-06-01 to nightly-2021-01-01 regressed nightly: nightly-2020-10-27 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsI'm pretty sure that isn't at fault here, but instead it just uncovers the problem.
MCVE:
Panic location:

def_id: DefId, tcx: TyCtxt<'tcx>, ) -> impl Iterator<Item = impl Iterator<Item = Ty<'tcx>> + Captures<'tcx>> { <del> let layout = tcx.generator_layout(def_id); </del> <ins> let layout = tcx.generator_layout(def_id).unwrap(); </ins> layout.variant_fields.iter().map(move |variant| { variant.iter().map(move |field| layout.field_tys[*field].subst(tcx, self.substs)) })


Question:
See below:
Reduced to only use the task proc-macro: It seems important, that Foo isn't defined, if I define a , the ICE goes away.
searched nightlies: from nightly-2020-06-01 to nightly-2021-01-01 regressed nightly: nightly-2020-10-27 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsI'm pretty sure that isn't at fault here, but instead it just uncovers the problem.
MCVE:
Panic location:

<ins> // Verifies that computing a layout of a generator tainted by type errors // doesn't ICE. Regression test for #80998. // // edition:2018 #![feature(type_alias_impl_trait)] use std::future::Future; pub struct Task<F: Future>(F); impl<F: Future> Task<F> { fn new() -> Self { todo!() } fn spawn(&self, _: impl FnOnce() -> F) { todo!() } } fn main() { async fn cb() { let a = Foo; //~ ERROR cannot find value `Foo` in this scope } type F = impl Future; // Check that statics are inhabited computes they layout. static POOL: Task<F> = Task::new(); Task::spawn(&POOL, || cb()); } </ins>