jiebi/CodeConvo huggingface dataset:
Change:
# Select LTO mode that will be used for compiling rustc. By default, thin local LTO # (LTO within a single crate) is used (like for any Rust crate). You can also select <del> # "thin" or "fat" to apply Thin/Fat LTO to the `rustc_driver` dylib. </del> <ins> # "thin" or "fat" to apply Thin/Fat LTO to the `rustc_driver` dylib, or "off" to disable # LTO entirely. </ins> #lto = "thin-local" # =============================================================================

Discussion:
Currently bootstrap supports LTO flavors thin-local (default), thin and fat. Adding the option to completely disable it can speed up develop cycles, especially with incremental compilation. See for benchmarks. When LTO is disabled the standard library still has to be built with so that it can be used by other crates which enable LTO. Disabling should become the default for the library and compiler profile templates. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim to not loose it to time, but feel free to claim it if you want, I might not start work on this until February.
Error: Parsing assign command in failed: ...' claim' ' to not lo'... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
claim Shouldn't this bot be able to detect end of command and silently ignore the rest of the line ?
Change:
--> $DIR/issue-23024.rs:8:39 | LL |     println!("{:?}",(vfnfer[0] as dyn Fn)(3)); <del> |                                       ^^ help: specify the associated type: `Fn<Output = Type>` </del> <ins> |                                       ^^ help: specify the associated type: `Fn::<Output = Type>` </ins> error: aborting due to 3 previous errors

Discussion:
Given the following code: %20%7B%0A%20%20%20%20let%20%20%3D%20MyIterator%3A%3Anext%3B%0A%20%20%20%20%2F%2Flet%20%20%3D%20MyIterator%3CItem%3D()%3E%3A%3Anext%3B%0A%7D) The current output is: But when when I write , it gets interpreted as comparison expressions like and it fails to compile with a lot of "cannot find value in this scope" and "cannot find crate in the list of imported crates". The suggestion is confusing because it is unclear how to apply it. The error goes away if you use directly: produces the error one would expect: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think it gets evaluated as an expression because you are missing a . If you add them, then you get a new error message ():
I see, let me rephrase the issue: The suggestion is "help: specify the associated type: " where "help: specify the associated type: " with a double colon would be correct.
Triage: Suggestion is correct for code using (which all code written in Rust =2021 uses). For code written without in Rust <2021: No change. As mentioned, the suggestion should use an expression-style path (i.e., one with turbofishes).
claim
Working on tests before creating a PR. Multiple tests exist already that have an odd hardcoded expectation for error output, so I'll be double checking those make sense with these changes, and adding a few tests of my own. Otherwise, this really does seem like it was a simple two character fix, unless I missed something somewhere.
Yeah, it's a pretty easy one. Adding before is always correct — not only in expression contexts but also in type contexts since turbofish is also possible in type positions (e.g., ) — albeit redundant. Omitting before in type contexts would be a possible "optimization". However, it really isn't worth doing here.

Consider the following code which is ill-formed even after specifying the assoc ty. () would only be well-formed if we defined an inherent associated type () on which doesn't work yet anyway () and is pretty niche) or once we support arbitrary shorthand projections ().
Change:
info!("going to format"); let (error_format, treat_err_as_bug, ui_testing) = diag_opts; let diag = core::new_handler(error_format, None, treat_err_as_bug, ui_testing); <del> html::render::run(krate, renderopts, passes.into_iter().collect(), renderinfo, &diag) .expect("failed to generate documentation"); 0 </del> <ins> match html::render::run( krate, renderopts, passes.into_iter().collect(), renderinfo, &diag, ) { Ok(_) => rustc_driver::EXIT_SUCCESS, Err(e) => { diag.struct_err(&format!("couldn't generate documentation: {}", e.error)) .note(&format!("failed to create or modify "{}"", e.file.display())) .emit(); rustc_driver::EXIT_FAILURE } } </ins> }) }

Discussion:
When running cargo doc, rustc panics if disk is full. Not a huge issue, just an invalid call of and since the message says it's a bug, I'm filling a report. Error message (with removed file path): Might be related to somehow?
This also happened with me today. The compiler starts panicing if you try to, Generate Documentation, Run, Compile or run . Maybe It should print a clear message and exit instead of panicing like that. Rust Version:
Change:
<ins> use std::collections::BTreeSet; #[derive(Hash)] pub enum ElemDerived { //~ ERROR recursive type `ElemDerived` has infinite size A(ElemDerived) } pub enum Elem { Derived(ElemDerived) } pub struct Set(BTreeSet<Elem>); impl Set { pub fn into_iter(self) -> impl Iterator<Item = Elem> { self.0.into_iter() } } fn main() {} </ins>

