jiebi/CodeConvo huggingface dataset:
Change:
op(cmt.clone(), pat); <del> // Note: This goes up here (rather than within the PatKind::TupleStruct arm // alone) because PatKind::Struct can also refer to variants. let cmt = match pat.node { PatKind::Path(hir::QPath::Resolved(_, ref path)) | PatKind::TupleStruct(hir::QPath::Resolved(_, ref path), ..) | PatKind::Struct(hir::QPath::Resolved(_, ref path), ..) => { match path.def { Def::Err => { debug!("access to unresolvable pattern {:?}", pat); return Err(()) } Def::Variant(variant_did) | Def::VariantCtor(variant_did, ..) => { // univariant enums do not need downcasts let enum_did = self.tcx.parent_def_id(variant_did).unwrap(); if !self.tcx.adt_def(enum_did).is_univariant() { self.cat_downcast(pat, cmt.clone(), cmt.ty, variant_did) } else { cmt } } _ => cmt } } _ => cmt }; </del> match pat.node { PatKind::TupleStruct(ref qpath, ref subpats, ddpos) => { let def = self.tables.qpath_def(qpath, pat.id); <del> let expected_len = match def { </del> <ins> let (cmt, expected_len) = match def { Def::Err => { debug!("access to unresolvable pattern {:?}", pat); return Err(()) } </ins> Def::VariantCtor(def_id, CtorKind::Fn) => { let enum_def = self.tcx.parent_def_id(def_id).unwrap(); <del> self.tcx.adt_def(enum_def).variant_with_id(def_id).fields.len() </del> <ins> (self.cat_downcast_if_needed(pat, cmt, def_id), self.tcx.adt_def(enum_def).variant_with_id(def_id).fields.len()) </ins> } Def::StructCtor(_, CtorKind::Fn) => { match self.pat_ty(&pat)?.sty { ty::TyAdt(adt_def, _) => { <del> adt_def.struct_variant().fields.len() </del> <ins> (cmt, adt_def.struct_variant().fields.len()) </ins> } ref ty => { span_bug!(pat.span, "tuple struct pattern unexpected type {:?}", ty);

Discussion:
I got panic with this code (): Backtrace: My rust version:
This code seems to be minimal example type Value = String; fn main() { let f = ""; Some("".into()).map(f); }
Change:
<del> // check-pass #![feature(allocator_api)] fn main() { Box::new_in((), &std::alloc::Global); } </del>

Discussion:
Hello, I've tested the feature and encountered an ICE: If tried this code (): I've used the "current" playground nighty compiler, but I can reproduce locally. : and also on <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
label: +requires-nightly +A-allocators
Slightly minimized: Doesn't ICE anymore if you either remove the field or if it is not an array.
Duplicate of ?
No, not really a duplicate (but possibly related). This issue and the linked one have completely different backtraces.
Just by the way, using inline storage in an allocator is actually unsafe unless the impl of the trait is using a reference. See the Allocator safety notes: (Emphasis mine) ()
FWIW this is also triggered with uninhabited types. Though looks like only when drop glue is involved. Eg works but doesn't.
Another MCVE that leads to this ICE: found in
claim
Change:
<ins> // run-rustfix fn main() { let x == 2; //~ ERROR unexpected `==` println!("x: {}", x) } </ins>

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should suggest replacing the with where appropriate as the suggestion for incorrect usage of in place of already exist. <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
attributes found"); } <ins> if self.is_test_crate { self.handler.span_err(attr.span(), "`--test` cannot be used with proc-macro crates"); return; } </ins> if !self.is_proc_macro_crate { self.handler.span_err(attr.span(), "the `#[proc_macro_derive]` attribute is 

Discussion:
I setup a crate using the example from There are no tests setup: no tests folder, no #[test] attributes. succeeds fails with: #[procmacroderive]proc-macro Naturally I expected this error not to occur. Run on the latest nightly via rustup: rustc 1.14.0-nightly ( 2016-10-27) binary: rustc commit-hash: commit-date: 2016-10-27 host: x86_64-unknown-linux-gnu release: 1.14.0-nightly LLVM version: 3.9
You can probably work around this by using (although I haven't tested that).
Thanks for the report! I'm not sure what the best way to solve this would be. We could either tell the compiler that doesn't work for these crate types, or we could tell Cargo to not test proc-macro libraries. Both should have the end goal though of having work by default.
Would a simple fix for this be to add to ? Or should - where it currently panics - quietly bail out if this is a test crate?
I'd personally prefer for to keep doing the same feature gating it's doing today, so in that sense I don't think it should take the same bail-out route that rustdoc takes. Adding some logic to though sounds good to me.
I think it was wrong that this ticket was closed with since it states
Actually fixing this appears simpler than I expected. I'm guessing a should be enough. This will ensure all the feature gating is still done, but no expansion is performed. Did you have any further thoughts?
of it works it works for me!
this is failing again. It works correctly on nightly-2017-01-17 rustc 1.16.0-nightly ( 2017-01-17) but fails on nightly-2017-01-18 rustc 1.16.0-nightly ( 2017-01-17).
This could be related to recently enabling doc-testing of proc-macro crates in cargo This rustc change should fix that If you look at the cargo output, does the error happen when running the normal tests, or after trying to run doc-tests? Edit: I've tested this in the latest nightly from rustup, and this is definitely what is happening. Hopefully it will be fixed soon.

thanks for staying on top of this! I've approved and p=1'd it to hopefully get it in soon. sorry for the breakage!
Change:
println!("normalized {}:n{}n", kind, actual); } else { println!("diff of {}:n", kind); <del> print_diff(expected, actual, 3); </del> <ins> print!("{}", write_diff(expected, actual, 3)); </ins> } }

Discussion:
Note: missing newline after is essential. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I've not been able to reproduce this on the latest nightly, I've bisected it to have been fixed in 2020-07-15 (report used 2020-07-11), probably by ; I've filed with a regression test.
Me neither.
Change:
<ins> // compile-flags: -O // build-pass #![feature(allocator_api, bench_black_box)] #[inline(never)] pub fn by_ref(node: &mut Box<[u8; 1], &std::alloc::Global>) { node[0] = 9u8; } pub fn main() { let mut node = Box::new_in([5u8], &std::alloc::Global); node[0] = 7u8; std::hint::black_box(node); let mut node = Box::new_in([5u8], &std::alloc::Global); by_ref(&mut node); std::hint::black_box(node); } </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. --Only when building with or do I trigger this issue. Found while working on . Compile test that triggers the issue: <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
modify labels: +A-allocators +A-lto
claim
claim
Hey thanks for looking into this bug (and for fixing my last reports as well :)). I've figured out some more information since first posting this. I'm able to reproduce the bug in a single crate when compiling with 1 and further minimized the triggering code: The bug seems to be specifically triggered when the allocator is non zero-sized, it doesn't matter whether it's a reference or not. Additionally if the boxed type is a struct or tuple, only accessing past the first non-zero field triggers the bug. Attempting to disassemble the bitcode dumped with with gives the same error, unless I pass the flag which causes the disassembly to succeed. The offending store instruction is encoded as follows: Unfortunately the flag strips all pointer types from the input, turning them to in the output, so I do not know what the original type was that is causing the issue. Using the following which doesn't trigger the issue: without gives:
Thanks for the info and minimized code! That's gonna make this easier.
I still don't know how this actually happens, I just know that the change in fixes it. I suspect it's some code assuming that a wide box is always a wide pointer, but I don't know where...
I think you're right about that assumption, using a wide pointer in the box has no issues:
Change:
) -> Result<(), &'static str> { let tcx = self.tcx; <ins> if let Some(_) = callee_body.tainted_by_errors { return Err("Body is tainted"); } </ins> let mut threshold = if self.caller_is_inline_forwarder { self.tcx.sess.opts.unstable_opts.inline_mir_forwarder_threshold.unwrap_or(30) } else if cross_crate_inlinable {

