jiebi/CodeConvo huggingface dataset:
Change:
cargo.rustdocflag("--extern-html-root-url"); cargo.rustdocflag("ena=https://docs.rs/ena/latest/"); <del> let mut compiler_crates = HashSet::new(); if paths.is_empty() { // Find dependencies for top level crates. for root_crate in &["rustc_driver", "rustc_codegen_llvm", "rustc_codegen_ssa"] { compiler_crates.extend( builder .in_tree_crates(root_crate, Some(target)) .into_iter() .map(|krate| krate.name), ); } </del> <ins> let root_crates = if paths.is_empty() { vec![ INTERNER.intern_str("rustc_driver"), INTERNER.intern_str("rustc_codegen_llvm"), INTERNER.intern_str("rustc_codegen_ssa"), ] </ins> } else { <del> for root_crate in paths { if !builder.src.join("compiler").join(&root_crate).exists() { builder.info(&format!( "tskipping - compiler/{} (unknown compiler crate)", root_crate )); } else { compiler_crates.extend( builder .in_tree_crates(root_crate, Some(target)) .into_iter() .map(|krate| krate.name), ); } } } </del> <ins> paths.into_iter().map(|p| builder.crate_paths[p]).collect() }; // Find dependencies for top level crates. let compiler_crates = root_crates.iter().flat_map(|krate| { builder.in_tree_crates(krate, Some(target)).into_iter().map(|krate| krate.name) }); </ins> let mut to_open = None; <del> for krate in &compiler_crates { </del> <ins> for krate in compiler_crates { </ins> // Create all crate output directories first to make sure rustdoc uses // relative links. // FIXME: Cargo should probably do this itself.

Discussion:
I tried this code: I expected to see this happen: bootstrap documents the whole compiler, like it does for . Instead, this happened: The problem is that is too naive and expects the name of each crate to match its file path on disk: It needs to map from the path to the name somehow. There's already a way to go from the name to the path: but I don't think there's a way to do the reverse. HEAD is . label +A-bootstrap
label: +A-bootstrap
label: +E-mentor +A-rustbuild
Change:
<ins> error[E0594]: cannot assign to `self.0` which is behind a `&` reference --> $DIR/issue-68049-1.rs:7:9 | LL |         self.0 += 1; |         ^^^^^^^^^^^ `self` is a `&` reference, so the data it refers to cannot be written error: aborting due to previous error For more information about this error, try `rustc --explain E0594`. </ins>

Discussion:
Summary: The compiler suggests changing to when trying to modify in a method. For trait implemantions this does not work because it would require changing the trait definition too (which is often not possible). Example: I was trying to implement the trait from the standard library for a custom type: () This of course doesn't work since you can't modify data behind a reference: However, I noticed that the help message suggests changing the to , which is incorrect since that would require changing the trait definition in the standard library too. Suggestion: I don't know if this is possible, but maybe this help message should only be shown for "normal" methods and hidden when implementing trait methods?
Maybe only hide the suggestion if the trait comes from a foreign crate?
Or suggest to change the trait (if it is in this crate) not change the function in the part.
One more idea: suggest ///
Change:
next } <del> crate fn unexpected<T>(&mut self) -> PResult<'a, T> { </del> <ins> pub fn unexpected<T>(&mut self) -> PResult<'a, T> { </ins> match self.expect_one_of(&[], &[]) { Err(e) => Err(e), // We can get `Ok(true)` from `recover_closing_delimiter`

Discussion:
The : pointed me to -- cc I see that there were regressions with during that review, but not exactly like what I'm seeing here. searched nightlies: from nightly-2020-09-28 to nightly-2020-10-04 regressed nightly: nightly-2020-09-30 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: </details
It's probably relevant that the actual token is passed as an arch-conditional parameter here:
Yes, I've missed this case, sorry. Will fix soon.
Fixed in
Works for me, thanks!
Change:
// locals as part of the prefix. We compute the layout of all of // these fields at once to get optimal packing. let discr_index = substs.as_generator().prefix_tys(def_id, tcx).count(); <del> // FIXME(eddyb) set the correct vaidity range for the discriminant. let discr_layout = self.layout_of(substs.as_generator().discr_ty(tcx))?; let discr = match &discr_layout.abi { Abi::Scalar(s) => s.clone(), _ => bug!(), }; </del> <ins> // `info.variant_fields` already accounts for the reserved variants, so no need to add them. let max_discr = (info.variant_fields.len() - 1) as u128; let discr_int = Integer::fit_unsigned(max_discr); let discr_int_ty = discr_int.to_ty(tcx, false); let discr = Scalar { value: Primitive::Int(discr_int, false), valid_range: 0..=max_discr }; let discr_layout = self.tcx.intern_layout(LayoutDetails::scalar(self, discr.clone())); let discr_layout = TyLayout { ty: discr_int_ty, details: discr_layout }; </ins> let promoted_layouts = ineligible_locals .iter() .map(|local| subst_field(info.field_tys[local]))

Discussion:
Currently they use a hardcoded discriminant, which is quite a lot of room considering that generators don't typically have billions of states. They should be able to use the smallest unsigned integer type that fits all states instead (so in the vast majority of cases).
The discriminant is also never marked with a valid range, meaning that it never provides any niches that could be used to store other values. Not sure if doing that has any drawbacks, but it seems like a somewhat easy size optimization on first glance.
Fixing this was way easier than I expected, but I'd appreciate help with benchmarking the runtime impact of the fix in . So if anyone knows any async/await benchmarks that are not I/O heavy (so that they mostly test CPU overhead of async/await), I'd be happy to run them.
Change:
ty::UnnormalizedProjection(..) => bug!("only used with chalk-engine"), <ins> // Zero-length arrays never contain anything to drop. ty::Array(_, len) if len.try_eval_usize(tcx, param_env) == Some(0) => false, </ins> // Structural recursion. ty::Array(ty, _) | ty::Slice(ty) => needs_drop(ty),

Discussion:
The following ICE's on nightly only: <details<summaryBacktrace:</summary</detailsThis ICE is the same as reported in , however the example given there currently runs fine without any errors.
cc
As the OP notes, this is closely related to . To fix that problem, zero-length arrays were special-cased so that they are never marked as indirectly mutable. However, this did not extend to projections of zero-length arrays. When compiling this code, the analysis sees a reference being taken to a place of type , which it cannot assume is . I should be able to make the validation passes agree in this particular case by checking the type of the target of each projection along the borrowed place, suppressing the indirectly mutable annotation for the base local if any of those types are a zero-sized array. It's unfortunate that we have to treat and differently here, but obviously backwards compatibility must be preserved. I wonder if there's a different way to handle this. It seems like should return for an empty array?
Change:
<ins> Change this file to make users of the `download-ci-llvm` configuration download a new version of LLVM from CI, even if the LLVM submodule hasn’t changed. Last change is for: https://github.com/rust-lang/rust/pull/78131 </ins>

Discussion:
I recently to in my local repository. In particular, this enables: When running the full test suite with I get three errors similar to this: Maybe the packaging of LLVM downloaded from CI needs to be fixed to include ?
Cc since you're the one who implemented this :)
Yes, that seems right. I did not know we relied on the LLVM tooling -- probably there's a few more tools we need too, will need to check. I imagine it's mostly a matter of just adding them to this section: , they should already be built. I would be happy to take a PR for this.
I can make a patch adding a couple lines for like the ones there for , but can I test it without landing it and waiting for the next Nightly? (I assume testing locally involves compiling LLVM, so I might wait to do that until I have access again to a many-cores desktop rather than just my laptop.)
Hm, sort of. So you will need to post a PR, but then bors try will generate sufficient artifacts to test. You will want to replace with the sha of the try build that bors posts.
might also be necessary but I'm not sure.
I’ll find out! I’ve already started a try build with just : I can temporarily hard-code in for the purpose of testing, but for everyone else the logic is still picking the last commit that touched the submodule, which after lands will still be some commit that does not include Would it make sense to have a "timestamp-ish" file, and pick the last commit that touched either the submodule or that file? That would only be useful until the next LLVM update, though. (Unless we need to tweak thepackaging of the component again.)
Change:
/// /// If you make any major changes (such as adding new values or changing default values), please /// ensure that the associated PR ID is added to the end of this list. <del> pub const CONFIG_CHANGE_HISTORY: &[usize] = &[115898, 116998, 117435]; </del> <ins> pub const CONFIG_CHANGE_HISTORY: &[usize] = &[115898, 116998, 117435, 116881]; </ins> /// Extra --check-cfg to add when building /// (Mode restriction, config name, config values (if any))

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:
), /// A macro invocation. /// <del> /// E.g., `macro_rules! foo { .. }` or `foo!(..)`. </del> <ins> /// E.g., `foo!(..)`. </ins> Mac(Mac), /// A macro definition.

Discussion:
E.g. becomes Specifically, the syntax contexts of and are linked (the s refer to the same identifier, even with hygiene) but this is not represented in the output at all, so one might interpret them as being distinct identifiers.
There is no more pretty=hygene, was it replaced with something?
Closing. is apparently no longer a thing, and the output looks sufficiently different with that I don't think it's the same.
There is a FIXME related to this issue, Now that the issue is closed can the FIXME be fix, or made more specific?
Looks like is a thing though so reopening... output today is below. I'm not completely sure whether this is fixed or not --- the output looks the same for the two s, I guess? Not sure which are being referred to either...
Change:
ScalarMaybeUninit::Scalar(l), ScalarMaybeUninit::Scalar(r), )) => l.is_bits() && r.is_bits(), <del> interpret::Operand::Indirect(_) if mir_opt_level >= 2 => { let mplace = op.assert_mem_place(&self.ecx); intern_const_alloc_recursive(&mut self.ecx, InternKind::ConstProp, mplace, false); true } </del> _ => false, } }

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. --code from ./src/test/ui/consts/constconstructor/const-construct- <!-- 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. --rustc @ <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Might be caused by That should have reduced the number of ICEs, not increased it, but who knows.^^

