jiebi/CodeConvo huggingface dataset:
Change:
let fn_ty = func.ty(self.mir, self.tcx); let mut callee_def_id = None; <del> let (mut is_shuffle, mut is_const_fn) = (false, false); </del> <ins> let mut is_shuffle = false; let mut is_const_fn = false; let mut is_promotable_const_fn = false; </ins> if let ty::FnDef(def_id, _) = fn_ty.sty { callee_def_id = Some(def_id); match self.tcx.fn_sig(def_id).abi() {

Discussion:
: produces cc
Not that this fixes the issue, but and aren't necessarily guaranteed to have the same representation without or on both and .
minified: is this a victim of the backwards algorithm for promotion? Just a hunch, but it might have promoted away the call to and then end up trying to promote the , but it's not in the place where it was expected, because it now lives inside the promoted. So it ends up trying to promote an argument in a basic block that was already promoted away
thanks , I'll update the PR that triggered this - for context
As a workaround until we fix this ICE, you can introduce an intermediate explicit constant for the argument to . Or is this part of a user-exposed API?
This is part of a user-exposed API, but that workaround should allow me to at least get the const tests running.
It won't remove the definition if there's more than one use (unless this is fallout from your changes?)
There's only one use. I don't see how my changes could have caused this, but it seems possible. I'll do a bisection
Oh, I see, is and that's missing a check like:
Fix instructions: Add a which, like the variable, is used to mark blocks whose terminator has been promoted out. skip promoting all such terminators when encountering said block id in a ()
You can use a , although I'm not even sure it's necessary. A promoted call ends up as a , so you could just skip it based on that?
Change:
<del> Subproject commit 027e428197f3702599cfbb632883768175f49173 </del> <ins> Subproject commit 9f9da27fbdb0ba7d887f8d2521e082f12b009417 </ins>

Discussion:
I'm using clang/llvm to build (instead of gcc). make sure sanitizers are built: use llvm ar and ranlib fails to build: `
For the record, I am at I believe this is a recent regression, probably introduced in the last 1-2 days.
I'm wondering if this was caused by /
Nope, reverting that did not fix the build failure..
cc
AFAICS includes a fix (glibc 2.31 changed ABI: ).
Change:
<ins> use std::ops::Deref; use std::rc::Rc; struct Value<T>(T); pub trait Wrap<T> { fn wrap() -> Self; } impl<R, A1, A2> Wrap<fn(A1, A2) -> R> for Value<fn(A1, A2) -> R> { fn wrap() -> Self { todo!() } } impl<F, R, A1, A2> Wrap<F> for Value<Rc<dyn Fn(A1, A2) -> R>> { fn wrap() -> Self { todo!() } } impl<F> Deref for Value<Rc<F>> { type Target = F; fn deref(&self) -> &Self::Target { &*self.0 } } fn main() { let var_fn = Value::wrap(); //~^ ERROR type annotations needed for `Value<Rc<_>>` // The combination of `Value: Wrap` obligation plus the autoderef steps // (caused by the `Deref` impl above) actually means that the self type // of the method fn below is constrained to be `Value<Rc<dyn Fn(?0, ?1) -> ?2>>`. // However, that's only known to us on the error path -- we still need // to emit an ambiguity error, though. let _ = var_fn.clone(); } </ins>

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. --It seems this is a particularly tricky interaction of , coercion and these two ; take away any one, and the compiler spits out a type annotation error as seen below. The compiler is also happy if is annotated as but I don't quite understand why this needs to be specified, given the inner casts on both branches. <!-- 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
reduced a bit
Regression in nightly-2020-06-24
This is minimized in the sense that spurious errors are avoided: The problem here is that the autoderef of a method is interacting strangely with the obligation registered by the line. This actually guides inference in such a way that an assertion in the compiler is not upheld -- that assertion is kinda nonsense though, so I'm just gonna rework it.
I've tried bisecting to a narrower point but didn't get far: commit[0] 2020-06-22: Auto merge of - ehuss:update-cargo, r=ehuss commit[1] 2020-06-22: Auto merge of - Aaron1011:revert/move-fn-self-msg, r=Manishearth commit[2] 2020-06-23: Auto merge of - yoshuawuyts:socketaddr-from-string-u16, r=sfackler commit[3] 2020-06-23: Auto merge of - Dylan-DPC:rollup-b4wbp42, r=Dylan-DPC commit[4] 2020-06-23: Auto merge of - Manishearth:rollup-68dr8fz, r=Manishearth commit[5] 2020-06-23: Auto merge of - ollie27:rustdocaliasfilter, r=GuillaumeGomez So I guess one , or WG-prioritization assigning priority (). label -I-prioritize +P-low
Change:
<ins> // Regression test for the ICE described in issue #91334. // error-pattern: this file contains an unclosed delimiter // error-pattern: expected one of // error-pattern: mismatched closing delimiter // error-pattern: mismatched types #![feature(generators)] fn f(){||yield(((){), </ins>

Discussion:
This debugassert: Is triggered by the following input, found by : <details<summary<strongBacktrace</strong</summary<p</p</details
Reduced (in terms of unrelated errors):
label +requires-nightly +A-generators +F-generators
Change:
<ins> // Regression test for #125325 // Tests that we suggest changing an `impl Fn` param // to `impl FnMut` when the provided closure arg // is trying to mutate the closure env. // Ensures that it works that way for both // functions and methods struct S; impl S { fn assoc_func(&self, _f: impl Fn()) -> usize { 0 } } fn func(_f: impl Fn()) -> usize { 0 } fn test_func(s: &S) -> usize { let mut x = (); s.assoc_func(|| x = ()); //~^ cannot assign to `x`, as it is a captured variable in a `Fn` closure func(|| x = ()) //~^ cannot assign to `x`, as it is a captured variable in a `Fn` closure } fn main() {} </ins>

Discussion:
I tried this code: I expected to see this happen: Code compilation, or at least a sensible error. Instead, this happened: I tried to make a reproducer using the following code that expresses the same type and fn signatures on Rust Playground, but I'm unable to trigger it. : tested on Nightly as well. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
- and even smaller example
Thank you!!
claim
Change:
<ins> // run-pass // edition:2021 const LIBUSB_HOTPLUG_EVENT_DEVICE_ARRIVED: i32 = 0x01; const LIBUSB_HOTPLUG_EVENT_DEVICE_LEFT: i32 = 0x02; pub fn hotplug_callback(event: i32) { let _ = || { match event { LIBUSB_HOTPLUG_EVENT_DEVICE_ARRIVED => (), LIBUSB_HOTPLUG_EVENT_DEVICE_LEFT => (), _ => (), }; }; } fn main() { hotplug_callback(1); } </ins>

Discussion:
The following ICE was found migrating 0.26.0 and  0.4.38. cc which was an error on the same line, though I think the cause is slightly different. Note that I think this is also triggering an incorrect lint for the parameter (the actual code uses the parameter). <!-- 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</detailscc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
tcx.ensure().generics_of(item.def_id); tcx.ensure().type_of(item.def_id); tcx.ensure().predicates_of(item.def_id); <del> if let hir::ForeignItemKind::Fn(..) = item.kind { tcx.ensure().fn_sig(item.def_id); </del> <ins> match item.kind { hir::ForeignItemKind::Fn(..) => tcx.ensure().fn_sig(item.def_id), hir::ForeignItemKind::Static(..) => { let mut visitor = PlaceholderHirTyCollector::default(); visitor.visit_foreign_item(item); placeholder_type_error(tcx, None, &[], visitor.0, false, None); } _ => (), </ins> } } }

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
The ICE happens because the type placeholder error has been gone since 1.43.
Assigning priority as discussed as part of the and removing . label -I-prioritize +P-medium
Change:
pub llvm_profile_generate: bool, pub llvm_bolt_profile_generate: bool, pub llvm_bolt_profile_use: Option<String>, <ins> /// Arguments appearing after `--` to be forwarded to tools, /// e.g. `--fix-broken` or test arguments. pub free_args: Option<Vec<String>>, </ins> } #[derive(Debug)]

Discussion:
Right now, x.py is pretty inconsistent with cargo's CLI. To pass arguments to compiletest, you use ; to pass arguments to you use ; to pass arguments to cargo you use CARGOFLAGS. I would like to unify these with the same syntax as cargo: would behave the same as today would behave the same as would behave the same as today, except that it would only pass it to cargo commands invoked by bootstrap, not when building bootstrap itself (avoiding the "argument --fix-broken not expected" error you'd get today). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Looking at the current setup for argument parsing, it appears that getopts::Options struct doesn't have a state engine based parser, so it wont be able to parse -- as a state changing flag. I'm thinking probably parse and translate the args in python then just pass it on to the bootstrap executable, (unless someone here has a better idea).
let's not put any logic in python if we can help it, it's going away soon: . I think it would be ok to switch to or another arg parser if it makes things easier.
Ah, I was thinking something like getting rid of the python script was going to happen someday. will probably do for the functionality we will need from it.
I'm out of town for the rest of the week so if anyone would like to take this issue while I'm away, go for it.
Change:
#[unstable(feature = "core", reason = "likely to be replaced by range notation and adapters")] <del> impl<A: Step + One + Clone> Iterator for RangeInclusive<A> { </del> <ins> impl<A> Iterator for RangeInclusive<A> where A: PartialEq + Step + One + Clone, for<'a> &'a A: Add<&'a A, Output = A> { </ins> type Item = A; #[inline]

Discussion:
I tried printing all valid s by doing and was surprised to find it only printed up to 254. I'm unsure if this is supposed to be this way ( can be used). If so, I'd propose adding this to the Iterators/Ranges section of the book.
The problem is the next method of RangeFrom: It returns the previous value, then updates itself to store the next one. The value 255 ends up being the value that represents a "done" state, so it can't return it. I can't think of any solution that doesn't involve adding a flag to RangeFrom.
Or impl IntoIter instead of Iterator (and use a helper struct to keep track of the range).
Seems similar to .
Question: What is the origin of this Rust behavior, or what is its justification? e.g.: Why an exclusive upper bound on ranges? This caught me by total surprise, coming from Haskell, and I don't know if any Rust I've written for my own cases is wrong now. It behaves differently from similar syntax in Haskell, Swift, and Go, so I'm wondering if it's fruitful to have behavior different from peer languages (in trying to attract people away from languages where syntax like this does not exist.)
Ruby has both exclusive and inclusive ranges
The origin is related to the for-loop idiom in C. corresponds to the range. It has some nice properties such as how it iterates over exactly elements, whereas an inclusive range does and would require you to say, for example, for the indices of a vector if were inclusive. Essentially, it seems like the exclusive behaviour is useful more often than inclusive in a systems language.
Exclusive behaviour is also a leaner implementation. For inclusive behaviour you need some kind of flag for "now yield the inclusive element". This issue is an exact example of why: How do you statefully write an iterator from to , inclusive?
cc , which adjusts this behavior by triggering an overflow on non-wrapped-arithmetic types; it makes the semantics equivalent to repeatedly updating .
so just to be clear, with the above PR merged, now panics. Is this the intended behavior?
Change:
do yeet primary } <del> // If `translate_with_bundle` returns `Err` with the primary bundle, this is likely // just that the primary bundle doesn't contain the message being translated or // something else went wrong) so proceed to the fallback bundle. </del> <ins> // ..otherwise, for end users, an error about this wouldn't be useful or actionable, so // just hide it and try with the fallback bundle. </ins> Some(Err(primary)) => translate_with_bundle(self.fallback_fluent_bundle()) .map_err(|fallback| primary.and(fallback))?,

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. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
claim
After doing some more investigation, this also happens on a crate with only the empty crate: and like the original error, and are all used in manual implementations.
There are a bunch of these triggering in various lints it seems, so I wonder if the assert might actually not be thaaat justified?
changed that when a message is not in the primary bundle and debugassertions are on, it ices. So, for example, if you are using a half translated French bundle with messages missing, and have debugassertions on, you'll probably ice a lot. I agree that that in hindsight might have been a bad idea, and we should back that out ...however we don't actually have any other bundles, so I have no idea how this can trigger. I did some more debugging today, and it looks like the primary bundle never has any messages, so it should only trigger if the message requires formatting. I have no idea why that is or why it only happens if you have a rustc built with debug_assertions, rather than during tests for example. The only thing I can come up with is that between invoking rustc and running tests the bundle is created differently.
Change:
} fn set_drop_flag(&mut self, loc: Location, path: MovePathIndex, val: DropFlagState) { <del> if let Some(&flag) = self.drop_flags.get(&path) { </del> <ins> if let Some(flag) = self.drop_flags[path] { </ins> let span = self.patch.source_info_for_location(self.body, loc).span; let val = self.constant_bool(span, val.value()); self.patch.add_assign(loc, Place::from(flag), val);

Discussion:
This code creates MIR statements based on an iteration order: is defined as: Since FxHashMap's fixed seed is different between 32 and 64 bit platforms, we may end up creating statements in a different order on 32-bit vs 64-bit hosts (the target platform passed to the compiler has no effect). We should probably sort by before creating the statements.
Perhaps it should just use instead?
Revisiting this issue to evaluate the priority. unsure about the status and global direction of this issue. Do we have some work in progress somewhere? I've tried following the breadcrumbs and landed on . Unsure if it helps and - if yes - how much does that pull request covers to fix this issue. opinions? thanks :)
Change:
} println!("eax is currently {}", result); # } <ins> # #[cfg(not(any(target_arch = "x86", target_arch = "x86_64")))] # fn main() {} </ins> ``` ## More Information

Discussion:
Triggers an LLVM assertion when targeting Android:
Something that works on any host (i.e. you needn’t compile libstd for android to repro):
As the error says, isn't a supported calling convention for the ARM target in LLVM. Not really much we can do from the rustc side unless we want to error early based on cc/target combinations. In any case, it should not crash.
I'm hitting this when I tried to run tests for 1.10.0 on arm64 (aarch64-unknown-linux-gnu). The build succeeds otherwise. I'm just adding and to for the time being.
Neither example crashes today. Closing, since I don't see any good opportunity for a test here (it'd have to be something like and that's probably not worth it). With (original example): Updated example:
Change:
let mut tarball = Tarball::new(builder, "rustc-docs", &host.triple); tarball.set_product_name("Rustc Documentation"); <del> tarball.add_dir(&builder.compiler_doc_out(host), "share/doc/rust/html/rustc"); </del> <ins> tarball.add_bulk_dir(&builder.compiler_doc_out(host), "share/doc/rust/html/rustc"); </ins> 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.)
Change:
<ins> // Regression test for #121094. // build-pass // compile-flags: -O --crate-type=lib // edition: 2021 use std::{future::Future, pin::Pin}; pub async fn foo(count: u32) { if count == 0 { return } else { let fut: Pin<Box<dyn Future<Output = ()>>> = Box::pin(foo(count - 1)); fut.await; } } </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. --This code compiles in debug mode, but fails in release mode (): On release mode, it errors with: I bisected it down to this patch causing the issue: cc <!-- 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<summaryBacktrace</summary<p</p</details
label +T-compiler +A-mir-opt +S-has-mcve -needs-triage
Shouldn't this be given a priority? label +P-critical cc cc
This fails to compile with either debug or release mode on stable. That means this isn't a regression, but rather an accidental stabilization. Probably still P-critical though
- good catch, I updated the example to use the dyn trait as suggested by the stable compiler, which passes both debug and release, but fails with nightly release.
This is not an accidental stabilization. This was stabilized in . This is a legitimate misoptimization.
Change:
ptr::drop_in_place(&mut self.ptr.as_mut().data); if self.inner().weak.fetch_sub(1, Release) == 1 { <del> atomic::fence(Acquire); </del> <ins> acquire!(self.inner().weak); </ins> Global.dealloc(self.ptr.cast(), Layout::for_value(self.ptr.as_ref())) } }

