jiebi/CodeConvo huggingface dataset:
Change:
} if let Some(non_sm_ty) = structural { <del> let adt_def = match non_sm_ty { traits::NonStructuralMatchTy::Adt(adt_def) => adt_def, </del> <ins> let msg = match non_sm_ty { traits::NonStructuralMatchTy::Adt(adt_def) => { let path = self.tcx().def_path_str(adt_def.did); format!( "to use a constant of type `{}` in a pattern,  `{}` must be annotated with `#[derive(PartialEq, Eq)]`", path, path, ) } traits::NonStructuralMatchTy::Dynamic => { format!("trait objects cannot be used in patterns") } </ins> traits::NonStructuralMatchTy::Param => { bug!("use of constant whose type is a parameter inside a pattern") } }; <del> let path = self.tcx().def_path_str(adt_def.did); let make_msg = || -> String { format!( "to use a constant of type `{}` in a pattern,  `{}` must be annotated with `#[derive(PartialEq, Eq)]`", path, path, ) }; </del> // double-check there even *is* a semantic `PartialEq` to dispatch to. //

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: Note that the error is also present on stable (1.42.0). <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
cc
cc I don't think should be structurally matchable.
Note that this isn't matching on , it's matching on . There's a double pointer indirection because AtomicPtr requires T to be Sized.
References match by their pointee value, unlike raw pointers. You should use if you want to actually compare the pointers.
Change:
} if let Some(non_sm_ty) = structural { <del> let adt_def = match non_sm_ty { traits::NonStructuralMatchTy::Adt(adt_def) => adt_def, </del> <ins> let msg = match non_sm_ty { traits::NonStructuralMatchTy::Adt(adt_def) => { let path = self.tcx().def_path_str(adt_def.did); format!( "to use a constant of type `{}` in a pattern,  `{}` must be annotated with `#[derive(PartialEq, Eq)]`", path, path, ) } traits::NonStructuralMatchTy::Dynamic => { format!("trait objects cannot be used in patterns") } </ins> traits::NonStructuralMatchTy::Param => { bug!("use of constant whose type is a parameter inside a pattern") } }; <del> let path = self.tcx().def_path_str(adt_def.did); let make_msg = || -> String { format!( "to use a constant of type `{}` in a pattern,  `{}` must be annotated with `#[derive(PartialEq, Eq)]`", path, path, ) }; </del> // double-check there even *is* a semantic `PartialEq` to dispatch to. //

Discussion:
Pretty straightforward. The idea is to plug logic into a template. This seems like something that should/could work. Playground link: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
"smaller": Error:
claim
release-assignment is not structural match so this should not compile. We probably shouldn't ICE here though :laughing: cc
It shouldn't be, but it currently is. To fix it you need to change , .
Change:
{ // FIXME: We could check that the call's *parent* takes `&mut val` to make the // suggestion more targeted to the `mk_iter(val).next()` case. Maybe do that only to <del> // check for wheter to suggest `let value` or `let mut value`. </del> <ins> // check for whether to suggest `let value` or `let mut value`. </ins> let span = in_loop.span; if !finder.found_breaks.is_empty()

Discussion:
I expect that the invocation to be for the value that is moved, but for some reason it is doing it for the entire closure. No response No response
label +E-needs-mcve
MCVE or
Change:
<ins> // run-rustfix enum Enum { Variant(i32), } struct Struct(i32); fn foo(x: Enum) -> i32 { let Enum::Variant(value) = x; value } fn bar(x: Enum) -> i32 { let Enum::Variant(value) = x; let x = value + 1; x } fn baz(x: Struct) -> i32 { let Struct(value) = x; let x = value + 1; x } fn main() { let _ = foo(Enum::Variant(42)); let _ = bar(Enum::Variant(42)); let _ = baz(Struct(42)); } </ins>

Discussion:
The following code () gives the following error: which is weird, since the clause would never be visited even if it was present. The equivalent one-arm match compiles just fine (expectedly). Adding an branch to the is, of course, possible, but unelegant, and really shouldn't be needed, as it can be inferred at compile time.
You can match irrefutably without in this case: though maybe we should give this special diagnostics.
I think this is too niche to deserve a special diagnostics (and I don't think we should substantially work on diagnostics for until let_chains is implemented). is defined by a desugaring: becomes: so what you really wrote is: The block is typed at which does not unify with unless it is also typed at .
I didn't know was a valid syntax. If I did, I probably wouldn't have filed the issue, because of course, in hindsight, that's how you write an infallible . (With that knowledge in mind) I agree that it's only a diagnostics issue and no language change is needed here. And I fully agree that it's a niche low-priority quirk that should maybe be fixed "someday". (I don't know what but even then I'd guess that this one is lower priority than that).
I think the appropriate thing to do here would be to lint on , which would have clarified things.
We already do.
But we do only after typechecking, and we don't if there are any errors before then. Quite a few lints have similar issues related to not happening early enough.
How do you know that the pattern is irrefutable before match checking in HAIR?
You can't, but you can write the lint in such a way that it triggers regardless. We're getting to typechecking, we should be able to detect irrefutability by then. It just can't use the standard linting machinery (like a few other lints already do to avoid being silenced by accident).
Change:
} Config::parse_inner(&["check".to_owned()], get_toml); } <ins> #[test] fn rust_optimize() { assert_eq!(parse("").rust_optimize.is_release(), true); assert_eq!(parse("rust.optimize = false").rust_optimize.is_release(), false); assert_eq!(parse("rust.optimize = true").rust_optimize.is_release(), true); assert_eq!(parse("rust.optimize = "1"").rust_optimize.get_opt_level(), Some("1".to_string())); assert_eq!(parse("rust.optimize = "s"").rust_optimize.get_opt_level(), Some("s".to_string())); } #[test] #[should_panic] fn invalid_rust_optimize() { parse("rust.optimize = "a""); } </ins>

Discussion:
It would be nice if we could speed up stage1 library builds by building it with less opts and no debuginfo. had the idea to control this with something like <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
i'm going to use as a separate more broad issue for - i'll repurpose this to just be for (which is a lot simpler to add)
mentoring instructions: add this option to the struct, then around , set
Can we confirm before we land this support that this is actually a significant win in practice? I recall historically having issues with optimize = false equivalents where the net effect is broken and slower tests - I would prefer to avoid landing support we don't want to actually support :)
this is especially useful in combination with - optimizing only rustc and not std should be a speedup even if we include the time taken for tests.
claim
Maybe we should just generalize the config value to a number/boolean, instead of adding a new attribute?
Change:
#![feature(array_windows)] #![feature(box_patterns)] #![feature(if_let_guard)] <ins> #![feature(iter_intersperse)] </ins> #![feature(let_chains)] #![feature(never_type)] #![feature(rustc_attrs)]

Discussion:
Newcomers might attempt to write a “generic” function pointer like . In such case, the compiler should provide a better error message. Inspired by a recent Reddit thread I sadly cannot find anymore. Given the following code: The compiler should mention that function pointers may not be generic or […] may not have generic parameters, suggest to move the lifetime(s) to a parameter list (this should be machine-applicable in my judgement) and be able to recover: For later reference, the current output is: Given the following code: The compiler should mention that function pointers may not be generic or […] may not have generic parameters and be able to recover emitting two diagnostics, one for each line. The compiler could also suggest moving the generic parameter list further up to the owning function, struct, etc. if available. Note that this might not be what the user intended (since there is a semantic difference between hypothetical higher-ranked generics and normal ones) and therefore shouldn't be machine-applicable. For later reference, the current output is: label A-parser A-suggestion-diagnostics D-newcomer-roadblock <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
}) } <ins> // #41697 -- we use `with_forced_impl_filename_line()` because // `item_path_str()` would otherwise trigger `type_of`, and this can // run while we are already attempting to evaluate `type_of`. </ins> fn dump_matched_mir_node<'a, 'tcx>(tcx: TyCtxt<'a, 'tcx, 'tcx>, pass_num: Option<(MirSuite, MirPassIndex)>, pass_name: &str,

