jiebi/CodeConvo huggingface dataset:
Code change:
let snippet = cx .sess() .source_map() <del> .span_to_snippet(span_of_attrs(attrs)) </del> <ins> .span_to_snippet(span_of_attrs(attrs)?) </ins> .ok()?; let starting_line = markdown[..md_range.start].matches('n').count();

Related discussion:
text: crashes on nightly () and also on stable () with "nightly" features turned on via . It does not trigger on stable without flag. Here is the output I'm getting: I created a small repro case + here: (it only happens when there is a certain combination of procedural macros, so I cannot make it a single file).
The source code is: with crate being a procedural macro crate with:
Couple of things that are important here: only happens with two procedural macros. macro has to do that . attribute has to be , does not reproduce with anything else.
Just a heads-up: AFAIK if a bug only occurs on stable with (I understand that it is not the case here), then it should probably be disregarded, because isn't supposed to be used when not bootstrapping the compiler.
The bug itself reminds me of
it happens on nightly as well. That detail was included to give context that evidently the ICE has been present for longer than 12 weeks, I believe.
With the following patch in the linked repo, the output is not ideal, but preferable to the ICE: I'll take a look to see if we can somehow keep the span for the entire attr doc, or at worst pointing at the correct macro.
Changing the patch to be gives us which makes more sense but is missing a primary span. Edit: I see no way to recover the original span after its has been modified. I guess we already rely on proc macro writers to be nice when it comes to spans, so this is acceptable as well.
Code change:
let pred = trait_ref.without_const().to_predicate(tcx).to_string(); let pred = pred.replace(&impl_trait_str, &type_param_name); let mut sugg = vec![ <ins> // Find the last of the generic parameters contained within the span of // the generics </ins> match generics .params .iter() <del> .filter(|p| match p.kind { hir::GenericParamKind::Type { synthetic: Some(hir::SyntheticTyParamKind::ImplTrait), .. } => false, _ => true, }) .last() </del> <ins> .map(|p| p.bounds_span().unwrap_or(p.span)) .filter(|&span| generics.span.contains(span) && span.desugaring_kind().is_none()) .max_by_key(|span| span.hi()) </ins> { // `fn foo(t: impl Trait)` //        ^ suggest `<T: Trait>` here None => (generics.span, format!("<{}>", type_param)), // `fn foo<A>(t: impl Trait)` //        ^^^ suggest `<A, T: Trait>` here <del> Some(param) => ( param.bounds_span().unwrap_or(param.span).shrink_to_hi(), format!(", {}", type_param), ), </del> <ins> Some(span) => (span.shrink_to_hi(), format!(", {}", type_param)), </ins> }, // `fn foo(t: impl Trait)` //                       ^ suggest `where <T as Trait>::A: Bound`

Related discussion:
text: (Edit: Actually, being an inherent fn doesn't matter. It happens with top-level fns too.) This prints the diagnostic: The suggestion in the last line is not valid syntax (). It also emits malformed syntax if the first parameter is a or parameter. The diagnostic becomes well-formed if any of the following is done: The first parameter is changed to instead ofThe fn is not an async fn. In either case, the diagnostic correctly says: Happens on both nightly: ... and stable:
This should hopefully be a fairly straightforward patch to the diagnostics code that generates the suggestion.
Code change:
<ins> //! Regression test for #74400: Type mismatch in function arguments E0631, E0271 are falsely //! recognized as E0308 mismatched types. use std::convert::identity; fn main() {} fn f<T, S>(data: &[T], key: impl Fn(&T) -> S) { } fn g<T>(data: &[T]) { f(data, identity) //~ ERROR implementation of `FnOnce` is not general } </ins>

Related discussion:
text: Regression from to . The following code yields an incorrect error: On beta, this gives: On nightly, this:
would you be so kind to label this issue? It's sliding down the list while being hard to search.
Regression occurred between nightly-2020-06-23 and nightly-2020-06-24, I suspect is related (it's ?).
It would be great to find the culprit PR. ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
searched nightlies: from nightly-2020-06-23 to nightly-2020-06-24 regressed nightly: nightly-2020-06-24 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.1</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsIf we rule out document changes then we have
Bisection seems to confirm this, cc
With a little more git bisect it seems is the first bad commit And I guess the change to the test case also shows that
Assigning as and removing .
Well, I can certainly imagine how this could come about as a result of the leak-check moving, since the same error can now be detected at a different point during type-checking. What's happening in that confusing error, I imagine, is that we are now winding up with a "universe error" that comes out from region checking. The identity function was inferred to take an argument for some ... Well, in short, I imagine that the solution here is to improve the error reporting for the new point where the error occurs, but it'll take a bit more digging to give good mentoring instructions into how to go about doing that.
This is now a stable regression.
Discussed in T-compiler meeting. Seems related to (or potential duplicate of) ?
On today's nightly, the error is now: That seems correct, and with the extra lifetime, the snippet compiles:
Code change:
LL - fn f2<X: ?Sized, Y: ?Sized>(x: &X) { LL + fn f2<X, Y: ?Sized>(x: &X) { | <ins> help: consider borrowing here | LL |     let y: &X; |            + </ins> error[E0277]: the size for values of type `Y` cannot be known at compilation time --> $DIR/unsized6.rs:17:12

Related discussion:
text: I tried compiling this code: which resulted in the following output of rustc: So the compiler says So I tried adding a borrow and recompiling the code: which resulted in: so the compiler says and so I'm stuck in a loop. The compiler can't decide whether I should borrow or not. As a newbie to Rust, this is very frustrating and the opposite of helpful, it just confuses me further. Please fix this indecisiveness :) :
For reference, what you likely want to do is one of the following which means they cannot be the type of a local binding. You can give a binding a slice type (), because that's morally equivalent to a pointer (with sizing info), which has a compile time determined size, as all borrows are .
Current output: After :
Code change:
// The lifetime was defined on node that doesn't own a body, // which in practice can only mean a trait or an impl, that // is the parent of a method, and that is enforced below. <del> assert_eq!(Some(param_owner_id), self.root_parent, "free_scope: {:?} not recognized by the  region scope tree for {:?} / {:?}", param_owner, self.root_parent.map(|id| tcx.hir().local_def_id_from_hir_id(id)), self.root_body.map(|hir_id| DefId::local(hir_id.owner))); </del> <ins> if Some(param_owner_id) != self.root_parent { tcx.sess.delay_span_bug( DUMMY_SP, &format!("free_scope: {:?} not recognized by the  region scope tree for {:?} / {:?}", param_owner, self.root_parent.map(|id| tcx.hir().local_def_id_from_hir_id(id)), self.root_body.map(|hir_id| DefId::local(hir_id.owner)))); } </ins> // The trait/impl lifetime is in scope for the method's body. self.root_body.unwrap().local_id

Related discussion:
text: The following minimal example causes an internal compiler error. Error in question: rustc version: This error was encountered on stable, but I can confirm that it also occurs on the latest nightly ().
Hasn't the feature gate issue been fixed? :|
I've removed the nomination and this to the tracking issue for GATs . The current impl is highly incomplete and ICEs are, sadly, expected. Also, I verified that a feature gate is indeed required.
triage: P-medium
I don't know if I get you wrong, but the example above ICEs on stable, beta and nightly without feature gate
oops, looks like I accidentally left the feature gate in there when I tried it out, but it produces the same ICE when it is omitted as well.
No, niko edited your question. ping I think you got something wrong there. Can you please clarify that?
Oh, I guess I was indeed incorreect. I tried it on play but didn't notice that, after the "correct" error, it goes on to print an ICE.
What about adding the I-nominated tag again?
I'm not sure why we would nominate this for discussion. Yes, it is an ICE (and an ICE that occurs without the user adding a feature gate), but the message pretty clearly states that you're using an unstable feature. It would be great to fix it so that it issues the error diagnostic without ICEing, but I wouldn't re-prioritize that work above P-medium.
assigning to self since its a clear annoyance
triage: P-medium. (dupe of )
(the remaining bug, when the feature gate is enabled, is tracked in issue )
Code change:
Value(int), Missing, } <del> fn main() { let x = Value(5); let y = Missing; match x { Value(n) => println!("x is {}", n), Missing  => println!("x is missing!"), } match y { Value(n) => println!("y is {}", n), Missing  => println!("y is missing!"), } } </del> ``` This enum represents an `int` that we may or may not have. In the `Missing`

Related discussion:
text: See: The keyword hasn't been introduced until that point but it's used in the code example which is confusing. I believe an if/else solution would be more explanatory, especially because the reader probably wants to see how to unpack the variant of . The same enum could then be used with the keyword in the beginning of the next chapter ().
You are correct. Nice catch!
Are you ok with simply reordering them ? Because introducing sum type without precedent knowledge of pattern matching is a bit pointles (or at least misses the fact that they are juste AWESOME for pattern matching). If you're ok with this I'll PR in a few hours :)
Maybe, if it flows okay, yeah. I do want to put SOME kind of mention of it first.
It's probably easy to find out what is doing by simply looking at it. This part of the tutorial is just a bit confusing and should be fixed. However, my main concern here is that the reader is left clueless on how to solve this problem with if/else: In fact, I really don't know how the equivalent code without would look like. I've briefly tried to figure it out and gave up.
With an Option you coul unwrap I guess. By the way why did you write a fake option enum ? Because that's basically what is done with this, it might be better to give out the real name
Because we haven't talked about generics yet.
Nicely done. However, my other concern, how this example could be done without , remains unresolved. I'm certain that I'm not the only one who wants to know how it works with before continue reading about . Should I open another issue for that matter?
I'm honestly not sure that it is possible with an arbitrary enum... You can test for some arbitrary values but i guess but that's it. Bt it's more an issue of sum types in general rather than a Rust issue (I can't find ways to do that in haskell nor in scala)
Alright, I expected something like this as I was unable to figure out how to write it without . I don't have much experience with statically typed languages, therefore the concept was new to me. If you are right, could we mention in the tutorial that it is actually not possible to write an equivalent solution with ? Certainly, I can't be the only one who was a bit puzzled.
Code change:
Value(int), Missing, } <del> fn main() { let x = Value(5); let y = Missing; match x { Value(n) => println!("x is {}", n), Missing  => println!("x is missing!"), } match y { Value(n) => println!("y is {}", n), Missing  => println!("y is missing!"), } } </del> ``` This enum represents an `int` that we may or may not have. In the `Missing`

Related discussion:
text: Cheers.
Thanks a lot for the remark, it's exactly the kind of comment needed, if you see others don't hesitate to open new issues :) I'll try to add this tonight or tomorrow.
Code change:
span } = *self; <del> hcx.hash_hir_item_like(attrs, |hcx| { </del> <ins> let is_const = match *node { hir::TraitItemKind::Const(..) | hir::TraitItemKind::Type(..) => true, hir::TraitItemKind::Method(hir::MethodSig { constness, .. }, _) => { constness == hir::Constness::Const } }; hcx.hash_hir_item_like(attrs, is_const, |hcx| { </ins> name.hash_stable(hcx, hasher); attrs.hash_stable(hcx, hasher); generics.hash_stable(hcx, hasher);

Related discussion:
text: Found via rust-icci: https://travis- The commit history of the regex crate contains on changeset that only adds a comment which in turn leads to the body of a function being moved. This results in the update of the source location pointed to by a potential overflow panic message. This message is not updated properly in incremental mode: I have not found out yet why the change is not detected. HIR fingerprinting has special treatment of operations that can trigger overflows: There must be some kind of mismatch between when HIR fingerprinting thinks that an operation can panic and when we actually emit panic messages. This is another span-related papercut cc
Full IR files for reference:
Code change:
<ins> error[E0277]: the `?` operator can only be applied to values that implement `std::ops::Try` --> $DIR/issue-72766.rs:14:5 | LL |     SadGirl {}.call()?; |     ^^^^^^^^^^^^^^^^^^ |     | |     the `?` operator cannot be applied to type `impl std::future::Future` |     help: consider using `.await` here: `SadGirl {}.call().await?` | = help: the trait `std::ops::Try` is not implemented for `impl std::future::Future` = note: required by `std::ops::Try::into_result` error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>

Related discussion:
text: <!-- 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 may be related, but I don't think this is the same bug because the above ICEs with nightly-2020-05-29.
cc
Code change:
--> $DIR/invalid-const-arg-for-type-param.rs:6:23 | LL |     let _: u32 = 5i32.try_into::<32>().unwrap(); <del> |                       ^^^^^^^^------ help: remove these generics |                       | |                       expected 0 generic arguments </del> <ins> |                       ^^^^^^^^ expected 0 generic arguments </ins> | note: associated function defined here, with 0 generic parameters --> $SRC_DIR/core/src/convert/mod.rs:LL:COL | LL |     fn try_into(self) -> Result<T, Self::Error>; |        ^^^^^^^^ <ins> help: consider moving this generic argument to the `TryInto` trait, which takes up to 1 argument | LL |     let _: u32 = TryInto::<32>::try_into(5i32).unwrap(); |                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ help: remove these generics | LL -     let _: u32 = 5i32.try_into::<32>().unwrap(); LL +     let _: u32 = 5i32.try_into().unwrap(); | </ins> error[E0599]: no method named `f` found for struct `S` in the current scope --> $DIR/invalid-const-arg-for-type-param.rs:9:7

Related discussion:
text: <!-- 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: When a user called with an annotation, it's helpful to suggest too. <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
If it's ok, I would like to give a shot. If you plan to work on it, please go ahead.
It's yours :)
claim
Hi, I would like to ask a question... I'm reading the code now and am thinking of extending the error messages by adding to . My plan is that start adding some fields (like ty::TraitRef) to and dbg! the output to get the value of trait information like for a new error message. Is my approach out of line or is there a better approach for that.
You don't have to hold information of in because we can get the info on-demand by the combination of and . Say you'd add a method of , the code will be something like this: For getting the name of the trait in question, or will be handy for you.
I appreciate your answer.
are you still working on this? :)
Code change:
<ins> error[E0310]: the associated type `<impl Iterator as Iterator>::Item` may not live long enough --> $DIR/closure-in-projection-issue-97405.rs:24:5 | LL |     assert_static(opaque(async move { t; }).next()); |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: consider adding an explicit lifetime bound `<impl Iterator as Iterator>::Item: 'static`... = note: ...so that the type `<impl Iterator as Iterator>::Item` will meet its required lifetime bounds error[E0310]: the associated type `<impl Iterator as Iterator>::Item` may not live long enough --> $DIR/closure-in-projection-issue-97405.rs:26:5 | LL |     assert_static(opaque(move || { t; }).next()); |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: consider adding an explicit lifetime bound `<impl Iterator as Iterator>::Item: 'static`... = note: ...so that the type `<impl Iterator as Iterator>::Item` will meet its required lifetime bounds error[E0310]: the associated type `<impl Iterator as Iterator>::Item` may not live long enough --> $DIR/closure-in-projection-issue-97405.rs:28:5 | LL |     assert_static(opaque(opaque(async move { t; }).next()).next()); |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: consider adding an explicit lifetime bound `<impl Iterator as Iterator>::Item: 'static`... = note: ...so that the type `<impl Iterator as Iterator>::Item` will meet its required lifetime bounds error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0310`. </ins>

Related discussion:
text: <!-- 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: Both asserts don't pass. Adding bound on makes it compile. We are requiring all the for closures and generators to outlive here: This is wrong and inconsistent with the logic in <!-- 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. --Build using the Nightly version: 1.63.0-nightly (2022-05-24 ) <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details label T-compiler A-lifetimes A-closures A-generators claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Error: Parsing assign command in failed: ...'bot assign' ''... Please let know if you're having trouble with this bot.
Code change:
use core::mem; use core::ops::{CoerceUnsized, Deref, DerefMut}; use core::ops::{Placer, Boxed, Place, InPlace, BoxPlace}; <del> use core::ptr::Unique; </del> <ins> use core::ptr::{self, Unique}; </ins> use core::raw::{TraitObject}; /// A value that represents the heap. This is the default place that the `box`

Related discussion:
text: We need to find a way to implement Clone for where . In user code, "cloning" such a box manually is simple: will do it with a short roundtrip through which should be unproblematic. In the rust distribution, we can't impl Clone easily since the tools to do so are in libcollections but the Box type lives in liballoc.
You do not need vec for the implementation. Something like the following would work: Note that because can panic it is required to keep track of the partial result so the correct stuff is dropped.
Yes, that's nice that it can be carefully solved by essentially extracting the needed parts from what Vec does. But the Box code is otherwise so clean, it doesn't feel like the right way to do it.
You're welcome to suggest an alternative but I doubt it can be done in a manner that is both correct and significantly cleaner :)
Your fundamental analysis is great: just isn't an exception safe representation while filling it with elements. It needs to keep track of the fill level, so a representation like Vec or BoxBuild is needed...
Clone is also wanted for , but that can be much simpler: There is no panic issue, and it can use a simple memcpy of the data.
Code change:
// Create the intermediate directories let mut cur = self.dst.clone(); let mut root_path = String::from_str("../../"); <del> clean_srcpath(&self.cx.src_root, &p, |component| { </del> <ins> clean_srcpath(&self.cx.src_root, &p, false, |component| { </ins> cur.push(component); mkdir(&cur).unwrap(); root_path.push_str("../");

Related discussion:
text: When visiting a page such as or the link src (for the source code) no longer works. Instead a 404 is returned. This seems to have been broken for several days now.
even before this, many but not all were broken. there may be multiple issues with this symptom.
The links link in the form but it seems like the actual source is being placed in a location in the form For example here's a link from the current docs which will 404: But the following will resolve:
Really annoyed by this. :<
Code change:
<ins> pub trait Foo { type Type; } pub struct Bar<T>(<Self as Foo>::Type) where Self: ; //~^ ERROR the trait bound `Bar<T>: Foo` is not satisfied fn main() {} </ins>

Related discussion:
text: Internal compiler error when missing bound on struct. Reproducible on stable/beta/nightly on . Also, not sure if it already has it's own issue, but is causing an illegal instruction error when you run it with on this code as well, which is also reproducible on playground if you turn the backtrace setting on. I tried this code: () I expected to see this happen: Instead, this happened: rustc versions (from playground): <details<summaryBacktrace (note the SIGILL at the end)</summary<p</p</details
cc
triage: P-high, removing nomination label (has PR).