Discussion:
iff the crate contains two or more unit tests. TODO Sanitizers are not yet in tree. (cf. ) cc
Like with I'd be tempted to say these are false positives, but these stack traces don't look so familiar so I'm not certain of that
This will be a false positive because drop_slow uses a fence, and tsan doesn't work with fences.
So I take it this isn't actually a problem since we're just using a fence and tsan doesn't support that? Should we close?
Can the false-positive be worked-around by manually annotating the happens-before relationship? See
Well, maybe if we could conditionally build without the fence (rework to use a load/store instead) when tsan is enabled then the error wouldn't be seen.
Change:
fn causes_ice(mut l: &mut Sexpression) { loop { match l { <del> &mut Sexpression::Num(ref mut n) => {}, //[mir]~ ERROR (Mir) [E0384] </del> <ins> &mut Sexpression::Num(ref mut n) => {}, </ins> &mut Sexpression::Cons(ref mut expr) => { //[ast]~ ERROR [E0499] //[mir]~^ ERROR (Ast) [E0499] //[mir]~| ERROR (Mir) [E0506] <del> //[mir]~| ERROR (Mir) [E0384] </del> //[mir]~| ERROR (Mir) [E0499] l = &mut **expr; //[ast]~ ERROR [E0506] //[mir]~^ ERROR (Ast) [E0506]

Discussion:
MIR borrowck considers variables still initialized after their storage ends, so if an immutable variable is defined and used in a loop, this causes an error. e.g.: Which causes:
working on it