Discussion:
erroneous recursive types (without being wrapped with ) having methods whose return type is causes the assertion failure.I expected the error message "recursive type has infinite size." Indeed, if there is no method with return type , we got the following normal error messages:aborted with the following assertion failure.:
glacier
Error: Parsing glacier command in failed: ...'cier https' ''... Please let know if you're having trouble with this bot.
glacier
Error: Parsing glacier command in failed: ...'cier https' ''... Please let know if you're having trouble with this bot.
glacier ""
Error: The feature is not enabled in this repository. To enable it add its section in the in the root of the repository. Please let know if you're having trouble with this bot.
Oh, we must have enabled this... Sorry for the noise!
I think now we could... glacier ""
Making the following change: makes the output look correct, but I am not sure of whether that should be the fix, making it always a and continue returning the or make the caller return instead (which seems to me to be the correct behavior). I do not understand why this has to panic in the first place.
Triage: Seems the ICE is fixed with the latest nightly, now catches this correctly (not bisected yet). Marking as E-needs-test, cc for awareness.
Change:
/// [`pin` module]: crate::pin #[stable(feature = "pin", since = "1.33.0")] #[rustc_on_unimplemented( <del> note = "consider using `Box::pin`", </del> <ins> note = "consider using the `pin!` macronconsider using `Box::pin` if you need to access the pinned value outside of the current scope", </ins> message = "`{Self}` cannot be unpinned" )] #[lang = "unpin"]

Discussion:
Consider the following code, taken from the (): Local pin construction was stabilized in . We should update the diagnostics to suggest this instead of the more expensive call. No response cc/ This is probably a "good first issue" as well. If someone can tag it as such? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
In some cases, works but does not (e.g., if you want ownership of the pinned future), so I think it's better to suggest both. Or something like:
claim
Alright, the suggestion has been in . IDK how to link a PR to an issue though, should I just reference the issue in the description of the PR?
if you put " in the PR description, it will automatically close this issue when the PR is merged :)
Change:
<ins> // run-rustfix // Check that the HELP suggestion is `l(vec![])` instead of `l($crate::vec::Vec::new())` fn l(_a: Vec<u8>) {} fn main() { l(vec![]) //~^ ERROR this function takes 1 argument but 2 arguments were supplied //~| HELP remove the extra argument } </ins>

Discussion:
I'm seeing an internal compiler error on the following input (found by ): Caused by this line introduced in I found a similar issue in the past, this pull request fixes it: Unfortunately, this one looks like a spurious failure. It can be reproduced in the playground using nightly 2022-04-18, but when I try it locally using the same nightly version there is no ICE. This is the error message: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Is this still reproducible? I didn't get the ICE, maybe theres some extra flags needed?
The playground seems to reliably reproduce it. And I can reproduce it sometimes using : But that is not always reliable. Given that the error message is "SourceNotAvailable", I guess this is related to how the toolchain is installed (the rust-src component?). Because at one point I tried the latest nightly with cargo-bisect-rustc and it did not ICE, but some days later I tried the same nightly using the same command and it did ICE. But I would just assume that while there is an in the code this issue is not fixed.
I'm currently using rustc 1.62.0-nightly ( 2022-04-25) and from the 10 times I tried executing the code, all of them generated an ICE.
I think I see this issue too. I also had to go back to 2022-04-18 to be able to compile my code.
I opened a pull request with a one line change that may fix this, but I have no way to reproduce it locally (compiling the example code works fine even without the changes of that pull request). The playground can still reproduce the issue as of nightly 2022-04-29, so we can use it to check if this issue is really fixed after that pull request is merged.
So I accidentally closed this issue by adding the words "may to the pull request description, but fortunately it looks fixed, as you can see thanks to the glacier bot.
Change:
<ins> // check-pass // compile-flags: --passes list // error-pattern: the `passes` flag is deprecated </ins>

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this command: I expected to see this happen: rustdoc shows a warning, the way it does for any other value you pass to : Instead, this happened: Rustdoc gives no warning and lists all passes. <!-- 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. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Mentoring instructions: Move this check earlier to before is processed:
claim
Change:
use rustc_hir::{ExprKind, ItemKind, Node}; use rustc_infer::infer; use rustc_middle::lint::in_external_macro; <del> use rustc_middle::ty::{self, Ty}; </del> <ins> use rustc_middle::ty::{self, Binder, Ty}; </ins> use rustc_span::symbol::kw; use std::iter;

