jiebi/CodeConvo huggingface dataset:
Code change:
<ins> //@ edition: 2021 #![feature(must_not_suspend, allocator_api)] #![deny(must_not_suspend)] use std::alloc::*; use std::ptr::NonNull; #[must_not_suspend] struct MyAllocatorWhichMustNotSuspend; unsafe impl Allocator for MyAllocatorWhichMustNotSuspend { fn allocate(&self, l: Layout) -> Result<NonNull<[u8]>, AllocError> { Global.allocate(l) } unsafe fn deallocate(&self, p: NonNull<u8>, l: Layout) { Global.deallocate(p, l) } } async fn suspend() {} async fn foo() { let x = Box::new_in(1i32, MyAllocatorWhichMustNotSuspend); //~^ ERROR allocator `MyAllocatorWhichMustNotSuspend` held across a suspend point, but should not be suspend().await; drop(x); } fn main() {} </ins>

Related discussion:
text: This code here has a potential issue: If the Box has a custom allocator, then that will not be checked at all. So whatever is used for, it ignores anything stored in custom allocators. It seems like this is just for a lint, so this is probably not critical, but I guess should still be fixed. Cc -- not sure whom else to ping for coroutine state machine transform things?
Cc (also a regular occurrence in this file's )
Lol sorry, I thought I had clicked enter on a comment but I must've not. Let me rewrite it. Yeah, this is approximately the level of urgency you determined. This code exists for an unstable lint, . I don't expect people to be writing , but technically they could.
Code change:
self.with_context(LabeledBlock, |v| v.visit_block(&b)); } hir::ExprBreak(label, ref opt_expr) => { <ins> opt_expr.as_ref().map(|e| self.visit_expr(e)); </ins> if self.require_label_in_labeled_block(e.span, &label, "break") { // If we emitted an error about an unlabeled break in a labeled // block, we don't need any further checking for this break any more

Related discussion:
text: Input: Output: This is on commit .
I've edited that code just recently so would want to work on this
Made PR to fix this
Thanks for fixing this :-) I also reported a couple of other looping-related bugs in in case you also want to have a look at those.
wow those are quite nice bugs :p. Will have a look.
Code change:
<ins> // error-pattern: aborting due to 6 previous errors fn i(n{...,f # </ins>

Related discussion:
text: I'm seeing an internal compiler error on the following input (found by ): The error happens on stable, beta, and nightly.
The only early return I see that doesn't emit is here:
Applying the most obvious patch, I get the following non-ICE output: The "expected , found " bit doesn't seem quite right. :slightlysmilingface:
is an unfortunate side effect of the unmatched delimiter recovery logic not accounting for s. Submit a PR with this patch to fix this ICE as fixing the slightly misleading message will require a much larger (unrelated) change.
I'll toss one up after I finish running the test suite. One thing: I'm not sure how to annotate the test. It looks like there's four errors that all point to EOF, but whatever I try to write, only one of them gets recognized as referring to that line.
this is what I did
Code change:
<ins> error[E0425]: cannot find function `missing` in this scope --> $DIR/error-body.rs:5:5 | LL |     missing(); |     ^^^^^^^ not found in this scope error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0425`. </ins>

Related discussion:
text: <!-- [31mICE[0m: Rustc '-Zvalidate-mir -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: unexpected body ty: {type error} phase Runtime(PostCleanup)', 'error: internal compiler error: unexpected body ty: {type error} phase Runtime(PostCleanup)' 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: [mirdropselaboratedandconstchecked] elaborating drops for [analysis] running analysis passes on this crate --
cc :D (note you'll need which was merged 10 minutes ago ^^ )
Code change:
<ins> error[E0425]: cannot find function `missing` in this scope --> $DIR/error-body.rs:5:5 | LL |     missing(); |     ^^^^^^^ not found in this scope error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0425`. </ins>

Related discussion:
text: <!-- [31mICE[0m: Rustc '--edition=2021 -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: impossible case reached', 'error: internal compiler error: impossible case reached' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [mirconst] preparing for borrow checking [mirpromoted] promoting constants in MIR for [mir_borrowck] borrow-checking [analysis] running analysis passes on this crate --
cc
Code change:
let msg = "asm template must be a string literal"; let template_sp = template_expr.span; <ins> let template_is_mac_call = matches!(template_expr.kind, ast::ExprKind::MacCall(_)); </ins> let (template_str, template_style, template_span) = { let ExpandResult::Ready(mac) = expr_to_spanned_string(ecx, template_expr, msg) else { return ExpandResult::Retry(());

Related discussion:
text: <!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'', 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'' 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: [resolverforlowering_raw] getting the resolver for lowering --
cc
(without looking at the code, is it ?) EDIT: ah no this might be the other class of macro-related unicode troubles, seems similar to
Code change:
return } <ins> // Package save-analysis from stage1 if not doing a full bootstrap, as the // stage2 artifacts is simply copied from stage1 in that case. let compiler = if build.force_use_stage1(compiler, target) { Compiler::new(1, compiler.host) } else { compiler.clone() }; </ins> let name = format!("rust-analysis-{}", package_vers(build)); let image = tmpdir(build).join(format!("{}-{}-image", name, target)); <del> let src = build.stage_out(compiler, Mode::Libstd).join(target).join("release").join("deps"); </del> <ins> let src = build.stage_out(&compiler, Mode::Libstd).join(target).join("release").join("deps"); </ins> let image_src = src.join("save-analysis"); let dst = image.join("lib/rustlib").join(target).join("analysis");

Related discussion:
text: So invalidated the assumption that the final stage is stage2, but [this piece of code][] still thought so, so the save-analysis data is never generated. This enraged the bots. Let's polish rustbuild with some more <3 so that we could have a fresh nightly for a nice New Year gift to everyone... []:
BTW the failure on the win32 beta bot (ouch!) is not related to this. It's most likely a Windows hiccup.
Ahhhh big failure of mine. I'm focusing on the generation part (the envvar) and forgot to touch the logic too, and the bots are as red as yesterday (facepalm). Trying to hit the 2017-01-02 nightly instead...
Code change:
version = "0.11.0" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ <del> "backtrace 0.3.25 (registry+https://github.com/rust-lang/crates.io-index)", </del> <ins> "backtrace 0.3.29 (registry+https://github.com/rust-lang/crates.io-index)", </ins> ] [[package]]

Related discussion:
text: Every since a recent nightly update, both distributed nightlies and locally built produce backtraces where every level of the stack is represented only by their memory address and the label : Sadly I don't have a more specific repro case, but I can consistently reproduce locally. Older distributed nightlies do not present this behavior.
This happens consistently for me as well (also macOS).
I've been seeing this on Linux too, though it's been at least a week. (It also may have been fixed in a rustc newer than the one servo uses)
We should have tests for backtraces, so they don't regress again in the future.
this is certainly happening on master, and it's been happening for a while, but I assumed it was my env.
It just occurred to me that this might be related to the new symbol mangling (although I doubt it).
I've been experiencing this for about a week now (also on macOS). It definitely started prior to being merged. I also have the following in my :
has absolutely no changes if you don't use the flag, so it's not from there.
It's definitely , I tried before and after. It works if you enable the "coresymbolication" feature, though that's obviously not an option for distribution. I tried the latest master of , but it didn't help.
To confirm, is everyone only experiencing problems on OSX for rustc itself? Are there problems with other projects on OSX? can you please confirm or deny your experience from Linux? Throwing in a new platform here changes this quite a lot
Ok I believe I've found the issue for OSX, but if other platforms are still an issue that would be good to know
I've only experienced this with rustc itself on OSX. Things it builds seem ok, and linux/windows seem to be ok.
No, it's still happening on Linux as of yesterday (I can try again today). I also assumed it was my env.
I think the Linux issue is separate since it's been happening much longer than the OSX one
Hey, this seems to an issue on nightly for Windows (msvc) as well: This uses backtrace via :
if that's only using the crate and not using libstd, can you open an issue on the repository? The OSX issue should be fixed in , which I'd like to finish testing and then I'll send an update to libstd.
Code change:
version = "0.11.0" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ <del> "backtrace 0.3.25 (registry+https://github.com/rust-lang/crates.io-index)", </del> <ins> "backtrace 0.3.29 (registry+https://github.com/rust-lang/crates.io-index)", </ins> ] [[package]]

Related discussion:
text: That could affect Linux as well but I doubt it, so if there are persisting Linux/Windows issues please feel free to let me know. If you can create an isolated problem which uses the crate rather than libstd that's even better!
Done: rust-lang/backtrace-rs
Code change:
[[package]] name = "rand" <del> version = "0.4.6" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "fuchsia-cprng 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)", "libc 0.2.54 (registry+https://github.com/rust-lang/crates.io-index)", "rand_core 0.3.0 (registry+https://github.com/rust-lang/crates.io-index)", "rdrand 0.4.0 (registry+https://github.com/rust-lang/crates.io-index)", "winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)", ] [[package]] name = "rand" </del> version = "0.6.1" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [

Related discussion:
text: I noticed this scrolling by while "Building stage0 compiler artifacts" today: Optimistically flagging E-easy
I'd like to work on this, how can I fix? make rustc use one version(maybe v0.6.1)?
You will need to look into each dependency that depends on (by searching through ), check if they have a newer version that depends on new , and finally use to upgrade those crates.
Thanks! When I checked, it seems each rand version is used.
Yeah, it's natural that they are all used, and you could try to eliminate those crates using old by upgrading or refactoring. That said, there isn't much drawback with an older , so in that case this issue can be just closed.
Oh, I'm sorry, I misunderstood. Hmmm, I think we don't have to fix this quickly and this may be a catalyst for a newbie like me to contribute, so I leave this, okay?
but one could argue that it will lower the time to compile so it's worth to fix IMHO ;)
Uh, would it be better to fix?
Disclaimer: I'm not a core member, but IMHO this is worth fixing. Also scottmcm who is a core member opened this issue, so I guess you're good to go and fix that issue :)
Okay, I want to try to fix. For instance, depends on , how can I update or refactor this?
That's one thing you can't edit, because rand is a dependency of crossbeam-channel here, so the crate crossbeam-channel needs to update its dependecy (maybe it already did and you just need to update crossbeam-channel itself)?
For future reference, running  from is an easy way to identify the source of all duplicates.
Thanks ! I got this tree(). I updated , but is latest and depends on (). What should I do?
I'm not on compiler (or core), so don't take my word on this one :slightlysmilingface: It looks like upstream rayon needs 0.5, so you could consider making a PR to upgrade it to 0.6. (Maybe .) Also, it seems that , so they'd probably appreciate a PR to upgrade it to newer upstream.
Current rayon only uses rand as a dev-dependency, since rayon-rs/rayon.
Code change:
[[package]] name = "rand" <del> version = "0.4.6" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "fuchsia-cprng 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)", "libc 0.2.54 (registry+https://github.com/rust-lang/crates.io-index)", "rand_core 0.3.0 (registry+https://github.com/rust-lang/crates.io-index)", "rdrand 0.4.0 (registry+https://github.com/rust-lang/crates.io-index)", "winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)", ] [[package]] name = "rand" </del> version = "0.6.1" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [

Related discussion:
text: That wouldn't show up in here at all, if rustc-rayon follows suit.
So the latest versions are and , but is used in this repository. They come from . Maybe those dependencies should be updated or made optional?
It looks like this was fixed in PR and merged by bors. Should this issue be closed now?
There are still 3 versions of rand in use:
will remove rand 0.5, I can get rid of 0.4 anytime but there are many PRs modifying right now.
Update: is used by , and (via ).
That's with -- only uses as a dev-dependency.
I didn't check now, but at some point was using an old version of a custom fork of .
has rebased since then, so it already reflects that dependency change.
I tried to fix a part of this in , but it didn't come out as planned. There is dependency and license whitelist that needs to be updated. I think just running leaves only one usage of via and (which can be updated). But then there is the licensing story, and it's not very clear to me which dependencies are used by the tools, and which by the compiler.
Last time I checked and were the only thing preventing of , otherwise I'd fix it already. We are working on removing it but it's blocked on releasing new version of .
I think goes away after a , so that one might be easy to fix. I don't know how dependencies are updated across the repository. Is it just that most of them are for the tools, not for and ? Does somebody run from time to time? And why does the license check fail on bors on my PR, but not on Travis or on my computer?
So released new version since. Correct, dependencies of everything that is created by are tracked by single . Dependencies are often updated separately as needed because upgrading everything at once is likely to break something and it's easier to find what is wrong when you change like 5 dependencies instead of 50. I think it should error when you run .
Also you can run the same image that found the error ( in this case) by using these steps
Code change:
return value else: return "'" + value + "'" <ins> elif isinstance(value, dict): return "{" + ", ".join(map(lambda a: "{} = {}".format(to_toml(a[0]), to_toml(a[1])), value.items())) + "}" </ins> else: raise RuntimeError('no toml')

Related discussion:
text: I tried this code: I expected to see this happen: generates a toml file with the contents Instead, this happened: HEAD is branched from . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Relevant code:
claim
Error: Parsing assign command in failed: ...' claim' ' :)'... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
I have a PR ready but I need to wait for to get merged since that PR was and creating a new branch now doesn't help
You can run (replace with the name of the rust-lang remote), then run . In the future, take the habit of always having your branch fast-forward able, it will avoid you hassles with the GitHub UI.
That worked for me, Thank you so much!
Code change:
adjusted_ty, index_ty); <del> // First, try built-in indexing. match (adjusted_ty.builtin_index(), &index_ty.sty) { (Some(ty), &ty::TyUint(ast::UintTy::Usize)) | (Some(ty), &ty::TyInfer(ty::IntVar(_))) => { debug!("try_index_step: success, using built-in indexing"); let adjustments = autoderef.adjust_steps(lvalue_pref); self.apply_adjustments(base_expr, adjustments); return Some((self.tcx.types.usize, ty)); } _ => {} } </del> for &unsize in &[false, true] { let mut self_ty = adjusted_ty; if unsize {

