jiebi/CodeConvo huggingface dataset:
Change:
// dependent alignment #[no_mangle] pub fn small_struct_alignment(x: &mut Bytes) { <del> // CHECK: [[VAR:%[0-9]+]] = load %Bytes*, %Bytes** %x </del> <ins> // CHECK: [[VAR:%[0-9]+]] = load {{(%Bytes*, )?}}%Bytes** %x </ins> // CHECK: [[VAR2:%[0-9]+]] = bitcast %Bytes* [[VAR]] to i32* // CHECK: store i32 %{{.*}}, i32* [[VAR2]], align 1 *x = Bytes {

Discussion:
Hrm, yeah, the IR format changed from 3.6 to 3.7. In this case, it's just the extra result type in the instructions. Making that optional by changing to something like should help with that. If you still have a build using LLVM 3.6 around, it'd be great if you could create a patch for this. If not, let me know and I'll create one this evening.
I will give it a try. I am not planning to switch to 3.7 right now as there is no official release yet.
This is fixed.
Change:
false } <ins> fn ast_ty_to_normalized<'tcx>(tcx: &ty::ctxt<'tcx>, id: ast::NodeId) -> Ty<'tcx> { let tty = match tcx.ast_ty_to_ty_cache.borrow().get(&id) { Some(&t) => t, None => panic!("ast_ty_to_ty_cache was incomplete after typeck!") }; infer::normalize_associated_type(tcx, &tty) } </ins> impl<'a, 'tcx> ImproperCTypesVisitor<'a, 'tcx> { /// Check if the given type is "ffi-safe" (has a stable, well-defined /// representation which can be exported to C code).

Discussion:
made the lint trigger for tuples, but as far as I understand, returning is equivalent to returning cvoid, and therefore should be allowed. Here is an example:
Yes, stupid mistake; I'll fix it. (As a workaround, you can write .)
since was merged i'm closing
Change:
} #[stable(feature = "rust1", since = "1.0.0")] <del> #[rustc_const_unstable(feature = "const_box", issue = "92521")] unsafe impl<#[may_dangle] T: ?Sized, A: Allocator> const Drop for Box<T, A> { </del> <ins> unsafe impl<#[may_dangle] T: ?Sized, A: Allocator> Drop for Box<T, A> { </ins> fn drop(&mut self) { // FIXME: Do nothing, drop is currently performed by compiler. }

Discussion:
() Note that this works even if implements in a non- way. This seems hightly problematic, especially provided we eventually want to support constructing at compile time. Relevant PR: Of course that impl claims to be unstable, but as we all know trait implementations are never unstable, unless the trait is unstable. (For ordinary traits, implementations of are thus unstable merely due to the fact that no user can use any such implementations in stable code yet.) label regression-from-stable-to-stable The fix should be straightforward: Remove the implementation (i.e. revert it to be non-), and add a test.
cc
that impl should be illegal, shouldn't it? I would expect us to need an explicit here. But also, reverting and maybe even backporting that impl for now seems like the right choice to me
Good catch! Actually calling this leads to odd behavior: It doesn't even say what went wrong. I expected an error saying a non-const function was called as part of the drop glue.
Change:
// CHECK:       call void %{{[0-9]}}({{{}*|ptr}} align 1 {{%[a-z].0|%_[0-9]}}, {{{}*|ptr|%Type3*}} align 1 {{%[a-z].0|%_[0-9]}}){{.*}}[ "kcfi"(i32 [[TYPE3:[[:print:]]+]]) ] } <ins> pub fn foo4<'a>(a: &dyn Trait4<'a, Type4, Output = &'a i32>) { let b = Type4; a.qux(&b); // CHECK-LABEL: define{{.*}}4foo4{{.*}}!{{<unknown kind #36>|kcfi_type}} !{{[0-9]+}} // CHECK:       call align 4 {{ptr|i32*}} %{{[0-9]}}({{{}*|ptr}} align 1 {{%[a-z].0|%_[0-9]}}, {{{}*|ptr|%Type4*}} align 1 {{%[a-z].0|%_[0-9]}}){{.*}}[ "kcfi"(i32 [[TYPE4:[[:print:]]+]]) ] } pub fn bar4<'a>() { let a = Type4; foo4(&a); let b = &a as &dyn Trait4<'a, Type4, Output = &'a i32>; b.qux(&a); // CHECK-LABEL: define{{.*}}4bar4{{.*}}!{{<unknown kind #36>|kcfi_type}} !{{[0-9]+}} // CHECK:       call align 4 {{ptr|i32*}} %{{[0-9]}}({{{}*|ptr}} align 1 {{%[a-z].0|%_[0-9]}}, {{{}*|ptr|%Type4*}} align 1 {{%[a-z].0|%_[0-9]}}){{.*}}[ "kcfi"(i32 [[TYPE4:[[:print:]]+]]) ] } </ins> // CHECK: !{{[0-9]+}} = !{i32 [[TYPE1]]} // CHECK: !{{[0-9]+}} = !{i32 [[TYPE2]]} // CHECK: !{{[0-9]+}} = !{i32 [[TYPE3]]} <ins> // CHECK: !{{[0-9]+}} = !{i32 [[TYPE4]]} </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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
<ins> // Copyright 2014 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. #[simd] pub struct i64x2(i64, i64); //~ ERROR: SIMD types are experimental fn main() {} </ins>  No newline at end of file

