jiebi/CodeConvo huggingface dataset:
Code 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. // This test makes sure that just changing a definition's location in the // source file also changes its incr. comp. hash, if debuginfo is enabled. // revisions:rpass1 rpass2 // compile-flags: -C overflow-checks=on #![feature(rustc_attrs)] #[cfg(rpass1)] pub fn main() { let _ = 0u8 + 1; } #[cfg(rpass2)] #[rustc_clean(label="Hir", cfg="rpass2")] #[rustc_dirty(label="HirBody", cfg="rpass2")] pub fn main() { let _ = 0u8 + 1; } </ins>

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> pub type Archived<T> = <m::Alias as n::Trait>::Archived; //~^ ERROR failed to resolve: use of undeclared crate or module `m` //~| ERROR failed to resolve: use of undeclared crate or module `n` fn main() {} </ins>

Related discussion:
text: <!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed: ().haserrors().issome()'', 'thread 'rustc' panicked at 'assertion failed: ().haserrors().issome()'' File: --auto-reduced (treereduce-rust): original: Version 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: [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
in 'ish ICEs, I am seeing ice now, im wondering if that also relates to somehow :thinking:
Quite likely, I'll take a look.
I can reproduce this. It's Saturday morning here, I might get to it today, if not I'll look on Monday morning.
Fixing this is really easy, I just need to adjust the assertion a tiny bit. The hard part is deciding where to put the test. is the obvious place, but then I get complaining that there are too many files in that directory. Suggestions?
just bump the limit by one like everybody else? :upsidedownface: :seenoevil:
I ended up putting the test in , because it happens during type checking.
Code change:
let ty = field.ty(tcx, args); try_visit!(visitor.visit(span, ty)); } <del> for (pred, span) in tcx.predicates_of(item).instantiate_identity(tcx) { </del> <ins> for (pred, span) in tcx.explicit_predicates_of(item).instantiate_identity(tcx) { </ins> try_visit!(visitor.visit(span, pred)); } }

Related discussion:
text: https://crater-
searched nightlies: from nightly-2024-02-01 to nightly-2024-03-20 regressed nightly: nightly-2024-02-10 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.8</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsprobably
WG-prioritization assigning priority (). label -I-prioritize +P-high
MCVE
Code change:
//  E0300, // unexpanded macro //  E0304, // expected signed integer constant //  E0305, // expected constant <del> E0313, // lifetime of borrowed pointer outlives lifetime of captured // variable </del> <ins> //  E0313, // removed: found unreachable </ins> //  E0314, // closure outlives stack frame //  E0315, // cannot invoke closure outside of its lifetime //  E0319, // trait impls for defaulted traits allowed just for structs/enums

