jiebi/CodeConvo huggingface dataset:
Change:
pub cmd: Subcommand, pub incremental: bool, pub dry_run: DryRun, <ins> /// Arguments appearing after `--` to be forwarded to tools, /// e.g. `--fix-broken` or test arguments. pub free_args: Vec<String>, </ins> /// `None` if we shouldn't download CI compiler artifacts, or the commit to download if we should. #[cfg(not(test))] download_rustc_commit: Option<String>,

Discussion:
Right now, x.py is pretty inconsistent with cargo's CLI. To pass arguments to compiletest, you use ; to pass arguments to you use ; to pass arguments to cargo you use CARGOFLAGS. I would like to unify these with the same syntax as cargo: would behave the same as today would behave the same as would behave the same as today, except that it would only pass it to cargo commands invoked by bootstrap, not when building bootstrap itself (avoiding the "argument --fix-broken not expected" error you'd get today). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Looking at the current setup for argument parsing, it appears that getopts::Options struct doesn't have a state engine based parser, so it wont be able to parse -- as a state changing flag. I'm thinking probably parse and translate the args in python then just pass it on to the bootstrap executable, (unless someone here has a better idea).
let's not put any logic in python if we can help it, it's going away soon: . I think it would be ok to switch to or another arg parser if it makes things easier.
Ah, I was thinking something like getting rid of the python script was going to happen someday. will probably do for the functionality we will need from it.
I'm out of town for the rest of the week so if anyone would like to take this issue while I'm away, go for it.
Change:
<ins> // check-pass fn foo<F, G>(_: G, _: Box<F>) where F: Fn(), G: Fn(Box<F>), { } fn main() { foo(|f| (*f)(), Box::new(|| {})); } </ins>

Discussion:
Problematic code: Minimal reproduction: This ICE happens on both nightly and stable. rustc 1.42.0-nightly ( 2020-01-06) binary: rustc commit-hash: commit-date: 2020-01-06 host: x86_64-unknown-linux-gnu release: 1.42.0-nightly LLVM version: 9.0 Backtrace:
I'm not sure how to reproduce the ICE given the two snippets at the top. Can you clarify the minimal reproduction: how do I reproduce it in the playground?
Simplified:
The failure occurs here: I guess we can add to first arm (), is it safe?
triage: P-high. Removing I-nominated label.
Change:
Entry::Occupied(entry) => Some(entry.get().clone()), Entry::Vacant(entry) => { // ensure that we don't place any AllocIds at the very beginning <del> // of the metadata file, because that would end up making our 0 and 1 indices </del> <ins> // of the metadata file, because that would end up making our indices </ins> // not special. This is essentially impossible, but let's make sure <del> assert!(pos != 0 && pos != 1); </del> <ins> assert!(pos >= interpret::SHORTHAND_START); </ins> entry.insert(pos); None },

Discussion:
fresh clone of using local Rust and Cargo latest nightly (also occurs in beta-1.25.0), MSVC x64 with Visual Studio 2017 In : set and to Rustup's proxies set (happens only in debug mode) set (specific value doesn't appear to affect the issue) run It gets to this point and ICEs: I grepped the error message () and it points to which appears to be associated with incremental compilation, which makes sense because this only triggers when building in debug mode and setting avoids the ICE. cc rust-lang/cargo
There's a very high chance that this is fixed by
I'll try to build the latest master and see what happens.
Nope, just changed the file the error is emitted from. I have the backtrace here if you like but it's more than 100 frames deep so I don't know how much context you need.
Thanks. I'll have a look. No need for a backtrace
Repro: The problem is that statics don't have allocations (because it makes no sense for them to have usable memory during const evaluation). This is easy to fix :)
Change:
<ins> warning: ambiguous wide pointer comparison, the comparison includes metadata which may not be expected --> $DIR/ambiguous_wide_pointer_comparisons_suggestions.rs:8:13 | LL |     let _ = a == b; |             ^^^^^^ | = note: `#[warn(ambiguous_wide_pointer_comparisons)]` on by default help: use `std::ptr::addr_eq` or untyped pointers to only compare their addresses | LL |     let _ = std::ptr::addr_eq(a, b); |             ++++++++++++++++++ ~  + help: use explicit `std::ptr::eq` method to compare metadata and addresses | LL |     let _ = std::ptr::eq(a, b); |             +++++++++++++ ~  + warning: 1 warning emitted </ins>