Discussion:
Our support isn't very complete at all, and details of the interface may change.
Nominating.
Accepted for P-backcompat-lang.
I'm working on this
Change:
<ins> error: cannot find attribute `empty_helper` in this scope --> $DIR/disappearing-resolution.rs:18:3 | LL | #[empty_helper] |   ^^^^^^^^^^^^ error[E0603]: derive macro `Empty` is private --> $DIR/disappearing-resolution.rs:11:8 | LL | use m::Empty; |        ^^^^^ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0603`. </ins>

Discussion:
Compiling this: Results in an ICE: Different error on nightly: Backtrace for stable:
triage: tagging as P-high for initial investigation as to severity. Doesn't seem like it warrants discussion at T-compiler meeting. Removing nomination tag.
I'll try to look at this during the weekend. This is not a regression, so the priority is probably not especially high.
Fixed in
Change:
Ok(self) } <del> fn print_type(self, ty: Ty<'tcx>) -> Result<Self::Type, Self::Error> { </del> <ins> fn print_type(mut self, ty: Ty<'tcx>) -> Result<Self::Type, Self::Error> { </ins> match ty.sty { <del> // types without identity </del> <ins> // Types without identity. </ins> | ty::Bool | ty::Char | ty::Int(_)

Discussion:
I believe this happened after
triage: P-high because it blocks presumed stabilization of (). Removing nomination tag.
you can have parameterization in scope that's not part of monomorphization (like the above). For name mangling (with the new scheme) we produce something that demangles to in that case. We could use in this case too.
I'm working on a fix that uses .
Change:
// token stream to match up with inserted parenthesis in the reparsed stream. let source_with_parens = pprust::nonterminal_to_string(nt); let filename_with_parens = FileName::macro_expansion_source_code(&source_with_parens); <ins> if GOOD_TOKEN_CACHE.with(|cache| cache.borrow().contains(&source_with_parens)) { return tokens; } </ins> let reparsed_tokens_with_parens = parse_stream_from_source_str( filename_with_parens, source_with_parens,

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. --We have a library that compiles fine on 1.47.0 but after uggrading to 1.48.0 the compilation hangs. This code-snippet above is reduced from the original code as much as I can. I'm having problems understanding exactly where the problem is coming from and any further modifications to reduce it haven't worked. It uses the "paste" crate, and I've tried a few different versions including the latest one but it doesn't make a difference . I've been building it with at 1.47.0 and 1.48.0 to reproduce the issue which I got just by running doesn't work on works on </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 --
Some quick notes as I find them: This reproduces on just a cargo check, so has nothing to do with codegen (unsurprising) Compilation time scales by a little more than 2x for each additional number (going from 0 to 20 took 11 seconds, 21 took 26, 22 took 1 min 5) Given that I don't think this is a hard hang per se, just a really really long running compilation Definitely something in macro expansion, compiling the post- code is instant Reproduces on current nightly. -Zself-profile shows all the time is spent in . Unfortunately I don't have a debug build of rustc handy, but I imagine slapping a profiler on one should make the issue fairly obvious. I'd recommend cutting the provided example down from 64 to 20 though.

searched nightlies: from nightly-2020-08-24 to nightly-2020-10-03 regressed nightly: nightly-2020-10-02 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsLooks like
If it helps, this crate was exploring some ideas related to the crate
Assigning and removing as in the prioritization working group.
This is caused by some of the extra logic I in to ensure that we don't throw out the captured unnecessarily. I'm looking into improving the performance. In the longer term, this will be solved by getting rid of the pretty-print/retokenize hack entirely.
Change:
to be resolvable dynamically; for more information visit  <https://doc.rust-lang.org/reference/items/traits.html#object-safety>", ); <ins> // Only provide the help if its a local trait, otherwise it's not actionable. </ins> if trait_span.is_some() { let mut reported_violations: Vec<_> = reported_violations.into_iter().collect(); reported_violations.sort(); <del> for violation in reported_violations { // Only provide the help if its a local trait, otherwise it's not actionable. violation.solution(&mut err); </del> <ins> let mut potential_solutions: Vec<_> = reported_violations.into_iter().map(|violation| violation.solution()).collect(); potential_solutions.sort(); // Allows us to skip suggesting that the same item should be moved to another trait multiple times. potential_solutions.dedup(); for solution in potential_solutions { solution.add_to(&mut err); </ins> } }

Discussion:
made it so that we report all object safety violations at the same time. However, it also results in a redundant note: We should not add the same note multiple times.
Can we add a debug assertion for duplicate identical help messages? (sorta like we do for "Span must not be empty and have no suggestion" or "Suggestion may not have overlapping parts" ?
I guess we could, but I think there are multiple diagnostics that currently do this, so we'll have to fix them first.
Did not find tooo much... inside :
Change:
pub st_lspare: int32_t, pub st_birthtime: time_t, pub st_birthtime_nsec: c_long, <del> pub __unused: [uint8_t; 2], </del> } #[repr(C)]

Discussion:
blksizet on 64-bit FreeBSD is 32 bits, not 64. on FreeBSD x8664 yields: yields: I tracked this down to the type definition, which is unconditionally 32-bit on FreeBSD (see , noting this line: this is unconditionally the definition of on FreeBSD - whether on 32-bit or 64-bit platform.)
Also, is a no-op (two fields of size 0) on 64-bit FreeBSD, the field can be deleted from the structure.
Change:
} #[derive(PartialEq, Eq, Clone, Copy, Debug)] <del> pub struct ExitCode(bool); </del> <ins> pub struct ExitCode(u8); </ins> impl ExitCode { <del> pub const SUCCESS: ExitCode = ExitCode(false); pub const FAILURE: ExitCode = ExitCode(true); </del> <ins> pub const SUCCESS: ExitCode = ExitCode(0); pub const FAILURE: ExitCode = ExitCode(1); </ins> pub fn as_i32(&self) -> i32 { self.0 as i32

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. --When compiled as a standard binary on the host system, the exit codes are returned as expected. When compiled with wasm32-wasip1, the use of ExitCode results in the exit code of 1, regardless of the value provided to ExitCode::from. The following are the minimal examples used while reproducing the bug: The above example produces the expected error code of 10 when compiling for the the host system and (executed with wasmtime 24.0.0). The above example produces the exit code when compiled for the host system but returns exit code 1 when compiled with (again run in wasmtime 24.0.0). Looking at the resulting WASM (decompiled to WAT) we see the main function returns a (here compiled with ): For source code of the reproducer, see: Tested against stable, beta and nightly. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
It seems that we just call ?
Minimized: claim label -O-wasi
Oh, "cool"!
that is so concise! Thanks. I’d also be very interested in getting some insight on where to look in the code base for this sort of thing.
I'm kinda just abusing my IDE (RustRover)’s Go To Declaration & Find Usages shortcuts, you may need to tell yours to use the wasm target for name resolution/code indexing instead of your OS’ default one.
I ran the tests in my reproducer repo against the latest nightly (post merge of ) and the all pass now. Thanks!
Change:
// Again, only create type information if full debuginfo is enabled let template_params: Vec<_> = if cx.sess().opts.debuginfo == FullDebugInfo { generics.types.as_slice().iter().enumerate().map(|(i, param)| { <del> let actual_type = actual_types[i]; </del> <ins> let actual_type = normalize_associated_type(cx.tcx(), &actual_types[i]); </ins> let actual_type_metadata = type_metadata(cx, actual_type, codemap::DUMMY_SP); let name = CString::new(param.name.as_str().as_bytes()).unwrap(); unsafe {

Discussion:
When trying to compile nphysics on a nightly created on or after , the compiler errors. Before this date it is fine. Example code: Presumably was that broke things, as it's a commit on that day that touches trans. On Windows 64 bit GNU this is the output:
cc
You sure it's that innocent commit and not, you know, my changes to debuginfo, for MIR? Specifically, is gone, that could cause problems.
I can't reproduce on master (just rebased one of my branches containing unrelated changes, so I had a compiler to check with). EDIT: Still no reproduction, even after .
Ok so I was misinterpreting which crate was being compiled. nphysics compiles fine, but , which uses nphysics, doesn't. I'm trying to narrow down the code now.
Here's some of the rust log that I got when compiling on debug builds:
That's not really helpful, sadly, nightly doesn't use yet, so there's no output.
This bug is not in beta, correct?
I'm afraid that I can't test that as I'm using s.
Can you check the test from instead? Particularly interested about the nightlies you had issues with.
Sure, unfortunately that test case works fine for both pre and post-.
Ah, beats me then.
I'll try and find which part of my code hits the error.
So I did some digging and I was wrong again, it turns out it is the nphysics crate. This is a minimal test case:
It depends on the crate, but it's not the crate itself, and that testcase is still large in terms of how much it needs to monomorphize.
True, sorry but I am not knowledgeable at all in rustc or nphysics, so it's the best I can do :/
triage: P-high
Still need a good regression test.
triage: P-low
I'm going to go ahead and close this. It's somewhat unlikely we'll hit this again (at least, we haven't obviously done so in the past 3ish years), and coming up with a good test case when the current case is all of nphysics is likely to be quite hard.
Change:
all supported platforms", issue = "44930")] struct VaListImpl { <del> stack: *mut (), gr_top: *mut (), vr_top: *mut (), </del> <ins> stack: *mut c_void, gr_top: *mut c_void, vr_top: *mut c_void, </ins> gr_offs: i32, vr_offs: i32, }

