jiebi/CodeConvo huggingface dataset:
Code change:
I'm currently doing some benchmarks and I've seen that is taking a really long time to calculate on wasm. Turns out that none of the helper functions it uses are inlined at all, so it does a ton of unnecessary calls and misses a lot of potential optimizations: The same is probably true for the Float trait.
It seems like initially had a lot more inline annotations but removed them later on. That may have regressed the performance on wasm, but I'm not entirely sure. This makes me wonder if compiler-builtins is even compiled with LTO at all as it supposedly is meant to be?!
Looks like this is indeed a regression that started with Rust 1.44, which switched from compiler-builtins 0.1.25 to 0.1.27, which is where this PR is part of. These are the instructions in 1.43: cc
There's been a few various changes around codegen units handling and compiler-builtins recently, and it looks like this is caused by compiling this crate with . The compiler but with only one CGU.
Ok I've transferred this to the rust-lang/rust repository since this isn't a bug with compiler-builtins itself I believe but rather how we build compiler-builtins. I believe this is an accidental regression from because only part of the compiler knows that compiler-builtins is built with more than one CGU, the rest of the compiler thinks it's one CGU (respecting CLI flags). I'll be opening a PR shortly to fix this.
Assigning as and removing .

Related discussion:
text: fn merge_codegen_units<'tcx>( tcx: TyCtxt<'tcx>, initial_partitioning: &mut PreInliningPartitioning<'tcx>, <del> mut target_cgu_count: usize, </del> <ins> target_cgu_count: usize, </ins> ) { assert!(target_cgu_count >= 1); let codegen_units = &mut initial_partitioning.codegen_units; <del> if tcx.is_compiler_builtins(LOCAL_CRATE) { // Compiler builtins require some degree of control over how mono items // are partitioned into compilation units. Provide it by keeping the // original partitioning when compiling the compiler builtins crate. target_cgu_count = codegen_units.len(); } </del> // Note that at this point in time the `codegen_units` here may not be in a // deterministic order (but we know they're deterministically the same set). // We want this merging to produce a deterministic ordering of codegen units
Code change:
I'm currently doing some benchmarks and I've seen that is taking a really long time to calculate on wasm. Turns out that none of the helper functions it uses are inlined at all, so it does a ton of unnecessary calls and misses a lot of potential optimizations: The same is probably true for the Float trait.
It seems like initially had a lot more inline annotations but removed them later on. That may have regressed the performance on wasm, but I'm not entirely sure. This makes me wonder if compiler-builtins is even compiled with LTO at all as it supposedly is meant to be?!
Looks like this is indeed a regression that started with Rust 1.44, which switched from compiler-builtins 0.1.25 to 0.1.27, which is where this PR is part of. These are the instructions in 1.43: cc
There's been a few various changes around codegen units handling and compiler-builtins recently, and it looks like this is caused by compiling this crate with . The compiler but with only one CGU.
Ok I've transferred this to the rust-lang/rust repository since this isn't a bug with compiler-builtins itself I believe but rather how we build compiler-builtins. I believe this is an accidental regression from because only part of the compiler knows that compiler-builtins is built with more than one CGU, the rest of the compiler thinks it's one CGU (respecting CLI flags). I'll be opening a PR shortly to fix this.
Assigning as and removing .

Related discussion:
text: <del> // Verifies that during compiler_builtins compilation the codegen units are kept // unmerged. Even when only a single codegen unit is requested with -Ccodegen-units=1. // // compile-flags: -Zprint-mono-items=eager -Ccodegen-units=1 #![compiler_builtins] #![crate_type="lib"] #![feature(compiler_builtins)] mod atomics { //~ MONO_ITEM fn compiler_builtins::atomics[0]::sync_1[0] @@ compiler_builtins-cgu.0[External] #[no_mangle] pub extern "C" fn sync_1() {} //~ MONO_ITEM fn compiler_builtins::atomics[0]::sync_2[0] @@ compiler_builtins-cgu.0[External] #[no_mangle] pub extern "C" fn sync_2() {} //~ MONO_ITEM fn compiler_builtins::atomics[0]::sync_3[0] @@ compiler_builtins-cgu.0[External] #[no_mangle] pub extern "C" fn sync_3() {} } mod x { //~ MONO_ITEM fn compiler_builtins::x[0]::x[0] @@ compiler_builtins-cgu.1[External] #[no_mangle] pub extern "C" fn x() {} } mod y { //~ MONO_ITEM fn compiler_builtins::y[0]::y[0] @@ compiler_builtins-cgu.2[External] #[no_mangle] pub extern "C" fn y() {} } mod z { //~ MONO_ITEM fn compiler_builtins::z[0]::z[0] @@ compiler_builtins-cgu.3[External] #[no_mangle] pub extern "C" fn z() {} } </del>
Code change:
Code like Generates the error Which is wrong. is not a type, it's a module.

