jiebi/CodeConvo huggingface dataset:
Change:
<ins> // Regression test for #116464 // Checks that we do not suggest Trait<..., Assoc=arg> when the trait // is referred to from one of its impls but do so at all other places pub trait Trait<T> { type Assoc; } impl<T, S> Trait<T> for i32 { type Assoc = String; } // Should not not trigger suggestion here... impl<T, S> Trait<T, S> for () {} //~^ ERROR trait takes 1 generic argument but 2 generic arguments were supplied //... but should do so in all of the below cases except the last one fn func<T: Trait<u32, String>>(t: T) -> impl Trait<(), i32> { //~^ ERROR trait takes 1 generic argument but 2 generic arguments were supplied //~| ERROR trait takes 1 generic argument but 2 generic arguments were supplied 3 } struct Struct<T: Trait<u32, String>> { //~^ ERROR trait takes 1 generic argument but 2 generic arguments were supplied a: T } trait AnotherTrait<T: Trait<T, i32>> {} //~^ ERROR trait takes 1 generic argument but 2 generic arguments were supplied impl<T: Trait<u32, String>> Struct<T> {} //~^ ERROR trait takes 1 generic argument but 2 generic arguments were supplied // Test for self type. Should not trigger suggestion as it doesn't have an // associated type trait YetAnotherTrait {} impl<T: Trait<u32, Assoc=String>, U> YetAnotherTrait for Struct<T, U> {} //~^ ERROR struct takes 1 generic argument but 2 generic arguments were supplied fn main() { } </ins>

Discussion:
The suggestion is not valid syntax. Applying the original suggestion like so: to this error instead: Note also that a more naive suggestion to keep the parameter like so: fail because it's unconstrained: needs to be a concrete type or an associated type of an input type parameter. The diagnostic is identical in beta and nightly. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
let ty = parent_trait_ref.skip_binder().self_ty(); let span = TyCategory::from_ty(self.tcx, ty) .map(|(_, def_id)| self.tcx.def_span(def_id)); <del> Some((ty.to_string(), span)) </del> <ins> Some((ty, span)) </ins> } } }

Discussion:
Type errors (and others) use and similar to write types that are too long to disk, so the cli output is easier to read. Trait bound errors do not do that. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I created . What was not visible in the tweet but that you will see when you build the repo, is that the types in the error notes are even longer. That's a shame because hidden in that noise the compiler gives the solution to the error (pin).
You can just create a gist with the error generating logic line highlighted. Much more helpful?
I can give more context too. I was implementing a K8s operator using . I start by creating a and then running it with . This returns a . That stream yields an item every time the reconcile loops reconciles an item or returns an error. For testing, I iterate over the stream to check that it reconciles items the way I expect. . The solution is to pin the stream returned by .
how would i go about solving this? claim
you can look at how we do it here You have to do the same thing but at the very least in the places we print out types to string here:
You also need to ensure that the type-shortening is conditional, based on whether the user wants verbose output or not (similar to the existing logic for type errors).
already checks whether is enabled or not before shortening.
into: by the looks: is the same as and i can call the method on it, but in the formatting (that returns a tuple) im not sure how to call those functions (as t is a string, and calling the function returns a string and pathbuf. in the closure should i just ignore ? or is that a bad approach?
Change:
#![feature(never_type)] #![feature(unwrap_infallible)] #![feature(option_unwrap_none)] <del> #![feature(peekable_next_if)] </del> #![feature(peekable_peek_mut)] #![feature(partition_point)] #![feature(once_cell)]

Discussion:
<!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilisation. Make sure to include the relevant RFC for the feature if it has one. Otherwise provide a short summary of the feature and link any relevant PRs or issues, and remove any sections that are not relevant to the feature. Remember to add team labels to the tracking issue. For a language team feature, this would e.g., be . Such a feature should also be labeled with e.g., . This label is used to associate issues (e.g., bugs and design questions) to the feature. --This is a tracking issue for the feature (). The feature gate for the issue is . Tracking issues are used to record the overall progress of implementation. They are also uses as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label. <!-- Include each step required to complete the feature. Typically this is a PR implementing a feature, followed by a PR that stabilises the feature. However for larger features an implementation could be broken up into multiple PRs. --- [x] Implement the RFC [ ] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide]) [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide]) [stabilization-guide]: https://rustc-dev- [doc-guide]: https://rustc-dev- <!-- Include any open questions that need to be answered before the feature can be stabilised. --- Should be named or ? Should be named or ?
modify labels: T-libs
I don't think the methods should be renamed to something else, becuase also has a method, and should use the same name but with the component. Also, if these questions are resolved and there are no other blockers, I would like to go ahead and stabilize this feature.
Change:
<ins> error: unexpected `==` --> $DIR/issue-101477-enum.rs:6:7 | LL |     B == 2 |       ^^ help: try using `=` instead error: expected item, found `==` --> $DIR/issue-101477-enum.rs:6:7 | LL |     B == 2 |       ^^ expected item error: aborting due to 2 previous errors </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 suggest replacing the with where appropriate as the suggestion for incorrect usage of in place of already exist. <!-- 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 --
claim
Change:
&self, field: Ident, expr_t: &'tcx ty::TyS<'tcx>, <ins> id: HirId, </ins> ) -> DiagnosticBuilder<'_> { let span = field.span; debug!("no_such_field_err(span: {:?}, field: {:?}, expr_t: {:?})", span, field, expr_t);

