jiebi/CodeConvo huggingface dataset:
Change:
<ins> // Emit additional suggestion to correct the trait implementation // on a pointer use std::{fmt, marker}; struct LocalType; impl fmt::Display for *mut LocalType { //~^ ERROR only traits defined in the current crate can be implemented for arbitrary types //~| NOTE impl doesn't use only types from inside the current crate //~| NOTE `*mut LocalType` is not defined in the current crate because raw pointers are always foreign //~| NOTE define and implement a trait or new type instead //~| HELP consider introducing a new wrapper type fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { write!(f, "This not compile") } } impl<T> marker::Copy for *mut T { //~^ ERROR only traits defined in the current crate can be implemented for arbitrary types //~| NOTE impl doesn't use only types from inside the current crate //~| NOTE `*mut T` is not defined in the current crate because raw pointers are always foreign //~| NOTE define and implement a trait or new type instead } 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 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 --
This could use some work, too, I think. Maybe "impl mentions type from outside the current crate" might be a sufficient replacement, though we should probably make sure that wording is compatible with current coherence rules. Though, in this case, for a non- self type like , we could then replace that^ message with something even more specific. I'm a bit skeptical of mentioning "try implementing on " when we have , since implementing something for and can have very different meanings depending on the signatures inside the trait.
Let's improve this case! claim
This was actually closer to my original error I got, it uses a type alias to create some extra confusion:
Amazing example :) thanks, I'm on it
This is a reproducible example without serde!
Change:
let path = @{span: span, global: false, idents: ~[nm], rp: None, types: ~[]}; @{id: self.next_id(), <del> node: ast::pat_ident(ast::bind_by_implicit_ref, </del> <ins> node: ast::pat_ident(ast::bind_by_ref(ast::m_imm), </ins> path, None), span: span}

Discussion:
cc Maybe related to
Also affects eclectica-0.0.9 cc
Also igo-0.2.1 cc
Also isbfc-0.0.1 cc
Also cargo-update-0.8.0 () cc
Also cc
Rust commit: (looks like bug isn't here) Cargo commit: , which seems correct. is the stable/nightly issue, is the PR updating cargo submodule to fix this, which probably needs to be backported to beta. I'm uncertain, though.
cc sorry to tag you in again, but if you could help take a look at this that'd be great! If not no worries!
Hi this definitely looks related to my changes in cargo. I've investigated and this crate defines two bins ( and ). I suppose they were intended to be aliases and this was possible because of a original "bug" in cargo (falling back to ). I have mixed feelings about this. I would say that cargo should fail here instead of falling back to , but I suppose we cannot do that because of backwards compatibility. Right? fails because it defines bin targets inside directly, instead of . Seems easy and I'll try to fix this today in the evening. Could you please provide me with the cargo's output for the other crates (especially )? That would be great.
Ah yeah for now our priority is to stem the breakage, and afterwards we can evaluate warnings cycles/etc to push further towards the desired behavior here. Thanks for investigating this
I think I have fixed this, just need one more day to do some more testing and I should open a pull request tomorrow.
Added a proposed fix.
Ah we should actually leave this open to track the inclusion into beta, I'll close when all the backports are done.
Ok I've , updated our and updated our , this'll get closed when those start merging. Thanks again for fixing this
Ok, I think everything's landed here
Change:
+ +     bb6: { +         _1 = CoroutineState::<i32, bool>::Yielded(move _8); <ins> +         StorageDead(_8); </ins> +         discriminant((*_6)) = 3; +         goto -> bb2; +     }

Discussion:
Reproduces with on commit Remove and add to get a lot of ICEs like this:
So, looks like we should either allow StorageLive on an already live local, or we need to ensure that all locals are explicitly marked StorageDead before returning. No idea how realistic it is to achieve the latter. Cc
Change:
args_span, } }); <ins> self.add_note_for_packed_struct_derive(err, original_path.local); </ins> } } }

