jiebi/CodeConvo huggingface dataset:
Change:
src/libstd  src/liballoc  src/libcore <ins> # Debug assertions in rustc are largely covered by other builders, and LLVM # assertions cause this builder to slow down by quite a large amount and don't # buy us a huge amount over other builders (not sure if we've ever seen an # asmjs-specific backend assertion trip), so disable assertions for these # tests. ENV NO_LLVM_ASSERTIONS=1 ENV NO_DEBUG_ASSERTIONS=1 </ins>

Discussion:
Currently the build times for Azure Pipelines are through the roof compared to Travis, taking up to an hour longer on relevant builds. The has . We're going to have to rework quite a lot I think to get the current 2-core within our time limits. We're shooting to have everything in 2h on a good day, and up to 3h if necessary to do things like rebuild caches and such.
Ok to expand on the comment linked above, I've run azure again but this time with step timings enabled for the no assertions build, yielding this chart: Here are some comparisons of build times between Travis/Appveyor to Azure. A sign means azure is slower for a step, and a means azure is faster. <details<summaryBuild time discrepancies of dist-i686-msvc:</summary</details<details<summaryBuild time discrepancies of dist-x8664-apple</summary</details<details<summaryBuild time discrepancies of dist-x8664-linux-alt</summary</detailsFrom this all I can really see is that everything is just blanket slower on Azure, namely compiling rustc. That makes sense since compiling rustc is quite parallel already. It also doesn't look like azure is doing anything Travis/AppVeyor isn't by accident, and furthermore they're configured the same. All-in-all I don't really see a great win for us to cash in on here.
Your "chart" has a Python backtrace at the end of the table. Two stupid questions: are LLVM assertions enabled on Travis and AppVeyor? do the Travis and Azure VMs have the same number of cores?
Digging further into the build logs of MSVC it looks like we're building really big crates like Cargo and rustc-ap-syntax twice. That'll save 10-ish minutes of build time so I'm going to investigate why that's coming up and how to prevent it. it depends on the builder for whether assertions are enabled or not. There is a different number of cores between the services, where we're using 4 on Travis/AppVeyor and only 2 on Azure.
We've since switched to azure, so I don't think this issue is serving much any more, so I'm going to close.
Change:
match *ty.kind() { // Print all nominal types as paths (unlike `pretty_print_type`). ty::FnDef(def_id, substs) <del> | ty::Alias(_, ty::AliasTy { def_id, substs, .. }) </del> <ins> | ty::Alias(ty::Projection | ty::Opaque, ty::AliasTy { def_id, substs, .. }) </ins> | ty::Closure(def_id, substs) | ty::Generator(def_id, substs, _) => self.print_def_path(def_id, substs),

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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
regression in cc
claim
another one `

<!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regression in cc
Thanks :) claim
Change:
}).unwrap_or_else(|| Some(YieldData { span: DUMMY_SP, expr_and_pat_count: 0, <del> source: match self.kind { // Guess based on the kind of the current generator. hir::GeneratorKind::Gen => hir::YieldSource::Yield, hir::GeneratorKind::Async(_) => hir::YieldSource::Await, }, </del> <ins> source: self.kind.into(), </ins> })); if let Some(yield_data) = live_across_yield { let ty = self.fcx.resolve_vars_if_possible(&ty); debug!("type in expr = {:?}, scope = {:?}, type = {:?}, count = {}, yield_span = {:?}", expr, scope, ty, self.expr_count, yield_data.span);

Discussion:
Consider for example this code (using ): This code will fail to compile due to types which cannot be fully inferred, with an error like this: However neither of these spans are anywhere near to the real problem which is the fact that variant is not inferred for . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
assign will do some investigation here and see if they can get an idea what's going on (and maybe fix)
Change:
use rustc::mir; use rustc::ty::{self, Ty}; use syntax::ast::FloatTy; <del> use std::cmp::Ordering; </del> use rustc::ty::layout::LayoutOf; use rustc_apfloat::ieee::{Double, Single}; use rustc_apfloat::Float;

Discussion:
The following tests do not pass for me, but I think they should, as comparisons with NaN should always simply evaluate to : I get this result on both debug and release builds. I'm on an x86_64 running Linux, rustc 1.27.0-nightly ( 2018-05-15).
Playground link for this test. Affects both debug and release, Nightly and Stable.
: ~I think this is an issue with rather than the floating-point comparisons, but I haven't dug into it yet.~
This seems to be a regression introduced by 1.26.
Reduced, . Edit: Or maybe a bug in Miri (cc
Bisection between ... gives as the regression PR, as expected.
I guess this logic, which I blindly copied, was never correct to begin with: I think this is how old const eval did it, and we didn't want to regress that. cc
Has the comment about existing bad behaviour.
The old logic used unwrap, meaning would just ICE (?). I think we can safely replace them directly as etc. Edit: The unwrap is in
The incorrect behavior mentioned in was this: If we fix the float comparison behavior, this code will no longer compile. But I think this is clearly a bug fix and breaking code like this is .
Fixed in
Change:
println!("cargo:rustc-link-lib=advapi32"); println!("cargo:rustc-link-lib=ws2_32"); println!("cargo:rustc-link-lib=userenv"); <del> println!("cargo:rustc-link-lib=shell32"); </del> } else if target.contains("fuchsia") { println!("cargo:rustc-link-lib=zircon"); println!("cargo:rustc-link-lib=fdio");

Discussion:
An showed that removing the dependency from LLVM speed up its test suite by a huge amount. For us libstd doesn't depend on directly but it does depend on which depends on (according to the blog post). Specificaly it looks like , the same function as LLVM, is used by us! It'd be great to investigate removing the shell32 dependency from libstd (may be a few other functions here and there). We should run some tests on Windows to see if this improves rustc cycle times!
Based on my limited investigation, it's likely that replacing with a pure Rust equivalent should be good enough to get rid of the gdi32 dependency in things that only use libstd. So really someone just needs to write that pure Rust implementation which should be easy to do.
It would be nice to get rid of this in the compiler too. We spawn a lot of compiler instances during bootstrapping.
So now that the change has been implemented, have we actually investigated how much of an impact the change made?
Perf, an lolbench are both linux only. So nether help with this question. So don't waste your time like I did.
Here are just number for on 8 cores / 16 threads on Windows 10 v1809: Without the dependency: 333.012 325.587 320.650 With : 310.852 319.165 323.645
For what it's worth, though there's no good way to differentiate PR-to-PR due to very high variance, it does look like there was a recent regression in PR build times: <img width="1409" alt="image" src="https://user-"
I see that the CPU usage averages about 40% when running , so maybe we'd see some real improvements if we got rid of in the compiler too. Something is certainly holding things back.
Yeah, I saw that the compiler doesn't load . So there's probably some other reason why doesn't load all the cores.
Change:
<ins> // Regression test for issue #119700. // check-pass #![feature(const_trait_impl, effects)] #[const_trait] trait Main { fn compute<T: ~const Aux>() -> u32; } impl const Main for () { fn compute<T: ~const Aux>() -> u32 { T::generate() } } #[const_trait] trait Aux { fn generate() -> u32; } impl const Aux for () { fn generate() -> u32 { 1024 } } fn main() { const _: u32 = <()>::compute::<()>(); let _ = <()>::compute::<()>(); } </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: no host param id for call in const yet no errors reported', 'error: internal compiler error: no host param id for call in const yet no errors reported' File: --auto-reduced (treereduce-rust): original: Version 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: --
Regression in nightly-2023-08-09
Change:
} #[stable] <ins> impl<T, I> ExactSizeIterator for Peekable<T, I> where I: ExactSizeIterator<Item = T> {} #[stable] </ins> impl<T, I> Peekable<T, I> where I: Iterator<Item=T> { /// Return a reference to the next element of the iterator with out advancing it, /// or None if the iterator is exhausted.

Discussion:
This should be in : This would require either implementing for (where ), or decoupling and (like in )
Change:
pub field: K, } <del> // Partial fix for #31260, doesn't work without {...}. </del> static STRUCT: Struct<&'static [u8]> = Struct { field: {&[1]} }; <ins> static STRUCT2: Struct<&'static [u8]> = Struct { field: &[1] }; </ins> fn main() {}

Discussion:
fails to type check, while succeeds.
This coercion is important when using byte string literals.
The tuple struct case is actually the function call "expected type" propagation, which would have to be adapted to struct literals as well.
Yes.
Coercion already happens in non-generic struct literals:
Yes, but the field types are taken from the struct and not combined with the overall expected type for the struct literal.
I just discovered this bug/unexpected behavior today (). I would like to see some movement on it because it's surprising that these two don't work the same way. Here's a workaround I found; it's ugly as hell but I'm using it in a generated file that no human would want to look through anyway: I tried type ascription but it seems to not cue coercion, it just moves the type error: It seems that forcing a concrete type on the struct literal works as well (I didn't expect this syntax to work, honestly): Unfortunately this won't work for me because I'm using too and I can't add this extra syntax myself.
Any news on this?
Is anyone working on it?
It seems like implemented a partial fix in but suggests that there are backwards incompatibility issues to be considered that preventing him from going further. I'm not quite sure what he had in mind there, perhaps he can elaborate.
Making sure we remember to look at this.
What I did is I computed a "light hint" (which becomes "strong hint", i.e. forcing coercion, if it reaches a block, and it's enough to help integer inference for ). This is a common problem with coercion hints, in that unless there's enough type information to prevent them from triggering, they will trigger early even if that breaks later on. The thing to try here is to replace with the simpler: doesn't even need to be computed if that works, since is at least as specific - AFAICT, we already have that "specificity" with function calls, but since it hasn't been used with struct literals before, crater/cargobomb might reveal regressions.
ok, I was mostly wondering if you encountered actual regressions in practice, or just theorize that this might lead to problems.
I don't think I got the chance to do a crater run and then I lost track of it.
will open a PR and we can try a crater run at least.

There is still a similar problem with the type inference of temporaries when you have an array that should be interpreted as a slice buried in a tuple inside an outer slice.
Change:
.insert(hash, RawDefId { krate: def_id.krate.as_u32(), index: def_id.index.as_u32() }); } <del> pub fn register_reused_dep_path_hash(&self, hash: DefPathHash) { if let Some(old_id) = self.foreign_def_path_hashes.get(&hash) { self.latest_foreign_def_path_hashes.lock().insert(hash, *old_id); </del> <ins> /// If the given `hash` still exists in the current compilation, /// calls `store_foreign_def_id` with its current `DefId`. /// /// Normally, `store_foreign_def_id_hash` can be called directly by /// the dependency graph when we construct a `DepNode`. However, /// when we re-use a deserialized `DepNode` from the previous compilation /// session, we only have the `DefPathHash` available. This method is used /// to that any `DepNode` that we re-use has a `DefPathHash` -> `RawId` written /// out for usage in the next compilation session. pub fn register_reused_dep_path_hash(&self, tcx: TyCtxt<'tcx>, hash: DefPathHash) { // We can't simply copy the `RawDefId` from `foreign_def_path_hashes` to // `latest_foreign_def_path_hashes`, since the `RawDefId` might have // changed in the current compilation session (e.g. we've added/removed crates, // or added/removed definitions before/after the target definition). if let Some(def_id) = self.def_path_hash_to_def_id(tcx, hash) { self.store_foreign_def_id_hash(def_id, hash); </ins> } }

Discussion:
This seems to be an incremental error‽ We need an external crate for this to work. Haven't managed it to work in an internal mod only :/ Also this only happens with . Haven't managed to get it running with sadly extern crate (let's call it f) code Then just remove and add afterwards again (or the other way round, it doesn't matter). This script does it for you: <!-- 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<pand with RUST_BACKTRACE=full the LLVMing assert vanishes </p</details
searched nightlies: from nightly-2020-12-08 to nightly-2020-12-10 regressed nightly: nightly-2020-12-10 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: </detailscc
Assigning as discussed as part of the and removing .
I've fixed the issue locally, and I'm working on a PR.
Opened
Change:
<ins> error[E0599]: no function or associated item named `iter` found for reference `&[u32]` in the current scope --> $DIR/issue-103271.rs:2:30 | LL |     let iter_fun = <&[u32]>::iter; |                              ^^^^ function or associated item not found in `&[u32]` | help: the function `iter` is implemented on `[u32]` | LL |     let iter_fun = <[u32]>::iter; |                     ~~~~~ error: aborting due to previous error For more information about this error, try `rustc --explain E0599`. </ins>

Discussion:
Given the following code (): The current output is: This suggestion is on the right track, but unfortunately it introduces a parse error. It should be: This suggestion is in . It suggests adding around the type because the type is a slice, but I already have in my program (and the span doesn't include the existing ). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Change:
let (file_metadata, line_number) = if !span.is_dummy() { let loc = cx.lookup_debug_loc(span.lo()); <del> (file_metadata(cx, &loc.file.name, LOCAL_CRATE), loc.line) </del> <ins> (file_metadata(cx, &loc.file, LOCAL_CRATE), loc.line) </ins> } else { (unknown_file_metadata(cx), None) };

Discussion:
shows a pretty big regression between and . I don't know if this is expected, but I'm putting this out there in case others see the dent in perf charts and wonder what had happened. <hr/EDIT( we how have a for . , the other PR in the range, (but only for a small subset of runs).
cc
The range is so the candidates are: "Make the rustc respect the flag in incremental mode." "Add hash of source files in debug info" EDIT: oops, missed - so it's likely . Slow MD5 implementation? I'm curious, why does (merge commit for ) not have its own perf run? Is there a way to trigger one now?
is in the queue:
It looks like this was caused by . I'll start investigating why. I timed several compilations of locally in debug with and without .
For the record, from . I'll update the issue description to minimize potential confusion. Two things I'm seeing: are way worse regressions than , you can focus on the worse ones to get better contrast in measurements (e.g. even has "patched incremental" runs slowed down a lot, unlike many others, being another example I guess) detailed profile (if you click the percentage for a run) shows a lot of LLVM differences, e.g. for , and most of the regressions are , with effectively no ones, so I think we might be able to get away without a revert, just adding a flag controlling whether LLVM sees these hashes (assuming that's the source of the slowdown)
We have (), which at a glance looks right. looks like noise, and so does , so I believe this confirms the fix is complete. For the cost of MD5 hashing compared to SipHash, based on the changes to runs in the original regression, it looks insignificant.
Change:
<ins> warning: unexpected `cfg` condition name: `linux` --> $DIR/cfg-value-for-cfg-name.rs:9:7 | LL | #[cfg(linux)] |       ^^^^^ help: found config with similar value: `target_os = "linux"` | = help: expected names are: `debug_assertions`, `doc`, `doctest`, `miri`, `overflow_checks`, `panic`, `proc_macro`, `relocation_model`, `sanitize`, `sanitizer_cfi_generalize_pointers`, `sanitizer_cfi_normalize_integers`, `target_abi`, `target_arch`, `target_endian`, `target_env`, `target_family`, `target_feature`, `target_has_atomic`, `target_has_atomic_equal_alignment`, `target_has_atomic_load_store`, `target_os`, `target_pointer_width`, `target_thread_local`, `target_vendor`, `test`, `unix`, `windows` = help: to expect this configuration use `--check-cfg=cfg(linux)` = note: see <https://doc.rust-lang.org/nightly/unstable-book/compiler-flags/check-cfg.html> for more information about checking conditional configuration = note: `#[warn(unexpected_cfgs)]` on by default warning: unexpected `cfg` condition name: `linux` --> $DIR/cfg-value-for-cfg-name.rs:14:7 | LL | #[cfg(linux = "os-name")] |       ^^^^^^^^^^^^^^^^^ | = help: to expect this configuration use `--check-cfg=cfg(linux, values("os-name"))` = note: see <https://doc.rust-lang.org/nightly/unstable-book/compiler-flags/check-cfg.html> for more information about checking conditional configuration warning: 2 warnings emitted </ins>

Discussion:
The user wanted something with "linux", and there is a name-value cfg that has the value "linux", so they probably wanted that. No response
Change:
<ins> // check-pass pub trait Associate { type Associated; } pub struct Wrap<'a> { pub field: &'a i32, } pub trait Create<T> { fn create() -> Self; } pub fn oh_no<'a, T>() where Wrap<'a>: Associate, <Wrap<'a> as Associate>::Associated: Create<T>, { <Wrap<'a> as Associate>::Associated::create(); } pub fn main() {} </ins>

Discussion:
() <details<summaryBacktrace (click to expand)</summary` </details label requires-nightly, F-genericassociatedtypes, A-traits, A-lifetimes, A-associated_items, A-typesystem, T-compiler I'm not whether I'd expect this code to fail or to compile successfully (though I might be leaning towards expecting the latter).
No longer ICEs since
GATs issue triage: not blocking. Fixed and needs test.

Source: It is worth noting that this code should not compile. This bug occurs in both beta and nightly. : <details<summary<strongBacktrace</strong</summary<p</p</details
No longer ICEs since
Change:
<ins> // edition:2018 async fn f() -> i32 { if true { //~ ERROR if may be missing an else clause return 0; } // An `if` block without `else` causes the type table not to have a type for this expr. // Check that we do not unconditionally access the type table and we don't ICE. } fn main() {} </ins>

Discussion:
() Triggers on playground on beta and nightly channels, not on stable. Stacktrace:
Even smaller sample (from
triage: P-high. Removing nomination.
triage: P-high, removing nomination label.
Change:
#[test] fn formatted() { <del> let s = CString::new(&b"12"[..]).unwrap(); assert_eq!(format!("{:?}", s), ""12""); </del> <ins> let s = CString::new(&b"abcx01x02nxE2x80xA6xFF"[..]).unwrap(); assert_eq!(format!("{:?}", s), r#""abcx01x02nxe2x80xa6xff""#); </ins> } #[test]

Discussion:
CString should escape its contents like a byte string, not trying to show it as utf-8. Right now it does the latter via
For example, if the CString contains the byte , I would expect that to be visible in the Debug output.
Change:
InvalidProgramInfo, ResourceExhaustionInfo, UndefinedBehaviorInfo, }; <del> pub use self::value::{Scalar, ScalarMaybeUndef, RawConst, ConstValue}; </del> <ins> pub use self::value::{Scalar, ScalarMaybeUndef, RawConst, ConstValue, get_slice_bytes}; </ins> pub use self::allocation::{Allocation, AllocationExtra, Relocations, UndefMask};

Discussion:
Results in cc
modify labels: I-ICE C-Bug T-compiler A-const-generics
I'm looking into this currently.
Partially as a note to myself and partially as an update to anyone interested The root cause of this bug seems to be the fact that we currently don't explicitly handle slice const values in , and therefore we always say they cannot match. This error eventually bubbles up to to produce all three errors.
Change:
Closure(closure_span) => { self.sess.dcx().emit_err(BreakInsideClosure { span, closure_span, name }); } <del> AsyncClosure(closure_span) => { self.sess.dcx().emit_err(BreakInsideAsyncBlock { span, closure_span, name }); </del> <ins> Coroutine { coroutine_span, kind, source } => { let kind = match kind { hir::CoroutineDesugaring::Async => "async", hir::CoroutineDesugaring::Gen => "gen", hir::CoroutineDesugaring::AsyncGen => "async gen", }; let source = match source { hir::CoroutineSource::Block => "block", hir::CoroutineSource::Closure => "closure", hir::CoroutineSource::Fn => "function", }; self.sess.dcx().emit_err(BreakInsideCoroutine { span, coroutine_span, name, kind, source, }); </ins> } UnlabeledBlock(block_span) if is_break && block_span.eq_ctxt(break_span) => { let suggestion = Some(OutsideLoopSuggestion { block_span, break_span });

Discussion:
Same issue as which was for blocks. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim