jiebi/CodeConvo huggingface dataset:
Change:
<ins> // Copyright 2018 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. // run-rustfix // edition:2018 // compile-pass // aux-build:remove-extern-crate.rs #![warn(rust_2018_idioms)] use core as another_name; use remove_extern_crate; #[macro_use] extern crate remove_extern_crate as something_else; fn main() { another_name::mem::drop(3); another::foo(); remove_extern_crate::foo!(); bar!(); } mod another { use core; use remove_extern_crate; pub fn foo() { core::mem::drop(4); remove_extern_crate::foo!(); } } </ins>

Discussion:
Migrated from It's been mentioned/requested multiple times on the that should remove the statements when moving to Rust 2018. One of the big draws of Rust 2018's module system is that all of the "redundant" lines can finally be removed. It took some of the excitement away when I went through all of the steps and still saw them there. I think it will just be a better experience for users to see one of the tangible benefits of this change. As it is right now, they just see the in front of all of their local imports and they might not realize what a nice change the module system updates really are. After I manually removed the 's I did get my satisfying result , but let's give this to users on the first go around. If I understand correctly this should be implemented in the compiler under the lints, rather than itself. cc
I'm moving this forward up on the milestone list due to just having closed in favor of this issue, which was itself on the RC milestone.
Ok so I've some triaging of related lint issues, and I believe the current work items are: A rustfix-fixable suggestion for removing needs to be implemented. The implementation would . Currently the lint suggests switching to simply . While technically correct and handles lots of corner cases, this doesn't achieve the desired goal of actually removing annotations. We can't blanket remove all statements, for example is correctly warned to use a rather than deleting the statement outright. I'm testing out some ideas locally as well.
I believe this should be fixed by , I think the naive solution actually works well!
Change:
typeid.push_str(&s); } <ins> ty::Generator(def_id, substs, ..) => { // u<length><name>[I<element-type1..element-typeN>E], where <element-type> is <subst>, // as vendor extended type. let mut s = String::new(); let name = encode_ty_name(tcx, *def_id); let _ = write!(s, "u{}{}", name.len(), &name); // Encode parent substs only s.push_str(&encode_substs( tcx, tcx.mk_substs(substs.as_generator().parent_substs()), dict, options, )); compress(dict, DictKey::Ty(ty, TyQ::None), &mut s); typeid.push_str(&s); } </ins> // Pointer types ty::Ref(region, ty0, ..) => { // [U3mut]u3refI<element-type>E as vendor extended type qualifier and type

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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
"" }; <ins> // `libtest` uses this to know whether or not to support // `-Zunstable-options`. if !builder.unstable_features() { cargo.env("CFG_DISABLE_UNSTABLE_FEATURES", "1"); } </ins> let mut features = String::new(); // Cranelift doesn't support `asm`.

Discussion:
I tried runnning I expected to see this happen: an error message similar to Instead, this happened: the tests ran and printed their output in json (mentioned in , cc )
See also . There are multiple issues with how this is handled.
Change:
foreign_crate::ForeignType(val) } <del> impl<T> foreign_crate::ForeignTrait for AliasOfForeignType<T> {} </del> <ins> impl foreign_crate::ForeignTrait for AliasOfForeignType<()> {} </ins> //~^ ERROR only traits defined in the current crate can be implemented for arbitrary types fn main() {}

