jiebi/CodeConvo huggingface dataset:
Change:
<ins> error: array lengths can't depend on generic parameters --> $DIR/issue-67739.rs:12:15 | LL |         [0u8; mem::size_of::<Self::Associated>()]; |               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error </ins>

Discussion:
: <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'd like to work on this. claim
Now ICE no longer occurs, I think it's fixed by . Marked as E-needstest.

When executed in the : <details<summaryCompiler output</summary</detailsEDIT: Here's the updated and the new stack trace as of Jan 7, 2020: <details<summaryCompiler output</summary</details
cc
I think this is another instance of However, we can leave this issue open to remember to add a test case when it's fixed.
The original issue no longer ICEs and instead errors with: which is essentially correct. However, providing the type annotations produces a new ICE:
In Source: <details<summaryStack trace</summary<p</p</details
Now ICE no longer occurs. I think it's fixed by .

This occurs on 1.34.1 and 1.34.0, is a regression from 1.33.0, and does.. not occur on nightly? Reproduction: compiled with Yields: I found this in building crates like and but pared it down to this
I think this is fixed in which might explain why it doesn't occur on nightly
triage: Probably fixed by . Normally an ICE would lead me to tag this as P-high, but the fact that this is only exposed by leads me to prioritize this as P-medium.
assigning to self to confirm that is the reason this is fixed, and (if need be) add a regression test.
Here's a slightly smaller case of what appears to potentially be the same thing which shows up if you select the "show MIR" option in In particular the following error is observed:
I think this issue is fixed in all channels. I tried stable and nightly both locally and on , and couldn't get any ICEs. Should we add a test? Otherwise we can just close I think.
Adding a test with seems like a good idea.

Compiler crash when using cfgif and defining a macro with macrorules twice. I tried this code: In a repo: I expected to see this happen: error: a macro named has already been exported Instead, this happened: error: internal compiler error: unexpected panic : Backtrace:
Regression from stable to stable (works in 1.30). Reduced test case:
mode is implemented on best effort basis, generally unsupported and will be removed in some time.
Ah, I see, the original issue doesn't have it. I'll investigate.
Reproducer in no longer ICEs.
Change:
<ins> error: array lengths can't depend on generic parameters --> $DIR/issue-67739.rs:12:15 | LL |         [0u8; mem::size_of::<Self::Associated>()]; |               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error </ins>

Discussion:
results in: Removing the constgenerics feature flag gets the expected error message: (IIUC that itself is a bug related to ) Using directly outside of a const-context works, which I guess is something const_generics enables that isn't otherwise allowed. Finally, the error message is the same whether or not the code is in a provided method or a impl block; I actually ran into the bug in the later.
I believe this should be fixed by
Now, it shows different ICE(s) ():
Now ICE no longer occurs. I think it's fixed by .
Change:
/// * `Offset` has the same semantics as [`offset`](pointer::offset), except that the second ///   parameter may be a `usize` as well. /// * The comparison operations accept `bool`s, `char`s, signed or unsigned integers, floats, <del> ///   raw pointers, or function pointers of matching types and return a `bool`. </del> <ins> ///   raw pointers, or function pointers and return a `bool`. The types of the operands must be ///   matching, up to the usual caveat of the lifetimes in function pointers. </ins> /// * Left and right shift operations accept signed or unsigned integers not necessarily of the ///   same type and return a value of the same type as their LHS. Like in Rust, the RHS is ///   truncated as needed.

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. --code from glacier / <!-- 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
another case 
Probably caused by cc
Oops. That's my b, I'll have a PR up in 10 minutes
Change:
add_constraints(&infcx, region_bound_pairs); <ins> infcx.process_registered_region_obligations( outlives_environment.region_bound_pairs(), param_env, ); </ins> let errors = infcx.resolve_regions(&outlives_environment); debug!(?errors, "errors");

