jiebi/CodeConvo huggingface dataset:
Code change:
Before (on librustc): After (on same librustc): cc
The extra RAM usage seems to be because of the AST not getting freed after the early lint checks. Not sure if this is intentional.
The AST should definitely still get freed, nobody touched , so it's not intentional (unless something about the command line options has changed?)
The performance regression in looks like it was caused by . I'll work on a fix now. I'm not sure what caused the RAM increase.
Resolution used to take about 1 seconds a few months ago in winapi and now it takes 9 seconds.
I fixed the performance regression in .

Related discussion:
text: prelude: RefCell::new(None), glob_importers: RefCell::new(Vec::new()), globs: RefCell::new((Vec::new())), <ins> traits: RefCell::new(None), </ins> populated: Cell::new(!external), arenas: arenas }
Code change:
Before (on librustc): After (on same librustc): cc
The extra RAM usage seems to be because of the AST not getting freed after the early lint checks. Not sure if this is intentional.
The AST should definitely still get freed, nobody touched , so it's not intentional (unless something about the command line options has changed?)
The performance regression in looks like it was caused by . I'll work on a fix now. I'm not sure what caused the RAM increase.
Resolution used to take about 1 seconds a few months ago in winapi and now it takes 9 seconds.
I fixed the performance regression in .

