jiebi/CodeConvo huggingface dataset:
Change:
LexicalScopeBinding::Res(res) => (res, None), }; <del> // An immutable (no `mut`) by-value (no `ref`) binding pattern without // a sub pattern (no `@ $pat`) is syntactically ambiguous as it could // also be interpreted as a path to e.g. a constant, variant, etc. let is_syntactic_ambiguity = !has_sub && bm == BindingMode::ByValue(Mutability::Not); </del> match res { Res::SelfCtor(_) // See #70549. | Res::Def(

Discussion:
For example: https://crater- https://crater- cc
This is a regression from produced an ambiguity error even if the binding is syntactically unambiguous (e.g. like in the example above) for some future-compatibility reasons (), but it can be easily tweaked to not produce it because backward-compatibility is more important.
Fixed in
Change:
// except according to those terms. #![forbid(deprecated)] <del> //~^ NOTE `forbid` lint level set here </del> <ins> //~^ NOTE `forbid` level set here </ins> <del> #[allow(deprecated)] //~ ERROR allow(deprecated) overruled by outer forbid(deprecated) </del> <ins> #[allow(deprecated)] //~^ ERROR allow(deprecated) overruled by outer forbid(deprecated) //~| NOTE overruled by previous forbid </ins> fn main() { }

Discussion:
From: src/test/compile- E0453 needs a spanlabel and a spannote changed to a span_label, updating it from: To:
Change:
<ins> error: expected identifier, found reserved identifier `_` --> $DIR/issue-62895.rs:4:5 | LL | mod _ { |     ^ expected identifier, found reserved identifier error: expected identifier, found reserved identifier `_` --> $DIR/issue-62895.rs:6:5 | LL | mod _ { |     ^ expected identifier, found reserved identifier error: missing `fn` for function definition --> $DIR/issue-62895.rs:7:4 | LL | pub    g() -> is |    ^^^^ help: add `fn` here to parse `g` as a public function | LL | pub fn g() -> is |     ^^ error: expected item, found `;` --> $DIR/issue-62895.rs:10:9 | LL | (), w20); |         ^ help: remove this semicolon error[E0412]: cannot find type `isizee` in this scope --> $DIR/issue-62895.rs:5:15 | LL | pub fn g() -> isizee { |               ^^^^^^ help: a builtin type with a similar name exists: `isize` error[E0308]: mismatched types --> $DIR/issue-62895.rs:3:11 | LL | fn v() -> isize { |    -      ^^^^^ expected isize, found () |    | |    this function's body doesn't return | = note: expected type `isize` found type `()` error: aborting due to 6 previous errors Some errors have detailed explanations: E0308, E0412. For more information about an error, try `rustc --explain E0308`. </ins>

Discussion:
I'm getting an internal compiler error on the following program (found by ): I'm seeing the error on stable, beta, and nightly. As with , the error occurs on () but not on (). , the proposed fix for , does not fix this error. cc
Change:
rustc_session = { path = "../rustc_session" } [dependencies.object] <del> version = "0.28.4" </del> <ins> version = "0.29.0" </ins> default-features = false features = ["read_core", "elf", "macho", "pe", "unaligned", "archive", "write"]

Discussion:
When compiling for , the resulting binaries should have the OS/ABI () field in the ELF header set to Standalone () as per the LLVM target, which it did before . Now, it is set to "UNIX - System V", which I only tested on Linux. identified the introduction of synthetic object files for exported symbols from to have changed this: I did not have a deep dive into the code yet, but I assume the synthetic object file has the host's OS/ABI, which is prevalent over the other OS/ABI. do you have any insight? Related:
Hmm, the crate sets to , which seems to be an alias of . Unfortunately currently crate provide no ways to set this field, so to fix this I suppose some postprocessing of the generated ELF file would be needed. I am surprised that this doesn't show up earlier, given that exactly the same routine is used to create rmeta files. Does hermit not support dylibs?
Ah, yes, sets the OS/ABI here: . I think there are three possibilities: proper support for setting OS/ABI in . This would probably take a lot of effort. before passing it to in This can be done quite easily. the synthetic object file after (?) the real ones. I think lld infers the OS/ABI from the first proper input object file, if I am reading this correctly:  For 1 and 2 we would need to know the proper OS/ABI from the real object files though. I am not sure how easy that would be to come by. What do you think? Hermit is a unikernel, which is linked statically to the application. There is no support for dynamic libraries. A similar problem occurs when using though (). This issue was closed, because we did not need anyways.
Here's how LLVM determines what OSABI to use: We could look at and use the same logic to determine the OSABI. The synthetic object can be placed after real object files (it only needs to be linked before any libraries), but assuming the linker only looks at the first object file sounds a bit hacky. cc what's your take on this issue?
object-rs has only recently been taught to set expected by some MIPS targets (). In think we can teach object-rs to set too, and then just set it, if some linker expects it.
All right.

Thanks for the quick feedback. I'll cook something up in the coming days.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low
I opened , but first the necessary changes in have to be released.
Change:
error: cannot specialize on trait `HasMethod` <del> --> $DIR/spec-marker-supertraits.rs:22:1 </del> <ins> --> $DIR/spec-marker-supertraits.rs:22:9 </ins> | LL | impl<T: Marker> Spec for T { <del> | ^^^^^^^^^^^^^^^^^^^^^^^^^^ </del> <ins> |         ^^^^^^ </ins> error: aborting due to previous error

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: <!-- Please provide a link to -- The current output is: <!-- The following is not always necessary. --Ideally the output should not reference the debug format of an internal type <!-- 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. -- modify labels +F-specialization +A-specialization +requires-nightly
Change:
warning: hidden lifetime parameters in types are deprecated <del> --> $DIR/reasons.rs:20:29 </del> <ins> --> $DIR/reasons.rs:20:34 </ins> | LL |     fn fmt(&self, fmt: &mut fmt::Formatter) -> fmt::Result { <del> |                             ^^^^^^^^^^^^^^ expected named lifetime parameter </del> <ins> |                                  ^^^^^^^^^ expected named lifetime parameter </ins> | = note: explicit anonymous lifetimes aid reasoning about ownership note: the lint level is defined here

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. --I tried this code: () I expected to see this happen (which works correctly with rustc 1.57.0 stable): But with , I get: <!-- 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. --: </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Also consider the following code, which creates an error message that could be more precise. I wouldn't call the following example a bug, but maybe these two issues are related: () Error output:
I think this is due to cc: let me see if I can fix this real quick.
claim
label +regression-from-stable-to-nightly +A-diagnostics
Error: Label P-low can only be set by Rust team members Please let know if you're having trouble with this bot.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Change:
|                    ^^^^^^^^^^^^^^^^^^^ the trait `Copy` is not implemented for `Header<'_>` | = note: the `Copy` trait is required because this value will be copied for each element of the array <ins> = help: consider using `core::array::from_fn` to initialize the array = help: see https://doc.rust-lang.org/stable/std/array/fn.from_fn.html# for more information </ins> help: consider annotating `Header<'_>` with `#[derive(Copy)]` | LL + #[derive(Copy)]

Discussion:
For this snippet (): rustc gives: Since , for const-able values, rustc suggests the creation of a constant binding. Here this is not possible because is not const fn. However, we can suggest instead.
Personally, I prefer over a separate binding. Even in the case, the generated code will call the initialization function many times. Maybe in the case where bindings are possible, we can suggest both? Where they are not possible, we don't suggest anything right now, so at the least we should suggest there. what do you think?
Once is stable we can suggest that :3. But until then sounds reasonable.
Agreed, good point about . It seems to have a stabilization PR open with an FCP, which is blocked: . Maybe there might be progress on it this month: . Even if we stabilize inline const, it might make sense to wait with suggesting it for a while so that we don't make code depend on the latest MSRV immediately. So therefore, I think that it might still make sense to implement this in the meantime.
I think this should (in the future) suggest  instead, since the function would only be called once if were , whereas calls it for every element.
Change:
background: transparent; } <ins> .small-section-header { display: flex; justify-content: space-between; position: relative; } </ins> .small-section-header:hover > .anchor { display: initial; }

Discussion:
Go to: It was but the rustdoc generates like: ! The problem is that the previous variant's version is placed at the same height. I think it's ideal to place the version of the item itself at the same height, like functions.
I am new here but it looks like something I could do. Can you point me in the right direction?
Sorry but I'm not familiar with rustdoc, could you help them?
I don't have time, sorry. may have suggestions.
I can help if needed. But first: how would you want it to look like?
As mentioned first, the version at the same height should be the variant's IMO.
Ah ok sorry, so it's a layout bug. I thought you wanted to improve the display (which would be welcome too!). The problematic line is . It should be set before the docblock (in the variant header if possible).
I will gladly take a look at it, so I can familiarize with the codebase.
Sure, go ahead! Do test locally: Like that you can then go to the page and check if the bug is fixed. ;)
Change:
<ins> // Regression test for issue #109759. // check-pass #![feature(inherent_associated_types)] #![allow(incomplete_features)] struct Foo; struct Bar<const X: usize>([(); X]); impl<const X: usize> Bar<X> { pub fn new() -> Self { Self([(); X]) } } impl Foo { type Bar<const X: usize> = Bar<X>; } fn main() { let _ = Foo::Bar::<10>::new(); } </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. --I used since just gave a {integer}` error. Don't know if it's related, but thought I should mention it. <!-- 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 --
searched toolchains nightly-2022-11-03 through nightly-2023-03-31 Regression in nightly-2022-11-06 Regression in Regression in
label F-inherentassociatedtypes claim
I've just pushed a commit to that will fix this issue. Thanks for mentioning. That's just an artifact.
Triage: this is no longer ICE since today's nightly. label: +E-needs-test
Change:
let empty_args = P(hir::GenericArgs { args: HirVec::new(), bindings: HirVec::new(), parenthesized: false, }); <del> let suppress_mismatch = Self::check_impl_trait(tcx, span, seg, &def); </del> <ins> let suppress_mismatch = Self::check_impl_trait(tcx, seg, &def); </ins> Self::check_generic_arg_count( tcx, span,

Discussion:
The spans for this error should point to the generic arguments, not the entire path. See <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Change:
<ins> #![feature(const_raw_ptr_to_usize_cast)] fn main() { [(); &(static |x| {}) as *const _ as usize]; //~^ ERROR: closures cannot be static //~| ERROR: type annotations needed [(); &(static || {}) as *const _ as usize]; //~^ ERROR: closures cannot be static //~| ERROR: evaluation of constant value failed } </ins>

Discussion:
This issue might be related to , which has been fixed in playground link: Backtrace:
removing the argument inside the closure gives a different ICE. Interestingly stable refuses to compile this, but beta and nightly ICE's playground: Backtrace:
UPDATE: now also ICE's in stable.
Now no longer ICE's since 1.32.
The ICE doesn't appear on the latest nightly via the above playground link, marked as E-needstest
Change:
<ins> #![feature(const_raw_ptr_to_usize_cast)] fn main() { [(); &(static |x| {}) as *const _ as usize]; //~^ ERROR: closures cannot be static //~| ERROR: type annotations needed [(); &(static || {}) as *const _ as usize]; //~^ ERROR: closures cannot be static //~| ERROR: evaluation of constant value failed } </ins>

Discussion:
While minimizing I stumbled upon another ICE () Errors:
modify labels: I-ICE A-closures A-impl-trait C-bug F-typealiasimpl_trait T-compiler
The ICE doesn't appear on the latest nightly
Change:
<ins> error[E0582]: binding for associated type `Output` references lifetime `'a`, which does not appear in the trait input types --> $DIR/constrain_inputs_unsound.rs:23:58 | LL |     type MalformedTy = dyn for<'a> Callable<Gal<&'a ()>, Output = &'a str>; |                                                          ^^^^^^^^^^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0582`. </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. --. Prior to , these types were rejected with this error: Currently, they're accepted. Based on the assumption that generic parameters on opaque type are not constrained (see Niko's comment ), I believe the previous behavior is correct. CC: label F-typealiasimpl_trait A-impl-trait T-compiler A-lifetimes
Out of curiosity, here's an exploit derived from . It type-checks but fails at monomorphization.
The above exploit is and should be easier to do with , where indirection through would not be necessary, so label I-unsound requires-nightly T-types
if the same code were written without lifetime params and used arguments instead, we'd see the same problem before , right?
Sorry, I've clearly missed the notification :sweat_smile:. I think you already know the answer given that you've just pushed a fix :).
Change:
// self types and rely on the suggestion to `use` the trait from // `suggest_valid_traits`. let did = Some(pick.item.container_id(self.tcx)); <del> let skip = skippable.contains(&did); if pick.autoderefs == 0 && !skip { </del> <ins> if skippable.contains(&did) { continue; } trait_in_other_version_found = self .detect_and_explain_multiple_crate_versions( err, pick.item.def_id, rcvr.hir_id, *rcvr_ty, ); if pick.autoderefs == 0 && !trait_in_other_version_found { </ins> err.span_label( pick.item.ident(self.tcx).span, format!("the method is available for `{rcvr_ty}` here"),

Discussion:
I'm writing code for a programming language that uses two libraries: one for a (very simple) parser, and another for a lower level byte code, which also uses the same parser library. The parser library (TSPL) defines the trait, with the byte code library (HVM) defining a that implements that trait through a macro from TSPL. Then, a third library does something like this, where is a method from that trait: This works as expected if the dependencies in are defined like this: If we change to use the version from the latest git commit like this: Then the code does not compile anymore, even though the version in the main branch in git has the exact same code as the published version . We get an error and a warning: Notice that the compiler error tells us the function has been found from the package, and we do as the error message tells us (), but the compiler does not recognize the trait is being used even so. While writing this issue, I figured out the problem: uses the version from crates-io and our library doesn't and, even though they have the exact same code, the two versions of clash and the compiler does not compile. If we do something like this it works as expected: I still want to open this issue because I believe the error message could be more descriptive: in other cases where dependencies have clashing versions of other dependencies, usually Rust specifies it as such. The current error message is not very descriptive - the solution it gives to the problem does not work at all and may push users into the wrong direction. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details

Consider three crates High, Mid and Low, where: Mid depends on Low; High depends on both Mid and Low. This is a quite common case. Now, it sometimes happens that the dependency of Mid is bumped to a more recent version of Low. If, however, the developer fails to bump the dependency of High to a more recent version of Low, surprising error messages arise. In particular, may arise, without any change to the code of either or . It would be great if the compiler could detect the error and somehow print something along the liens of
Triage: I feel like this has gotten better in certain cases, but not all. It would be nice to make a way to reproduce this more easily, but it's non-trivial.
Change:
<ins> // Copyright 2018 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. // compile-pass fn main() { const MIN: i8 = -5; match 5i8 { MIN...-1 => {}, _ => {}, } } </ins>

Discussion:
The previous version of the crate fails to compile with the error (see the build log). No error nor warning was present in the 1.25 release. Since is actually , the error is wrong and should be fixed. regressed from stable to beta () cc
cc -- initial git log dive notes that this could be related to miri transition? Not sure.
Jup it's a regression. :
Not yet fixed on beta, this needs a backport.
Backported to beta! Thanks!
Change:
)) { // If it's a trait bound and an opaque that doesn't satisfy it, // then we can emit a suggestion to add the bound. <del> let (suggestion, suggest_span) = </del> <ins> let add_bound = </ins> match (proj_term.kind(), assoc_pred.kind().skip_binder()) { <del> (ty::Opaque(def_id, _), ty::PredicateKind::Trait(trait_pred)) => ( format!(" + {}", trait_pred.print_modifiers_and_trait_path()), Some(cx.tcx.def_span(def_id).shrink_to_hi()), ), _ => (String::new(), None), </del> <ins> (ty::Opaque(def_id, _), ty::PredicateKind::Trait(trait_pred)) => Some(AddBound { suggest_span: cx.tcx.def_span(*def_id).shrink_to_hi(), trait_ref: trait_pred.print_modifiers_and_trait_path(), }), _ => None, </ins> }; cx.emit_spanned_lint( OPAQUE_HIDDEN_INFERRED_BOUND,

Discussion:
Note: Switching back to 1.65 compiles fine : </p</details
label +E-needs-mcve
Sorry for the noise on this issue, but I just realized what I had done which apparently got around this issue. I fixed a new warning in my web server library by turning this.. into this
I caused this. Let me put up a fix.
Change:
abi, align, size, <del> }) </del> <ins> }; let best_layout = match (tagged_layout, niche_filling_layout) { (tagged_layout, Some(niche_filling_layout)) => { // Pick the smaller layout; otherwise, // pick the layout with the larger niche; otherwise, // pick tagged as it has simpler codegen. cmp::min_by_key(tagged_layout, niche_filling_layout, |layout| { let niche_size = layout.largest_niche.as_ref().map_or(0, |n| n.available(dl)); (layout.size, cmp::Reverse(niche_size)) }) } (tagged_layout, None) => tagged_layout, }; tcx.intern_layout(best_layout) </ins> } // Types with no meaningful known layout.

Discussion:
This prints the values in comments: Note that contains strictly more opportunities for optimization, but it's optimized worse. That's because it uses a "niche-filling" layout (using in the field of for ), but the "tag" layout wouldn't be any larger, because it has enough space in bytes to fit the (byte-sized) tag, and . uses the tagged layout since it has no other choice, and ends up with free values in the byte-sized tag, but "jumps the gun" on using a pre-existing niche.
Change:
use rustc_middle::lint::LintDiagnosticBuilder; use rustc_middle::ty::print::with_no_trimmed_paths; use rustc_middle::ty::subst::{GenericArgKind, Subst}; <ins> use rustc_middle::ty::Instance; </ins> use rustc_middle::ty::{self, layout::LayoutError, Ty, TyCtxt}; use rustc_session::Session; use rustc_span::edition::Edition;

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. --Rustc 1.48.0 gives an incorrect warning about an external symbol being redeclared with a different signature, when the external symbols are in different namespaces. I tried this code: I expected to see this happen: Compile without warnings Instead, this happened: <!-- 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 same behavior exists on nightly as well: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
cc would you be willing to help take a look at this? (it looks like you this way-back-when in ) On wasm targets there's which is why this should work but not actually generate a warning. Do you know if it's possible to call that logic perhaps? (would be able to consolidate "what's the name of this symbol" logic too!)
Sure thing! I'm currently in the process of moving, but will be able to get onto this on the weekend :) claim
No worries, and thanks! If you run out of time/steam I'm happy to look into this as well