Discussion:
The following UB compiles: The impl is invalid because the lifetime parameter appears unconstrained in the impl header. It should be rejected for the same reason that projection types doesn't constraint impl generics: label C-bug T-types I-unsound requires-nightly F-typealiasimpl_trait
Change:
/// use std::net::Ipv6Addr; /// /// fn main() { <del> ///     assert_eq!(Ipv6Addr::new(0, 0, 0, 0, 0, 0xffff, 0xc00a, 0x2ff).is_unicast_link_local(), ///                false); ///     assert_eq!(Ipv6Addr::new(0xfe8a, 0, 0, 0, 0, 0, 0, 0).is_unicast_link_local(), true); </del> <ins> ///     let ip = Ipv6Addr::new(0xfe80, 0, 0, 0, 0, 0, 0, 0); ///     assert!(ip.is_unicast_link_local()); /// ///     let ip = Ipv6Addr::new(0xfe80, 0, 0, 0, 0xffff, 0xffff, 0xffff, 0xffff); ///     assert!(ip.is_unicast_link_local()); /// ///     let ip = Ipv6Addr::new(0xfe80, 0, 0, 1, 0, 0, 0, 0); ///     assert!(ip.is_unicast_link_local()); ///     assert!(!ip.is_unicast_link_local_strict()); /// ///     let ip = Ipv6Addr::new(0xfe81, 0, 0, 0, 0, 0, 0, 0); ///     assert!(ip.is_unicast_link_local()); ///     assert!(!ip.is_unicast_link_local_strict()); </ins> /// } /// ``` <ins> /// /// # See also /// /// - [IETF RFC 4291 section 2.4] /// - [RFC 4291 errata 4406] /// /// [IETF RFC 4291 section 2.4]: https://tools.ietf.org/html/rfc4291#section-2.4 /// [`true`]: ../../std/primitive.bool.html /// [RFC 4291 errata 4406]: https://www.rfc-editor.org/errata/eid4406 /// [`is_unicast_link_local_strict()`]: ../../std/net/struct.Ipv6Addr.html#method.is_unicast_link_local_strict /// </ins> pub fn is_unicast_link_local(&self) -> bool { (self.segments()[0] & 0xffc0) == 0xfe80 } <del> /// Returns [`true`] if this is a deprecated unicast site-local address /// (fec0::/10). </del> <ins> /// Returns [`true`] if this is a deprecated unicast site-local address (fec0::/10). The /// unicast site-local address format is defined in [RFC 4291 section 2.5.7] as: /// /// ```no_rust /// |   10     | /// |  bits    |         54 bits         |         64 bits            | /// +----------+-------------------------+----------------------------+ /// |1111111011|        subnet ID        |       interface ID         | /// +----------+-------------------------+----------------------------+ /// ``` </ins> /// /// [`true`]: ../../std/primitive.bool.html <ins> /// [RFC 4291 section 2.5.7]: https://tools.ietf.org/html/rfc4291#section-2.5.7 </ins> /// /// # Examples ///