Related discussion:
text: This issue is a proposal for the deprecation of error code . I opened a PR () as part of an effort to add long error explanations for error codes that didn't have one (). I chose and for my erroneous code example, I used the example from . I quickly realized, through running the example and other code that would also raise and through the CI failure message, that was not being raised. I went back to consult the issue I received the original code example from and noticed comments about not occurring anymore with . The issue was eventually labeled with . But, looking at the current contents of the file, can still be emitted even while it isn't: also doesn't have any UI tests as it is part of the error codes in . Since , is no longer actually emitted (although it is in code that it could) thanks to , I believe it should be deprecated. I would be happy to help deprecate the error code, if it is decided that it should happen. I would just need to know the proper steps to take to deprecate an error code. If there are reasons for why it is still an error code, I would love to be enlightened. claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
If is not emitted anymore then it can be removed immediately. A crater run can also be done to ensure that this is the case. I'm also happy to do this if you want.
Sure, that sounds good.
Sorry just for clarification, do you want me to do the PR or you?
Code change:
*x } <ins> async fn async_fn_with_borrow_named_lifetime<'a>(x: &'a u8) -> u8 { await!(wake_and_yield_once()); *x } fn async_fn_with_impl_future_named_lifetime<'a>(x: &'a u8) -> impl Future<Output = u8> + 'a { async move { await!(wake_and_yield_once()); *x } } async fn async_fn_with_named_lifetime_multiple_args<'a>(x: &'a u8, _y: &'a u8) -> u8 { await!(wake_and_yield_once()); *x } </ins> fn async_fn_with_internal_borrow(y: u8) -> impl Future<Output = u8> { async move { await!(async_fn_with_borrow(&y))

Related discussion:
text: suggested this is because when we lower the async function, we add `), whereas it should be parented as something outside of the impl trait context (as that is how such an expression would be parented, if it actually existing in the AST). I have a bit of code where I'd like to use a reference with a lifetime in an "async" function, which panics the compiler. I tried this code: I expected to see this happen: My understanding was that async functions are allowed to take references as parameters. helped to debug this a little bit and there is a suspicion that named lifetimes are somehow not properly propagated. I stumbled into this because I wanted to have 2 args with references, but if the lifetimes are elided the compiler asks for them to be . Adding them ICEs the compiler. Instead, this happened: I got a compiler panic. Backtrace:
suggested might be related
It would appear one can workaround this by using async blocks manually: I still need to test this does what I expect.
why do you need the immediately invoked closure there,
Yeah, just noticed. I think I also had some other issue / ICE, but I don't remember exactly what it was. Gonna have to check it again. Also, I don't think I knew that on blocks was a thing.
I didn't quite understand why I needed the move. I am trying to fix the original ICE, I think I got some time today tomorrow, hopefully, will make some progress. But compiler newbie, so might not work out.
You need to move to avoid the closure borrowing the references locally. It's the same situation as with I just removed all immeditaly invoked functions from eval :wink:
I am playing around with similar types of borrowing patterns, namely using StreamObj to carry a stream around inside of a struct. I can't seem to use the posted work-arounds: I am taking this working code and I'm refactoring it. Starts as: this works, compiles and runs. Then I try my hand at refactoring to move the stream out of the same scope as the await code pulling out values.
Code change:
*x } <ins> async fn async_fn_with_borrow_named_lifetime<'a>(x: &'a u8) -> u8 { await!(wake_and_yield_once()); *x } fn async_fn_with_impl_future_named_lifetime<'a>(x: &'a u8) -> impl Future<Output = u8> + 'a { async move { await!(wake_and_yield_once()); *x } } async fn async_fn_with_named_lifetime_multiple_args<'a>(x: &'a u8, _y: &'a u8) -> u8 { await!(wake_and_yield_once()); *x } </ins> fn async_fn_with_internal_borrow(y: u8) -> impl Future<Output = u8> { async move { await!(async_fn_with_borrow(&y))

Related discussion:
text: Now I can get the same ICE as this ticket: ICE: full backtrace: Then I try some of your posted workarounds and they don't do the trick, here's my best try: but this fails to compile due to an ownership issue I can't figure out:
your final borrow error is because Fahrenheit while your contains a local stack borrow. You could try using  instead of Fahrenheit.
Alternatively to what suggested, you could move the code in to an async fn:
Code 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. #![feature(associated_consts)] #![deny(dead_code)] // use different types / traits to test all combinations trait Const { const C: (); } trait StaticFn { fn sfn(); } struct ConstStruct; struct StaticFnStruct; enum ConstEnum {} enum StaticFnEnum {} struct AliasedConstStruct; struct AliasedStaticFnStruct; enum AliasedConstEnum {} enum AliasedStaticFnEnum {} type AliasConstStruct    = AliasedConstStruct; type AliasStaticFnStruct = AliasedStaticFnStruct; type AliasConstEnum      = AliasedConstEnum; type AliasStaticFnEnum   = AliasedStaticFnEnum; macro_rules! impl_Const {($($T:ident),*) => {$( impl Const for $T { const C: () = (); } )*}} macro_rules! impl_StaticFn {($($T:ident),*) => {$( impl StaticFn for $T { fn sfn() {} } )*}} impl_Const!(ConstStruct, ConstEnum, AliasedConstStruct, AliasedConstEnum); impl_StaticFn!(StaticFnStruct, StaticFnEnum, AliasedStaticFnStruct, AliasedStaticFnEnum); fn main() { let _ = ConstStruct::C; let _ = ConstEnum::C; StaticFnStruct::sfn(); StaticFnEnum::sfn(); let _ = AliasConstStruct::C; let _ = AliasConstEnum::C; AliasStaticFnStruct::sfn(); AliasStaticFnEnum::sfn(); } </ins>

Related discussion:
text: Warning:
By the way, the warning goes away if you explicitly specify the trait who's static method you are calling, like so:
Code change:
"`{expected_ty}` does not implement `Clone`, so `{found_ty}` was cloned instead" ), ); <ins> let owner = self.tcx.hir().enclosing_body_owner(expr.hir_id); if let ty::Param(param) = expected_ty.kind() && let Some(generics) = self.tcx.hir().get_generics(owner) { suggest_constraining_type_params( self.tcx, generics, diag, vec![(param.name.as_str(), "Clone", Some(clone_trait_did))].into_iter(), ); } else { self.suggest_derive(diag, &[(trait_ref.to_predicate(self.tcx), None, None)]); } </ins> } }

Related discussion:
text: This gives the very unintuitive error: You expect to return , i.e. a . It mysteriously returns an instead. Because has a clone impl, it too, can be cloned (really, copied), returning a reference of the same lifetime. This is an operation you rarely want to do explicitly, except when dealing with generics. This error can crop up when you've forgotten to implement on , and have a reference (which could have been silently inserted using , as in the code above). However, it's not very obvious what's happening here. It can also crop up We should hint that itself isn't cloneable and thus we fell back to cloning here. This could be a lint on hitting the clone impl for references, but lints run too late. I'm not sure how this can be implemented, since we need to see the source of a value and that's a bit tricky.
cc
Interesting. This does seem like it would require some pretty special-case code to achieve, but I agree it'd be a nice case to capture.
A relatively easy way to catch most instances of this is to Pick up the expression which has a type error like this If it is a method call, check if that method call is a clone() call resolving to If it is a variable, find the variable's def If the def is a local def, look at the init expr, check if it's a bad clone This will miss things, but I think the majority of such bugs will be due to this. As it stands this feels like an incredibly easy case to hit (we've all forgotten to decorate structs).
cc
CC
As reported in : This reports:
Current output is even worse for the original report: The last comment's code is marginally different:
Current output: The last case should suggest constraining . Edit: that was easier than I thought (we already had the suggestion machinery): <img width="511" alt="Screen Shot 2022-12-13 at 6 41 23 PM" src="https://user-"
Code change:
macro_rules! mac { ($ ($ tt : tt) *) => () } mac! { <del> struct S { field1 : u8 , field2 : u16 , } impl Clone for S </del> <ins> struct S { field1 : u8, field2 : u16, } impl Clone for S </ins> { fn clone () -> S {

Related discussion:
text: proc-macro derive panicked All of the 62 regressions are due to old versions of having an assert expecting instead of . So this is again a consequence of whitespace changes in pretty-printing (). I think we should be able to fix this by special casing the comma token during token stream pretty-printing and not printing the space before it.
Fixed in
Just FYI, we discussed this in the meeting. We felt like the action here was appropriate -- while in general we do not guarantee stability of pretty printing, it makes sense to be judicious, and in this particular case not having a leading space before just looks better anyway.
Code change:
//! Unicode string slices. //! <ins> //! The `&str` type is one of the two main string types, the other being `String`. //! Unlike its `String` counterpart, its contents are borrowed. //! //! # Basic Usage //! //! A basic string declaration of `&str` type: //! //! ``` //! let hello_world = "Hello, World!"; //! ``` //! //! Here we have declared a string literal, also known as a string slice. //! String literals have a static lifetime, which means the string `hello_world` //! is guaranteed to be valid for the duration of the entire program. //! We can explicitly specify `hello_world`'s lifetime as well: //! //! ``` //! let hello_world: &'static str = "Hello, world!"; //! ``` //! </ins> //! *[See also the `str` primitive type](../../std/primitive.str.html).* #![stable(feature = "rust1", since = "1.0.0")] // Many of the usings in this module are only used in the test configuration.

Related discussion:
text: Part of Here's what needs to be done to close out this issue: is fine, but should point out why and the primitive type are different. should use the same boilerplate as  has the same issue. has the same issue. has the same issue. should link to the method it comes from. should use the same boilerplate as . should link to those functions. should have an example of implementing it. should link the types it mentions. should link that .
As shown in , there's a lot of junk there that could be in instead.
I am happy to mentor anyone who wants to tackle this issue.
Hello! I'd like to give this issue a try.
that'd be great! this issue is very general, so any improvements would be welcome. Let me know if you need any help!
Shouldn't this remain open? 3 points have been hit on, but the rest of the bullets need to be addressed
Yes, whoops! That was an auto-close from a PR message; gotta be careful with that!
Can you explain what you mean by "the same boilerplate" in points 2-5? Boilerplate as in the description text or the struct line, or something else? Getting some clarification could get those knocked out in short order
Yes, absolutely! is the main set of iterators, for . When I did these docs, I took care to make them all consistent: etc. and etc don't use this; when I wrote it, I was thinking that would be the right way to go; but looks like is slightly different than the ones. So we should change all of these to look like the ones in . Make sense?
Ahhh, so for , it should be something along the lines of: An iterator over the lines of a string, as string slices. With the proper links to and as well, yes? I could run through each of those structs, format them like that, with a commit for each and then do one big pull request for the lot of them if that would be convenient
Exactly. Sure thing! That'd be great.
I think the last two PRs should take care of the remaining bits of the task list. When they're merged, I think we'll be good to close this issue out!
Code change:
//! Unicode string slices. //! <ins> //! The `&str` type is one of the two main string types, the other being `String`. //! Unlike its `String` counterpart, its contents are borrowed. //! //! # Basic Usage //! //! A basic string declaration of `&str` type: //! //! ``` //! let hello_world = "Hello, World!"; //! ``` //! //! Here we have declared a string literal, also known as a string slice. //! String literals have a static lifetime, which means the string `hello_world` //! is guaranteed to be valid for the duration of the entire program. //! We can explicitly specify `hello_world`'s lifetime as well: //! //! ``` //! let hello_world: &'static str = "Hello, world!"; //! ``` //! </ins> //! *[See also the `str` primitive type](../../std/primitive.str.html).* #![stable(feature = "rust1", since = "1.0.0")] // Many of the usings in this module are only used in the test configuration.

Related discussion:
text: Module documentation () Bytes should use the same boilerplate as Lines () CharIndices has the same issue. () Chars has the same issue. () EncodeUtf16 has the same issue. () ParseBoolError should link to the method it comes from. () SplitWhitespace should use the same boilerplate as Lines. () Utf8Error should link to those functions. () FromStr should have an example of implementing it. () fromutf8 should link the types it mentions. () fromutf8_unchecked should link that &str. ()
Everything's merged! Good to close
Yes! Thank you for all the help!
Code change:
#[allow(unused)] pub fn doctest_runner(bin: &std::path::Path, test_nb: usize) -> Result<(), String> {{ let out = std::process::Command::new(bin) <del> .arg(self::RUN_OPTION) .arg(test_nb.to_string()) </del> <ins> .env(self::RUN_OPTION, test_nb.to_string()) .args(std::env::args().skip(1).collect::<Vec<_>>()) </ins> .output() .expect("failed to run command"); if !out.status.success() {{

Related discussion:
text: The crater run for merged doctests () detected a large number of regressions due to tests examining the process arguments. (I don't have an exact number, but let's say ~50 projects.) Previously, there were no arguments, but now it gets arguments like which the user's CLI parsing code isn't expecting. For example, using something like  will now fail. It seems to be fairly common to have objects whose default constructor will parse the arguments from the command line. I'm not sure if or how we should resolve that. One idea is to use a different mechanism for passing in the test information (like via an environment variable).
I vaguely remember that using environment variables was discussed but can't find anything except mentioning it . Maybe it'd be a better approach indeed. Let me send a PR so we can make a crater run on it.
Code change:
<ins> use std::convert::TryInto; trait A<T> { fn foo() {} } trait B<T, U> { fn bar() {} } struct S; impl<T> A<T> for S {} impl<T, U> B<T, U> for S {} fn main() { let _ = A::foo::<S>(); //~^ ERROR //~| HELP remove these generics //~| HELP consider moving this generic argument let _ = B::bar::<S, S>(); //~^ ERROR //~| HELP remove these generics //~| HELP consider moving these generic arguments let _ = A::<S>::foo::<S>(); //~^ ERROR //~| HELP remove these generics let _ = 42.into::<Option<_>>(); //~^ ERROR //~| HELP remove these generics //~| HELP consider moving this generic argument } </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. 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? :)