Related discussion:
text: let mut search_module = self.current_module; loop { // Look for trait children. <del> let mut search_in_module = |module: Module<'a>| module.for_each_child(|_, ns, binding| { if ns != TypeNS { return } let trait_def_id = match binding.def() { Some(Def::Trait(trait_def_id)) => trait_def_id, Some(..) | None => return, }; if self.trait_item_map.contains_key(&(name, trait_def_id)) { add_trait_info(&mut found_traits, trait_def_id, name); let trait_name = self.get_trait_name(trait_def_id); self.record_use(trait_name, TypeNS, binding); </del> <ins> let mut search_in_module = |module: Module<'a>| { let mut traits = module.traits.borrow_mut(); if traits.is_none() { let mut collected_traits = Vec::new(); module.for_each_child(|_, ns, binding| { if ns != TypeNS { return } if let Some(Def::Trait(_)) = binding.def() { collected_traits.push(binding); } }); *traits = Some(collected_traits.into_boxed_slice()); </ins> } <del> }); </del> <ins> for binding in traits.as_ref().unwrap().iter() { let trait_def_id = binding.def().unwrap().def_id(); if self.trait_item_map.contains_key(&(name, trait_def_id)) { add_trait_info(&mut found_traits, trait_def_id, name); let trait_name = self.get_trait_name(trait_def_id); self.record_use(trait_name, TypeNS, binding); } } }; </ins> search_in_module(search_module); match search_module.parent_link {
Code change:
Should it expect a ? Full example code:
It should expect , but it's lost from the expected set. I't not an issue specific for , but a symptom of a more general problem with expected token sets. There's a long weekend ahead, I'll investigate.
Oh wait, this works on nightly, as expected (fixed in , more specifically). It means there are no problems with expected token sets.

Related discussion:
text: <ins> // Copyright 2016 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. use foo.bar; //~ ERROR expected one of `::`, `;`, or `as`, found `.` </ins>
Code change:
Errors like are happening on the bots, e.g.: This is under the covers, but rustbuild's command should blow away the build system directory ahead of time to be more resilient to bugs like this.

Related discussion:
text: return os.path.join(self.bin_root(), '.cargo-stamp') def rustc_out_of_date(self): <del> if not os.path.exists(self.rustc_stamp()): </del> <ins> if not os.path.exists(self.rustc_stamp()) or self.clean: </ins> return True with open(self.rustc_stamp(), 'r') as f: return self.stage0_rustc_date() != f.read() def cargo_out_of_date(self): <del> if not os.path.exists(self.cargo_stamp()): </del> <ins> if not os.path.exists(self.cargo_stamp()) or self.clean: </ins> return True with open(self.cargo_stamp(), 'r') as f: return self.stage0_cargo_date() != f.read()
Code change:
Errors like are happening on the bots, e.g.: This is under the covers, but rustbuild's command should blow away the build system directory ahead of time to be more resilient to bugs like this.

Related discussion:
text: return '' def build_bootstrap(self): <ins> build_dir = os.path.join(self.build_dir, "bootstrap") if self.clean and os.path.exists(build_dir): shutil.rmtree(build_dir) </ins> env = os.environ.copy() <del> env["CARGO_TARGET_DIR"] = os.path.join(self.build_dir, "bootstrap") </del> <ins> env["CARGO_TARGET_DIR"] = build_dir </ins> env["RUSTC"] = self.rustc() env["LD_LIBRARY_PATH"] = os.path.join(self.bin_root(), "lib") env["DYLD_LIBRARY_PATH"] = os.path.join(self.bin_root(), "lib")
Code change:
Errors like are happening on the bots, e.g.: This is under the covers, but rustbuild's command should blow away the build system directory ahead of time to be more resilient to bugs like this.

Related discussion:
text: def main(): parser = argparse.ArgumentParser(description='Build rust') parser.add_argument('--config') <ins> parser.add_argument('--clean', action='store_true') </ins> parser.add_argument('-v', '--verbose', action='store_true') args = [a for a in sys.argv if a != '-h']
Code change:
Errors like are happening on the bots, e.g.: This is under the covers, but rustbuild's command should blow away the build system directory ahead of time to be more resilient to bugs like this.

Related discussion:
text: rb.rust_root = os.path.abspath(os.path.join(__file__, '../../..')) rb.build_dir = os.path.join(os.getcwd(), "build") rb.verbose = args.verbose <ins> rb.clean = args.clean </ins> try: with open(args.config or 'config.toml') as config:
Code change:
The rust book states that asm! clobbers should be written as "{rdx}" but when you use them as such the clobbers will be silently ignored making for some nasty bugs. output Relevant part of objdump: Relevant LLVM IR: As we can seen in the emitted LLVM IR, the given clobbers are surrounded by {{}}. I'm not sure what effect this has, but it seems like LLVM just silently ignores them. A fix would either be to not send the extra {}'s to LLVM or to edit the documentation to reflect that clobbers should be given without surrounding {}'s. Either way, this should probably not generate invalid code silently.

Related discussion:
text: asm!("xor %eax, %eax" : : <del> : "{eax}" </del> <ins> : "eax" </ins> ); # } } ```
Code change:
The rust book states that asm! clobbers should be written as "{rdx}" but when you use them as such the clobbers will be silently ignored making for some nasty bugs. output Relevant part of objdump: Relevant LLVM IR: As we can seen in the emitted LLVM IR, the given clobbers are surrounded by {{}}. I'm not sure what effect this has, but it seems like LLVM just silently ignores them. A fix would either be to not send the extra {}'s to LLVM or to edit the documentation to reflect that clobbers should be given without surrounding {}'s. Either way, this should probably not generate invalid code silently.

Related discussion:
text: # #![feature(asm)] # #[cfg(any(target_arch = "x86", target_arch = "x86_64"))] # fn main() { unsafe { <del> asm!("xor %eax, %eax" ::: "{eax}"); </del> <ins> asm!("xor %eax, %eax" ::: "eax"); </ins> # } } ```
Code change:
The rust book states that asm! clobbers should be written as "{rdx}" but when you use them as such the clobbers will be silently ignored making for some nasty bugs. output Relevant part of objdump: Relevant LLVM IR: As we can seen in the emitted LLVM IR, the given clobbers are surrounded by {{}}. I'm not sure what effect this has, but it seems like LLVM just silently ignores them. A fix would either be to not send the extra {}'s to LLVM or to edit the documentation to reflect that clobbers should be given without surrounding {}'s. Either way, this should probably not generate invalid code silently.

Related discussion:
text: # #[cfg(any(target_arch = "x86", target_arch = "x86_64"))] # fn main() { unsafe { // Put the value 0x200 in eax <del> asm!("mov $$0x200, %eax" : /* no outputs */ : /* no inputs */ : "{eax}"); </del> <ins> asm!("mov $$0x200, %eax" : /* no outputs */ : /* no inputs */ : "eax"); </ins> # } } ```
Code change:
The rust book states that asm! clobbers should be written as "{rdx}" but when you use them as such the clobbers will be silently ignored making for some nasty bugs. output Relevant part of objdump: Relevant LLVM IR: As we can seen in the emitted LLVM IR, the given clobbers are surrounded by {{}}. I'm not sure what effect this has, but it seems like LLVM just silently ignores them. A fix would either be to not send the extra {}'s to LLVM or to edit the documentation to reflect that clobbers should be given without surrounding {}'s. Either way, this should probably not generate invalid code silently.

Related discussion:
text: if OPTIONS.iter().any(|&opt| s == opt) { cx.span_warn(p.last_span, "expected a clobber, found an option"); <ins> } else if s.starts_with("{") || s.ends_with("}") { cx.span_err(p.last_span, "clobber should not be surrounded by braces"); </ins> } clobs.push(s); } }
Code change:
The rust book states that asm! clobbers should be written as "{rdx}" but when you use them as such the clobbers will be silently ignored making for some nasty bugs. output Relevant part of objdump: Relevant LLVM IR: As we can seen in the emitted LLVM IR, the given clobbers are surrounded by {{}}. I'm not sure what effect this has, but it seems like LLVM just silently ignores them. A fix would either be to not send the extra {}'s to LLVM or to edit the documentation to reflect that clobbers should be given without surrounding {}'s. Either way, this should probably not generate invalid code silently.