Discussion:
Lets consider the following code () : Here, we try to access a property on an object of type . Up to the 1.50 version, the error message was the following : However, since Rust 1.51 and onward, the diagnostic message changed to this: While there is indead a property on the struct, this can't be accessed like that, applying the compiler suggestion implies making the property of public, which is not possible. The compiler should not look at non- properties when searching for properties with a matching name for diagnostic purposes. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
label +A-diagnostics
Related issue:
Change:
quote_depth: @mut 0, obsolete_set: @mut HashSet::new(), mod_path_stack: @mut ~[], <del> open_braces: @mut ~[] </del> <ins> open_braces: @mut ~[], non_copyable: util::NonCopyable </ins> } }

Discussion:
The unit struct via , so it's the cleanest way to do this. This could potentially be a lint warning, with a suggestion.
A lint for empty drops is probably unnecessary, I wouldn't imagine that would be a common idiom once NonCopyable is well-known.
I only see one of these, in libsyntax.
Change:
<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #![crate_type="lib"] // This is a file that pulls in a separate file as a submodule, where // that separate file has many multi-byte characters, to try to // encourage the compiler to trip on them. mod issue24687_mbcs_in_comments; pub use issue24687_mbcs_in_comments::D; </ins>

Discussion:
I’m getting an ICE when compiling using
I was able to trace down the bug. It is due to me using a unicode character in the documentation of a function this somehow triggers the compiler bug. A minimal example is:
I believe Servo is also currently hitting this in the script crate during our current rust upgrade.
Yes, at least the failing assertion is the same. Removing non-ASCII characters from doc comments didn’t seem to help, though.
cc might this be another overflow error?
recommended on IRC to build with , but log output seems to be disabled in Nightly. So I built Rust with debugging enabled and tried again. (This took forever because of .) There was a lot of output, here is just the end of it:
This is lines / 299MB of output.
my current hypothesis is that this is the problem; it is at the very least very suspicious considering that five lines up in the previous statement we are normalizing the position to zero by subtracting the , not adding it.
(other good news: I have figured out how to make a regression test for this that will integrate into the rust test suite.)
Change:
let llval = get_dataptr(bcx, v0); let llbox = Load(bcx, llval); let bcx = drop_ty(bcx, v0, content_ty, DebugLoc::None); <ins> // FIXME(#36457) -- we should pass unsized values to drop glue as two arguments </ins> let info = get_meta(bcx, v0); let info = Load(bcx, info); let (llsize, llalign) =