Discussion:
This code should be correct, because according to document, all address in are not global reachable. But it panic on assertion failed in latest nightly (2019-01-11) (see )
Relevant thread:
Sorry, fixed
Change:
"intrinsic": "256_sad_epu8", "width": [256], "llvm": "psad.bw", <del> "ret": "u8", </del> <ins> "ret": "u64", </ins> "args": ["0", "0"] }, {

Discussion:
According to the return type should be but rustc expects a Test case: Compiler error:
cc
I think the has an incorrect return type?
Change:
), ); } <ins> let (span, sugg, post) = if let SuggestionTarget::SimilarlyNamed = suggestion.target && let Ok(snippet) = self.tcx.sess.source_map().span_to_snippet(span) && let Some(span) = suggestion.span && let Some(candidate) = suggestion.candidate.as_str().strip_prefix("_") && snippet == candidate { // When the suggested binding change would be from `x` to `_x`, suggest changing the // original binding definition instead. (#60164) (span, snippet, ", consider changing it") } else { (span, suggestion.candidate.to_string(), "") }; </ins> let msg = match suggestion.target { SuggestionTarget::SimilarlyNamed => format!( <del> "{} {} with a similar name exists", </del> <ins> "{} {} with a similar name exists{post}", </ins> suggestion.res.article(), suggestion.res.descr() ),

Discussion:
Variables can be marked as unused by prepending with an underscore. If at some point such a variable is used again, the compiler suggests to name the use , even though every single time I have encountered this, what I wanted is to change the definition of to . () Errors:
I feel we should have a counterpart to the unused lint that checks for variables that are used but use the unused bar convention. That wouldn't be useful for the case presented here where you're using an unused bar for the first time, but seems like a reasonable addition.
Such a lint is problematic within macros or other compiler-expanded code, since it's a common pattern to work around not knowing if there are any uses by naming the variables appropriately (for an example look at the loop lowering code)
I agree but I'm pretty sure that most lints should ignore code with spans in macro context already.
Hi, I'd like to work on this!
sorry for not responding earlier. I only have very broad instructions right now, but don't hesitate to ask here or on the stream on zulip if you need more help. the place where the diagnostic "a local variable with a similar name exists" is emitted note that the "local variable" part may be a placeholder and the rest of the string might be broken across multiple lines if that place has more info than just the name of the local variable not, add a to whatever datastructure holds the name I'm not sure how the name is obtained right now, but there should be a way to get at the there, too. E.g. if the name is an , then it has a field. emitting the "similar name" diagnostic, first check whether the suggested name starts with an underscore, but the name used in the code does not that chek fails, keep the old message , emit the suggestion not on the span that it is currently emitted on, but on the definition span (and change the suggestion to remove the underscore)
Hi I've already done most of that :) I think I'll have a working PR next week.
I can work on this if you guys are caught up with something else :)
sure. Just once you start working on it. Maybe you can even get the WIP branch from fork
Change:
fn visit_generics(&mut self, generics: &'a Generics) { let mut prev_ty_default = None; for param in &generics.params { <del> if let GenericParamKind::Type { ref default, .. } = param.kind { if default.is_some() { </del> <ins> match param.kind { GenericParamKind::Lifetime => (), GenericParamKind::Type { default: Some(_), .. } => { </ins> prev_ty_default = Some(param.ident.span); <del> } else if let Some(span) = prev_ty_default { self.err_handler() .span_err(span, "type parameters with a default must be trailing"); break; </del> <ins> } GenericParamKind::Type { .. } | GenericParamKind::Const { .. } => { if let Some(span) = prev_ty_default { let mut err = self.err_handler().struct_span_err( span, "type parameters with a default must be trailing", ); if matches!(param.kind, GenericParamKind::Const { .. }) { err.note( "using type defaults and const parameters  in the same parameter list is currently not permitted", ); } err.emit(); break; } </ins> } } }

Discussion:
Should the following code be accepted? if so, we probably also want to accept the following: cc
So,how would the following be handled? That is (passing an identifier as a const argument).
should be equal to imo. rn literals which are in both the type and the value namespace are always used as type params though (see ). So this would fail to compile even if we get to work.
Change:
use rustc_ast::Mutability; use rustc_errors::Applicability; use rustc_hir as hir; <ins> use rustc_middle::ty::subst::InternalSubsts; </ins> use rustc_middle::ty::{Ref, Ty}; use rustc_session::lint::builtin::RUST_2021_PRELUDE_COLLISIONS; use rustc_span::symbol::kw::Underscore; use rustc_span::symbol::{sym, Ident}; use rustc_span::Span; <ins> use rustc_trait_selection::infer::InferCtxtExt; </ins> use crate::check::{ method::probe::{self, Pick},

Discussion:
(As I mentioned :) I tried out the migration lints on some of my own code, and ran into one false positive: A struct being used with This doesn't actually become ambiguous when FromIterator is imported, because Opt doesn't implement that. Niko :
(If we don't end up doing this, we should at least change the wording to say instead of .)
Which exact function on which type do you mean? Do you have some pointers here?
Maybe Niko meant evaluate-obligation ?
Okay I have an implementation that uh.. compiles. And seems to work, maybe? (:
Change:
// compile-flags: -D path-statements <del> fn main() { </del> <ins> struct Droppy; impl Drop for Droppy { fn drop(&mut self) {} } fn main() { </ins> let x = 10; x; //~ ERROR path statement with no effect <ins> let y = Droppy; y; //~ ERROR path statement drops value let z = (Droppy,); z; //~ ERROR path statement drops value </ins> }

Discussion:
() Removing the "no effect" line definitely has effect. The warning may instead suggest to explicitly use if that is what is needed.
Huh, I ran into this a couple weeks ago and typed up an issue, then decided at the last second to back out of it for some reason. Maybe I just figured that writing is more idiomatic anyways. This lint is old, by the way. (in Rust years, anyways)
requires adding before closure (somewhat suprisingly unlike ) Writing instead of may be more idiomatic if one wants to emphasize that running is significant.
Bumping this, as it's relevant to . (See also , ) When the path statement invokes a move, this lint is plain wrong; as the value has been moved, the old binding is no longer usable. When this move invokes drop glue, this lint is even more wrong, because the drop glue is an observable effect, and removing the statement would change the semantics of the program. "Path statement with no effect is further potentially damaging, as it may lead the user to write to silence the warning, which again changes the semantics of the program, because binding to the wildcard pattern does actually not perform a move from the place. I believe the correct behavior for this lint would be to suggest removing path statements that have no associated drop glue, but to suggest for types that do have drop glue, signaling clarity of intent.
Change:
use core::default::Default; use core::fmt; use core::hash::{self, Hash}; <ins> use core::iter::Iterator; </ins> use core::marker::Sized; use core::mem; use core::option::Option;

Discussion:
This code fails to compile: error message: A similar error occurs if is used instead of . However, if you comment out the for loop, the call to works just fine. I thought maybe it had something to do with auto-deref, so I tried dereferencing the iterator: but dumps core: I'm not sure, but this may be related to ? dumps core when I try too. version:
CC
I think the problem is worse than this; trait objects in general don’t seem to be being recognised as implementing their traits: All three fail:
I'm not sure this is a bug at all. You're pretty much asking for an automatic - I did come up with a & -based model that would kinda work for this and IIRC pointed out that object-safe traits would eventually qualify for this. We do have object safety now, so it might be doable, but I wouldn't bet on it making into 1.0. In the meanwhile, does work? If it doesn't, is it just the case of missing in a couple places?
This a particular case of . See comments over there. is leaning towards an opt-in syntax extension that handles the boiler plate code, instead of automatic s by the compiler.
ByRef for trait objects seems to hit the same llvm assertion: output:
Interesting. So if I have a value with type where is a trait, then we can't say that implements in the general case? (Assuming object safety.) So my guess is that can still call because of auto deref? Shouldn't that mean it can work with ? Maybe that is what is about... You have to explicitly deref a to use it in ? (Sorry for all the questions. I'm just confused!)
doing autoderef on the iterator in seems like something reasonable to have. looks like the compiler is mistakenly treating an unsized lvalue as an rvalue, in trans.
On Mon, Jan 12, 2015 at 01:33:08PM -0800, Andrew Gallant wrote: Actually, I believe it works with , but not with the other types.
Just thank you for this issue. It resolves all my problems perfectly!
Change:
<ins> // run-rustfix mod test { pub const X: i32 = 123; //~^ ERROR expected one of `!` or `::`, found keyword `const` } fn main() { println!("{}", test::X); } </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 on stable 1.63.0: The current output on Beta version 1.64.0-beta.6 (2022-09-09 ): The current output on Nightly version 1.65.0-nightly (2022-09-09 ): Since ( cc ) is somewhat recent the help diagnostics improvement currently is only on beta. However, the latest nightly has regressions regarding the suggestion as shown above. Hence, the output should suggest changing with as that is the desired output. Note: base issue for improved diagnostics ( -): Note: since this is technically a regression from beta to nightly, what should be the appropriate label to add? The one below this? label +regression-untriaged <!-- 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 --
Can you please add the Rustc versions?
[Note that I don't think this should have happened at all, I wrote tests for the changed diagnostic suggestions]
I have retested the above code snippet against the current stable, beta and nightly version (I have the version numbers above) of the compiler in the official rust playground and the regression still persist. Not sure if this only occurs on the rust playground although I highly doubt it. Maybe you could look into this as the implementation of that diagnostics improvement is written by you. If you have any evidence that this regression issue is misinformed do let me know and I will happily close the issue. Thanks a lot.

Not sure if this is the cause but maybe the test you wrote in is slightly different to the above code snippet as the test uses the wrong keyword in the top-level. However, the above code snippet uses the incorrect keyword inside of a user-defined module. Hence, this may lead to a PR that potentially causes a regression in the recovery of -to not trip off a CI fail. Therefore, undetected. That being said, all those are just my guess and it may be wrong. label +E-needs-bisection
This may related to my PR:
claim
label -E-needs-bisection
Change:
// y.method(); (y.vtable.method)(y.data); ``` <ins> ## Object Safety Not every trait can be used to make a trait object. For example, vectors implement `Clone`, but if we try to make a trait object: ```ignore let v = vec![1, 2, 3]; let o = &v as &Clone; ``` We get an error: ```text error: cannot convert to a trait object because trait `core::clone::Clone` is not object-safe [E0038] let o = &v as &Clone; ^~ note: the trait cannot require that `Self : Sized` let o = &v as &Clone; ^~ ``` The error says that `Clone` is not ‘object-safe’. Only traits that are object-safe can be made into trait objects. A trait is object-safe if both of these are true: * the trait does not require that `Self: Sized` * all of its methods are object-safe So what makes a method object-safe? Each method must require that `Self: Sized` or all of the following: * must not have any type parameters * must not use `Self` Whew! As we can see, almost all of these rules talk about `Self`. A good intuition is “except in special circumstances, if your trait’s method uses `Self`, it is not object-safe.” </ins>

Discussion:
Currently, the only documentation of the rules for object safety I could find is in . However, this should also become part of the official documentation, for example .
It is currently defined in but having it in the book would be nice too.
Change:
#### Cost <del> There is no runtime cost to using `Cell<T>`, however if you are using it to wrap larger (`Copy`) </del> <ins> There is no runtime cost to using `Cell<T>`, however if you are using it to wrap larger </ins> structs, it might be worthwhile to instead wrap individual fields in `Cell<T>` since each write is otherwise a full copy of the struct. ## `RefCell<T>` <del> [`RefCell<T>`][refcell] also provides interior mutability, but isn't restricted to `Copy` types. </del> <ins> [`RefCell<T>`][refcell] also provides interior mutability, but doesn't move data in and out of the cell. </ins> <del> Instead, it has a runtime cost. `RefCell<T>` enforces the read-write lock pattern at runtime (it's </del> <ins> However, it has a runtime cost. `RefCell<T>` enforces the read-write lock pattern at runtime (it's </ins> like a single-threaded mutex), unlike `&T`/`&mut T` which do so at compile time. This is done by the `borrow()` and `borrow_mut()` functions, which modify an internal reference count and return smart pointers which can be dereferenced immutably and mutably respectively. The refcount is restored when

Discussion:
broke a library of mine where I had code like this: calls that used to call this trait method now call the new inherent method, but since that’s unstable the crate didn’t build until I . After that I could remove the trait since the new method has the same behavior. Anyway, this is just FYI. If we don’t want this kind of breakage we can’t add any new method to existing types ever, so that doesn’t sound viable. If the new method had had different behavior or if I wanted to keep supporting older compilers, it wouldn’t be too hard to rename my trait’s method or use UFCS.
Yeah in general we reserve the right to break downstream code with differences in method resolution because the downstream code can always be written in an "elaborated" form which works on all compilers (e.g. using ufcs). If a change to the standard library breaks an excessive amount of code in the ecosystem, though, then we'd need to take the steps much more purposefully.
Sounds good. Again, I don’t expect anything to change here and only made the previous comment to let people know this happened. I made this particular crate as an experiment, I don’t know of anyone actually using it.
Given that the core changes to the bounds on existing methods were instantly stable, it doesn't make a lot of sense to keep and as unstable. I propose we immediately stabilize these APIs. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
ping (checkbox)
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.
What’s the next step here? Batch stabilization PR near the end of the release cycle?
Yep, I'm preparing one right now.