Discussion:
On x8664, Aarch64, and PowerPC will not pass the lint, but it should. Given the following: The compiler will yield: The implementation of for the x8664, Aarch64, and PowerPC architectures uses or as the pointer type for the pointers to the architecture specific save areas (e.g., ).
defines . Perhaps should be used instead of
It would be fine to just special-case the language item in the lint implementation.
This seems reasonable to me too. The structure should (for obvious reasons) always be FFI safe.
Change:
<ins> // edition:2018 // run-rustfix fn foo() -> Box<impl std::future::Future<Output = u32>> { let x = 0u32; Box::new(async move { x } ) //~^ ERROR E0373 } fn main() { let _foo = foo(); } </ins>

Discussion:
emits the following error The correct code needs the to be part of the block because it is a stack allocation that needs to be in the generator: Ideally, the error message would mention : thanks to for bringing this up! CC <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
We could also consider suggesting an block, similar to the hints we provide for closures.
Marking this as a focus item. assign
Change:
<ins> //@ only-windows // Reason: dos devices are a Windows thing use std::path::Path; use run_make_support::{rustc, static_lib_name}; fn main() { rustc().input(r".NUL").crate_type("staticlib").run(); rustc().input(r"?NUL").crate_type("staticlib").run(); assert!(Path::new(&static_lib_name("rust_out")).exists()); } </ins>