Related discussion:
text: ValueNS } <ins> #[deriving(Eq)] pub enum NamespaceError { NoError, ModuleError, TypeError, ValueError } </ins> /// A NamespaceResult represents the result of resolving an import in /// a particular namespace. The result is either definitely-resolved, /// definitely- unresolved, or unknown.
Code change:
Code like Generates the error Which is wrong. is not a type, it's a module.

Related discussion:
text: } <del> pub fn namespace_to_str(ns: Namespace) -> ~str { </del> <ins> pub fn namespace_error_to_str(ns: NamespaceError) -> &'static str { </ins> match ns { <del> TypeNS  => ~"type", ValueNS => ~"value", </del> <ins> NoError     => "", ModuleError => "module", TypeError   => "type", ValueError  => "value", </ins> } }
Code change:
Code like Generates the error Which is wrong. is not a type, it's a module.

Related discussion:
text: // * If no duplicate checking was requested at all, do //   nothing. <del> let mut is_duplicate = false; </del> <ins> let mut duplicate_type = NoError; </ins> let ns = match duplicate_checking_mode { ForbidDuplicateModules => { <del> is_duplicate = child.get_module_if_available().is_some(); </del> <ins> if (child.get_module_if_available().is_some()) { duplicate_type = ModuleError; } </ins> Some(TypeNS) } ForbidDuplicateTypes => { match child.def_for_namespace(TypeNS) { Some(def_mod(_)) | None => {} <del> Some(_) => is_duplicate = true </del> <ins> Some(_) => duplicate_type = TypeError </ins> } Some(TypeNS) } ForbidDuplicateValues => { <del> is_duplicate = child.defined_in_namespace(ValueNS); </del> <ins> if child.defined_in_namespace(ValueNS) { duplicate_type = ValueError; } </ins> Some(ValueNS) } ForbidDuplicateTypesAndValues => {
Code change:
Code like Generates the error Which is wrong. is not a type, it's a module.

Related discussion:
text: Some(def_mod(_)) | None => {} Some(_) => { n = Some(TypeNS); <del> is_duplicate = true; </del> <ins> duplicate_type = TypeError; </ins> } }; if child.defined_in_namespace(ValueNS) { <del> is_duplicate = true; </del> <ins> duplicate_type = ValueError; </ins> n = Some(ValueNS); } n } OverwriteDuplicates => None }; <del> if is_duplicate { </del> <ins> if (duplicate_type != NoError) { </ins> // Return an error here by looking up the namespace that // had the duplicate. let ns = ns.unwrap(); self.session.span_err(sp, fmt!("duplicate definition of %s `%s`", <del> namespace_to_str(ns), </del> <ins> namespace_error_to_str(duplicate_type), </ins> self.session.str_of(name))); { let r = child.span_for_namespace(ns); for r.iter().advance |sp| { self.session.span_note(*sp, <del> fmt!("first definition of %s %s here:", namespace_to_str(ns), </del> <ins> fmt!("first definition of %s `%s` here", namespace_error_to_str(duplicate_type), </ins> self.session.str_of(name))); } }
Code change:
Some Miri tests, e.g. , now ICE with This is a regression introduced by The likely cause is Cc
I removed "regression from stable" as Miri does not exist on stable.
Sorry, got it.

Related discussion:
text: impl<'mir, 'tcx, Tag, Extra> Frame<'mir, 'tcx, Tag, Extra> { /// Return the `SourceInfo` of the current instruction. <del> pub fn current_source_info(&self) -> Option<mir::SourceInfo> { self.loc.map(|loc| { let block = &self.body.basic_blocks()[loc.block]; if loc.statement_index < block.statements.len() { block.statements[loc.statement_index].source_info } else { block.terminator().source_info } }) </del> <ins> pub fn current_source_info(&self) -> Option<&mir::SourceInfo> { self.loc.map(|loc| self.body.source_info(loc)) </ins> } }
Code change:
Some Miri tests, e.g. , now ICE with This is a regression introduced by The likely cause is Cc
I removed "regression from stable" as Miri does not exist on stable.
Sorry, got it.

Related discussion:
text: }) // Assert that there is always such a frame. .unwrap(); <ins> // Assert that the frame we look at is actually executing code currently // (`current_source_info` is None when we are unwinding and the frame does // not require cleanup). </ins> let loc = frame.loc.unwrap(); <ins> // If this is a `Call` terminator, use the `fn_span` instead. </ins> let block = &frame.body.basic_blocks()[loc.block]; <del> assert_eq!(block.statements.len(), loc.statement_index); debug!( "find_closest_untracked_caller_location:: got terminator {:?} ({:?})", block.terminator(), block.terminator().kind ); if let TerminatorKind::Call { fn_span, .. } = block.terminator().kind { return fn_span; </del> <ins> if loc.statement_index == block.statements.len() { debug!( "find_closest_untracked_caller_location:: got terminator {:?} ({:?})", block.terminator(), block.terminator().kind ); if let TerminatorKind::Call { fn_span, .. } = block.terminator().kind { return fn_span; } </ins> } <del> unreachable!(); </del> <ins> // This is a different terminator (such as `Drop`) or not a terminator at all // (such as `box`). Use the normal span. frame.body.source_info(loc).span </ins> } /// Allocate a `const core::panic::Location` with the provided filename and line/column numbers.
Code change:
When encountering a , there must be a corresponding in the MIR body. If there isn't, later passes can panic due to indexing out of bounds of the array. The validation pass could detect this problem earlier. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Instructions: Extend the validation pass in by implementing for the MIR visitor: The trait is documented . The method should check that the local exists in , and fail with a descriptive error message if not (by calling , not by panicking directly).
claim
FYI, the validation pass currently fails on even libcore until is merged, so you need to either wait for that, or cherry-pick some commits from there to get it to work. You can test your changes by running (the validator only runs on very little code by default, turns it on for everything).
I wanted to double check, running should fail when I run it, right? It actually passed for me after I merged in your branch from I wonder if I should try clean and build stage 1 again. :
It should pass with applied, but fail on current master.
So your PR fixes this issue () as well?
Ah, no, this issue is just about adding additional validation. It shouldn't actually detect any locals that don't exist. So the command should work both before and after implementing this. If it fails after implementing this, something else is going on that we should look into.
are you still working on this?
No, sorry. Didn’t have time for it. Go ahead.
release-assignment
Would like to work on this, but it seems there is another check, not on the declaration like this one, but on the memory liveness. This should cover the case that the local is not declared (I think), or would it not?

Related discussion:
text: impl<'a, 'tcx> Visitor<'tcx> for TypeChecker<'a, 'tcx> { fn visit_local(&mut self, local: &Local, context: PlaceContext, location: Location) { <ins> if self.body.local_decls.get(*local).is_none() { self.fail( location, format!("local {:?} has no corresponding declaration in `body.local_decls`", local), ); } </ins> if self.reachable_blocks.contains(location.block) && context.is_use() { // Uses of locals must occur while the local's storage is allocated. self.storage_liveness.seek_after_primary_effect(location);
Code change:
Recently enabled benchmarks () frequently fail on arm-android builder on GitHub Actions: The issue looks similar to previously reported .
I'm sorry, I noticed this during my local testing, but figured it was due to my hardware which had a very high parallel count, and it seemed to go away when I lowered the parallel test threads. I also had great difficulty running these tests at -j32 on android as well: They either seemed to hang, or took a very long time to finish. Would people prefer to just disable the bench tests on android, or should we do more investigation?
Again? cc
Looks like didn't fix the "died due to signal 11" errors either :(
hm, yeah if these keep coming back I guess that's reason enough for me to allocate time for it again.
will open a PR disabling collectionsbench on Android for the time being.

Related discussion:
text: <ins> // Disabling on android for the time being // See https://github.com/rust-lang/rust/issues/73535#event-3477699747 #![cfg(not(target_os = "android"))] </ins> #![feature(btree_drain_filter)] #![feature(map_first_last)] #![feature(repr_simd)]
Code change:
Recently enabled benchmarks () frequently fail on arm-android builder on GitHub Actions: The issue looks similar to previously reported .
I'm sorry, I noticed this during my local testing, but figured it was due to my hardware which had a very high parallel count, and it seemed to go away when I lowered the parallel test threads. I also had great difficulty running these tests at -j32 on android as well: They either seemed to hang, or took a very long time to finish. Would people prefer to just disable the bench tests on android, or should we do more investigation?
Again? cc
Looks like didn't fix the "died due to signal 11" errors either :(
hm, yeah if these keep coming back I guess that's reason enough for me to allocate time for it again.
will open a PR disabling collectionsbench on Android for the time being.

Related discussion:
text: // std testing crates, okay for now at least "src/libcore/tests", "src/liballoc/tests/lib.rs", <ins> "src/liballoc/benches/lib.rs", </ins> // The `VaList` implementation must have platform specific code. // The Windows implementation of a `va_list` is always a character // pointer regardless of the target architecture. As a result,
Code change:
The following code: gives the following error: However, is a , so this code can be made to compile by creating a new item: We should suggest this to user when a function is being called in the array initializer. <strikeAssuming that is accepted, we could eventually suggest an inline block.</strikeOn Nightly, we could suggest an inline block. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think this would make a good first issue for someone looking to get started contributing. I'd be happy to mentor anyone who wants to work on this.
claim
Is this still an issue that I can work on?
Yes, assuming that is no longer working on this.
Should I claim it?
It looks like DavidHusicka hasn't had any activity this month, so I think it would be fine for you to take the issue. Feel free to reach out to me if you have any questions about how to get started implementing this.
claim

Related discussion:
text: /// Inline asm operand type must be `Sized`. InlineAsmSized, /// `[T, ..n]` implies that `T` must be `Copy`. <del> RepeatVec, </del> <ins> /// If the function in the array repeat expression is a `const fn`, /// display a help message suggesting to move the function call to a /// new `const` item while saying that `T` doesn't implement `Copy`. RepeatVec(bool), </ins> /// Types of fields (other than the last, except for packed structs) in a struct must be sized. FieldSized {
Code change:
The following code: gives the following error: However, is a , so this code can be made to compile by creating a new item: We should suggest this to user when a function is being called in the array initializer. <strikeAssuming that is accepted, we could eventually suggest an inline block.</strikeOn Nightly, we could suggest an inline block. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think this would make a good first issue for someone looking to get started contributing. I'd be happy to mentor anyone who wants to work on this.
claim
Is this still an issue that I can work on?
Yes, assuming that is no longer working on this.
Should I claim it?
It looks like DavidHusicka hasn't had any activity this month, so I think it would be fine for you to take the issue. Feel free to reach out to me if you have any questions about how to get started implementing this.
claim

Related discussion:
text: use crate::dataflow::impls::MaybeInitializedPlaces; use crate::dataflow::move_paths::MoveData; use crate::dataflow::ResultsCursor; <ins> use crate::transform::{ check_consts::ConstCx, promote_consts::is_const_fn_in_array_repeat_expression, }; </ins> use crate::borrow_check::{ borrow_set::BorrowSet,
Code change:
The following code: gives the following error: However, is a , so this code can be made to compile by creating a new item: We should suggest this to user when a function is being called in the array initializer. <strikeAssuming that is accepted, we could eventually suggest an inline block.</strikeOn Nightly, we could suggest an inline block. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think this would make a good first issue for someone looking to get started contributing. I'd be happy to mentor anyone who wants to work on this.
claim
Is this still an issue that I can work on?
Yes, assuming that is no longer working on this.
Should I claim it?
It looks like DavidHusicka hasn't had any activity this month, so I think it would be fine for you to take the issue. Feel free to reach out to me if you have any questions about how to get started implementing this.
claim

Related discussion:
text: Operand::Copy(..) | Operand::Constant(..) => { // These are always okay: direct use of a const, or a value that can evidently be copied. } <del> Operand::Move(_) => { </del> <ins> Operand::Move(place) => { </ins> // Make sure that repeated elements implement `Copy`. let span = body.source_info(location).span; let ty = operand.ty(body, tcx); if !self.infcx.type_is_copy_modulo_regions(self.param_env, ty, span) { <ins> let ccx = ConstCx::new_with_param_env(tcx, body, self.param_env); let is_const_fn = is_const_fn_in_array_repeat_expression(&ccx, &place, &body); debug!("check_rvalue: is_const_fn={:?}", is_const_fn); </ins> let def_id = body.source.def_id().expect_local(); self.infcx.report_selection_error( &traits::Obligation::new( ObligationCause::new( span, self.tcx().hir().local_def_id_to_hir_id(def_id), <del> traits::ObligationCauseCode::RepeatVec, </del> <ins> traits::ObligationCauseCode::RepeatVec(is_const_fn), </ins> ), self.param_env, ty::Binder::bind(ty::TraitRef::new(
Code change:
The following code: gives the following error: However, is a , so this code can be made to compile by creating a new item: We should suggest this to user when a function is being called in the array initializer. <strikeAssuming that is accepted, we could eventually suggest an inline block.</strikeOn Nightly, we could suggest an inline block. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think this would make a good first issue for someone looking to get started contributing. I'd be happy to mentor anyone who wants to work on this.
claim
Is this still an issue that I can work on?
Yes, assuming that is no longer working on this.
Should I claim it?
It looks like DavidHusicka hasn't had any activity this month, so I think it would be fine for you to take the issue. Feel free to reach out to me if you have any questions about how to get started implementing this.
claim

Related discussion:
text: promotions } <ins> /// This function returns `true` if the function being called in the array /// repeat expression is a `const` function. crate fn is_const_fn_in_array_repeat_expression<'tcx>( ccx: &ConstCx<'_, 'tcx>, place: &Place<'tcx>, body: &Body<'tcx>, ) -> bool { match place.as_local() { // rule out cases such as: `let my_var = some_fn(); [my_var; N]` Some(local) if body.local_decls[local].is_user_variable() => return false, None => return false, _ => {} } for block in body.basic_blocks() { if let Some(Terminator { kind: TerminatorKind::Call { func, destination, .. }, .. }) = &block.terminator { if let Operand::Constant(box Constant { literal: ty::Const { ty, .. }, .. }) = func { if let ty::FnDef(def_id, _) = *ty.kind() { if let Some((destination_place, _)) = destination { if destination_place == place { if is_const_fn(ccx.tcx, def_id) { return true; } } } } } } } false } </ins>
Code change:
The following code: gives the following error: However, is a , so this code can be made to compile by creating a new item: We should suggest this to user when a function is being called in the array initializer. <strikeAssuming that is accepted, we could eventually suggest an inline block.</strikeOn Nightly, we could suggest an inline block. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think this would make a good first issue for someone looking to get started contributing. I'd be happy to mentor anyone who wants to work on this.
claim
Is this still an issue that I can work on?
Yes, assuming that is no longer working on this.
Should I claim it?
It looks like DavidHusicka hasn't had any activity this month, so I think it would be fine for you to take the issue. Feel free to reach out to me if you have any questions about how to get started implementing this.
claim

Related discussion:
text: ObligationCauseCode::Coercion { source: _, target } => { err.note(&format!("required by cast to type `{}`", self.ty_to_string(target))); } <del> ObligationCauseCode::RepeatVec => { </del> <ins> ObligationCauseCode::RepeatVec(is_const_fn) => { </ins> err.note( "the `Copy` trait is required because the repeated element will be copied", ); <ins> if is_const_fn { err.help( "consider creating a new `const` item and initializing with the result  of the function call to be used in the repeat position, like  `const VAL: Type = const_fn();` and `let x = [VAL; 42];`", ); } if self.tcx.sess.is_nightly_build() && is_const_fn { err.help( "create an inline `const` block, see PR  #2920 <https://github.com/rust-lang/rfcs/pull/2920>  for more information", ); } </ins> } ObligationCauseCode::VariableType(hir_id) => { let parent_node = self.tcx.hir().get_parent_node(hir_id);