jiebi/CodeConvo huggingface dataset:
Change:
b.iter(|| v.iter().flat_map(|color| color.rotate_left(8).to_be_bytes()).collect::<Vec<_>>()); } <ins> /// Reference benchmark that `retain` has to compete with. #[bench] fn bench_retain_iter_100000(b: &mut Bencher) { let mut v = Vec::with_capacity(100000); b.iter(|| { let mut tmp = std::mem::take(&mut v); tmp.clear(); tmp.extend(black_box(1..=100000)); v = tmp.into_iter().filter(|x| x & 1 == 0).collect(); }); } </ins> #[bench] fn bench_retain_100000(b: &mut Bencher) { <del> let v = (1..=100000).collect::<Vec<u32>>(); </del> <ins> let mut v = Vec::with_capacity(100000); </ins> b.iter(|| { <del> let mut v = v.clone(); </del> <ins> v.clear(); v.extend(black_box(1..=100000)); </ins> v.retain(|x| x & 1 == 0) }); }

Discussion:
I noticed today that using is much slower than filtering and allocating a new Vector. I realize the former is probably more memory efficient, but I still found it surprising that it would be that much slower (or really slower at all). When testing with this code: on 1.59.0-nightly ( 2021-12-01), I get these benchmark results: on a Ryzen 5900X running Linux. Testing on a different machine (Xeon E3-1271 v3), I get similar numbers: seemed like the obvious choice to me, so it being slower is either a bug or should be documented somewhere. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
i7 8700k windows 10 default configuration: with lto = true rustc 1.59.0-nightly ()
Setting makes the disparity even bigger for me:
It looks like is optimized () for small or large probabilities of keeping elements, i.e. long runs of elements that will be either kept or deleted. on the other hand just reads elements one by one, filters them and writes out those that passed, i.e. it does not care about runs. Since the test-case here drops every second element it's the worst possible case for , possibly even worse than random selection (since random clusters may have runs). Edit: Hrm, the benchmarks look like they're optimizing for high/low retain probabilities; but the code doesn't, it still moves one element at a time when previous ones have been dropped.
Edit: Doh, but at least now we now that caused some major slowdown.
You're not copying the most recent version of retain. has gained a const bool parameter in and thus gets instantiated in two flavors.
I tried a few scenarios that should heavily favor but the effect remains. i7 8700k w10 rustc 1.59.0-nightly ()
I'll take a stab at this. claim
Submitted , if anyone wants to confirm my benchmark results.
Change:
use rustc_errors::{Applicability, ErrorReported}; use rustc_hir as hir; use rustc_hir::def_id::{DefId, LocalDefId, LOCAL_CRATE}; <ins> use rustc_hir::intravisit::Visitor; </ins> use rustc_hir::lang_items::LangItem; <del> use rustc_hir::{ItemKind, Node}; </del> <ins> use rustc_hir::{def::Res, ItemKind, Node, PathSegment}; </ins> use rustc_infer::infer::type_variable::{TypeVariableOrigin, TypeVariableOriginKind}; use rustc_infer::infer::{RegionVariableOrigin, TyCtxtInferExt}; use rustc_middle::ty::fold::TypeFoldable;