Discussion:
While writing a SparseArray impl, I forgot a return on . This should_ be an error, but I got an ice instead. This fails with the expected on stable. playground: (Note that switching to stable resolves the ICE) <!-- 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. --:
label regression-from-stable-to-nightly
Bisection result searched nightlies: from nightly-2021-02-22 to nightly-2021-02-28 regressed nightly: nightly-2021-02-24 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Caused by :
Change:
use rustc::mir::interpret::truncate; use rustc::ty::{self, Ty}; use rustc::ty::layout::{ <del> self, Size, Abi, Align, LayoutOf, TyLayout, HasDataLayout, VariantIdx, PrimitiveExt </del> <ins> self, Size, Align, LayoutOf, TyLayout, HasDataLayout, VariantIdx, PrimitiveExt </ins> }; use rustc::ty::TypeFoldable;

Discussion:
This ICEs on stable, probably since March 2018, but it requires the user to do UB in constants, so... I think a possible fix would be to enable validation in const eval (cc ), though we should benchmark the perf considerations around that first. Alternatively we can just not ICE here and instead emit an error. () Errors:
Interesting. ICEs in Miri with are also bugs, so I'd say doing more validation is not the right call. Do you have a backtrace? Which code is responsible for ICEing here and how hard/bad would it be to just error instead?
It's ICEing in and we could indeed just emit a UB error here, but it seems very... odd, since the field access check has very little to do with UB at a first glance. The layout is a union with zero fields, because it's essentially .
TBH this looks like a bug to me. That's the layout of which type, ? It should have a field, and it should not be a union. Cc
It's not a bug. Just like layout for a newtype with a single field is not a bug (E.g. ).
Precisely by analogy with , I think this is a bug. Your has a with exactly 1 field, matching what is declared. It does not have 2 fields which would be the case if it had a "pair layout". So, transparent layout changes the , but it does not change how many "fields" a type is considered to have. Similarly, has 3 fields in its layout, despite still being a . So, correspondingly, should have 1 field.
oh... right. Yea we should totally fix that
This being a layout bug would trivially break codegen, why is only miri affected?
Codegen might skip the field access because the type is uninhabited?
I wouldn't be so sure, codegen calls on layouts a lot without checking. Can the ICE print the whole ? That might be more useful here. EDIT: oh this might be why: we don't check the index at all:
yea but we can't use because that ICEs during const prop in the array case. I have a local branch that I'm playing with to get the entire picture
You can literally remove the assert to get the same effect.

But if the field count is wrong I'd rather have an assert in both places and fix the count (if possible).
The full is and so far I haven't figured out how that can happen
Ah, nevermind, I found it:
Ah so that's a micro-optimization. Maybe we should compute the right thing.
computes the layout for structs but keeps returning the never layout for enums without inhabited variants
Change:
// except according to those terms. impl Drop for u32 {} //~ ERROR E0117 <ins> //~^ NOTE impl doesn't use types inside crate //~| NOTE the impl does not reference any types defined in this crate </ins> fn main() { }

Discussion:
From: src/test/compile- Error E0118 needs a spanlabel and a spannote to be a simple note, updating from: To: Bonus: It'd be good if we could underline the type it's complaining about.
In case no one is working with this yet, I can give this a go.

From: src/test/compile- Error E0117 needs a span_label, updated error text, and a note, updating it from: to:
In case no one is working with this yet, I can give this a go.
Change:
<ins> error[E0642]: patterns aren't allowed in methods without bodies --> $DIR/issue-50571.rs:2:12 | LL |     fn foo([a, b]: [i32; 2]) {} |            ^^^^^^ help: give this argument a name or use an underscore to ignore it | LL |     fn foo(_: [i32; 2]) {} |            ^ error: aborting due to previous error For more information about this error, try `rustc --explain E0642`. </ins>

Discussion:
Using a generic function to "converge" two into when T is an associated type for another trait causes the following error: Example code (): This may or may not be related to the compiler seemingly failing to assert that , an error that can be triggered by using the alternate signature for at line 40 of the example. I tested this with the linked playground on the latest stable (1.32.0), as well as a recent nightly: Compiling with doesn't seem to yield a very useful stack but here it is:
Another example by that causes only the second "call dest mismatch" ICE:
P-medium. Removing nomination label. (But maybe we should have a WG-impl-trait to provide a structured effort for working through the bugs with impl trait?)
This has been fixed in 1.38.0 as, while I can reproduce the ICE in 1.37.0, I am not observing it in neither of: stable (1.38.0), beta nor nightly. modify labels: E-needstest