Discussion:
: Fails on nightly 1.66.0 but not on stable 1.64.0. <details<summary<strongBacktrace</strong</summary<p</p</detailsEdited: minified the code
Also ICEs on beta
stable error -beta ICE I tried moving things around so lifetime is on , but that's fine. This also requires the lifetime .
Going to preemptively assign P-medium, since this code isn't correct anyways. I think this has something to do with our error recovery here, since this valid code is fine, which only changes the trait:
I got a fix here.
Change:
<ins> // Copyright 2017 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. // compile-flags: -Z span_free_formats // Tests that MIR inliner works for any operand fn main() { println!("{}", bar()); } #[inline(always)] fn foo(x: i32, y: i32) -> bool { x == y } fn bar() -> bool { let f = foo; f(1, -1) } // END RUST SOURCE // START rustc.bar.Inline.after.mir // ... // bb0: { //     ... //     _0 = Eq(move _3, move _4); //     ... //     return; // } // ... // END rustc.bar.Inline.after.mir </ins>

Discussion:
This code: should not pattern-match on , but rather call its method to get its type. What this means is that should inline as well as (but today it doesn't). cc
Actually it should handle both cases, I think. Handling the constant is useful when the type has been erased but constant propagation managed to propagate the actual function anyway.
It's type-based today, but it only handles the case. While handling function pointer types based on the value would be interesting, it's not done today.
Working on this one :)
Change:
<ins> error[E0271]: type mismatch resolving `<[generator@$DIR/issue-94429.rs:16:9: 18:10] as Generator>::Yield == ()` --> $DIR/issue-94429.rs:16:9 | LL | /         move || { LL | |             yield 1; LL | |         } | |_________^ expected integer, found `()` error: aborting due to previous error For more information about this error, try `rustc --explain E0271`. </ins>

Discussion:
Possibly related to as both ICEs arise from , but this ICE occurs on a different line. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
No longer ICEs since

I tried this code: I expected to see this happen: code compiles successfully Instead, this happened: : : modify labels: +requires-nightly +F-typealiasimpl_trait
This is fixed now

I'm writing a simple Generator that takes a reference to an RNG, and yields values from it. This makes sense as long as the generator doesn't outlive the RNG which it references. I want to name the type of the generator with an existential type, but I can't do so unless I wrap a version of the function that uses an formulation. Here's the direct version which doesn't work and here's the more convoluted version which does and here's a playground link containing both versions, as well as a bit of scaffolding The full error message I'm seeing looks like this
I don't know if this properly counts as a compiler bug, but it feels like one because the "fix" is a very mechanical code transformation.
cc
Yea that's definitely a bug. I'll investigate where this unnamed lifetime is coming from. Maybe I'm accidentally erasing lifetimes somewhere
This is fixed in master. A more minimal example that probably still failed previously (needs to be checked) that doesn't depend on or never type:

I assumed that the following code would be legal, as it does not require indefinitely sized types, but apparently somewhere the existential type is revealed too early: () Errors:
Updated version: This still doesn't compile.
Using min-type-alias-impl-trait (), you get an error. I think this is ok, though, as it is we don't support cyclic types like this. I'm going to mark this as E-needs-test.
If we adopted a different model of impl trait, one where they were more "nominal" and hence could be cyclic, that'd be a different thing.
Change:
let directory_prefix = Path::new(Path::new(uncompressed_filename).file_stem().unwrap()); // decompress the file <del> let data = t!(File::open(tarball)); </del> <ins> let data = t!(File::open(tarball), format!("file {} not found", tarball.display())); </ins> let decompressor = XzDecoder::new(BufReader::new(data)); let mut tar = tar::Archive::new(decompressor); <ins> // `compile::Sysroot` needs to know the contents of the `rustc-dev` tarball to avoid adding // it to the sysroot unless it was explicitly requested. But parsing the 100 MB tarball is slow. // Cache the entries when we extract it so we only have to read it once. let mut recorded_entries = if dst.ends_with("ci-rustc") && pattern == "rustc-dev" { Some(BufWriter::new(t!(File::create(dst.join(".rustc-dev-contents"))))) } else { None }; </ins> for member in t!(tar.entries()) { let mut member = t!(member); let original_path = t!(member.path()).into_owned();