Discussion:
On a Windows machine, run: : Which is here: Specifically the panics. The device is pretty weird as it's a device in its own right that you can read/write to but also a kind of root directory (you can do ) and calling on should return . It doesn't quite fit with std's model of paths. <details<summary<strongBacktrace</strong</summary<p</p</details
To be clear, this is a strange thing to be doing so I wouldn't consider this a high priority or anything.
Change:
// option. This file may not be copied, modified, or distributed // except according to those terms. <ins> #[no_std]; </ins> #[allow(unused_variable)]; #[deny(dead_code)];

Discussion:
Currently if you have some dead_code and you want to preserve it, you have to annotate every function you want to preserve and all the dead code that function calls. I think we should consider annotated code to be alive, and then all the code that touches to be alive as well.
cc sounds like a cool idea to me.
By "annotate", do you mean putting an attribute above the function you want to preserve?
yes.
Change:
} } <del> #[unstable(feature = "fused", issue = "35602")] impl<B, I, St, F> FusedIterator for Scan<I, St, F> where I: FusedIterator, F: FnMut(&mut St, I::Item) -> Option<B> {} </del> /// An iterator that maps each element to an iterator, and yields the elements /// of the produced iterators. ///

Discussion:
: Since the closure to can choose to return , this implementation is overly broad. It would need to take the closure into account, which seems... not possible. Here's a reproduction showing the unexpected behavior when the closure returns : This example requires nightly for the feature to demonstrate, but the effect can be felt in stable Rust.
Change:
<ins> error[E0392]: type parameter `T` is never used --> $DIR/inline-tainted-body.rs:7:21 | LL | pub struct WeakOnce<T>(); |                     ^ unused type parameter | = help: consider removing `T`, referring to it in a field, or using a marker such as `PhantomData` = help: if you intended `T` to be a const parameter, use `const T: /* Type */` instead error: functions with the "rust-call" ABI must take a single non-self tuple argument --> $DIR/inline-tainted-body.rs:11:35 | LL |     extern "rust-call" fn try_get(&self) -> Option<Arc<T>> {} |                                   ^^^^^ error[E0308]: mismatched types --> $DIR/inline-tainted-body.rs:11:45 | LL |     extern "rust-call" fn try_get(&self) -> Option<Arc<T>> {} |                           -------           ^^^^^^^^^^^^^^ expected `Option<Arc<T>>`, found `()` |                           | |                           implicitly returns `()` as its body has no tail or `return` expression | = note:   expected enum `Option<Arc<T>>` found unit type `()` error: aborting due to 3 previous errors Some errors have detailed explanations: E0308, E0392. For more information about an error, try `rustc --explain E0308`. </ins>

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:
# Main test targets ###################################################################### <del> check: all tidy check-stage3  </del> <ins> check: all tidy check-stage2  </ins> check-full: all tidy check-stage1 check-stage2 check-stage3 

Discussion:
We're not comparing stage2 and stage3 at the moment, and the amount of bugs caught by that extra stage that wouldn't be caught in stage2 is probably very small. We could shave off some cycle time by only going to stage2, and doing a stage3 check only on checkpoints.
Fixed in .
Change:
fn check_path(&mut self, x: &'a Path, kind: PathKind) { match kind { PathKind::Trait => self.add_trait_id(&x.id), <del> PathKind::StructEnumUnion => self.add_struct_enum_union_id(&x.id), </del> <ins> PathKind::Type => self.add_type_id(&x.id), </ins> } if let Some(args) = &x.args { self.check_generic_args(&**args);

Discussion:
Produces json (abridged) which is correct, but fails for this modify labels: +A-rustdoc-json +A-testsuite +T-rustdoc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This was found while working on , as it causes jsondoclint to fail for core (in addition to it catching the linked issue)