Discussion:
The following successfully typechecks on , but generates an LLVM assertion failure: Error: Note that replacing with (and making mutable) allows compilation to succeed.
First occurs in nightly-2016-08-03 which turns on mir by default, does not occur on nightly-2016-08-03 with -Z orbit=off.
Using this was introduced between and ().
Problem seems to be that we call the with a fat pointer as 2 arguments, but it expects a pointer to a tuple.
I have a fix for this, running the full locally now to see if I broke anything else on the way.
Change:
<ins> #![feature(return_position_impl_trait_in_trait)] pub trait Trait { fn create() -> impl Iterator<Item = u64> { std::iter::empty() } } pub struct Basic; pub struct Intermediate; pub struct Advanced; impl Trait for Basic { // method provided by the trait } impl Trait for Intermediate { fn create() -> std::ops::Range<u64> { // concrete return type 0..1 } } impl Trait for Advanced { fn create() -> impl Iterator<Item = u64> { // opaque return type std::iter::repeat(0) } } // Regression test for issue #113929: pub trait Def { fn def<T>() -> impl Default {} } impl Def for () {} </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. --The command causes an ICE error. This happens when we use the features of () in different workspaces. workspace- : workspace- : <!-- 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 --<!-- TRIAGEBOT_END --
label T-rustdoc
label -needs-triage A-cross-crate-reexports Ah lol, just noticed that we're also leaking the desugared form of RPITITs (the assoc ty) for a slightly altered non-icing version of this code (still cross-crate tho). Also needs to be addressed at some point, taking a mental note. claim
Change:
<ins> // run-rustfix fn foo(x: &str) -> bool { x.starts_with("hi".to_string() + " you") //~^ ERROR expected a `FnMut<(char,)>` closure, found `String` } fn foo2(x: &str) -> bool { x.starts_with("hi".to_string()) //~^ ERROR expected a `FnMut<(char,)>` closure, found `String` } fn main() { foo("hi you"); foo2("hi"); } </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 look like: <!-- 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 --
claim
The code here: Seems we can only get more context from , with only we can not know whether the current code snippet is an ident or a more complicated expression. The current is . An completed solution should make sure we get something like in ? A hack I'm thinking is checking whether contains spaces, if so we suggest it like:
I guess we have more similar issues for other suggestions come from .
This is an similar case, but we handle it well: Output is: The codepath is different, we take care parenthesis here, with :
Change:
err.span_label(item_sp, "this is not `async`"); } err.emit(); <del> return hir::ExprKind::Err; </del> } } let span = self.mark_span_with_reason(

Discussion:
Hi I'm pretty new to rust and programming in general. I was trying (failing) to write some toy async code and I got this internal compiler error, the theme seems to be always report ICEs so here we go This was from cargo: ~ The code I was trying was this code: ~ <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Minimized:
ICEs with any statement between while inside a function that isn't async ICE Error without and without the ICE statement inside async function
claim
This is actually the same as . I think I've got a fix for both.
do you have a PR for this open?
Closing as a duplicate of , both of which are fixed by

<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Not had a lot of time to look at this unfortunately and it appears has come up with a fix in in the meantime. release-assignment
claim
assign (Sorry for the noise, testing a new GH feature)
Change:
self.suggest_trait_fn_ty_for_impl_fn_infer(hir_id, Some(i)) { infer_replacements.push((a.span, suggested_ty.to_string())); <del> return suggested_ty; </del> <ins> return Ty::new_error_with_message( self.tcx(), a.span, suggested_ty.to_string(), ); </ins> } }

Discussion:
<!-- [31mICE[0m: Rustc '-Zincremental-verify-ich=yes -Cincremental=<dir-Cdebuginfo=2' 'error: internal compiler error: unexpected region encountered in variance inference: ReLateParam(DefId(0:22 ~ 4CE26EEF2326F71D6A2A2B20D320CA8739959CBFE29E1EDC8A012C82A71A1C39[9323]::{impl}::deserialize), BrNamed(DefId(0:27 ~ 4CE26EEF2326F71D6A2A2B20D320CA8739959CBFE29E1EDC8A012C82A71A1C39[9323]::Deserialize::deserialize::'), '))', 'error: internal compiler error: unexpected region encountered in variance inference: ReLateParam(DefId(0:22 ~ 4CE26EEF2326F71D6A2A2B20D320CA8739959CBFE29E1EDC8A012C82A71A1C39[9323]::{impl}::deserialize), BrNamed(DefId(0:27 ~ 4CE26EEF2326F71D6A2A2B20D320CA8739959CBFE29E1EDC8A012C82A71A1C39[9323]::Deserialize::deserialize::'), '))' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: note: compiler flags: -Z incremental-verify-ich=yes -C incremental=[REDACTED] -C debuginfo=2 [cratevariances] computing the variances for items in this crate [variancesof] computing the variances of [checkwellformed] checking that is well-formed [checkmodtype_wf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --
cc
Minimized:
Change:
fn is_unit(this: TyAndLayout<'tcx>) -> bool { matches!(this.ty.kind(), ty::Tuple(list) if list.len() == 0) } <ins> fn is_transparent(this: TyAndLayout<'tcx>) -> bool { matches!(this.ty.kind(), ty::Adt(def, _) if def.repr().transparent()) } </ins> } /// Calculates whether a function's ABI can unwind or not.