Related discussion:
text: Hello, today we've found some weird behaviour of array indexing. Here is the Code snippet: The question is, why is the indexing operator behaves depending on whether we evaluate in place or not.
Highly related question :
Moreover, does not compile too.
points to this being a difference in how builtin indexing works vs overloaded indexing. My cleaned up version of the transcript: Highly related to , which will cause these types of situations to occur more frequently.
As a workaround, you can write an explicit type of which will then allow builtin indexing to happen:
Code change:
adjusted_ty, index_ty); <del> // First, try built-in indexing. match (adjusted_ty.builtin_index(), &index_ty.sty) { (Some(ty), &ty::TyUint(ast::UintTy::Usize)) | (Some(ty), &ty::TyInfer(ty::IntVar(_))) => { debug!("try_index_step: success, using built-in indexing"); let adjustments = autoderef.adjust_steps(lvalue_pref); self.apply_adjustments(base_expr, adjustments); return Some((self.tcx.types.usize, ty)); } _ => {} } </del> for &unsize in &[false, true] { let mut self_ty = adjusted_ty; if unsize {

Related discussion:
text: It appears that when it's not obvious the index type is , we fall back to overloaded indexing: Fails in constant checking, : And also with the new MIR-based constant checker, :
Code change:
} fn parse_borrowed_pointee(&mut self) -> PResult<'a, TyKind> { <del> let opt_lifetime = if self.check_lifetime() { Some(self.expect_lifetime()) } else { None }; </del> <ins> let and_span = self.prev_token.span; let mut opt_lifetime = if self.check_lifetime() { Some(self.expect_lifetime()) } else { None }; </ins> let mutbl = self.parse_mutability(); <ins> if self.token.is_lifetime() && mutbl == Mutability::Mut && opt_lifetime.is_none() { // A lifetime is invalid here: it would be part of a bare trait bound, which requires // it to be followed by a plus, but we disallow plus in the pointee type. // So we can handle this case as an error here, and suggest `'a mut`. // If there *is* a plus next though, handling the error later provides better suggestions // (like adding parentheses) if !self.look_ahead(1, |t| t.is_like_plus()) { let lifetime_span = self.token.span; let span = and_span.to(lifetime_span); let mut err = self.struct_span_err(span, "lifetime must precede `mut`"); if let Ok(lifetime_src) = self.span_to_snippet(lifetime_span) { err.span_suggestion( span, "place the lifetime before `mut`", format!("&{} mut", lifetime_src), Applicability::MaybeIncorrect, ); } err.emit(); opt_lifetime = Some(self.expect_lifetime()); } } </ins> let ty = self.parse_ty_no_plus()?; Ok(TyKind::Rptr(opt_lifetime, MutTy { ty, mutbl })) }

Related discussion:
text: Expected result: a diagnostic suggests placing before Actual diagnostic output: <details</details
Output from rustc 1.43 (): The size of the output appears to be a recent regression.
: searched nightlies: from nightly-2020-03-09 to nightly-2020-06-21 regressed nightly: nightly-2020-03-12 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsLooks like ?
Further testing confirms , specifically  introduced the large number of diagnostics.
Assigning .
Code change:
<ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // #39872, #39553 #![feature(conservative_impl_trait)] fn will_ice(something: &u32) -> impl Iterator<Item = &u32> { //~^ ERROR the trait bound `(): std::iter::Iterator` is not satisfied [E0277] } fn main() {} </ins>

Related discussion:
text: I was playing around with some code which can be found and is attached below. When I click on output I get the following output: I don't have a rust installation locally right now, so I cannot create the backtrace. I'll add it later today. The code which triggers this:
Stack trace: (There is no ICE with (nothing generated either due to type error). Perhaps playpen should use instead.)
You can get backtrace on playpen here: !
Looks like this has been fixed recently
Code change:
<ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // #39872, #39553 #![feature(conservative_impl_trait)] fn will_ice(something: &u32) -> impl Iterator<Item = &u32> { //~^ ERROR the trait bound `(): std::iter::Iterator` is not satisfied [E0277] } fn main() {} </ins>

Related discussion:
text: I was in the middle of making a big changes to some code when this panic occurred. I was expecting a lot of compiler errors but got a compiler panic instead! :fearful: I ran the build with and the panic still occurred. Run to get this. Here's the full output with : Since I was in the middle of editing, there's no commit to point to, so I just attached my source code as is so you have something to debug. When you download it and run , the compiler should panic. The repo is called . I don't know how to narrow this issue down, or else I would try to find a smaller example for you. Hope this is good enough.
Some context for the change that caused this: Before this error happened, I changed the file . I split into two structs, and . I was relying on the compiler to find all the places where that change would effect things, and it seems that something went wrong in the compiler while trying to do that.
Once I fix that, everything works again. No more compiler panic. So it seems to have something to do with when I split up that struct. All the messed up pattern matches caused a panic. (Actually just fixing 2 broken pattern matches fixed the problem.)
I've just encountered this myself. I managed to reduce it down: It looks like this happens when a closure's body is a single (non-block) expression, and a tuple struct pattern is used somewhere in the expression. A simple workaround (if anyone needs one for some reason), then, is to just make the closure body a block: