jiebi/CodeConvo huggingface dataset:
Change:
obligation: &TraitObligation<'tcx>, candidates: &mut SelectionCandidateSet<'tcx>, ) { <del> if obligation.has_non_region_param() { </del> <ins> if obligation.predicate.has_non_region_param() { </ins> return; }

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 --
Error: Parsing assign command in failed: ...' assign' ''... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
searched toolchains nightly-2023-04-13 through nightly-2023-04-17 Regression in nightly-2023-04-15 searched toolchains through Regression in Attempting to search unrolled perf builds Found commits ["", "", "", "", "", "", "", "", ""] Regression in cc
claim
Thanks, I'll take a look at this
Change:
.map(|param| tcx.type_of(param.def_id)) // This is no generic parameter associated with the arg. This is // probably from an extra arg where one is not needed. <del> .unwrap_or(tcx.types.err) </del> <ins> .unwrap_or_else(|| { tcx.sess.delay_span_bug( DUMMY_SP, &format!( "missing generic parameter for `AnonConst`, parent {:?}", parent_node ), ); tcx.types.err }) </ins> } else { tcx.sess.delay_span_bug( DUMMY_SP,

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. --I was writing some generic code over vectors using the under-construction feature of const generics, and had a circular chain of super-traits that required me to cast the Self type to the trait as can be seen in the supertrait requirement. I believe that is causing the MIR error. I think this may be related to but it is subtly different so I'm putting the issue up regardless. <!-- 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. --: I updated my rust version on nightly right before I ran this so hopefully it is up to date: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
minimized: claim
Looks like maybe constants in trait paths don't get their type correctly? cc
Initially I thought this was about bounds but no, this also fails: ()
I believe this code is responsible: And the problem is that this doesn't handle associated types which need the same treatment:
Alternatively, instead of using to get the , maybe we could use the olution from the segment we found the const parameter in? I believe nowadays we have per-segment resolutions, which would avoid breaking GATs in the future. Actually, I expect is also broken, let's try it... Yupp: () EDIT: took a second look and that is in a , which has to be resolved by the body of , which means it's as bad as the method call form (which I just ). Maybe we should disallow passing explicit generic args to methods for now? Since I have no idea how one would figure out the expected type.
If you look at this later btw, my comment above () still isn't addressed, but I haven't made an issue yet about it.
Change:
<ins> #[prelude_import] use ::std::prelude::rust_2015::*; #[macro_use] extern crate std; // compile-flags: -Zunpretty=hir // check-fail // In #100948 this caused an ICE with -Zunpretty=hir. fn main() { <bad-literal>; } </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
Reduced: `
Regression in
The assert was in I MENT (sorry, I should no do this on the phone... :roll_eyes: ) cc
Change:
] [[package]] <ins> name = "cargo_metadata" version = "0.9.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "8d2d1617e838936c0d2323a65cc151e03ae19a7678dd24f72bccf27119b90a5d" dependencies = [ "semver", "serde", "serde_derive", "serde_json", ] [[package]] </ins> name = "cargotest2" version = "0.1.0"

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.
triage: P-medium. Removing I-nominated.
There is opening PR to fix this:
Change:
crate::io::set_output_capture(output_capture); <ins> // SAFETY: we constructed `f` initialized. let f = f.into_inner(); </ins> // SAFETY: the stack guard passed is the one for the current thread. // This means the current thread's stack and the new thread's stack // are properly set and protected from each other.

Discussion:
Scopes threads as currently implemented are potentially unsound due to passing a reference to a function where the memory the reference points to is potentially deallocated while the function still runs. Specifically, takes as implicit argument its closure environment, which contains . That environment might just be a reference to some memory that is allocated in the caller stack frame. However the function can keep running after got dropped (implicitly at the end of ). Then the scope might end and the memory might be deallocated all while is still running. If the environment is just a reference, it ends up being a newtype and we will (AFAIK) add the attribute, meaning deallocation while the function runs is actually LLVM UB. Miri found the error in , where the invalidates the reference that was passed to the forked-off threads. ( doesn't actually get deallocated, it just has a unique reference created to it, but deallocation is also a possibility). To fix this properly, I think we need a language extension: we want a way to store references in a type without having alias guarantees for that reference. In terms of Stacked Borrows this means Stacked Borrows will stop recursing at that type during retags. In terms of the LLVM IR we generate it means we must not add or attributes for references inside that type. We don't have such a type currently but I think it makes sense to make that type (or even if we add a new type for this, should use it). Also see .
I believe included a fix for this.
Doesn't look like it -- the user-provided closure seems to be handled exactly the same as currently?
Ah, I read too quickly and misunderstood, apologies. It solves a different potential unsoundness (one more similar to the Arc drop issue).
Yeah, it looks like an alternative fix for the part of
While the , I am proposing a preliminary fix in
Change:
#[inline] unsafe fn into_ascii_nocheck(self) -> Vec<Ascii> { <del> let v: Vec<u8> = mem::transmute(self); v.into_ascii_nocheck() </del> <ins> self.into_bytes().into_ascii_nocheck() </ins> } }

Discussion:
There are 3 cases of this undefined behaviour in : There is no guarantee that and have the same layout under the new rules. This needs to manually copy over the fields one by one which would compile to the same code as long as a feature like struct randomization wasn't enabled. Since vectors expose , it could be switched to make use of that. However, this is a pervasive issue with in the standard libraries.
I would like to fix this one. However, I don't understand why you would need to use . If we need to copy everything, why don't we do it directly to a ?
the fields of Vec are private, so you can't just use
Change:
Consistent, &fields[..], |s, field| { <ins> s.print_outer_attributes(&field.attrs); </ins> s.ibox(INDENT_UNIT); if !field.is_shorthand { s.print_ident(field.ident);

Discussion:
If we have an attribute macro whose input contains attributes on fields of a struct-expression, those attributes all seem to disappear before the macro is invoked. The following repro compiles successfully if #[repro::repro] is removed, but fails with "error[E0062]: field  specified more than once" if the macro is present even though it does nothing. <details<summaryHere is a script that reproduces the behavior as of rustc 1.42.0-nightly ( 2020-01-30)</summary</details<details<summaryHere is the input token stream as received by the proc macro</summary</detailscc
I have a fix in The bug was in pretty printing (usually the case in these types of bugs).
Change:
<del> Subproject commit aaa16a5f4b8caabf8e044e6dd1c48330dfb7900d </del> <ins> Subproject commit 0d0a457c8b1750e82f19527b18b313f3514633f0 </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! And nominating for compiler team prioritization.
Removing nomination, as part of pre-triage we are looking anyways into tool breakage.
Change:
.entry(LinkerFlavor::Lld(LldFlavor::Link)) .or_default() .extend(pre_link_args_msvc); <ins> // Workaround for #95429 base.has_thread_local = false; </ins> Target { llvm_target: "i686-pc-windows-msvc".to_string(),

Discussion:
As the title says, the crash disappeared once we set the on i686-pc-windows-msvc target spec. Could we disable it? cc (the codebase is really huge, cannot generate a small test case) was enabled in
cc
Disabling it for i686 sounds reasonable if it's still causing issues. It is unfortunate we don't have a test case though. I'll make a quick PR.
It would still be great if we could have a regression test case to put into our test suite, otherwise some time down the line somebody might end up re-enabling TLS on the affected platform again.
I wonder if the crash here is an example of the issue works around (or hopes to, anyway).
Would you be able to reproduce this bug?
Change:
= help: consider adding a `#[repr(C)]` or `#[repr(transparent)]` attribute to this struct = note: this struct has unspecified layout note: the type is defined here <del> --> $DIR/lint-ctypes-94223.rs:27:1 </del> <ins> --> $DIR/lint-ctypes-94223.rs:34:1 </ins> | LL | pub struct FfiUnsafe; | ^^^^^^^^^^^^^^^^^^^^ error: `extern` fn uses type `FfiUnsafe`, which is not FFI-safe <del> --> $DIR/lint-ctypes-94223.rs:37:56 </del> <ins> --> $DIR/lint-ctypes-94223.rs:44:56 </ins> | LL | pub static BAD_TWICE: Result<extern "C" fn(FfiUnsafe), extern "C" fn(FfiUnsafe)> = Ok(f); |                                                        ^^^^^^^^^^^^^^^^^^^^^^^^ not FFI-safe

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. -- at <details<summary<strongBacktrace</strong</summary<p</p</detailssearched nightlies: from nightly-2023-01-01 to nightly-2023-08-14 regressed nightly: nightly-2023-07-04 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
As referenced in the other issue this now also happens on stable since = 1.70. The culprint seems to be this type alias: Removing the reference in the Option works around this panic.
Here's a minimal example that reproduces the issue: Interestingly, this only happens while the function is extern "C".
WG-prioritization assigning priority (). cc: for the bisection pointing to label -I-prioritize +P-high
claim
The panic originates in the on this line: It happens because returns which it does because normalization of fails. The reason the normalization fails is because trait resolution fails for the projection due to not being sufficiently bound. If, for example, I change in 's example above to by adding a bound, the panic goes away as trait resolution succeeds now. Since the normalization failure can be legitimate as in this case, I feel this unwrap: should be removed to fix the issue. However, I'm not sure what the enclosing method should do upon receiving a from . I'd presume it should return . Please review and let me know if this analysis makes sense. cc:
Closely related PR: . It fixes an ICE due to similar causes but on a different line. In fact the very next line.
Yeah, I think making not and just bubble up the is the right behavior here.
Change:
<ins> error: constant evaluation is taking a long time --> $DIR/no-ice-on-inference-failure.rs:5:9 | LL | /         while n < 5 { LL | | LL | |             x = &0; LL | |         } | |_________^ | = note: this lint makes sure the compiler doesn't get stuck due to infinite loops in const eval. If your compilation actually takes a long time, you can safely allow the lint. help: the constant being evaluated --> $DIR/no-ice-on-inference-failure.rs:2:22 | LL |       let array = [(); { |  ______________________^ LL | |         let mut x = &0; LL | |         let mut n = 0; LL | |         while n < 5 { ...  | LL | |         0 LL | |     }]; | |_____^ = note: `#[deny(long_running_const_eval)]` on by default error: aborting due to 1 previous error </ins>

Discussion:
<!-- [31mICE[0m: Rustc '-Zincremental-verify-ich=yes -Cincremental=<dir-Cdebuginfo=2' 'thread 'rustc' panicked at 'called on a value'', 'thread 'rustc' panicked at 'called on a value'' 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: note: compiler flags: -Z incremental-verify-ich=yes -C incremental=[REDACTED] -C debuginfo=2 [checkmodprivacy] checking privacy in top-level module [analysis] running analysis passes on this crate --
this bisects to
Change:
<ins> use crate::base::allocator_kind_for_codegen; </ins> use std::collections::hash_map::Entry::*; use rustc_ast::expand::allocator::ALLOCATOR_METHODS;

Discussion:
Building Rust toolchain using latest leads to an error when compiling libtest at stage0: Error is coming from (Enable --no-undefined-version by default.), with the description indicating that our version scripts were not correct. Local workaround is to pass in Rustflags. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I ran into this too. I wonder why rustc is attempting to export those symbols from , but not ? I'm seeing that e.g. works but does not. I can't determine what's different between and that would cause only the latter to output an invalid version script.
This actually repros outside of . If you attempt to compile any crate as a dylib, and is available as a dylib and linked as such (e.g. with the ) flag, you can reproduce the error by simply passing . This was with stable rustc and my system . Hopefully reproducing it outside of Rust's bootstrap will make it easier to debug.
related discussion: https://rust-
I suspect I found the issue: First, early in compilation rustc determines if a crate needs an allocator (whether or not it comes from the crate itself, or a dep). This is filled in a crate metadata struct field: If , the field says whether the crate graph contains a or not, but that's not directly relevant to the bug. This field will usually be ; it's if and are not used. Later, rustc checks whether to codegen the et al functions: Notably, if any dependency is linked as a , it will not generate them and instead link to the implementations exported from another . Independently, rustc determines which symbols to export when generating a and provides this list to the linker. Part of this is deciding whether to export the allocator symbols: Notably it does not perform the check from the last step. Even if a dependency is linked whose allocator symbols this crate should use, the export list still contains these symbol names. So when building a that links another , rustc tells the linker to export symbols that weren't actually defined. The build failure is just one instance of this bug. who helped in the Zulip discussion. Can you confirm this explanation makes sense?
Most of it.

There is a further complication that you can specify multiple crate types for a single compilation. It is then possible for some crate types to generate the allocator shim while others don't generate it. The list of exported symbols however is for all crate types at the same time. One way to fix this would be to have a separate list of exported symbols for each crate type. Another option would be to move the addition of the symbols to the actual code that invokes the linker.
Listing exported symbols per crate type seems like the most correct fix in principle, but the lists will be almost the same except for the allocator symbols. I'll try to find a clean way to do the latter.
claim
Change:
<ins> enum Bug<S> { Var = { let x: S = 0; //~ ERROR: mismatched types 0 }, } fn main() {} </ins>

Discussion:
Given this Rust code: A call to generates IR like this on x86_64 Linux: So we have a 12 byte alloca from which we then read 16 bytes.
Isn't this subject to alignment by LLVM?
what do you mean? The alloca is only 12 bytes large. That's also the amount of bytes we write in the , but then we ask to read data for a type that is 16 bytes large. I don't see how alignment is relevant here.
here's a demo: Build without optimizations on x86_64 Linux, and you should be able to observe in the C code, although it hasn't been passed as an argument. The mismatch in the struct type definitions is deliberate to show the problem.
Reading past the end of an alloca has well-defined behavior in LLVM IR. I guess we might end up with false positives if we ever support msan.
are you implying that the generated IR is fine? If so, what is the defined behaviour / where can I read up on that? reads as if it is undefined. Without optimizations, this gives random output: With optimizations, SROA ignores the out-of-bounds read and emits a warning in debug mode, which doesn't seem like it is well-defined behaviour to me either.
Basically, if a pointer points to valid memory, and is sufficiently aligned, you can load bytes up to the alignment... LLVM itself does this at etc. That said, looking a bit more closely, the given testcase performs an "align 8" load from an "align 4" pointer, which is more problematic.
Thanks! That looks like it just assumes that the load won't trap. Part of my concern here is that we might expose additional data this way, like observing in that C code example. Though I guess optimizations might eventually leave the upper 32bits undefined and expose data anyway, so this might be moot. The alignment problem is probably due to bad usage of . Ultimately, we should load and pass the struct elements individually anyway.
This has been fixed, we now only load 12 bytes: instead of . Marking as E-needstest.
Change:
<ins> // check-pass #![feature(inline_const)] #![allow(incomplete_features)] #![deny(dead_code)] const fn one() -> i32 { 1 } const fn two() -> i32 { 2 } const fn three() -> i32 { 3 } fn inline_const() { // rust-lang/rust#78171: dead_code lint triggers even though function is used in const pattern match 1 { const { one() } => {} _ => {} } } fn inline_const_range() { match 1 { 1 ..= const { two() } => {} _ => {} } } struct S<const C: i32>; fn const_generic_arg() { match S::<3> { S::<{three()}> => {} } } fn main() { inline_const(); inline_const_range(); const_generic_arg(); } </ins>

Discussion:
This should compile without warnings (): Yet it warns: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Note that this only occurs in const patterns. This produces no warnings (): Output:
Cc – this only occurs with inline const expressions; no warning is triggered with const items.
claim
Change:
</span>", item_type = ItemType::StructField, id = id, <del> name = field.name.as_ref().unwrap(), </del> <ins> name = field_name, </ins> ty = ty.print(cx) ); document(w, cx, field, Some(it));

Discussion:
Rustdoc should expose doc comments written on tuple fields: Tagging based on conversation on IRC.
This issue also applies to tuple variant fields:
It promises to be very interesting from a design point of view. We'll to think about how to render this nicely.
Change:
<ins> // check-pass pub trait Trait<'a, 'b> { fn method(self, _: &'static &'static ()) where 'a: 'b; } impl<'a> Trait<'a, 'static> for () { // On first glance, this seems like we have the extra implied bound that // `'a: 'static`, but we know this from the trait method where clause. fn method(self, _: &'static &'a ()) {} } fn main() {} </ins>

Discussion:
The lint is triggered by the following code (from , cc : In the environment , the type surprisingly requires for well-formedness (see ), but this constraint is not used in implied bounds, so I believe it can't be exploited for unsoundness. The lint was upgraded to deny-by-default in the current beta (1.68.0-beta.5 2023-02-15 ). So this counts as regression? cc label C-bug T-types T-compiler regression-from-stable-to-beta
:facepalm: I think this is due to us preferring param-env candidates for .
So the issue here is that requires . We try to prove that in the hybrid param-env of the impl's WC + trait method's WC, being after substituting . Due to some frustrating precedence rules around candidate assembly in the trait solver, we try to match against the param-env candidate and get . We also assemble a built-in sized bound, but always prefer the param-env candidate over that. That requires us to prove , which is not known to be true in the hybrid param-env, triggering the lint.
I wonder if we could get away with not checking , but just the implied lifetime bounds or something :thinking:
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Been thinking about this a little bit. One thought I had was to check that the impl method is WF given only the trait method, but I think that would break this example: I wonder if we could get away with not checking WF(return-type), but just the implied lifetime bounds or something This is annoying difficult, because it's not straightforward to get "just the implied lifetime bounds" of a type. I'm playing around with using and filtering outlives bounds, but that can generate more predicates (which, I thought we had somewhere a function that recurses though those). We'll see if this works...