<!-- 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. --core reduced from <!-- 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. --: repo is @ <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
This does not reproduce with though, so it's a very recent regression.
` produces the same error it seems.
Change:
<ins> fmt thread 'main' panicked at 'PrintOnFmt', $DIR/fmt-only-once.rs:20:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace </ins>

Discussion:
I tried this code: I expected to see this happen: No panic during runtime Instead, this happened: Panicked during runtime <details<summaryFormat: was already formatted once</summary</details<!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Rust 1.70 (beta) and Rust 1.69 (stable) <!-- Provide the version you are using that has the regression. --: None I also reported this here , but I think this one is on . assigning you, because I suspect this has something to do with recent changes.
I'll look into this tomorrow. Can you check if it also happens with -Zflatten-format-args=no?
This is unrelated to and was caused by a recent change to the panic runtime. I've posted a fix at
Change:
<ins> error: future cannot be sent between threads safely --> $DIR/issue-86507.rs:17:13 | LL | /             Box::pin( LL | |                 async move { LL | |                     let x = x; LL | |                 } LL | |             ) | |_____________^ future created by async block is not `Send` | note: captured value is not `Send` because `&` references cannot be sent unless their referent is `Sync` --> $DIR/issue-86507.rs:19:29 | LL |                     let x = x; |                             ^ has type `&T` which is not `Send`, because `T` is not `Sync` = note: required for the cast to the object type `dyn Future<Output = ()> + Send` help: consider further restricting type parameter `T` | LL |         where 'me:'async_trait, T: std::marker::Sync { |                               ^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error </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. 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. --Given the following code: The current output is: The compiler helpfully points out that is required, but nonetheless and I both got confused by this error for some time before we noticed it. The suggestion was kind of buried by all the other details.
I'm not sure the ideal output, but it might be something like this:
This error can be replicated without any external crates (i.e., without ) like so:
Change:
/// `rust.save-toolstates` in `config.toml`. If unspecified, nothing will be /// done. The file is updated immediately after this function completes. pub fn save_toolstate(&self, tool: &str, state: ToolState) { <ins> // If we're in a dry run setting we don't want to save toolstates as // that means if we e.g. panic down the line it'll look like we tested // everything (but we actually haven't). if self.config.dry_run { return; } // Toolstate isn't tracked for clippy, but since most tools do, we avoid // checking in all the places we could save toolstate and just do so // here. if tool == "clippy-driver" { return; } </ins> if let Some(ref path) = self.config.save_toolstates { if let Some(parent) = path.parent() { // Ensure the parent directory always exists

Discussion:
fails currently due to However, the toolstate is green nevertheless. Looks like somehow toolstate tracking is broken. Due to this, we currently ship a broken Miri via rustup. Cc
I can't make heads or tails of the log in It looks to me like tests weren't run at all?
Yeah that's expected, the dist builders only build the tools and do not test them. The tools builder tests them. Manifest creation (when the final toolchain is to rustup, as part of auto -master promotion) reads the toolstate JSON files and omits Miri if its tests failed. (So far, no other tool opted into using that system, as far as I know.)
But for some reason, the tools builder doesn't even seem to build Miri?!?
It runs the miri tests and shows that they fail. The toolstate processing after that is just not verbose enough to tell us what's up
It says But that did not even get to Miri. It stopped after another test failure: I think that's a clippy test. So what likely happened is that a clippy test failed, but for some reason, instead of aborting CI, that lead to all tools being marked as test-pass...
That line says ? And above some tests fail, but those are not Miri's tests.
Oh... right... maybe clippy tests failing cause all other tools not to get tested at all, thus leading to "successful" test results
And, notably, clippy tests failing do not block the PR from landing!
oh... right :facepalm: so... let's do this PR and figure out things in another try? rollup-
You did this in an issue, not sure what that is going to accomplish. :D
oops. I thought we were on the PR
Change:
<ins> #![feature(prelude_import)] #![no_std] #[prelude_import] use ::std::prelude::rust_2015::*; #[macro_use] extern crate std; // pretty-compare-only // pretty-mode:expanded // pp-exact:format-args-str-escape.pp fn main() { { ::std::io::_print(format_args!("u{1b}[1mHello, world!u{1b}[0mn")); }; { ::std::io::_print(format_args!("u{1b}[1mHello, world!u{1b}[0mn")); }; { ::std::io::_print(format_args!("Not an escape sequence: u{{1B}}[1mboldx1B[0mn")); }; { ::std::io::_print(format_args!("{0}n", "x1B[1mHello, world!x1B[0m")); }; } </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 code (): I expected to see this happen: When running , the format string literals for the first two s should remain valid string literals. Instead, this happened: This code is generated: Note the double and in the escapes. The escape sequences in the last are correctly preserved. This is annoying because it makes it impossible to run on the macro-expanded source, which is helpful when trying to read macro-generated code. <!-- 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 --
I haven't looked at it, but this is probably going wrong somewhere in when printing .
Looks like you’re right: As I understand this, it duplicates curlies regardless of whether they’re part of an escape sequence.
claim
Change:
#![feature(maybe_uninit_slice)] #![feature(maybe_uninit_uninit_array)] #![cfg_attr(test, feature(new_uninit))] <del> #![feature(nonnull_slice_from_raw_parts)] </del> #![feature(pattern)] #![feature(pointer_byte_offsets)] #![feature(provide_any)]

Discussion:
This is a tracking issue for the method proposed in PR The feature gates for the issue are , and for using as a . Docs: [x] Implementation: [x] FCP: [ ] Stabilization PR
merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [ ] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
I'm willing to file the stabilization report for this if the library team is on board for stabilization.
I'd certainly appreciate one!
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon.
Change:
set(&mut config.llvm_release_debuginfo, llvm.release_debuginfo); set(&mut config.llvm_version_check, llvm.version_check); set(&mut config.llvm_static_stdcpp, llvm.static_libstdcpp); <ins> config.llvm_targets = llvm.targets.clone(); </ins> } if let Some(ref rust) = toml.rust {

Discussion:
Currently, llvm is built with all the possible targets including Mips, ARM... For development, we can speed the build by enabling only the native target (x86 or x86_64). Maybe it would also speed the build of rustc?
FWIW, for development I use ccache (pass to ) and building LLVM takes one minute or less on a "fresh" bootstrap. (I usually work with several branches at the same time; one docker container per branch and all of them reuse the same ccache directory) Just please don't change the defaullt. I'd be very upset if I spent several minutes building stage1 rustc just to learn that it can't cross compile anything.
yeah, of course.
This is such a niche use case, to the point that it's arguably already moot by use of , if the sole purpose is to reduce build time. However there may be some other advantages, maybe space savings for use on some really storage-constrained systems? I don't know, it's trivial to make the list of targets configurable but the maintenance and support burden is real. What do the Rust team think? cc
Seems fine to me to add an option for this! We won't do it on the bots, but that doesn't mean it can't exist.