Discussion:
No response The lint is marked able but applying the suggestion fails: ` No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Same problem with
claim
I think this is a known issue with with applying all suggestions even if they are multually exclusive. I'm pretty sure there's nothing to do in the lint, it correctly suggests the two (valid) suggestions, only one of them should be applied.
Well we can either remove one of the suggestions or make the lint MaybeIncorrect or something?
I think this is We can't remove one of the suggestions, they are both necessary. We can however make them for the time being.
That is indeed unfortunate.
Change:
use rustc_data_structures::fx::FxHashMap; use rustc_data_structures::fx::FxHashSet; use rustc_data_structures::graph::dominators::Dominators; <del> use rustc_data_structures::stack::ensure_sufficient_stack; </del> use rustc_index::bit_set::BitSet; use rustc_index::{Idx, IndexSlice, IndexVec}; use rustc_serialize::{Decodable, Encodable};

Discussion:
tracking issue: Inspired by comment in For things like it'd be nice to not have to even give LLVM the code for the else branch to have to emit. Ought to save time and binary size. Tentatively marked mir-opt, since we presumably still need to make the MIR for it, in order to borrow-check and such the unreachable code. But might need to be codegen-time instead to pick up on monomorphized inline constants. Hopefully should be doable relatively easily when the const is an inline const, since that forces const folding already, and thus there should just be a in the MIR.
Well, turns out this already works for simple constants in MIR! However, the place I actually needed it was more like , which doesn't work with today. So maybe come back to this once that's fixed.
This should be done by which AFAIK is run unconditionally. I wonder if its match needs to be expanded? Is there mcve?
The problem is that this can't be done on generic constants, as we don't mir-optimize post-monomorphization. We could start doing some benchmarks to see how bad running all mir opts (or at least a select few) would be if we duplicated, substituted and optimized MIR bodies for concrete generic parameters.
I would say qualifies as an MCVE as the monomorphized gives the following llvm ir
Maybe it should also be evaluated together with polymorphization or constevaluatablechecked since those can cut down on the duplication before applying further optimizations.
Bonus points if this can avoid monomorphizing functions called in the dead code too. Demo extracted from : (cc ) Would be great to not codegen all the downstream stuff that's only called in the else block of a .
FYI this should work with
Totally wild (and probably bad) idea: could we avoid borrow-checking unreachable code? After all, the purpose of borrow-checking is to prevent memory unsafety at runtime, but unreachable code cannot be memory unsafe, because it never executes!
We already do! As a , (But this isn't really the right issue to discuss possible extensions to that.)
This seems closely related to and
recent PR seems related here? If the condition becomes a constant during codegen, we should be entirely skipping it now and not even generate LLVM IR.

However, if that dead code calls functions, those still get codegen'd as usual -- the collector that determines which function to codegen doesn't know about dead branches. We'd have to embed a (simple) monomorphization-time reachability analysis in the collector to fix that.
Change:
<del> error[E0433]: failed to resolve: could not find `xcrate` in `{{root}}` </del> <ins> error[E0433]: failed to resolve: could not find `xcrate` in crate root </ins> --> $DIR/non-existent-2.rs:4:15 | LL |     let s = ::xcrate::S; <del> |               ^^^^^^ could not find `xcrate` in `{{root}}` </del> <ins> |               ^^^^^^ could not find `xcrate` in crate root </ins> error: aborting due to previous error

Discussion:
Test program: This produces the following error messages: Both the error and the help seem entirely unhelpful. The error suggests that it looked for a function in the crate root, but in fact it looked for a crate . The whole "possible candidate" help seems incorrect, and adding that line would lead to a compilation failure.
cc
This is still an issue, but at least the incorrect help message is no longer displayed:
Change:
for (j, &tupled_arg_ty) in tupled_arg_tys.iter().enumerate() { let dst = StructGEP(bcx, llval, j); let arg = &self.fn_ty.args[idx]; <ins> idx += 1; </ins> let b = &bcx.build(); if common::type_is_fat_ptr(bcx.tcx(), tupled_arg_ty) { let meta = &self.fn_ty.args[idx];

Discussion:
This code compiles fine on stable/beta, but ICEs on nightly: cc happened last night, maybe recent trans changes?
That's weird...
Change:
<ins> // Regression test for #74429, where we didn't think that a type parameter // outlived `ReEmpty`. // check-pass use std::marker::PhantomData; use std::ptr::NonNull; pub unsafe trait RawData { type Elem; } unsafe impl<A> RawData for OwnedRepr<A> { type Elem = A; } unsafe impl<'a, A> RawData for ViewRepr<&'a A> { type Elem = A; } pub struct OwnedRepr<A> { ptr: PhantomData<A>, } // these Copy impls are not necessary for the repro, but allow the code to compile without error // on 1.44.1 #[derive(Copy, Clone)] pub struct ViewRepr<A> { life: PhantomData<A>, } #[derive(Copy, Clone)] pub struct ArrayBase<S> where S: RawData, { ptr: NonNull<S::Elem>, } pub type Array<A> = ArrayBase<OwnedRepr<A>>; pub type ArrayView<'a, A> = ArrayBase<ViewRepr<&'a A>>; impl<A, S> ArrayBase<S> where S: RawData<Elem = A>, { pub fn index_axis(&self) -> ArrayView<'_, A> { unimplemented!() } pub fn axis_iter<'a>(&'a self) -> std::iter::Empty<&'a A> { unimplemented!() } } pub fn x<T: Copy>(a: Array<T>) { // drop just avoids a must_use warning drop((0..1).filter(|_| true)); let y = a.index_axis(); a.axis_iter().for_each(|_| { drop(y); }); } fn main() {} </ins>

Discussion:
I tried this code: I expected to see this happen: On Rust 1.44.0, this compiles. Instead, this happened: :
For reproduction, the following is used.
This is a regression from stable to nightly.
Let’s bisect this and try to find an MCVE. ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
The code succeeds to compile on 1.44.1 and fails on 1.45, so this is actually a stable-to-stable regression.
Assigning as and removing .
So far I've reduced it to this, which depends only on (without the feature):
: searched nightlies: from nightly-2020-04-20 to nightly-2020-06-02 regressed nightly: nightly-2020-05-25 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsregressed in
The reproduction does not produce error in . However, I find this throws error on this nightly, as well as on 1.45.0. Here is an even shorter one: The line seems critical. Without this, there will be no reproduction with both snippets. This is also reproducible on the nightly .
cc
The PR that made my reduced code (without ) start successfully compiling again is , in case it helps show what's going on. <details<summaryFull bisect-rustc</summarysearched nightlies: from nightly-2020-05-25 to nightly-2020-07-17 regressed nightly: nightly-2020-06-24 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </summary
Single-crate repro:
I can volunteer myself for looking into the issue. I have a question about the region inference.

Is there a way to visualize, or trace the region inference? Guidance and mentoring instructions are very welcome. :smile:
Change:
for _ in range(0, skip) { s.push(' '); } <del> let orig = fm.get_line(lines.lines[0] as int); for pos in range(0u, left-skip) { let cur_char = orig.as_bytes()[pos] as char; // Whenever a tab occurs on the previous line, we insert one on // the error-point-squiggly-line as well (instead of a space). // That way the squiggly line will usually appear in the correct // position. match cur_char { 't' => s.push('t'), _ => s.push(' '), }; </del> <ins> if let Some(orig) = fm.get_line(lines.lines[0]) { for pos in range(0u, left - skip) { let cur_char = orig.as_bytes()[pos] as char; // Whenever a tab occurs on the previous line, we insert one on // the error-point-squiggly-line as well (instead of a space). // That way the squiggly line will usually appear in the correct // position. match cur_char { 't' => s.push('t'), _ => s.push(' '), }; } </ins> } try!(write!(&mut err.dst, "{}", s)); let mut s = String::from_str("^"); let hi = cm.lookup_char_pos(sp.hi); if hi.col != lo.col { // the ^ already takes up one space <del> let num_squigglies = hi.col.to_uint()-lo.col.to_uint()-1u; </del> <ins> let num_squigglies = hi.col.to_uint() - lo.col.to_uint() - 1u; </ins> for _ in range(0, num_squigglies) { s.push('~'); }

Discussion:
When trying to build with I'm getting
Is there a temporary workaround? Thanks!
Most likely change the occurrences of (or ) to . Like .
I just tripped over this ICE in serde. I love c-reduce. It came up with the following code that reproduces the bug by reducing 203K down to this in 15 minutes: Here's the error:
Change:
<ins> #![feature(generic_const_exprs)] #![feature(adt_const_params)] #![allow(incomplete_features)] #![allow(dead_code)] #[derive(PartialEq, Eq)] struct U; struct S<const N: U>() where S<{ U }>:; //~^ ERROR: overflow evaluating the requirement `S<{ U }> well-formed` fn main() {} </ins>

Discussion:
The compiler hangs on: searched nightlies: from nightly-2022-06-16 to nightly-2022-10-28 regressed nightly: nightly-2022-06-30 searched commit range: regressed commit: () label +A-const-generics +F-genericconstexprs +I-hang +T-compiler
Change:
<ins> error[E0133]: use of extern static is unsafe and requires unsafe function or block --> $DIR/issue-28575.rs:8:5 | LL |     FOO() |     ^^^ use of extern static | = note: extern statics are not controlled by the Rust type system: invalid data, aliasing violations or data races will cause undefined behavior error: aborting due to previous error For more information about this error, try `rustc --explain E0133`. </ins>

Discussion:
When learning async/await feature I was struggling with running multiple tasks simultaneously. Loop causes compiler to crash Github Action crash output: I expected to see this happen: Error message if something goes wrong. Instead, this happened: Compiler crashed Crash happens on macOS rustc 1.40 / Linux rustc 1.40 / Linux rustc 1.39 ( github actions ) :
If you could provide an example that ICEs in e.g. the playground that would be helpful towards fixing the issue. :)
Provided example is pretty small, but it is dependent on tokio and actix-web. I do not know how to create such an example in playground, I do know know how I can replace async tokio::sync::mpsc with standard library which does not have async alternative as far as i know. I have tried to simplify code but then crash disappear. Just putting everything into one file and crash is gone, code wont compile and reasonable errors show up.
Visiting from triage.. we decided that as the first step we should reduce this reproducer to a more self-contained one.
Can repro. Will try and min.
Reduced version so far is here:
This no longer ICEs on the latest nightly.
Let's see if we can shrink further so that we can add a test. ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
I’ve reduced it quite a bit. Down to dependencies on only. Appears to need 2 crates.

I hit this problem while trying to make a task joining function. The problem occured when I started messing around with Arc<RwLock<FuturesUnordered. The nightly compiler crashes on this too. Problematic code: Clone the smtpbis repo on the rustice branch. : rustc 1.39.0 ( 2019-11-04) binary: rustc commit-hash: commit-date: 2019-11-04 host: x86_64-unknown-linux-gnu release: 1.39.0 LLVM version: 9.0 Backtrace:
for exact reproduction:
Does this reproduce on nightly?
yes, I get the error using rustc 1.41.0-nightly ( 2019-11-28)
line seems to be the culprit. It only exhibits when going over crate bound (at least I couldn't minify it further). in the binaries folder:
cc
triage: P-high, at least to identify whether this is a long-standing bug or a stable-to-stable regression. Removing nomination.
This won't build on 1.30:
Removing and as the bug's been fixed in , but leaving open to add a regression test.
I'm confused. Did you add a testcase for this or not?
As discussed in , we didn't add the test case there due to diffs of diagnostics on some environment.
Change:
self.draw_code_line( &mut buffer, &mut row_num, <del> &Vec::new(), </del> <ins> &[], </ins> p + line_start, l, show_code_change,

Discussion:
The bug is in the help section of the "missing lifetime specifier" error (E0106). When the method head is formatted over multiple lines, then green highlighting will be misaligned. I tried this code: I expected to see this happen: For the function it looks like this, which is fine <img width="417" alt="image" src="https://user-"Instead, this happened: But for the function the highlight is misaligned <img width="564" alt="image" src="https://user-"<!-- 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. --: also on stable: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details
Change:
use crate::builder::Kind; use crate::config::{LlvmLibunwind, TargetSelection}; use crate::util::{ <del> exe, libdir, mtime, output, run, run_suppressed, symlink_dir, try_run_suppressed, </del> <ins> dir_is_empty, exe, libdir, mtime, output, run, run_suppressed, symlink_dir, try_run_suppressed, </ins> }; mod bolt;

Discussion:
This might not be a valid request (I have to tell it what to test), but surely it shouldn't just result in such an obscure panic. Cc
you don't have dir ?
it doesn't exists until fetching the submodule
Seems like I don't have that submodule checked out; I don't work on the book so it's not needed (and I keep the checked-out submodules to a minimum to avoid having to update them all the time).
I reproduced it in local, without in and don't update submodule manually, will fail like this.
I can fix it tomorrow, feel free to work on it if you want to fix it earlier.
by the way, do you know why we use those for here?
Not particularly, I am not so familiar with the compiletest code. Probably we panic there so the compiletest runner process can handle(being able to understand compiletest was failed) that.
The fix shouldn't make any changes on the compiletest side. We just need to avoid using submodules(if doesn't exists) instead of assuming that they exist.
Yes, that's another issue, I just met it today.
Change:
AnonRegionFromYieldTy(Span, String), /// An anonymous region from an async fn. AnonRegionFromAsyncFn(Span), <ins> /// An anonymous region from an impl self type or trait AnonRegionFromImplSignature(Span, &'static str), </ins> } /// Describes what to highlight to explain to the user that we're giving an anonymous region a

Discussion:
<details<summary<strongBacktrace</strong</summary<p</p</details
Changing Self{field} to MyStruct{field} makes it build btw.
I haven't done a search for the exact commit, but on the playground this regressed between beta and nightly. label +regression-from-stable-to-nightly
This is due to the NLL stabilization PR , since it manifests with on 1.61 (with to allow feature flags). I'll be looking at it in a few hours when I get home!
Change:
<del> Subproject commit e8642c7a2900bed28003a98d4db8b62290ac802f </del> <ins> Subproject commit 43ac9416d935942d6c7d2b2e0c876c551652c4ec </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver 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 I-nominated label.
Change:
<ins> #![deny(unused_doc_comments)] #![feature(rustc_attrs)] macro_rules! foo { () => {}; } fn main() { /// line1 //~ ERROR: unused doc comment /// line2 /// line3 foo!(); // Ensure we still detect another doc-comment block. /// line1 //~ ERROR: unused doc comment /// line2 /// line3 foo!(); } </ins>

Discussion:
Other expressions work as expected: it reports just one error, for the whole sequence of doc comment lines. () Errors:
( is a rustc lint.)
True, but I as well since it's a rustdoc-related lint.
Change:
if let Some(source_dir) = source_dir { git.current_dir(source_dir); <ins> // If we are running inside git (e.g. via a hook), `GIT_DIR` is set and takes precedence // over the current dir. Un-set it to make the current dir matter. git.env_remove("GIT_DIR"); // Also un-set some other variables, to be on the safe side (based on cargo's // `fetch_with_cli`). In particular un-setting `GIT_INDEX_FILE` is required to fix some odd // misbehavior. git.env_remove("GIT_WORK_TREE") .env_remove("GIT_INDEX_FILE") .env_remove("GIT_OBJECT_DIRECTORY") .env_remove("GIT_ALTERNATE_OBJECT_DIRECTORIES"); </ins> } git

Discussion:
To reproduce, I am in a worktree without (i.e., not the "main" worktree). I have a pre-commit hook set up as follows Now I change something trivial (e.g. remove a trailing in some comments) and commit. That does the following After a second or two I get suspicious and hit Ctrl-C. Now it looks like bootstrap has done something with the (previously clean) cargo submodule So let's and see what's up Eh... so the files are rustc files? Why are those being in ? Something is going seriously wrong here.
I think this only happens with . I attempted to reproduce it about 25 times without success.
Yes indeed, this does not happen in my folder (the main checkout, where lives), but it happens in worktree folders.
Adding some debug logging, it seems like some truly strange things are happening... This is the HEAD commit of the outer repository! I think what's happening is that some environment variables are set inside the git hook which overwrite the . x.py relies on just setting the working directory to determine which git dir to use, but e.g. GITDIR takes precedence over that. I tried setting instead of using and that does seem to help.