Related discussion:
text: <ins> // Copyright 2016 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. // ignore-android // ignore-arm // ignore-aarch64 #![feature(asm, rustc_attrs)] #[cfg(any(target_arch = "x86", target_arch = "x86_64"))] #[rustc_error] pub fn main() { unsafe { // clobber formatted as register input/output asm!("xor %eax, %eax" : : : "{eax}"); //~^ ERROR clobber should not be surrounded by braces } } </ins>
Code change:
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-"

Related discussion:
text: use rustc_infer::infer; use rustc_infer::traits::{self, StatementAsExpression}; use rustc_middle::lint::in_external_macro; <del> use rustc_middle::ty::{self, Binder, DefIdTree, IsSuggestable, Ty}; </del> <ins> use rustc_middle::ty::{ self, suggest_constraining_type_params, Binder, DefIdTree, IsSuggestable, ToPredicate, Ty, }; </ins> use rustc_session::errors::ExprParenthesesNeeded; use rustc_span::symbol::sym; use rustc_span::Span;
Code change:
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-"

Related discussion:
text: && !results.expr_adjustments(callee_expr).iter().any(|adj| matches!(adj.kind, ty::adjustment::Adjust::Deref(..))) // Check that we're in fact trying to clone into the expected type && self.can_coerce(*pointee_ty, expected_ty) <ins> && let trait_ref = ty::Binder::dummy(self.tcx.mk_trait_ref(clone_trait_did, [expected_ty])) </ins> // And the expected type doesn't implement `Clone` && !self.predicate_must_hold_considering_regions(&traits::Obligation::new( self.tcx, traits::ObligationCause::dummy(), self.param_env, <del> ty::Binder::dummy(self.tcx.mk_trait_ref( clone_trait_did, [expected_ty], )), </del> <ins> trait_ref, </ins> )) { diag.span_note(
Code change:
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-"

Related discussion:
text: "`{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> } }
Code change:
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-"

Related discussion:
text: self.suggest_derive(err, &preds); } <del> fn suggest_derive( </del> <ins> pub fn suggest_derive( </ins> &self, err: &mut Diagnostic, unsatisfied_predicates: &[(
Code change:
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-"

Related discussion:
text: <ins> // run-rustfix fn wat<T: Clone>(t: &T) -> T { t.clone() //~ ERROR E0308 } #[derive(Clone)] struct Foo; fn wut(t: &Foo) -> Foo { t.clone() //~ ERROR E0308 } fn main() { wat(&42); wut(&Foo); } </ins>
Code change:
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-"

Related discussion:
text: <ins> // run-rustfix fn wat<T>(t: &T) -> T { t.clone() //~ ERROR E0308 } struct Foo; fn wut(t: &Foo) -> Foo { t.clone() //~ ERROR E0308 } fn main() { wat(&42); wut(&Foo); } </ins>