Discussion:
The following code causes a compilation error. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is intended, it is an attempt to make derives and work in more cases. The derive cannot know whether the field is copy. It cannot take a reference to the field, since it's not aligned. So it tries to copy, which at least works for types.
Should, or can this be fixed?
It cannot. repr(packed) sucks.
Atleast, we should modify the error message to make it clearer? Something like error[E0507]: cannot move out of which is behind a shared reference -- | 3 | #[derive(Debug)] | ----- in this derive macro expansion 4 | struct B(String); | ^^^^^^ move occurs because has type , which does not implement the trait | = note: this error originates in the derive macro (in Nightly builds, run with -Z macro-backtrace for more info) = note: this struct is marked as , but unaligned field references are undefined behaviour. For more information about this error, try .
that's possible.
claim
I'll let others implement the diagnostic message.
Change:
<ins> // test for #113326 #![feature(type_alias_impl_trait)] pub type Diff = impl Fn(usize) -> usize; pub fn lift() -> Diff { |_: usize |loop {} } pub fn add( n: Diff, m: Diff, ) -> Diff { move |x: usize| m(n(x)) //~ ERROR: concrete type differs } fn main() {} </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
Can be reduced to
Also causes the out of bounds panic (), but not the earlier type mismatch ICE
Triage: Fixed on the latest nightly, marked as E-needs-test labels: +E-needs-test
Change:
}; match self.r.resolve_path( &segments, <del> Some(TypeNS), </del> <ins> None, </ins> parent_scope, finalize.then(|| Finalize::new(id, path.span)), None,

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
glacier ""
searched nightlies: from nightly-2022-10-05 to nightly-2023-03-16 regressed nightly: nightly-2022-10-12 searched commit range: regressed commit:
Newer version of cargo-bisect-rustc can bisect through rollups
The one that is not released yet? :smile: Thx, will install git then.. :)
label +S-bug-has-mcve
Change:
// revisions: x86_64_wrs_vxworks // [x86_64_wrs_vxworks] compile-flags: --target x86_64-wrs-vxworks // [x86_64_wrs_vxworks] needs-llvm-components: x86 <del> // revisions: x86_64h_apple_darwin // [x86_64h_apple_darwin] compile-flags: --target x86_64h-apple-darwin // [x86_64h_apple_darwin] needs-llvm-components: x86 </del> // Sanity-check that each target can produce assembly code.

Discussion:
Right now I have to run with applied, but when I do several tests fail, eg: tests/assembly/targets/targets- more are visible in
I think this test should check for instead of . I believe that currently this test is actually matching something like , which is not emitted on Solaris since I assume the intention was to look for , but that's one of the section types for which an explicit is normally omitted.
Okay, just looking for doesn't work, because apparently targets-elf, despite the name, currently also includes the MachO targets.
Change:
<del> // 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()) } // 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" {{.*}} } </del>

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:
let mut bytes = Lrc::new_uninit_slice(len as usize); let mut buf = BorrowedBuf::from(Lrc::get_mut(&mut bytes).unwrap()); <del> file.read_buf_exact(buf.unfilled())?; </del> <ins> match file.read_buf_exact(buf.unfilled()) { Ok(()) => {} Err(e) if e.kind() == io::ErrorKind::UnexpectedEof => { drop(bytes); return fs::read(path).map(Vec::into); } Err(e) => return Err(e), } </ins> // SAFETY: If the read_buf_exact call returns Ok(()), then we have // read len bytes and initialized the buffer. <del> Ok(unsafe { bytes.assume_init() }) </del> <ins> let bytes = unsafe { bytes.assume_init() }; // At this point, we've read all the bytes that filesystem metadata reported exist. // But we are not guaranteed to be at the end of the file, because we did not attempt to do // a read with a non-zero-sized buffer and get Ok(0). // So we do small read to a fixed-size buffer. If the read returns no bytes then we're // already done, and we just return the Lrc we built above. // If the read returns bytes however, we just fall back to reading into a Vec then turning // that into an Lrc, losing our nice peak memory behavior. This fallback code path should // be rarely exercised. let mut probe = [0u8; 32]; let n = loop { match file.read(&mut probe) { Ok(0) => return Ok(bytes), Err(e) if e.kind() == io::ErrorKind::Interrupted => continue, Err(e) => return Err(e), Ok(n) => break n, } }; let mut bytes: Vec<u8> = bytes.iter().copied().chain(probe[..n].iter().copied()).collect(); file.read_to_end(&mut bytes)?; Ok(bytes.into()) </ins> } }

Discussion:
In this diff is subtly broken: because it trusts that the size of the file returned by is trustworthy, and it does not need to be. The correct implementation is to call until EOF is reached. This can be observed by trying to (just be sure to use the resultant ).
WG-prioritization assigning priority (). label -I-prioritize +P-high
Change:
<ins> error[E0017]: references in constants may only refer to immutable values --> $DIR/issue-65394.rs:8:13 | LL |     let r = &mut x; |             ^^^^^^ constants require immutable values [ERROR rustc_mir::transform::qualify_consts] old validator: [($DIR/issue-65394.rs:8:13: 8:19, "MutBorrow(Mut { allow_two_phase_borrow: false })")] [ERROR rustc_mir::transform::qualify_consts] new validator: [($DIR/issue-65394.rs:8:13: 8:19, "MutBorrow(Mut { allow_two_phase_borrow: false })"), ($DIR/issue-65394.rs:7:9: 7:14, "LiveDrop")] error: aborting due to previous error For more information about this error, try `rustc --explain E0017`. </ins>