Discussion:
The types and do not have the same ABI, as demonstrated by this testcase: The first is The second is Not sure whom to ping for RISC-V issues.
I think the fix will have to be to treat repr(transparent) unions specially somewhere around here
Cc
I'm afraid that the semantics of on unions are not clearly defined enough to figure out exactly how they should be specially treated (which variant should be used? etc.). Can you ping other people who have more knowledge on this? (If on unions turns out to be incompatible with ABIs that have content destructuring semantics that depends on the types of the field in the (e.g. the RISC-V C psABI) then we definitely have a bigger problem.)
I have no idea who would know anything about RISC-V calling conventions. :shrug: and no other ABI is failing this test. Basically, when the ABI description says "unions do X", then this should only apply to repr(C) and repr(Rust) unions. A repr(transparent) union must be treated exactly like its non-ZST field.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
I haven't seen the Rust representation before - is the example saying that is splitting the values into float and integer registers and passing them, whereas is treating the whole thing as an bigger opaque integer? If so then based on section 18.2 here, I think the first one would be correct, assuming Rust doesn't ever make its tuples opaque helped me with something RISC-V at some point so may know where to look. Or deferring to clang
I honestly don't know what that means, it is sadly mostly undocumented. But I know it must be the same for the types to be ABI-compatible. has been opened to fix this issue.
now that this is fixed, is there a CI test to catch regressions?
There is a test in  but we don't run tests for riscv, since it's a tier 2 target.
Also see for another ABI issue that affects riscv (and more).
Are tier 2 tests run once before release or anything like that? It seems like at least a subset of tests (this one) are important enough that we should raise a red flag if we brake them somehow on any targets.

But that doesn't fit well into the tiering structure...
I'm not aware of any process like that. Part of the point of being tier 2 is not to burden all contributors with keeping the target working, is it? If we do want to accept that burden, we could consider running something like for tier 2 targets. But having this discussion in a closed issue makes little sense. Do you want to open a new issue or Zulip thread for discussing tier 2 target test coverage?
Inspired by I found a way to have a test for this:
Awesome! Thanks for the update here
Change:
<ins> // compile-flags: -O #![crate_type = "lib"] use std::mem::MaybeUninit; // Boxing a `MaybeUninit` value should not copy junk from the stack #[no_mangle] pub fn box_uninitialized() -> Box<MaybeUninit<usize>> { // CHECK-LABEL: @box_uninitialized // CHECK-NOT: store // CHECK-NOT: alloca // CHECK-NOT: memcpy // CHECK-NOT: memset Box::new(MaybeUninit::uninit()) } // https://github.com/rust-lang/rust/issues/58201 #[no_mangle] pub fn box_uninitialized2() -> Box<MaybeUninit<[usize; 1024 * 1024]>> { // CHECK-LABEL: @box_uninitialized2 // CHECK-NOT: store // CHECK-NOT: alloca // CHECK-NOT: memcpy // CHECK-NOT: memset Box::new(MaybeUninit::uninit()) } #[repr(align(1024))] pub struct LotsaPadding(usize); // Boxing a value with padding should not copy junk from the stack #[no_mangle] pub fn box_lotsa_padding() -> Box<LotsaPadding> { // CHECK-LABEL: @box_lotsa_padding // CHECK-NOT: alloca // CHECK-NOT: getelementptr // CHECK-NOT: memcpy // CHECK-NOT: memset Box::new(LotsaPadding(42)) } // Hide the `allocalign` attribute in the declaration of __rust_alloc // from the CHECK-NOT above, and also verify the attributes got set reasonably. // CHECK: declare {{(dso_local )?}}noalias noundef ptr @__rust_alloc(i{{[0-9]+}} noundef, i{{[0-9]+}} allocalign noundef) unnamed_addr [[RUST_ALLOC_ATTRS:#[0-9]+]] // CHECK-DAG: attributes [[RUST_ALLOC_ATTRS]] = { {{.*}} allockind("alloc,uninitialized,aligned") allocsize(0) {{(uwtable )?}}"alloc-family"="__rust_alloc" {{.*}} } </ins>

Discussion:
See the following extreme test-case: This is what godbolt says rust stable does with it with -O: That is, it allocates 1024 bytes (expected), writes directly at the allocated location, and then proceeds to copy 1016 (uninitialized) bytes from the stack.
Similar to , but not quite the same issue.
Looks resolved around 1.52
label: +E-needs-test -A-LLVM (~ already has the optimization and as I understand that hasn't been touched by LLVM's optimizer yet. So it isn't LLVM-specific, right?~)
Change:
&& generator_did.is_local() // Try to avoid cycles. && !generator_within_in_progress_typeck <ins> && let Some(generator_info) = self.tcx.mir_generator_witnesses(generator_did) </ins> { <del> let generator_info = &self.tcx.mir_generator_witnesses(generator_did); </del> debug!(?generator_info); 'find_source: for (variant, source_info) in generator_info.variant_fields.iter().zip(&generator_info.variant_source_info) {

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
regression in cc
Hmm, I guess that before this function just received broken MIR and carried on, but exited due to the HIR errors without trying to dump it. Now that we return an error body for broken code we're getting a panic