Discussion:
cc I tried this: I expected to see this happen: The tests pass. Instead, this happened: The tests fail: These tests are pretty complicated but the error message looks correct: I'm not sure why both files are there and particularly why they have different hashes. shows that is being downloaded from CI, and I guess the is coming from somewhere - maybe we should clear the directory before doing that? <!-- 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. --HEAD is <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Ok, it turns out both versions are coming from CI: I am ... surprised this hasn't broken anything else? I don't know why only this specific test would be failing.
The difference between this test and others is that somehow in other tests knows ahead of time which hash it should use: for the allocator tests, it doesn't know, and gives an ambiguity error:
ok, here's a minimal reproducer: I think what's going on is for the working tests, the implicit injected by the compiler also loads libc, because std depends on libc: Then, when the compiler sees , it's already seen the version depends on and resolves the ambiguity by reusing that crate. But for the failing test, we never load std, so we don't have a pre-existing hash to default to, so it gives a hard ambiguity error.
Change:
parse_invalid_expression_in_let_else = a `{$operator}` expression cannot be directly assigned in `let...else` parse_invalid_curly_in_let_else = right curly brace `{"}"}` before `else` in a `let...else` statement not allowed <ins> parse_extra_if_in_let_else = remove the `if` if you meant to write a `let...else` statement </ins> parse_compound_assignment_expression_in_let = can't reassign to an uninitialized variable .suggestion = initialize the variable

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 removing the additional keyword in front of the . This mistake can occur due to muscle memory as , , and in the future are somewhat similar syntactically. Thanks. label +D-confusing +F-let-else <!-- 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 --
I think the current suggestion is valid. Because one writes instead of writing . So the suggestion if changed maybe fall-negative.
We should likely add an alternative suggestion to remove the , but keep both. I think that the current suggestion is likely going to be the more common situation, so it should still come first.
claim
What would be the best way to go about adding an alternate suggestion? I'd like to try my hand at this. What I think needs to be done is adding help text to , add a variant to , and then add something to to add the alternate after the primary suggestion. Is this a good starting point?
it sounds like you are in the right path.
I looked a bit into this issue and have already found where to add text to the and the as mentioned, but i am a bit overwhelmed how and where to start in the in the . Does anyone have a hint for me?
claim
claim
You can add instructions in the parser to track your progress.

