jiebi/CodeConvo huggingface dataset:
Change:
let bound_vars = self.tcx.late_bound_vars(fn_id); let ty = self.tcx.erase_late_bound_regions(Binder::bind_with_vars(ty, bound_vars)); let ty = self.normalize_associated_types_in(expr.span, ty); <ins> let ty = match self.tcx.asyncness(fn_id.owner) { hir::IsAsync::Async => self.tcx.infer_ctxt().enter(|infcx| { infcx.get_impl_future_output_ty(ty).unwrap_or_else(|| { span_bug!( fn_decl.output.span(), "failed to get output type of async function" ) }) }), hir::IsAsync::NotAsync => ty, }; </ins> if self.can_coerce(found, ty) { err.multipart_suggestion( "you might have meant to return this value",

Discussion:
Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like it does for the : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +A-async-await +D-papercut
I'm gonna try and take a shot at this. claim
Thanks for putting up a PR so quickly, label +AsyncAwait-Triaged +AsyncAwait-Polish
Change:
#![feature(proc_macro_internals)] #![feature(proc_macro_span)] #![feature(try_blocks)] <del> #![recursion_limit = "256"] </del> #[macro_use] extern crate rustc_macros;

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. --Context: "regression" caught by future-proofing CI from After working on reducing the code, I've identified the root cause of the ICE. For context: this patterns stem from "old" Rust code wanting to support proc-macros emitting item definitions in "statement" position for Rust: the trick is to use the to wrap an item-defs-emitting proc-macro call inside a function so that Rust doesn't interpret it as a statement, refusing the then-unstable stmt-emitting proc-macro call (). <!-- 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. --: Bonus: the ICE seems to have been introduced in between today's () and yesterday's nightly. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailscc I suspect this is up your alley
searched nightlies: from nightly-2021-08-01 to nightly-2021-08-10 regressed nightly: nightly-2021-08-07 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high +A-macros
Thanks nice job
Change:
/// kept separate because of issue #42760. #[derive(Clone, RustcEncodable, RustcDecodable, PartialEq, Eq, Debug, Hash)] pub enum DocFragment { <del> // FIXME #44229 (misdreavus): sugared and raw doc comments can be brought back together once // hoedown is completely removed from rustdoc. </del> /// A doc fragment created from a `///` or `//!` doc comment. SugaredDoc(usize, syntax_pos::Span, String), /// A doc fragment created from a "raw" `#[doc=""]` attribute.

Discussion:
Given the following source: The span conversion calculation in the error reporting will give the wrong offset when reporting the resolution failure, leading to a confusing report: Strangely enough, putting either the leading or the closing on its own line will cause the report to change to something that looks correct, if a little too broad: I believe the code at fault is this section here: Because it assumes that every doc comment will have a padding of 3 characters (the or ), it includes that in its calculation of each line's offset. However, for block-style comments, this assumption is false.
I'm working on this.
You can also reproduce this with unsugared docs:
Change:
<ins> // edition:2018 use std::future::Future; use std::pin::Pin; use std::task::{Context, Poll}; fn spawn<T: Send>(_: T) {} pub struct AFuture; impl Future for AFuture{ type Output = (); fn poll(mut self: Pin<&mut Self>, _: &mut Context<'_>) -> Poll<()> { unimplemented!() } } async fn foo() { spawn(async { //~ ERROR future cannot be sent between threads safely let _a = std::ptr::null_mut::<()>(); // `*mut ()` is not `Send` AFuture.await; }); } fn main() {} </ins>

Discussion:
I wanted to quickly prototype a bit of code involving tokio and some shared state but ran into a rustc panic: I installed by running rustup update a few hours back. In my code (see below) there seems to be a mistake, having a lock living too long i suppose. The following code leads to the error (based on ) : Unfortunately I could not remove unnecessary parts of the code without making the panic go away. Might this has something to do with detecting the lock lifetimes?
ICE occurs in:
Error before: Regression in cc (I'm on a MCVE)
triage: P-high, removing nomination tag.
Here we go: So takes a type that is , but isn't . That's causing the ICE.
modify labels: -E-needs-mcve
Not sure how to express the for the MCVE here. You can of course use a new struct (like I did before with ), or use a . Interesting this works with as well, but not with other (custom) traits. Maybe because is an ?
Fixed output:
Change:
<ins> // Ensure that coroutine drop glue is valid when mixing different panic // strategies. Regression test for #116953. // // no-prefer-dynamic // build-pass // aux-build:unwind-aux.rs // compile-flags: -Cpanic=abort // needs-unwind extern crate unwind_aux; pub fn main() { unwind_aux::run(String::new()); } </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. -- <p<details</p</details<!-- 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</detailsBuild with
can reproduce
can you include a and (for example as a link to a project (+commit), or right here), to be able to reproduce this in the future?
Sorry, forgot to add those, I've attached them
does needs MCVE mean an example not relying on tokio?
yes
Ran a bisect. searched nightlies: from to regressed nightly: searched commit range: ... regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Spent some unforgettable time chopping down 80k lines of tokio code piece by piece, but it was worth it, I hope. Here's an MCVE: : :
Since this seems to be somehow caused by mir drop tracking, cc
WG-prioritization assigning priority (). label -I-prioritize +P-high
Change:
fn index(self, slice: &str) -> &Self::Output { assert!(self.end != usize::max_value(), "attempted to index str up to maximum usize"); <del> let end = self.end + 1; self.get(slice).unwrap_or_else(|| super::slice_error_fail(slice, 0, end)) </del> <ins> (..self.end+1).index(slice) </ins> } #[inline] fn index_mut(self, slice: &mut str) -> &mut Self::Output { assert!(self.end != usize::max_value(), "attempted to index str up to maximum usize"); <del> if slice.is_char_boundary(self.end) { unsafe { self.get_unchecked_mut(slice) } } else { super::slice_error_fail(slice, 0, self.end + 1) } </del> <ins> (..self.end+1).index_mut(slice) </ins> } }

Discussion:
Caught while fleshing out a much beefier test suite for SliceIndex, which I plan to submit as a PR. (this Issue is here just in case that PR never happens). The unicode character boundary check here should be looking at . Better yet, the method could just delegate to instead. (note: it can't delegate to here without NLL, which seems to be a leading factor as to how this function ended up this way)
Not technically a regression but tagging it as such to ensure that we don't forget about it.
my commit message accidentally closed this, which might defeat the purpose of the tag you (note: I myself can't reopen it because Github attributed the message to Bors)
Oh that's ok, the tags on the PR take over now for backporting and that's how we'll track this.
(ahhhh, now I see. The tag is used in automation for a Github Project to track regressions. That's actually pretty cool!) ('t mind me, just talking to myself)
Change:
<ins> fn main() { let _ = format!(concat!("{0}𝖳𝖾𝗌𝗍{"), i); //~^ ERROR: invalid format string: expected `'}'` but string was terminated //~| NOTE: if you intended to print `{`, you can escape it using `{{` //~| NOTE: in this expansion of concat! //~| NOTE: in this expansion of concat! //~| NOTE: expected `'}'` in format string } </ins>

Discussion:
Reproducer: Playground link: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'd love to take a look at this. Seems to be ICEing in code that displays the diagnostic to fixup the actual compiler error here. claim
Change:
/// /// # Example /// <del> /// The Cell type is an example which uses unsafe code to achieve /// "interior" mutability: </del> <ins> /// The Cell type is an example of an `InvariantType` which uses unsafe /// code to achieve "interior" mutability: </ins> /// /// ``` /// struct Cell<T> { value: T } /// ``` /// <del> /// The type system would infer that `value` is only read here and /// never written, but in fact `Cell` uses unsafe code to achieve /// interior mutability. </del> <ins> /// The type system would infer that `value` is only read here /// and never written, but in fact `Cell` uses unsafe code to achieve /// interior mutability. In order to get correct behavior, the /// `InvariantType` marker must be applied. </ins> #[unstable(feature = "core", reason = "likely to change with new variance strategy")] #[lang="invariant_type"]

Discussion:
It starts talking about cell for some reason. I think this was copy + pasted from InvariantLifetime and never updated.
cc
doesn't have this example (atm), and, the example only makes sense with since there's no lifetimes involved in the definition of the type. I do think the example could probably have a little more description, but I don't think it's wrong. For reference, it currently says: rust /// The Cell type is an example which uses unsafe code to achieve /// "interior" mutability: /// /// /// /// The type system would infer that is only read here and /// never written, but in fact uses unsafe code to achieve /// interior mutability.
Change:
<ins> // Regression test for issue #80233 // Tests that we don't ICE when processing auto traits #![crate_type = "lib"] pub trait Trait1 {} pub trait Trait2 { type Type2; } pub trait Trait3 { type Type3; } impl Trait2 for Struct1 { type Type2 = Struct1; } impl<I: Trait2> Trait2 for Vec<I> { type Type2 = Vec<I::Type2>; } impl<T: Trait1> Trait3 for T { type Type3 = Struct1; } impl<T: Trait3> Trait3 for Vec<T> { type Type3 = Vec<T::Type3>; } pub struct Struct1 {} // @has issue_80233_normalize_auto_trait/struct.Question.html // @has - '//code' 'impl<T> Send for Question<T>' pub struct Question<T: Trait1> { pub ins: <<Vec<T> as Trait3>::Type3 as Trait2>::Type2, } </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. --This bug occurs with . works fine. <!-- 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
might be a duplicate of
I think there are important differences: this code doesn't use feature gates, and it successfully builds, so rustdoc should be expected to succeed instead of erroring or ICE, and the rationale for prioritizing that low (that the input is invalid) doesn't apply.
MCVE (although it panics in a slightly different place):
Oh interesting my MCVE is not correct - that panics because the impls are missing: If I add those impls, suddenly rustdoc works:
In fact there are some programs rustdoc accepts that rustc doesn't:
Slightly smaller repro:
Change:
target_os = "emscripten", target_os = "fuchsia", target_os = "l4re", <ins> target_os = "linux", </ins> target_os = "haiku"))] pub fn set_cloexec(&self) -> io::Result<()> { unsafe {

Discussion:
There are several bugs here, but they all stem from the same problem -- the stdlib doesn't handle correctly in a few places. causes most other flags to be ignored, so requiring a mode is a little bit weird. Really, should probably be handled as another mode. This one can be worked around pretty trivially (though it is a bit silly in my view), but unfortunately that's when you hit the next issue: This doesn't work with because file descriptors have which means that all s on them fail (this is a security feature). Rust proactively sets close-on-exec in many different places, which means that any method that ends up triggering an gives a spurrious . The most obvious problem is with but I'm sure there are plenty of other examples: Rust really should use because s are blocked on all descriptors (while works without issue).
It does: There's a fallback to support older kernels that you're probably running into:
I figured out the reason why was missing -- it's because of a bug in a kernel patch I'm writing (which I'm simultaneously writing a Rust library for). So the fact that the "let's try setting explicitly" path gets tripped is totally my fault. However, I would argue Rust still really shouldn't be using -- because it doesn't work for (or any file with ) while always works. This would just boil down to and removing it from the impl.
I just found another problem this causes -- will fail with on files because doesn't work on file descriptors: The patch to fix this issue is literally just: I can submit a PR for this if that would be acceptable?
Sure
PR is here: .
I still do not see any fix for Should I open an new issue for it?
Yeah, I forgot to write a fix for that. I can open a new issue for that...
Are you kidding me? Yesterday I looked at the function where I needed this again after a year. And today I get a notifications here. Do you want to claim that coincidence exists? SGTM
Change:
--> $DIR/hrtb-just-for-static.rs:24:5 | LL |     want_hrtb::<StaticInt>() <del> |     ^^^^^^^^^^^^^^^^^^^^^^^^ implementation of `Foo` is not general enough </del> <ins> |     ^^^^^^^^^^^^^^^^^^^^^^ implementation of `Foo` is not general enough </ins> | = note: `StaticInt` must implement `Foo<&'0 isize>`, for any lifetime `'0`... = note: ...but it actually implements `Foo<&'static isize>`

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 ( , regressed in the past week) 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. --The desired result can be achieved by swapping the order of the two statements and . <!-- 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 --<!-- TRIAGEBOT_END --
searched nightlies: from nightly-2022-06-07 to nightly-2022-06-08 regressed nightly: nightly-2022-06-08 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details are you working on this? I'll probably be investigating this due to it being related to the recent removal of the borrowck migration mode.
I've been working on it a bit, but please feel free to take over this issue!
This actually looks like a particularly difficult issue. I think it's either a bug in , or something weird with the that is convincing us that the correct source for this region error is through the on line 12 of the example. It may also be notable that we end up going thru a when emitting this error. This issue seems to be out of my area of expertise, so I won't claim it. if you can't find a solution then it may be best to hand off to someone with mir-borrowck expertise.
Actually, what I said was totally wrong.

This is definitely because we're passing in the wrong when . I think I have a fix for this, though I probably want to eliminate other dummy locations we're passing around mir borrowck... cc sorry for all the pings, but don't keep wasting time on this unless you've made significant progress :stuckout_tongue: claim
Change:
<ins> #![feature(generators)] fn main() { yield || for i in 0 { } //~^ ERROR yield expression outside of generator literal //~| ERROR `{integer}` is not an iterator } </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</detailsNOTE: The bug is found by our work-in-progress compiler testing tool Kira, and the test program is reduced/minimized by
Assigning and removing .
This ICEs since modify labels: +regression-from-stable-to-stable
Change:
<ins> // force-host // no-prefer-dynamic #![crate_type = "proc-macro"] extern crate proc_macro; use proc_macro::*; #[proc_macro_derive(same_name, attributes(same_name))] pub fn derive_a(_: TokenStream) -> TokenStream { TokenStream::new() } </ins>

Discussion:
So pointed out to me that some recent changes in name resolution seem to have broken . They pointed me at dealing with the fallout -- maybe you can leave a few notes as to what errors you were seeing before this commit? cc -- could this be the recent changes around name resolution of helper attributes in macros? It seems the relevant code is stuff like:
(Nominated for discussion around the breakage policy/implications here.)
Duplicate of , I'll prepare a fix.
fix Or rather a "tiebreaker" for the ambiguity, since both names are indeed in scope and create ambiguity, which is correctly detected after .
Fixed in

This is a dependency of . I was trying to compile ; it failed on both the master branch and the current published version. is ambiguous (derive helper attribute vs any other name) Indeed, the code does seem to treat as simultaneously a derive macro and an attribute macro. It works fine on stable.
Example of failing builds:
modify labels: +E-needs-bisection It'd be nice if somebody pinpointed specific PR (or nightly at least). Maybe has a clue what could have caused it.
Seems to be introduced at nightly-2019-11-17. Unfortunately I'm not able to bisect that further because cargo-bisect-rustc is telling me:
Likely
This is a consequence of , I'll provide a ASAP.
Fixed in
Change:
<ins> error[E0308]: mismatched types --> $DIR/dont-suggest-path-names.rs:7:31 | LL | fn select<F, I>(filter: F) -> Select<F, I> {} |    ------                     ^^^^^^^^^^^^ expected `Select<F, I>`, found `()` |    | |    implicitly returns `()` as its body has no tail or `return` expression | = note: expected struct `Select<F, I>` found unit type `()` error[E0282]: type annotations needed --> $DIR/dont-suggest-path-names.rs:11:23 | LL |     let lit = select(|x| match x { |                       ^        - type must be known at this point | help: consider giving this closure parameter an explicit type | LL |     let lit = select(|x: /* Type */| match x { |                        ++++++++++++ error: aborting due to 2 previous errors Some errors have detailed explanations: E0282, E0308. For more information about an error, try `rustc --explain E0282`. </ins>

Discussion:
No response This error is very confusing and unreadable, and the compiler even proposes adding a type containing a local path into the code. That seems very problematic and incorrect. No response No response
Try updating your nightly compiler and checking if it's still like that? You're using a nightly compiler from January.
To second compiler-errors' comment, I know that there was a change in this suggestion sometime in the past month. Edit: nevermind
Output with the PR linked above: We still need a minimal repro to add a test to the test suite.
Needs test.
Minimized reproduction in 1.77 nightly
Change:
fn register_reused_dep_path_hash(&self, hash: DefPathHash) { if let Some(cache) = self.queries.on_disk_cache.as_ref() { <del> cache.register_reused_dep_path_hash(hash) </del> <ins> cache.register_reused_dep_path_hash(*self, hash) </ins> } }

Discussion:
This seems to be an incremental error‽ We need an external crate for this to work. Haven't managed it to work in an internal mod only :/ Also this only happens with . Haven't managed to get it running with sadly extern crate (let's call it f) code Then just remove and add afterwards again (or the other way round, it doesn't matter). This script does it for you: <!-- 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<pand with RUST_BACKTRACE=full the LLVMing assert vanishes </p</details
searched nightlies: from nightly-2020-12-08 to nightly-2020-12-10 regressed nightly: nightly-2020-12-10 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailscc
Assigning as discussed as part of the and removing .
I've fixed the issue locally, and I'm working on a PR.
Opened