The following code works on beta: But when used in a trait like so: rustc reports the following error:
Possibly related to rustc expecting possibly a type in this scenario? As you can declare trait methods with no parameter name
Possibly related to rustc expecting possibly a type in this scenario? Exactly. When becomes an error, we'll be able to accept arbitrary patterns in parameters of trait methods, but for now only very limited subset is allowed.
The example in the issue now compiles. If we don't have existing tests for this, we ought to add one.
Change:
in the same format as C: ```rust,ignore <del> #![feature(lang_items)] </del> <ins> #![feature(lang_items, core_intrinsics)] </ins> #![feature(start)] #![no_std] <ins> use core::intrinsics; </ins> // Pull in the system libc library for what crt0.o likely requires. extern crate libc;

Discussion:
The following file, when compiled without optimizations, correctly generates an overflow check in : However, compiling with optimizations plus or generates code without the overflow check. However, if I move to a separate no_core crate like this, the issue disappears and the overflow check is generated:
noticed that my panic implementation () is UB according to LLVM (see ), so it optimizes the overflow check out on the assumption that it can never be triggered (since that would be UB). Replacing it with e.g. fixes the issue.
Change:
aux_bins: vec![], aux_crates: vec![], revisions: vec![], <del> rustc_env: vec![("RUSTC_ICE".to_string(), "0".to_string())], </del> <ins> rustc_env: vec![ ("RUSTC_ICE".to_string(), "0".to_string()), ("RUST_BACKTRACE".to_string(), "short".to_string()), ], </ins> unset_rustc_env: vec![("RUSTC_LOG_COLOR".to_string())], exec_env: vec![], unset_exec_env: vec![],

Discussion:
<!-- [31mICE[0m: Rustc '--edition=2021 -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: relating different kinds: {const error}: &'static str KeyNil', 'error: internal compiler error: relating different kinds: {const error}: &'static str KeyNil' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [typeck] type-checking [analysis] running analysis passes on this crate --
This bisects to
Minimized further:
Is related? Current ICE-loc: Issue-'s ICE-loc:
cc PR author
Change:
}; let (pat, ty) = if is_name_required || this.is_named_param() { debug!("parse_param_general parse_pat (is_name_required:{})", is_name_required); let (pat, colon) = this.parse_fn_param_pat_colon()?; if !colon { let mut err = this.unexpected::<()>().unwrap_err();

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --I tried this almost-correct code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
let mut tarball = Tarball::new(builder, "rust-docs", &host.triple); tarball.set_product_name("Rust Documentation"); <del> tarball.add_dir(&builder.doc_out(host), dest); </del> <ins> tarball.add_bulk_dir(&builder.doc_out(host), dest); </ins> tarball.add_file(&builder.src.join("src/doc/robots.txt"), dest, 0o644); Some(tarball.generate()) }

Discussion:
CC On today's git () seems to get stuck if you are building docs. In : will get stuck at: The underlying command is: Adding this to the config seems to work around the hang: Thanks!
How long did you let the command run before killing it? I remember installing the docs taking a long time last time I did it.
I left it for half an hour or so IIRC. I'll run it for longer and see if it goes away. How long do you think it should take to install on a modern SSD?
I don't remember exactly how long it takes, but it doesn't depend on the speed of the disk. is just really inefficient. You can see if it's actually hanging by checking the contents of this command while it's installing:
The log file is empty, but I can see new files appearing on the disk (using and ) so progress must be occurring. Slowly.
It's been about 40 minutes now. It seems to be adding files to is that right?
So it's just very slow.
I took a look into this. The main issue is that the generated is very inefficient; it takes about 5 minutes to copy 2500 files (there are more than 2500, but I got bored and cancelled it). what do you think about rewriting this inner loop in Rust so it's not launching so many external processes?
This issue is compounded on macOS, where it seems to be even more inefficient to launch lots of processes from a shell. Sorry I don't have timings, but it takes tens of minutes at least for this step [edit: over an hour]; long enough that I would expect most users who are trying to build our software from source in macOS (it's Zcash, which installs a pinned version of Rust in order to build) are likely to think it's hanging and give up.
I think the problem may largely be that the generated for rust-docs component (at least) is a file: list instead of using the directory: command; directory commands should be much more efficient. This change may be a recent(ish) regression; I suspect that fixing that is likely the right solution here.
Oops I forgot to link back here: we discussed this briefly and it was difficult to do in a cross-platform way.
We solved our problem for Zcash by just not installing rust-docs (passing to ).

This reduced our total build time on macOS ! Obviously it doesn't solve the underlying issue.
FYI, addresses this (not the underlying cause of the inefficiency but the majority of its extent).
I bisected the underlying issue to “bootstrap: convert rust-docs to use Tarball” (). Before this commit, rust-docs installs in half a second, and is 1 line: After this commit, rust-docs installs in some twenty minutes, and is lines:
Proposed fix in . (We should also do the optimization in rust-lang/rust-installer of course.)