I'm not sure about the specifics out of the top of my head here of what type each step in the parse is, but you will have successfully parsed the , the condition and then you'll encounter an token when a body/block was expected. That's where the new recovery should kick in, pointing at the span saying that you might want to remove it.
claim
Change:
ret_ty, Applicability::MachineApplicable, ); <del> } else if matches!(ret_ty.kind(), ty::FnDef(..)) && let Some(fn_sig) = ret_ty.fn_sig(tcx).make_suggestable(tcx, false) { diag.span_suggestion( ty.span, "replace with the correct return type", fn_sig, Applicability::MachineApplicable, ); </del> <ins> should_recover = true; </ins> } else if let Some(sugg) = suggest_impl_trait(tcx, ret_ty, ty.span, def_id) { diag.span_suggestion( ty.span,

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
That second function can be named anything, for the record. e.g.
Change:
<ins> // Regression test for issue #69490 // check-pass pub trait Trait<T> { const S: &'static str; } impl<T> Trait<()> for T where T: for<'a> Trait<&'a ()>, { // Use of `T::S` here caused an ICE const S: &'static str = T::S; } // Some similar cases that didn't ICE: impl<'a, T> Trait<()> for (T,) where T: Trait<&'a ()>, { const S: &'static str = T::S; } impl<T> Trait<()> for [T; 1] where T: Trait<for<'a> fn(&'a ())>, { const S: &'static str = T::S; } fn main() {} </ins>

Discussion:
mullvad-vpn build fails after jnix crate upgrade to v0.2.0 I tried this code: sudo pacman -Russnc mullvad-vpn sudo rm -rf /var/cache/mullvad-vpn/ sudo rm -rf /var/log/mullvad-vpn/ git clone cd mullvad-vpn makepkg -si I expected to see this happen: build completes without errors Instead, this happened: rustc panicks at 'assertion failed: data.isempty()', :
cc
ping icebreakers-cleanup-crew
Currently running
prints: searched nightlies: from nightly-2020-02-11 to nightly-2020-02-18 regressed nightly: nightly-2020-02-16 searched commits: from to regressed commit: source code: modify labels: -E-needs-bisection
modify labels: -E-needs-mcve
triage: P-high. Removing nomination.
I'm also getting this error. : Backtrace:
Change:
"ban_nonexisting_field: field={:?}, base={:?}, expr={:?}, expr_ty={:?}", field, base, expr, expr_t ); <del> let mut err = self.no_such_field_err(field, expr_t); </del> <ins> let mut err = self.no_such_field_err(field, expr_t, base.hir_id); </ins> match *expr_t.peel_refs().kind() { ty::Array(_, len) => {

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:
Array, Tuple, RawPointer, <ins> Reference, </ins> } #[derive(Clone, RustcEncodable, RustcDecodable, Copy, Debug)]

Discussion:
E.g. there's no for or .
cc
What sorts of impls would be expected on this page? Listing impls for every (, , , , ) might be excessive, although of course it's better to err on the side of documenting too much than not enough :-)
It might be, yeah. In principle, there should at least be some kind of page I can put some text on, even if it says "Most of the methods aren't shown on this page because it's too primitive" or something.
At least inherent methods should be listed now.
Triage: no change
Since i just did function pointers (), i'll add this while the details are fresh in mind. What details should go here? ? Using for reborrowing and Deref? Copy/paste details from either edition of the book? Leave it as a skeleton and fill it out later? As for what impls to include, my initial thought was to only include impls where it's a reference to a generic. Otherwise it'll show up on the referent's page, like it is now.
Change:
|         ^^^^^^^^^^^^^ | = note: ...which again requires processing `X::A::{{constant}}#0`, completing the cycle <del> note: cycle used when const-evaluating `X::A::{{constant}}#0` </del> <ins> note: cycle used when processing `X::A::{{constant}}#0` </ins> --> $DIR/issue-23302-1.rs:4:9 | LL |     A = X::A as isize,

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:
<ins> error: unused variable: `theOtherTwo` --> $DIR/issue-24690.rs:20:9 | 20 |     let theOtherTwo = 2; |         ^^^^^^^^^^^ | note: lint level defined here --> $DIR/issue-24690.rs:16:9 | 16 | #![deny(warnings)] |         ^^^^^^^^ error: variable `theTwo` should have a snake case name such as `the_two` --> $DIR/issue-24690.rs:19:9 | 19 |     let theTwo = 2; |         ^^^^^^ | note: lint level defined here --> $DIR/issue-24690.rs:16:9 | 16 | #![deny(warnings)] |         ^^^^^^^^ error: variable `theOtherTwo` should have a snake case name such as `the_other_two` --> $DIR/issue-24690.rs:20:9 | 20 |     let theOtherTwo = 2; |         ^^^^^^^^^^^ error: aborting due to 3 previous errors </ins>

Discussion:
Example: Adding to a crate will point out the location of this line for every time the lint fires (). This should be listed only once. It should be reasonably easy to deduplicate these based upon equal span and message.
I think this is a good "E-easy" candidate. Relevant code is in . Using a as a field on should work, so that we only emit a note the first time we encounter it.
Question -- in , we get only "lint level defined here" per , even if it applies to multiple lints (e.g., ). Do people think it'd be better to have it like this, or would you rather see different messages for (say) and , even if they both apply to the same ?
Can someone with perms close this? I forgot to use the in .
Great! Fixed in
Change:
<ins> //@ edition: 2021 #![feature(async_closure, noop_waker)] use std::future::Future; use std::pin::pin; use std::task::*; pub fn block_on<T>(fut: impl Future<Output = T>) -> T { let mut fut = pin!(fut); // Poll loop, just to test the future... let ctx = &mut Context::from_waker(Waker::noop()); loop { match unsafe { fut.as_mut().poll(ctx) } { Poll::Pending => {} Poll::Ready(t) => break t, } } } </ins>

Discussion:
Importantly note that the closure passed to foo is ; does not ICE. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Regression in ()
Change:
<ins> // Copyright 2014 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. #[path="foo foo.rs"] pub mod foo; pub mod bar; </ins>

Discussion:
and maybe other characters as well? I'm not actually entirely sure what syntax should be used, but I imagine that gcc knows!
Change:
<ins> error: `?Trait` is not permitted in trait object types --> $DIR/issue-72267.rs:4:21 | LL |     let _: Box<(dyn ?Sized)>; |                     ^^^^^^ error[E0224]: at least one trait is required for an object type --> $DIR/issue-72267.rs:4:17 | LL |     let _: Box<(dyn ?Sized)>; |                 ^^^^^^^^^^ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0224`. </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. --reduced 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</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc although I think they might've already seen this?
claim