Discussion:
running yields Happening on . Did not happen on the latest nightly available through rustup on 27.04.2017.
Last working nightly: First broken nightly: .
maybe it was ? cc
could be. let me try it on my big MIR refactoring branch =)
I confirm that the error occurs at but not at So it looks to me like is indeed the culprit.
Yes. I can reproduce. Will investigate.
I see the problem. PR coming soon.
Fix at
I'm still seeing this issue, on the latest nightly and on master.
can you give more details of how you are reproducing the problem? (I a test for the precise scenario reported, so I'm reasonably sure it's not that case anymore.)
Hmm, perhaps my regression test wasn't sufficient. I see I used ; I remember that the test did fail, but I guess that it passing doesn't prove all issues are resolved. =)
The earliest commit where I can reproduce this problem is
Change:
<ins> struct S1 { struct S2 { //~^ ERROR structs are not allowed in struct definitions } } fn main() {} </ins>

Discussion:
<!-- 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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should include a note informing the user that the declaration of another struct within a struct is not allowed and they should use separate declarations. (Wording might need a bit of tweaking). <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label D-terse
claim
Change:
LL |     [(); return while let Some(n) = Some(0) {}]; |          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ <del> warning: irrefutable while-let pattern --> $DIR/issue-51714.rs:11:17 | LL |     [(); return while let Some(n) = Some(0) {}]; |                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: #[warn(irrefutable_let_patterns)] on by default </del> error: aborting due to 4 previous errors For more information about this error, try `rustc --explain E0572`.

Discussion:
Super-High-Level Instructions: Replace with And then follow up by making sure that the compiler doesn't ICE anywhere (e.g. during MIR building). It should probably "just work" nowadays. A crater run isn't necessary, as this will only ICE if an error wasn't handled properly. Successfully compiling code is unaffected.
I took a look at this and all tests seem fine in just dropping in the code you have above as you said. However I just wanted to check is no longer needed? Pretty unfamiliar with this code so I wanted to confirm before submitting as it's not explicitly mentioned in the other thread that it should be removed.
Yes that should be removed, too. It will automatically be run when fetching the MIR of the current constant.
ok, cool! I have filed a PR for this in Let me know if anything needs to be updated!
Change:
LL |     let x = -3.40282357e+38_f32; |              ^^^^^^^^^^^^^^^^^^ | <del> = note: the literal `3.40282357e+38_f32` does not fit into the type `f32` and will be converted to `std::f32::INFINITY` </del> <ins> = note: the literal `3.40282357e+38_f32` does not fit into the type `f32` and will be converted to `f32::INFINITY` </ins> error: literal out of range for `f32` --> $DIR/lint-type-overflow2.rs:10:14

Discussion:
This program: Produces this output: Note the references to ; these symbols have been superseded by associated consts at (). the error message to suggest the new symbols if any of the other old symbols are contained in any error messages. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
See also .
I am working on this. claim
: I've gone and grepped through for , , etc. and found no accidental uses there. I then grepped for each of the individual symbols listed in RFC 2700 (, , etc.) and didn't notice anything out of place. I also grepped for (as seen in this issue) and found only a hint message for things like etc which only triggers when an item isn't found at all, which won't trigger for any of the new consts. Probably safe to close this once merges.
You are right. I was thinking of cases like this one but this can likely be closed with the merge of that PR. I was operating with an abundance of caution.
Yeah, that's the aforementioned case that only shows up in the event of an error, so (AFAICT) that path won't be taken for the new constants since they resolve successfully.
Change:
<ins> error[E0277]: the trait bound `[bool]: Copy` is not satisfied --> $DIR/ice-unsized-struct-arg-issue2-121424.rs:5:22 | LL | const MYSLICE_GOOD: &MySliceBool = &MySlice(true, [false]); |                      ^^^^^^^^^^^ the trait `Copy` is not implemented for `[bool]` | = help: the trait `Copy` is implemented for `[T; N]` note: required by a bound in `MySlice` --> $DIR/ice-unsized-struct-arg-issue2-121424.rs:3:19 | LL | struct MySlice<T: Copy>(bool, T); |                   ^^^^ required by this bound in `MySlice` error[E0277]: the trait bound `[bool]: Copy` is not satisfied --> $DIR/ice-unsized-struct-arg-issue2-121424.rs:5:22 | LL | const MYSLICE_GOOD: &MySliceBool = &MySlice(true, [false]); |                      ^^^^^^^^^^^ the trait `Copy` is not implemented for `[bool]` | = help: the trait `Copy` is implemented for `[T; N]` note: required by a bound in `MySlice` --> $DIR/ice-unsized-struct-arg-issue2-121424.rs:3:19 | LL | struct MySlice<T: Copy>(bool, T); |                   ^^^^ required by this bound in `MySlice` = note: duplicate diagnostic emitted due to `-Z deduplicate-diagnostics=no` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0277`. </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --:
<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details

<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: writeimmediatetomplace: invalid ScalarPair layout: TyAndLayout {', 'error: internal compiler error: writeimmediatetomplace: invalid ScalarPair layout: TyAndLayout {' File: --snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [evaltoallocationraw] const-evaluating + checking [evaltoconstvalueraw] simplifying constant for the type system [analysis] running analysis passes on this crate --
cc
Change:
#[no_mangle] pub static mut P: u8 = 0; } <del> // CHECK-LABEL: ; external_no_mangle_statics::x // CHECK-NEXT: ; Function Attrs: // CHECK-NEXT: define internal </del>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --I couldn't I couldn't produce a single file example, as it seems the ICE is triggered when cross crate compilation is involved; i.e dumping the contents of into does not trigger the ICE. This seems like a regression of the feature as this previously worked on nightly of the 1.50 stable release. : : <!-- 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
While regression itself is related to the introduction of CTFE MIR, it seems this actually never worked correctly, with static ending up duplicated.
Assigning priority as discussed as part of the and removing . label -I-prioritize +P-medium
I can't reproduce with the latest nightly and cargo. Are there any further instructions for reproducing this?
Apologies, forgot to mention you'll need to add Or build for a target that does not have panic unwinding enabled by default.
(discussed in T-compiler meeting. This is an issue on stable, and might get a backport via . Re-opening to investigate details of what worked, what stopped working, what is fixed, and what is still broken.)
In the case reported here, one crate references static from another crate. During mono item collection, based on reachability determines whether it will link to item from an upstream crate or codegen it locally. When decision is made to codegen locally, it is followed by an assertion that optimized MIR is available to do so. In 1.50 static is non-reachable and codegenned locally. In 1.51 and 1.52 static is non-reachable, but the assertion fails since statics no longer use optimized MIR. In nightly, since , the static is reachable and linked to. The change seems safe for backporting to me.
Closing as the .
Change:
match self.resolve_macro_path(path, Some(MacroKind::Derive), &parent_scope, true, force) { Ok((Some(ref ext), _)) if ext.is_derive_copy => { <del> self.add_derives(invoc.expansion_data.id, SpecialDerives::COPY); </del> <ins> self.add_derives(invoc_id, SpecialDerives::COPY); </ins> return Ok(None); } Err(Determinacy::Undetermined) => result = Err(Indeterminate),

Discussion:
This code ([playpen]) compiles on stable but not on nightly and beta: [playpen]: Standard Error Edit: Removed macro Originally posted by in
modify labels: A-macros A-resolve C-bug T-compiler
I updated the snippet to remove the module.
This is a regression from (cc Slightly more minimized reproduction will look like this: performs eager expansion on its arguments and hygienic context of produced by such expansion looks like it was produced by the opaque for some reason, so it's resolved at ' definition site. It maybe either some issue with hygiene infra interacting with eager expansion, but it also may be caused by incorrect spans produced by .
(I'm currently looking into the details.) UPD: I have a fix locally, will submit tomorrow.
Fixed in

() Errors: If either the recursion () or the is removed (), this compiles exactly as expected. Additionally, if I explicitly name my crate, it works as expected, but would be vulnerable to crate renames in user code (can't reproduce in playground because it doesn't build a library).
If you try and build Rustup, you get a similar failure, but without recursion or . Seems that just using another macro and is enough in some circumstances
cc for the hygiene macro in
This code () compiles on stable but not on nightly and beta:
Please, file a separate issue for the regression, I'll prioritize it over pre-existing issues (which the original issue seems to be).
Thanks, I filed it in
Fixed in
Thanks for your work on this!
Change:
/// Report an error that a generic argument did not match the generic parameter that was /// expected. <del> fn generic_arg_mismatch_err(sess: &Session, arg: &GenericArg<'_>, kind: &'static str) { </del> <ins> fn generic_arg_mismatch_err( sess: &Session, arg: &GenericArg<'_>, kind: &'static str, help: Option<&str>, ) { </ins> let mut err = struct_span_err!( sess, arg.span(),

Discussion:
The current diagnostics are a little ad hoc and rely on counting the number of mismatches (e.g. they will only produce an error for the first mismatch). It would be nice to produce diagnostics like: cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is follow up work for
Please give more context on this. I am not sure the error message of which test should be improved.
This is more of the kind of issue opened to avoid forgetting about finishing some work, sorry for the confusion. That is, this is leaving a TODO to themselves about improving the diagnostics from .
Ok. I see. Thanks for the explanation.
That said, if is too busy to work on this, you could talk to them on Discord or Zulip to see what their plans were, and maybe turn this into a mentored issue.
The idea is essentially this. We currently emit errors telling the user that the generic arguments they provide are in the wrong order: However, what we'd like to do is suggest reordering the parameters, and let rustfix automatically apply the suggestion. I don't have the bandwidth to work on this at the moment, or any time soon, so if anyone is interested in tackling it, I'll be happy to mentor the issue.
would you mind if I take this up?
you're very welcome to! Let me know if you need any guidance in tackling this issue!
claim
Change:
<ins> error: expected one of `!`, `(`, `)`, `+`, `,`, `::`, or `<`, found `:` --> $DIR/diagnostics-parenthesized-type-arguments-ice-issue-122345.rs:3:33 | LL |         dealloc(ptr2, Layout::(x: !)(1, 1)); |                             --- ^ expected one of 7 possible tokens |                             | |                             while parsing this parenthesized list of type arguments starting here error: expected one of `.`, `;`, `?`, `}`, or an operator, found `)` --> $DIR/diagnostics-parenthesized-type-arguments-ice-issue-122345.rs:3:43 | LL |         dealloc(ptr2, Layout::(x: !)(1, 1)); |                                           ^ expected one of `.`, `;`, `?`, `}`, or an operator error: aborting due to 2 previous errors </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at ', 'thread 'rustc' panicked at ' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
Ah, of course, we want to the returned by .
I will try to remedy the situation. claim