jiebi/CodeConvo huggingface dataset:
Change:
let expected = ScalarMaybeUninit::from(Scalar::from_bool(*expected)); let value_const = self.ecx.read_scalar(value).unwrap(); if expected != value_const { <ins> enum DbgVal<T> { Val(T), Underscore, } impl<T: std::fmt::Debug> std::fmt::Debug for DbgVal<T> { fn fmt(&self, fmt: &mut std::fmt::Formatter<'_>) -> std::fmt::Result { match self { Self::Val(val) => val.fmt(fmt), Self::Underscore => fmt.write_str("_"), } } } </ins> let mut eval_to_int = |op| { <del> let op = self .eval_operand(op, source_info) .expect("if we got here, it must be const"); self.ecx.read_immediate(op).unwrap().to_const_int() </del> <ins> // This can be `None` if the lhs wasn't const propagated and we just // triggered the assert on the value of the rhs. match self.eval_operand(op, source_info) { Some(op) => { DbgVal::Val(self.ecx.read_immediate(op).unwrap().to_const_int()) } None => DbgVal::Underscore, } </ins> }; let msg = match msg { AssertKind::DivisionByZero(op) => {

Discussion:
UPDATE: MCVE can be found . Nightly compilation error due to rustc bug I tried this code: I expected to see this happen: explanation Successful compilation. Instead, this happened: tells to report a bug, see backtrace. : Reproduce with (1st update) <details<summaryBacktrace</summary<p</p</details
cc
Also occured with
I'm getting this when I try to repro: On a side note, are there any cargo feature flags I can pass to cut down on how much stuff is being compiled? Compiling 900 crates to get a repo is quite a lot
Also occured with just now.
mmh try with commit hash ? (for )
updated script:
Yeah, sorry for that. One of the difficulties of working with a big framework like Substrate. I'll see if I can narrow it down more.
That did it! Thank you
Some with the same issue (a different chain also using Substrate) found out that apparently works.
Seems is the cause, marking as .
Here's a smaller repro (at least in terms of how much code is built: 33 crates instead of a few hundred):
just confirmed that it does not occur with
I have a minimal repro:
Wild guess: erases the local before we are able to emit the diagnostic message.
I seem to be getting a similar error again on a more current nightly (). Should I open a new issue or do we just reopen this one?
This is still broken. I'm pretty confused because running the test you in on the shows that it ICEs. Is the test not actually working for some reason? Edit: Does that test need in order to actually check the body of those functions since they are uncalled from ?
Assigning as and removing I-prioritize.
Hi and have either of you had a chance to upgrade to a recently nightly? I just wanted to confirm this is fixed for you.
I've updated to rust version 1.47.0-nightly ( 2020-07-22), and tried compiling the crate which was triggering this ICE (). I no longer encounter an ICE, the crate compiles successfully.
I can confirm is not throwing ICE :+1:
Great, thank you!
Change:
if let Some(recv) = followed_by_ty_params { assert!(recv.is_empty()); *recv = attrs; <del> } else { </del> <ins> debug!("parse_lifetime_defs ret {:?}", res); return Ok(res); } else if !attrs.is_empty() { </ins> let msg = "trailing attribute after lifetime parameters"; return Err(self.fatal(msg)); } <del> debug!("parse_lifetime_defs ret {:?}", res); return Ok(res); </del> } }

Discussion:
Code: Compiles on 1.13-stable,beta, fails on 1.14-nightly.
(Forget that, see below).
Apart from that, this was introduced between and ().
I strongly suspect this is an unintended side effect of Prohibiting this deliberately doesn't make any sense, empty lists are allowed in () all other possible contexts.
Yeah, I probably mis-remembered :( I agree that this was probably a side effect of .
In fact, this fails too:
Change:
[[package]] name = "cargo" <del> version = "0.42.0" </del> <ins> version = "0.43.0" </ins> dependencies = [ "atty", "bytesize",

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.
Change:
data_layout: "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64".to_string(), arch: "arm".to_string(), target_os: "linux".to_string(), <del> target_env: "gnueabihf".to_string(), </del> <ins> target_env: "gnu".to_string(), </ins> target_vendor: "unknown".to_string(), options: TargetOptions {

Discussion:
Right now is predominately used to conditionally compile code for differing C libraries like msvc, glibc, musl, etc. On ARM, however, there are two glibc annotations, "gnueabi" and "gneuabihf". This then also extends to musl with "musleabi" and "musleabihf". This seems unnecessarily complicated to say "conditionally compile this code when using musl", that is it should only require one annotation, not three. We could possibly change as I doubt anyone's using "gnueabihf" as a matcher, or we could add a new .
cc
The presence of absence of hard float should be denoted inside its own feature instead ( or something). I believe we already have (or plans for) a few such switches already.
Could we use for choosing between static vs dynamic or release vs debug for the msvc CRT?
The toosl team discussed this issue at triage and the decision was to name as either gnu or musl instead of also gnueabi/musleabi. I'll send a PR shortly
There should probably also be a good way to distinguish between statically linked musl and dynamically linked musl targets.
Change:
<del> Subproject commit 03684905101f0b7e49dfe530e54dc1aeac6ef0fb </del> <ins> Subproject commit e19f07f5a6e5546ab4f6ea951e3c6b8627edeaa7 </ins>

Discussion:
LLVM 7.0 has been branched as of 2018-08-01, with the final tag probably a couple weeks away. The first release candidate will be tagged in a couple of days. is the llvm-dev announcement, and is a view of the commits on the branch. Once the final release has been tagged, Rust should be updated to LLVM 7.0.
Great! I've started our branches: I'm hoping that this'll be pretty smooth since we upgraded most of the way through the cycle! I'm testing locally now and will send a PR once green.
Change:
/// assert!(map.into_iter().eq(vec![(0, 0), (2, 20), (4, 40), (6, 60)])); /// ``` #[inline] <del> #[unstable(feature = "btree_retain", issue = "79025")] </del> <ins> #[stable(feature = "btree_retain", since = "1.53.0")] </ins> pub fn retain<F>(&mut self, mut f: F) where K: Ord,

Discussion:
This is a tracking issue for and (part of rust-lang/rfcs). The feature gate for the issue is . [x] Implement the RFC [x] FCP [ ] Adjust documentation [ ] Stabilization PR Is the performance of the current implementation (based on ) good enough to be useful? Concern raised in . Initial implementation:
We discussed this in today's meeting. We'd like to see a comment documenting the performance characteristics of this (as well as a corresponding update to ), and suggesting that this might not be what you want if you're removing a substantial number of elements. Beyond that documentation, though, we'd be happy to see this stable. 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] [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.
: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. The RFC will be merged soon.
Change:
} return None; } <del> PathResult::NonModule(path_res) if path_res.base_res() == Res::Err => { </del> <ins> PathResult::NonModule(_) => { </ins> if no_ambiguity { assert!(import.imported_module.get().is_none()); } // The error was already reported earlier. return None; } <del> PathResult::Indeterminate | PathResult::NonModule(..) => unreachable!(), </del> <ins> PathResult::Indeterminate => unreachable!(), </ins> }; let (ident, target, source_bindings, target_bindings, type_ns_only) = match import.kind {

Discussion:
Happens on stable and nightly. Compiler crash <details<summary<strongBacktrace</strong</summary<p</p</details
This regression looks to be really old. Could not pinpoint a specific commit while bisecting
I don't think this is a regression, the flag just didn't exist before 1.31 (the panic doesn't occur without ).
Assigning and removing as in the prioritization working group. label: +P-low -I-prioritize
Change:
} debug!("sizing_type_of {:?}", t); <ins> let _recursion_lock = cx.enter_type_of(t); </ins> let llsizingty = match t.sty { _ if !type_is_sized(cx.tcx(), t) => { Type::struct_(cx, &[Type::i8p(cx), Type::i8p(cx)], false)

Discussion:
Repeating segment:
Note: the type is regular, just not representable (actual non-regular data types make selection overflow, possibly at trans time).
This particular case could be handled in type-checking, but the general case requires some sort of recursion check after the type has been monomorphized.

causes a stack overflow.
This is a stack overflow inside middle::traits::project::normalizeprojectiontype

I've encountered a variant of this bug (or is it another bug? please advise if so and I will post it separately): If I remove the lifetime, the stack overflow no longer occurs.
Seems to be a dupe of
example was fixed in 1.4.

The following program generates a trans-time stack overflow.
Can confirm this is still an issue
This is somewhat distinct from , as it creates an irregular type without selection errors.
actually, not really.

On 3/4/2015 on playpen, the following code: the following error: This may be considered a duplicate of issue , which notes a similar problem with recursive trait bounds. I figured this may be unique given that this involves a recursive associated type on a trait, rather than a recursive trait itself.
cc
This was just rediscovered in the #rust IRC.
The code that that IRC example was simplified from was code that looked reasonably sane (and was quite far removed from simple recursion like this), so trying to come up with an error message instead of a crash would be quite handy.
Change:
ENV RUST_CONFIGURE_ARGS --build=x86_64-unknown-linux-gnu --set rust.ignore-git=false ENV SCRIPT python2.7 ../x.py test distcheck ENV DIST_SRC 1 <ins> # The purpose of this builder is to test that we can `./x.py test` successfully # from a tarball, not to test LLVM/rustc's own set of assertions. These cause a # significant hit to CI compile time (over a half hour as observed in #61185), # so disable assertions for this builder. 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:
//! compiler. This module is also responsible for assembling the sysroot as it //! goes along from the output of the previous stage. <del> use std::collections::HashMap; </del> <ins> use std::env; </ins> use std::fs::{self, File}; <ins> use std::io::BufReader; use std::io::prelude::*; </ins> use std::path::{Path, PathBuf}; <del> use std::process::Command; use std::env; </del> <ins> use std::process::{Command, Stdio}; use std::str; </ins> use build_helper::{output, mtime, up_to_date}; use filetime::FileTime; <ins> use rustc_serialize::json; </ins> use channel::GitInfo; use util::{exe, libdir, is_dylib, copy};

Discussion:
Rustbuild compiles the compiler in a particular location and is then responsible for copying artifacts over to the actual structure the compiler is expecting (e.g. rustbuild assembles a sysroot). In order to handle stale folders rustbuild , deduplicated by hash. This pretty obviously, though, doesn't work with multiple versions of the same library! We should probably call Cargo with and learn about compiled artifacts, that way we can copy precisely what we need to into the sysroot.
Change:
let (ident, fn_decl, generics, top_level_block, span, has_path) = match fnitem { ast_map::NodeItem(ref item) => { <ins> if contains_nodebug_attribute(item.attrs.as_slice()) { return FunctionDebugContext { repr: FunctionWithoutDebugInfo }; } </ins> match item.node { ast::ItemFn(fn_decl, _, _, ref generics, top_level_block) => { (item.ident, fn_decl, generics, top_level_block, item.span, true)

Discussion:
Right now debuginfo can only be turned on or off globally. Sometimes it would be good to be able to exclude only specific functions from debuginfo, especially when they trigger a bug in rustc's or LLVM's debuginfo handling (e.g. ). This way, one would be able to still mostly use debuginfo in the presence of (localized) debuginfo issues.
Change:
extern "system" fn(ExceptionInfo: *mut EXCEPTION_POINTERS) -> LONG; #[repr(C)] <del> #[derive(Copy, Clone)] pub struct CONSOLE_READCONSOLE_CONTROL { pub nLength: ULONG, pub nInitialChars: ULONG, pub dwCtrlWakeupMask: ULONG, pub dwControlKeyState: ULONG, } pub type PCONSOLE_READCONSOLE_CONTROL = *mut CONSOLE_READCONSOLE_CONTROL; #[repr(C)] </del> pub struct BY_HANDLE_FILE_INFORMATION { pub dwFileAttributes: DWORD, pub ftCreationTime: FILETIME,

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --Building std library (-Zbuild-std) with nightly for uwp-windows-msvc targets has been failing with compile errors since around after 17/10/22 I expected to see this happen: Last successeful build on 16/10: Instead, this happened: Lastest failed build: It most recently worked on: rustc 1.66.0-nightly ( 2022-10-14) : <!-- Did the compiler crash? If so, please provide a backtrace. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --
Hey, is anyone looking into this because ALXR ci (uwp) builds are failing for over a week. Should this issue be posted in another repo?
This is the right repo, but it fell through the cracks for whatever reason. I can get to it this weekend.
Thank you :)
Oh, sorry I missed this! Since 10.0. console functions are available on UWP (see ). So I think the thing to do here is to simply stop making the function conditionally imported.
Change:
#[inline] fn clone(&self) -> Mixed { let _: ::core::clone::AssertParamIsClone<u32>; <ins> let _: ::core::clone::AssertParamIsClone<Option<u32>>; let _: ::core::clone::AssertParamIsClone<Option<i32>>; </ins> *self } }

Discussion:
I tried this code: I expected to see this happen: code fails to compile. Instead, this happened: code compiles, and assertion fails. Changing order of enum variants to make go first fixes the issue: : It's reproducible in in Stable, Beta and Nightly. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I have played around a bit with the example and got to compile an even bigger class of bad programs: You can reproduce this in the . As you can see, the compiler is tricked into thinking that implements . This works with sum and product types, as long as: is the first field (or variant) and are "wrapped" with the same type, i.e , or . I have little experience with internals. Maybe someone more experienced could direct us to where this magic happens?
Expanding the macro yields a looks like it only asserts ness for the first field - whoops! claim
Gonna hand it over to you as discussed on zulip release
claim
On 1.63.0 this failed to compile, as expected (): label regression-from-stable-to-stable
this was recently introduced when was doing derive optimizations.
I'll take a look today, thanks for the report.
Don't worry, we've found the issue already, just wanted to let you know.
See for the fix.
WG-prioritization assigning priority a posteriori () mostly to help tracking the fix progress. label -I-prioritize +P-high
Change:
} #[stable(feature = "manually_drop", since = "1.20.0")] <del> impl<T> DerefMut for ManuallyDrop<T> { </del> <ins> impl<T: ?Sized> DerefMut for ManuallyDrop<T> { </ins> #[inline] fn deref_mut(&mut self) -> &mut Self::Target { &mut self.value

Discussion:
currently requires . It would be nice if we could remove this restriction. I'm not sure how to do it with the current implementation using though.
Doesn't seem possible until we get by-value DSTs
care to explain why?
Ah, nevermind. It would just need to make unsized, too.
The and methods can keep could keep their bounds, we just need to relax the bound on the struct itself, and make sure . Then the following code would be possible:
I guess this would be possible by allowing types to be when there is only one variant. I was worried that would be unsound, but then I realized, the only way to create a DST type would be from an unsize coercion, and then way you know what the erased type is and can get the vtable/slice length then, just like any other unsize coercion.
See
Change:
if let (None, Some(ty)) = (self.found_arg_pattern, self.node_ty_contains_target(param.hir_id)) { <del> self.found_arg_pattern = Some(&*param.pat); self.found_node_ty = Some(ty); </del> <ins> if self.target_span.contains(param.pat.span) { self.found_arg_pattern = Some(&*param.pat); self.found_node_ty = Some(ty); } </ins> } } intravisit::walk_body(self, body);

Discussion:
This compiles just fine: But this gives a compiler error: It seems really weird that the second statement is affected like this? Empty project (created with ), unmodified (so no extra dependencies): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It is actually that the first statement has type error, but somehow the error is reported to the second statement. The first statement alone reports the error correctly and by fixing the error, the following compiles fine
This happens on Nightly and on Stable.
Labeling as this was a regression introduced by 1.41.0.
Assigning .
Problem seems to be that we always assume the last closure was the source of the inference failure
Just sticking a return after is enough to get the correct diagnostic in this specific instance. However, we clearly need to be smarter than that, as in a sequence of closures, any of them could be the source of an inference error (current implementation always assumes last, just adding a return always assumes first).
Definitely not the case - looking into some alternative fixes. claim
Ok this is even more subtle than I first thought. There's just far too much ambiguity here for this diagnostic code to produce a sensible suggestion. Any time a sub-expression/local pattern/argument pattern/closure's type contains the inference target it immediately becomes a candidate for suggesting on. In this case though, the inference target is , so any code that has anything to do with strings will trip the diagnostic...
Compiling the above results in this - clearly the has nothing to do with the error...
I have a similar message to: But what I don't understand is: why does it complain it can't infer the type if it clearly knows the type?
Change:
self.flush_delayed( bugs.into_iter().map(DelayedDiagnostic::decorate), "no warnings or errors encountered even though `delayed_good_path_bugs` issued", <ins> GoodPathBug, </ins> ); }

Discussion:
With beta but nightly does not show backtraces: edits this is with prioritize
can you share your example code, as it doesn't seem that all ICEs are missing backtraces: on the same nightly and beta, and which has a backtrace on both. (if you have the time to do so and a master checkout, it'd be interesting to know whether ThinLTO could be involved like in ; bisection would also be worthwhile)
Hmm interesting, maybe its' something that only happens with :thinking: does not show a backtrace for me ! I also can't force it with or anything :(
This backtrace was removed on purpose in because it's useless. It just points at the place in the error machinery where delayed bugs get flushed, which is either just noise or misleading at worse.
This also affects explicit calls too -- these should be restored in . Regarding s backtraces being useless, see .