Discussion:
Offending snippet using : The code shouldn't build, as per the first few errors below, but currently on nightly it also causes the compiler to panic. It does not panic on stable or beta. Version: 1.40.0-nightly (2019-10-12 ) Playground: Quite possibly a duplicate of just buried inside the macro expansion but I'm not familiar enough with Rust compiler internals to make that determination.
cc
I've to the following: A mutable reference is required in all variants of this, so this particular mismatch does not represent a true backwards compatibility hazard: Creating a reference that would allow mutation is forbidden in all contexts. We could simply stop triggering the mismatch ICE when both lists contain the same error. The underlying issue, however, is that is being too conservative once again. As soon as a mutable reference is taken to , we use type-based qualification instead of looking at the qualif which gets cleared when is moved from. Increasing the precision here would require a dataflow analysis. This would get checked first whenever was queried (much like how we currently check first). I believe this will be necessary when we do allow in contexts, otherwise writing code would be quite painful. I could hack together a solution for this particular case that doesn't require another dataflow analysis. Basically, during validation, we could keep track of which s have been moved out of in the current basic block and use that as a conservative approximation of . This would fail if the local was moved from in one basic block and then dropped in a successor of that block. It seems relatively hard to write rust code that gets translated to that MIR, however. For example, the following does not do it, but I think it should be possible.
cc
Checking for moves in the same block fails pretty often. I've implemented the first fix described above, but we probably want to use a analysis in the long term.
triage: P-medium. Assigning to . Removing nomination label.
Change:
debug_assert!(utf16.len() <= c::c_int::MAX as usize); debug_assert!(utf8.len() <= c::c_int::MAX as usize); <ins> if utf16.is_empty() { return Ok(0); } </ins> let result = unsafe { c::WideCharToMultiByte( c::CP_UTF8,              // CodePage

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. --I tried this code: In windows terminal running Git Bash (also occured in Nushell, though I'm not sure if this is terminal or shell-land), I pressed Ctrl-Z + Enter to send EOF. I expected to see this happen: The application would gracefully exit the loop Instead, this happened: I saw this error message: <!-- 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<summaryBacktrace</summary<p</p</details
The underlying regression here is that the way we call does not accept zero length strings. And we're calling in a way that makes ctrl-z immediately return without reading anything after it. This is important because a zero length read is how we signal to stdlib that an eof has occurred (so ctrl-z handling is pretty indirect). The fix is simple, if anyone wants to claim this issue. needs to check for zero length input and immediately return in that case.
Seems like a good first issue, I can take a stab at it.
That would be great!
Where would be a good place to write a test for this?
Hm, this is a Windows specific issue so it should probably stay close to the affected code. Take a look at how for tests and do something similar for stdio.
Never mind, I see how things are glued together.
It's a sub module so it should be able to access the private functions of its parent (aka ) module. This is noted in the :
For sure, just misread the directory structure.
Change:
let Coverage { kind } = coverage; match *kind { <del> // Span markers are only meaningful during MIR instrumentation, // and have no effect during codegen. CoverageKind::SpanMarker => {} </del> <ins> CoverageKind::SpanMarker => unreachable!( "unexpected marker statement {kind:?} should have caused an early return" ), </ins> CoverageKind::CounterIncrement { id } => { func_coverage.mark_counter_id_seen(id); // We need to explicitly drop the `RefMut` before calling into `instrprof_increment`,

Discussion:
The immediate symptoms of were fixed by , but some users reported that their builds now encounter another coverage-related ICE:
label +T-compiler +A-code-coverage
This ICE does not occur on current stable/beta, but does occur on nightly. label +regression-from-stable-to-nightly
(This will be fixed by , which is awaiting review.)
WG-prioritization assigning priority (). label -I-prioritize +P-high
Change:
AddThenBlock(#[primary_span] Span), } <ins> #[derive(Subdiagnostic)] #[help(parse_extra_if_in_let_else)] pub(crate) struct IfExpressionLetSomeSub { #[primary_span] pub if_span: Span, } </ins> #[derive(Diagnostic)] #[diag(parse_if_expression_missing_condition)] pub(crate) struct IfExpressionMissingCondition {

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:
None } }) <del> .map(|res| res.expect_full_res()) </del> <ins> .and_then(|res| res.full_res()) </ins> .filter(|res| { // Permit the types that unambiguously always // result in the same type constructor being used

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
I think this is related to