Discussion:
<!-- [31mICE[0m: Rustc '-Zpolymorphize=on -Zinline-mir=yes -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'mentioneditems for DefId(0:15 ~ a[1172]::unsound) have not yet been set'', 'thread 'rustc' panicked at 'mentioneditems for DefId(0:15 ~ a[1172]::unsound) have not yet been set'' 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: [optimizedmir] optimizing MIR for [unusedgenericparams] determining which generic parameters are unused by -- label +F-traitupcasting
Regression in nightly-2024-08-03 Regression in cc
Looks like another tainting issue to me -- we shouldn't be inlining MIR bodies that don't even pass type-checking... Cc

<!-- [31mICE[0m: Rustc '-Zpolymorphize=on -Zinline-mir=yes -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: Closure arguments are not passed as a tuple', 'error: internal compiler error: Closure arguments are not passed as a tuple' 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: [optimizedmir] optimizing MIR for [unusedgenericparams] determining which generic parameters are unused by [analysis] running analysis passes on this crate --
This one also seems to be cc
Change:
fail!("{}", "explicit failure") ); ($msg:expr) => ({ <del> static _FILE_LINE: (&'static str, uint) = (file!(), line!()); ::core::failure::fail_str($msg, &_FILE_LINE) </del> <ins> static _MSG_FILE_LINE: (&'static str, &'static str, uint) = ($msg, file!(), line!()); ::core::failure::fail(&_MSG_FILE_LINE) </ins> }); ($fmt:expr, $($arg:tt)*) => ({ // a closure can't have return type !, so we need a full

Discussion:
These appear all the time and result in large code bloat. At least the file and line should be combined into a static.
Also, and result in inefficient codegen and code bloat because they call into the string formatter when they don't need to.
This seems to be done for . The macro in still uses the string formatter for all invocations, but I don't even know how to use those.
Change:
self.is_keyword_ahead(1, &[ kw::Impl, kw::Const, <ins> kw::Async, </ins> kw::Fn, kw::Unsafe, kw::Extern,

Discussion:
The keyword doesn't seem to currently work with specialization (namely ). The order of keywords does not matter — I'm not sure which it's supposed to be. Minimal example from in dtolnay/async-trait: which gives the following error
Note that in traits is not yet allowed, so this would be meaningless even if it parsed.
[async_trait] can handle this if rustc will parse it.
Where this came up is when attempting to use the crate, which uses a proc macro to transform async traits to current syntax. I was attempting to use it in Rocket when I ran into this.
Change:
<ins> error[E0308]: try expression alternatives have incompatible types --> $DIR/issue-51632-try-desugar-incompatible-types.rs:20:5 | LL |     missing_discourses()? |     ^^^^^^^^^^^^^^^^^^^^^ |     | |     expected enum `std::result::Result`, found isize |     help: try wrapping with a success variant: `Ok(missing_discourses()?)` | = note: expected type `std::result::Result<isize, ()>` found type `isize` error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>

Discussion:
Given this example: I get this error (): It seems like it should not be talking about =)
Ideally, I would think it should say something like "missing ", but that may be a separate bug -- i.e., maybe we should strive to just produce the same error you would get if you did
Change:
struct MakeByMoveBody<'tcx> { tcx: TyCtxt<'tcx>, <del> field_remapping: UnordMap<FieldIdx, (FieldIdx, Ty<'tcx>, bool, &'tcx [Projection<'tcx>])>, </del> <ins> field_remapping: UnordMap<FieldIdx, (FieldIdx, Ty<'tcx>, bool, Vec<Projection<'tcx>>)>, </ins> by_move_coroutine_ty: Ty<'tcx>, }

Discussion:
<!-- [31mICE[0m: Rustc '-Zvalidate-mir --edition=2018 -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'broken MIR in CoroutineKindShim { coroutinedefid: DefId(0:8 ~ a[8079]::hello::{closure}::{closure}) } (after pass CheckPackedRef) at bb0[2]:'', 'thread 'rustc' panicked at 'broken MIR in CoroutineKindShim { coroutinedefid: DefId(0:8 ~ a[8079]::hello::{closure}::{closure}) } (after pass CheckPackedRef) at bb0[2]:'' 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: [mirbuilt] building MIR for [checkunsafety] unsafety-checking -- label +F-async_closure
nightly-2024-05-23 =
With this full minimization: The real blame commit is:
Change:
/// When `is_collectin_in_band_lifetimes` is true, each lifetime is checked /// against this list to see if it is already in-scope, or if a definition /// needs to be created for it. <del> in_scope_lifetimes: Vec<Ident>, </del> <ins> /// /// We always store a `modern()` version of the param-name in this /// vector. in_scope_lifetimes: Vec<ParamName>, </ins> current_module: NodeId,

Discussion:
The following breaks on nightly (see ) With: CC: dtolnay/async-trait
Reduced:
Forgot to mention in case this helps, giving the inner fn a matching lifetime avoids this issue for some reason:
The reason this is happening is that the desugared version of applies all in-scope lifetimes to the returned existential type, which in this case is creating , which is invalid. I'm not sure exactly what the best fix is for this, though, since elided lifetimes in the impl signature are intentionally unnameable. The closest idea I have would be to create some special new lifetime that is but can refer to lifetimes originating from the impl header. cc who may have opinions.
Hmm wouldn't you expect the nested to not inherit anything from its enclosing scopes? Seems like a bug to me that it does? Am I confused about something?
The function in the middle is actually a bit of a source of confusion here, although it does indicate that there's a second bug since we shouldn't be inheriting generics since the nested isn't part of the . The bug I was focusing on is better illustrated by this example: which produces this error: This is because the code is transformed into and in that case does not refer back to the usage from the header.
I see. Indeed, I would expect that, internally, we'd have some way to refer back to the from the impl header. I believe this should be possible, no? In particular, the in impls expands (internally) to for some integer N, which I believe is basically treated like any other named lifetime.
Yep, I would've expected so as well-- I'm not sure why that isn't working, I'd have to take a look.
I was looking and I think the bug lies here: Probably needs to be a instead, or we need to use something else for this purpose.
A closer reading suggests I was mistaken. The lifetimes from the impl should show up in -- includes only the explicitly declared lifetimes written by the user on the impl. I'm not quite sure what the problem is yet.
OK, no, I was correct. When processing impl items, we convert the lifetimes into entries. EDIT: Er, I'm still not entirely sure. Reading more. =)
OK, I have a fix for the method issue, but not the nested async fn item issue.

I forked off for the method issue
I didn't prep a fix for this one yet. It seems obvious that some internal state is not being reset when we enter a new item.
but if you have a chance to investigate, would be appreciated
Presumably the problem is that doesn't "reset" the vector -- it only seems to extend it...
Indeed, in-band lifetimes are broken in the same way. This fails to compile ():
Working on a possible fix
Yep, have a fix.
Inband lifetimes looks similar to fwiw
thanks
Change:
// // Library features (core): // tidy-alphabetical-start <ins> #![cfg_attr(bootstrap, feature(c_str_literals))] </ins> #![feature(char_internals)] #![feature(core_intrinsics)] #![feature(core_io_borrowed_buf)]

Discussion:
hello everyone, I got this error when I bootstrap the current rust-beta branch: There was a lot of pushing and reverting changesets relevant to the c literals stabilization, I tried to get an overview of what backport might be missing here, but I failed and am at a loss. I am on linux x86_64, with musl as my libc, I doubt the later is causing the issues.
What are you using as your bootstrap compiler? We only support using the previous release.
I think I understand what is going on. If you try to bootstrap 1.77 from 1.76, it will fail. We were intending to have c-string literals stabilized in 1.76, but that got reverted. However, the revert did not include the appropriate parts of I can probably put something together to fix it.
Posted with a fix.
Change:
// This offset and the ones below need to be signed to account for replacement code // that is shorter than the original code. <del> let mut offset: isize = 0; </del> <ins> let mut offsets: Vec<(usize, isize)> = Vec::new(); </ins> // Only show an underline in the suggestions if the suggestion is not the // entirety of the code being shown and the displayed code is not multiline. if show_underline {

Discussion:
Hi, i have made some changes for a crate to support a generic type that implements from , but suddenly the code can't compile because it runs out of memory with 6, 8, 10 GB. This is the code i'm trying to compile: if changed the type for or it then compiles and runs fine. Source: It fails to compile on x86_64-unknown-linux-gnu with , . I'm attaching the Heaptrack files for further analysis.
It seems a problem with utilized in the , unfortunately memory report is strange, the execution time tracked is wrong besides the graph shows up the memory grow. I'm thinking ways to better troubleshoot, but the side effects of the issue is hard.
It'd be helpful to try and simplify the code, ideally to something that doesn't have dependencies (beyond std or so), or at least as few dependencies as possible. As a start putting up a github repository with a and as simple a crate as possible would be helpful for reproducing on our side (i.e., extracting the file you've linked from that crate -- or, if the crate is really necessary, then indicating as such). The heaptrack profile looks pretty useless unfortunately -- rustc on linux is shipped with jemalloc as the allocator which likely makes heaptrack tracking not really work too well.
Thank you, sorry for the late response (working) but i get it working on playground. I'm now trying to minimize them to focus on the issue.
Got it down to 18 lines. Still produces the same error. I have not tested if this goes out-of-memory. But receiving a would signal that. EDIT: After taking some more time, I got rid of Tokio and reduced it to 6 lines: Additionally, I advise to rename this issue to something like to make it very clear and concise.
One liner: . Strangely, this no longer crashes if you remove any of , , , or .

There's nothing special about Send or Sync, this also crashes: Even weirder, this does not crash: (I didn't come up with the one-liner, that was
I stopped rustc (SIGSTOP) and got a backtrace with gdb, it looks like it's trying to generate infinite errors: <details<summarybacktrace</summary</details
It looks like this is a problem with the error reporter itself: it's affected by the length of the name (!!) OOM: No OOM:
I figured out the issue has to do with how the error printer places the annotations, adding a newline after the trait names and before the plus solves the issue.
Probably caused by some code in here:
Change:
<ins> // Regression test for issue #101980. // Ensure that we don't suggest impl'ing `Copy` for a type if it already impl's `!Copy`. // check-pass #![feature(negative_impls)] #![deny(missing_copy_implementations)] pub struct Struct { pub field: i32, } impl !Copy for Struct {} fn main() {} </ins>

Discussion:
I would expect the following code to compile successfully since we explicitly opt out of implementing : However, the code fails to compile with the following error message: label C-bug A-lint F-negativeimpls <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
The compiler only checks if the type implements already to return early and not emit the lint diagnostic but it doesn't check if the type implements :
I think this makes the trick, you are right! the last think is to explore what is the code of the method The code of the method looks not so trivial :) If you did not find already I can play with your on it by mentoring you, I had some experience in "git archeology" :) label +E-mentor
claim