Discussion:
Following the improvement for the diagnostic of the error reported in this issue , it would be nice (depending on how is prioritized) to have the same error message when instead of returning the function returns . When is returned I get a nice error message (on rustc 1.47): But if is used I get: with no suggestion to spell the type.
remove-assignment feel free to re-claim if you are working on this.
Change:
let mut cargo = builder.cargo(compiler, mode, source_type, target, cmd_kind); match cmd_kind { <del> // No need to configure the target linker for these command types. Kind::Clean | Kind::Check | Kind::Suggest | Kind::Format | Kind::Setup => {} </del> <ins> // No need to configure the target linker for these command types, // as they don't invoke rustc at all. Kind::Clean | Kind::Suggest | Kind::Format | Kind::Setup => {} </ins> _ => { cargo.configure_linker(builder); }

Discussion:
Some time over the last days, this started happening: The third invocation should finish immediately, but instead it rebuilds everything. So what is usually a 1s edit-test cycle now takes a full minute. Cc
I wonder if has anything to do with this.
Yeah that sounds likely. Configuring the linker sets some env vars and when those differ between check and test builds, everything gets rebuilt.
Should we revert that PR then? Or is there some other short-term fix? This is a significant hurdle for rustc development right now.
I suppose that we could for now just skip the command from I tried the three commands that you have posted, and the last command did not rebuild anything (or rather, everything was fresh). What code should I modify between running these commands to reproduce the behavior that the third command rebuilds a lot of stuff?
Nevermind, I reproduced it. And the fix with removing check from configuring the linker works. I'll send a PR.
I think excluding is quite good short-term fix.
Change:
<ins> error[E0403]: the name `T` is already used for a generic parameter in this item's generic parameters --> $DIR/issue-86756.rs:1:14 | LL | trait Foo<T, T = T> {} |           -  ^ already used |           | |           first use of `T` error[E0412]: cannot find type `dyn` in this scope --> $DIR/issue-86756.rs:5:10 | LL | fn eq<A, B>() { |           - help: you might be missing a type parameter: `, dyn` LL |     eq::<dyn, Foo> |          ^^^ not found in this scope warning: trait objects without an explicit `dyn` are deprecated --> $DIR/issue-86756.rs:5:15 | LL |     eq::<dyn, Foo> |               ^^^ help: use `dyn`: `dyn Foo` | = note: `#[warn(bare_trait_objects)]` on by default = warning: this is accepted in the current edition (Rust 2015) but is a hard error in Rust 2021! = note: for more information, see issue #80165 <https://github.com/rust-lang/rust/issues/80165> error[E0107]: missing generics for trait `Foo` --> $DIR/issue-86756.rs:5:15 | LL |     eq::<dyn, Foo> |               ^^^ expected at least 1 generic argument | note: trait defined here, with at least 1 generic parameter: `T` --> $DIR/issue-86756.rs:1:7 | LL | trait Foo<T, T = T> {} |       ^^^ - help: add missing generic argument | LL |     eq::<dyn, Foo<T>> |               ^^^^^^ error: aborting due to 3 previous errors; 1 warning emitted Some errors have detailed explanations: E0107, E0403, E0412. For more information about an error, try `rustc --explain E0107`. </ins>

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
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low
Change:
config.llvm_build_config = llvm.build_config.clone().unwrap_or(Default::default()); let asserts = llvm_assertions.unwrap_or(false); <del> config.llvm_from_ci = match llvm.download_ci_llvm { Some(StringOrBool::String(s)) => { assert_eq!(s, "if-available", "unknown option `{s}` for download-ci-llvm"); crate::core::build_steps::llvm::is_ci_llvm_available(&config, asserts) } Some(StringOrBool::Bool(b)) => b, None => { config.channel == "dev" && crate::core::build_steps::llvm::is_ci_llvm_available(&config, asserts) } }; </del> <ins> config.llvm_from_ci = config.parse_download_ci_llvm(llvm.download_ci_llvm, asserts); </ins> if config.llvm_from_ci { // None of the LLVM options, except assertions, are supported

Discussion:
The profile is intended not just for people working on LLVM itself, but also anyone who touches codegen but not LLVM. For example, anyone who modifies or is only changing the IR we send to LLVM, not LLVM itself. We should keep on for them but not for , but ideally we wouldn't build LLVM from source if it's unmodified. points out some things that we should fix before enabling that option by default for the profile: Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim Should all 3 tasks be in one PR or is it 3 separate PR's?
I'd say it depends how challenging they are - if it's simple to fix all three in one PR that seems fine, but if it takes a more than a day to do one of the tasks, it probably makes sense to open a PR for it early.
I think I can tackle points 1 and 3 by tonight so I'll make that into one PR. I'll open a separate PR for the second point, since I think it has more work involved, if that's alright :)
release-assignment
Change:
<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. #![feature(rustc_attrs)] #![allow(warnings)] mod foo { pub fn bar() {} } pub use foo::*; use b::bar; mod foobar { use super::*; } mod a { pub mod bar {} } mod b { pub use a::bar; } #[rustc_error] fn main() {} //~ ERROR compilation successful </ins>

Discussion:
Unfortunately, I can't reproduce this at a smaller scale. This issue occurs with as of commit . Rust version is Currently the tests (run from the directory with ) pass. However, applying the following patch: causes the following compiler error: which is claiming that an import conflicts with itself. I have pushed up the branch with that change applied for easy reproduction. Again, I'm sorry that I cannot provide a report on a smaller scale, but this appears to be some edge case blowing up. I have no clue why adding a module with a few imports and nothing else would be causing this issue.
Bisecting to find the nightly which caused this
I can confirm that this issue does not occur on . Unfortunately, there was a bug that prevented us from compiling on that wasn't fixed until , so I cannot provide anything more specific than that.
cc
Thanks for the report! This bug was introduced in . I diagnosed the issue and will fix it ASAP.
Change:
<ins> // run-rustfix // https://github.com/rust-lang/rust/issues/79076 use std::cmp::PartialEq; #[derive(Clone, Eq)] //~ ERROR [E0277] pub struct Struct<T: std::clone::Clone>(T); impl<T: Clone, U> PartialEq<U> for Struct<T> where U: Into<Struct<T>> + Clone { fn eq(&self, _other: &U) -> bool { todo!() } } fn main() {} </ins>

Discussion:
Let's say I want my struct to be comparable with anything that can be converted into the struct itself, but the actual comparison requires : () Errors:
For reference,
Change:
Windows.Win32.Storage.FileSystem.FILE_ADD_FILE Windows.Win32.Storage.FileSystem.FILE_ADD_SUBDIRECTORY Windows.Win32.Storage.FileSystem.FILE_ALL_ACCESS <ins> Windows.Win32.Storage.FileSystem.FILE_ALLOCATION_INFO </ins> Windows.Win32.Storage.FileSystem.FILE_APPEND_DATA Windows.Win32.Storage.FileSystem.FILE_ATTRIBUTE_ARCHIVE Windows.Win32.Storage.FileSystem.FILE_ATTRIBUTE_COMPRESSED

Discussion:
Reported on discord, using will fail on Windows if the file is hidden. This also affects methods like or that open the file the same way. The reason for this is that we use , which has : So to make it work the caller needs to match the requested attributes to the existing attributes at the time of opening. It was suggested we could instead use and then manually truncate the file using to zero.
Manually truncating would require also clearing the alternate data streams too, right? And it would presumably stop erroring if another process still has the file open and instead corrupt the file fron the view of the other process.
No? The proposed solution would work the same was as in the case where the file already exists. Which we use for .
Right, got confused with .
Change:
}; let test = opt_present(match, "test"); <del> let mode = if opt_present(match, "G") { if opt_present(match, "mode") { fail "--mode and -G both provided"; } if opt_present(match, "g") { fail "-G and -g both provided"; } system_mode } else if opt_present(match, "g") { if opt_present(match, "mode") { fail "--mode and -g both provided"; } if opt_present(match, "G") { fail "-G and -g both provided"; } user_mode } else if opt_present(match, "mode") { alt getopts::opt_str(match, "mode") { "system" { system_mode } "user" { user_mode } "local" { local_mode } _ { fail "argument to `mode` must be one of `system`" + ", `user`, or `normal`"; </del> <ins> let G = opt_present(match, "G"); let g = opt_present(match, "g"); let m = opt_present(match, "mode"); let is_install = vec::len(match.free) > 1u && match.free[1] == "install"; if G && g { fail "-G and -g both provided"; } if g && m { fail "--mode and -g both provided"; } if G && m { fail "--mode and -G both provided"; } let mode = if is_install { if G { system_mode } else if g { user_mode } else if m { alt getopts::opt_str(match, "mode") { "system" { system_mode } "user" { user_mode } "local" { local_mode } _ { fail "argument to `mode` must be one of `system`" + ", `user`, or `local`"; } </ins> } <del> } } else { local_mode }; if mode == system_mode { // FIXME: Per discussion on #1760, we need to think about how // system mode works. It should install files to the normal // sysroot paths, but it also needsd an area to place various // cargo configuration and work files. fail "system mode does not exist yet"; } </del> <ins> } else { local_mode } } else { system_mode }; </ins> {test: test, mode: mode, free: match.free} } fn configure(opts: options) -> cargo { <ins> let syscargo = result::get(get_cargo_sysroot()); </ins> let get_cargo_dir = alt opts.mode { system_mode { get_cargo_sysroot } user_mode { get_cargo_root }

Discussion:
There's some code for this in cargo now, but it doesn't quite do the right thing. See .
Also worth considering the difference between sysroot and the install prefix - they are not the same. For instance, I never install cargo, always running it out of the build directory, in which case the build directory is sysroot.
I think this is resolved.
Change:
<del> use rustc_ast::{self as ast, token}; </del> <ins> use rustc_ast as ast; </ins> use rustc_data_structures::fx::{FxHashMap, FxHashSet}; use rustc_data_structures::sync::Lrc; use rustc_errors::{ColorConfig, ErrorReported, FatalError};

Discussion:
We have a Rust-2015 doc test which has an which started failing to build on nightly 2021-11-21 (but passes on stable/2021-11-20). It now fails with
Probably caused by (; no rollup?).
That seems unlikely, is more plausible. doesn't affect doctests.
Oh, I think I got misled by the "rustdoc" bit.
I can't reproduce this. I tried /// extern crate inner; /// and running , but all the tests passed fine. can you link the original code?
The failure is You can see the first failure in CI at
The following seems like a minimal reproduction when used with 2015: /// extern crate mycrate; /// mycrate::foo(); /// Bisected to .
cc , I think it might make sense to revert temporarily unless you already have an idea for a fix.
Change:
// we exit. struct Bomb<B: ExtraBackendMethods> { coordinator_send: Sender<Box<dyn Any + Send>>, <del> result: Option<WorkItemResult<B>>, </del> <ins> result: Option<Result<WorkItemResult<B>, FatalError>>, </ins> worker_id: usize, } impl<B: ExtraBackendMethods> Drop for Bomb<B> { fn drop(&mut self) { let worker_id = self.worker_id; let msg = match self.result.take() { <del> Some(WorkItemResult::Compiled(m)) => { </del> <ins> Some(Ok(WorkItemResult::Compiled(m))) => { </ins> Message::Done::<B> { result: Ok(m), worker_id } } <del> Some(WorkItemResult::NeedsFatLTO(m)) => { </del> <ins> Some(Ok(WorkItemResult::NeedsFatLTO(m))) => { </ins> Message::NeedsFatLTO::<B> { result: m, worker_id } } <del> Some(WorkItemResult::NeedsThinLTO(name, thin_buffer)) => { </del> <ins> Some(Ok(WorkItemResult::NeedsThinLTO(name, thin_buffer))) => { </ins> Message::NeedsThinLTO::<B> { name, thin_buffer, worker_id } } <del> None => Message::Done::<B> { result: Err(()), worker_id }, </del> <ins> Some(Err(FatalError)) => { Message::Done::<B> { result: Err(Some(WorkerFatalError)), worker_id } } None => Message::Done::<B> { result: Err(None), worker_id }, </ins> }; drop(self.coordinator_send.send(Box::new(msg))); }

Discussion:
Ok, so rustc outputting to /dev/null is a bit pathelogical but it used to not ICE the compiler. If you checkout and from dir tests/suite/futurescore run: rustc --crate-type lib -o /dev/null Then rustc is vexed: (ICEs on stable and nightly) The irony is that this is in the test suite of a rust code minimisation project.... Let me minimise the reproduction of the problem...
Thanks to rust-reduce I managed to get the repro down to: Interestingly it doesn't ICE on playground - I'm guessing playground is on linux?
Indeed
triage: P-medium, removing nomination tag, assigning self.
hmm. I nonetheless see an ICE on my own Linux machine. (There is probably some other reason the ICE does not replicate on the playpen.)
Change:
// equality assert_eq!(v4_1, v4_1); assert_eq!(v6_1, v6_1); <del> assert_eq!(v4_1, SocketAddr::V4(v4_1)); assert_eq!(v6_1, SocketAddr::V6(v6_1)); </del> assert_eq!(SocketAddr::V4(v4_1), SocketAddr::V4(v4_1)); assert_eq!(SocketAddr::V6(v6_1), SocketAddr::V6(v6_1)); <del> assert!(v4_1 != SocketAddr::V6(v6_1)); assert!(v6_1 != SocketAddr::V4(v4_1)); </del> assert!(v4_1 != v4_2); assert!(v6_1 != v6_2);

Discussion:
as a minimal example. Unclear whether this is a new trait impl or some regression elsewhere.
has been in 1.45 which would explain this:
There were roughly ~15-20 crates that failed in the crater run due to this, mostly in tests. I'm not sure whether we think that's sufficient reasoning to drop the impl, I get that it can be useful... cc (and relabeling as this is not an inference regression)
Can we add to the types? That would provide a path to patch the regression. Being able to easily compare a socketaddr to a string seems pretty valuable for testing, I'd rather see we make it easier than require the turbofish. for the PR that these impls
I’m not in favor since this would blur the difference between "this string does not parse as a valid socket address" v.s. "it does, but one not equal to that one". Code that doesn’t care about that difference can already use and compare strings.
mostly cared about PartialOrd and Ord impls (as you can tell from the PR title). Unlike PartialEq, none existed before on SocketAddr so they won't be problematic. I think the PR included new PartialEq impls only in support of heterogeneous PartialOrd (see ) which was ultimately removed from the PR anyway. I opened to revert the new PartialEq impls, leaving the PartialOrd and Ord impls from .
Change:
<ins> // Moving from a reference/raw pointer should be an error, even when they're // the field of a union. #![feature(untagged_unions)] union Pointers { a: &'static String, b: &'static mut String, c: *const String, d: *mut String, } unsafe fn move_ref(u: Pointers) -> String { *u.a //~^ ERROR cannot move out of `*u.a` } unsafe fn move_ref_mut(u: Pointers) -> String { *u.b //~^ ERROR cannot move out of `*u.b` } unsafe fn move_ptr(u: Pointers) -> String { *u.c //~^ ERROR cannot move out of `*u.c` } unsafe fn move_ptr_mut(u: Pointers) -> String { *u.d //~^ ERROR cannot move out of `*u.d` } fn main() {} </ins>

Discussion:
The following code ICEs, when it should produce a cannot move error
Worse, the following compiles:
regression from stable-to-beta and stable-to-nightly
triage: P-high
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. #![feature(never_type)] #![allow(dead_code)] #![allow(path_statements)] #![allow(unreachable_patterns)] fn never_direct(x: !) { x; } fn never_ref_pat(ref x: !) { *x; } fn never_ref(x: &!) { let &y = x; y; } fn never_pointer(x: *const !) { unsafe { *x; } } fn never_slice(x: &[!]) { x[0]; } fn never_match(x: Result<(), !>) { match x { Ok(_) => {}, Err(_) => {}, } } pub fn main() { } </ins>

Discussion:
The following error results from dereferencing a as in this code:
What’s the correct fix? Compiler error with a nice error message?
I think this should compile and UB, but a lint against this is probably a good idea.
Reduced test case:
I'm working on a fix for this. Progress on . The idea is to avoid the typing issues entirely by terminating the blocks with as soon as a -value is constructed. Currently the examples given here are fixed, but some more convoluted examples still crash.
Change:
[[package]] name = "tester" <del> version = "0.6.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "7647e6d732eb84375d8e7abda37818f81861ddbfc7235e33f4983cb254b71e4f" dependencies = [ "getopts", "libc", "term 0.6.0", ] [[package]] name = "tester" </del> version = "0.7.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "ee72ec31009a42b53de9a6b7d8f462b493ab3b1e4767bda1fcdbb52127f13b6c"

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.
triage: P-medium, removing nomination label.
Change:
#![feature(unboxed_closures)] #![feature(unsafe_cell_raw_get)] #![feature(unwind_attributes)] <ins> #![feature(unwrap_infallible)] </ins> #![feature(vec_into_raw_parts)] #![feature(vec_spare_capacity)] // NB: the above list is sorted to minimize merge conflicts.

Discussion:
See for an example of the problem. Here we panic without any landing pads available upstack, because we are already the top-most(-ish) frame in the first place. This is UB.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical
Playground link with full code:
FWIW, Miri does detect this. :)
Change:
#### Machine-dependent integer types <del> The Rust type `uint` [^rustuint] is an unsigned integer type with target-machine-dependent size. Its size, in bits, is equal to the number of bits required to hold any memory address on the target machine. The Rust type `int` [^rustint]  is a two's complement signed integer type with target-machine-dependent size. Its size, in bits, is equal to the size of the rust type `uint` on the same target machine. [^rustuint]: A Rust `uint` is analogous to a C99 `uintptr_t`. [^rustint]: A Rust `int` is analogous to a C99 `intptr_t`. </del> <ins> The `uint` type is an unsigned integer type with the same number of bits as the platform's pointer type. It can represent every memory address in the process. The `int` type is a signed integer type with the same number of bits as the platform's pointer type. The theoretical upper bound on object and array size is the maximum `int` value. This ensures that `int` can be used to calculate differences between pointers into an object or array and can address every byte within an object along with one byte past the end. </ins> ### Textual types

Discussion:
LLVM does not support objects larger than bytes, because it represents sizes as counts of bits. Currently, to be safe, I'm blocking compile-time objects bigger than 2 GiB (in case LLVM uses an int count of bytes somewhere). It would be nice to find out how much can we increase this, especially on 64-bit targets.
bounds object size by 2 GiB on 32-bit architectures and 128 TiB () on 64-bit architectures.