jiebi/CodeConvo huggingface dataset:
Change:
// option. This file may not be copied, modified, or distributed // except according to those terms. <del> use rustc_serialize::{Encodable, Decodable, Encoder, Decoder}; </del> use rustc_data_structures::stable_hasher; use std::mem; use std::slice; <del> #[derive(Eq, PartialEq, Ord, PartialOrd, Hash, Debug, Clone, Copy)] </del> <ins> #[derive(Eq, PartialEq, Ord, PartialOrd, Hash, Debug, Clone, Copy, RustcEncodable, RustcDecodable)] </ins> pub struct Fingerprint(u64, u64); impl Fingerprint {

Discussion:
Attempting to compile this example program using a nightly compiler: On a native mips big endian machine gives me this: If I compile to an object and dump the symbols, I see that the hash for is different between the object and the rlib file: After some debugging, I managed to work out that the value of for passed to the in is byteswapped when run natively compared to running on an x86 -mips cross compiler. I couldn't work out where this value originally comes from, but hopefully someone here knows. :) I also tried using a stable compiler, but it failed with the issue before getting to this stage.
cc
I don't have a MIPS machine right here, but it certainly looks that should be returning a , which should be endianness-correct (i.e. return the same 2 u64s) -
Does beta work, btw?
It looks like affects beta as well. I get the same error as on stable - this is with:
Change:
# Shorthand for build/stageN/bin HB = $(HBIN$(ISTAGE)_H_$(CFG_HOST_TRIPLE)) <ins> HB3 = $(HBIN3_H_$(CFG_HOST_TRIPLE)) </ins> # Shorthand for build/stageN/lib HL = $(HLIB$(ISTAGE)_H_$(CFG_HOST_TRIPLE)) # Shorthand for the prefix bin directory

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:
const TEST_V: Discriminant<SingleVariant> = discriminant(&SingleVariant::V); <ins> pub const TEST_VOID: () = { // This is UB, but CTFE does not check validity so it does not detect this. // This is a regression test for https://github.com/rust-lang/rust/issues/89765. unsafe { std::mem::discriminant(&*(&() as *const () as *const Void)); }; }; </ins> fn main() { assert_eq!(TEST_A, TEST_A_OTHER); assert_eq!(TEST_A, discriminant(black_box(&Test::A(17))));

Discussion:
Interpreter calls on zero variant enum, when asked unsafely to do so :-). label: +requires-nightly +A-const-eval
cc
Ah, nasty unsafe code is nasty. ;) This reminds me of discussions I had with a while ago about the for 0-variant enums. Basically the bad code is like but is this really the only part of the compiler that assumes that for , we can use ?
FTR this is the layout of the empty enum: The fix could be to make return for 0-variant enums (treating them basically like any other type that does not actually have a discriminant) to add some logic in that avoids calling for 0-variant enums I haven't made up my mind yet about which one seems better... but I am leaning towards the first option.
As pointed out at , our codegen backend actually says that on any uninhabited type is UB. If we want to stick to that, this limits our options, at least for Miri (CTFE does not have to do all the same checks): pretty much the only clean solution I can think of is to require the place to contain data that satisfies the validity invariant. CTFE does not check validity invariants, so this does not clearly say what we should do there; we could still treat all types without discriminants the same (by returning 0).
In release mode returns an undef (look at llvm IR) even though from all docs it should be sound. At least as long as is sound, which I don't know if it has been decided yet.
I have not been able to weaponize it, but we should probably just make the codegen backend return 0
In my book is not sound, but indeed it has not been decided yet.
In , things look like we should properly check full validity of a value when reading its discriminant. However, that on its own cannot fix this ICE since the first thing validity checking will do is of course read the discriminant...
Change:
// FIXME(type_alias_impl_trait): What does this test? This needs a comment // explaining what we're worried about here. #![feature(type_alias_impl_trait)] trait Trait {} type Opaque<T> = impl Sized;

Discussion:
The following UB compiles: The impl is invalid because the lifetime parameter appears unconstrained in the impl header. It should be rejected for the same reason that projection types doesn't constraint impl generics: label C-bug T-types I-unsound requires-nightly F-typealiasimpl_trait
Change:
} } <ins> #[stable(feature = "mpsc_debug", since = "1.7.0")] impl fmt::Debug for Select { fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { write!(f, "Select {{ .. }}") } } #[stable(feature = "mpsc_debug", since = "1.7.0")] impl<'rx, T:Send+'rx> fmt::Debug for Handle<'rx, T> { fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { write!(f, "Handle {{ .. }}") } } </ins> #[cfg(test)] #[allow(unused_imports)] mod tests {

Discussion:
All public types should implement Debug. Per conversation on #rust-internals, there might be some useful information that could be printed for these types -- but even just "Sender { .. }" etc. would be a start.
Was this
probably. It has been suggested that way more useful info could actually be printed instead of the opaque placeholders -- but that would be more of a wishlist item than a bug... The patch is sufficient to fix the actual problem I was running into: not being able to #[derive(Debug)] on any structure containing mpsc Senders/Receivers.
Ok, closing.
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 pub trait Nullable { const NULL: Self; fn is_null(&self) -> bool; } impl<T> Nullable for *const T { const NULL: Self = 0 as *const T; fn is_null(&self) -> bool { *self == Self::NULL } } fn main() { } </ins>

Discussion:
Building the crate causes an ICE in beta 1.28. Looking at the backtrace seems like that's caused by the const evaluator. regressed from stable to beta () cc cc
is fixing so not going to bisect this
Change:
<del> // run-rustfix #![allow(unused_imports)] pub mod x { pub struct A; pub struct B; } // `.` is similar to `,` so list parsing should continue to closing `}` use x::{A, B}; //~ ERROR expected one of `,`, `::`, `as`, or `}`, found `.` fn main() {} </del>

Discussion:
Was reported here : but still occurring. <!-- 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
Simpler repro: ()
I assume this repros for any non-ascii character, right? I tried with ü, ß, and , and I was able to repro.
Correct :) é was just the character my big fingers typed when I found that bug!
Assigning and removing as .20.E2.80.A6) in the prioritization working group.
This is a regression since modify labels: +regression-from-stable-to-stable
Change:
<ins> // Regression test for #75883. pub struct UI {} impl UI { pub fn run() -> Result<_> { //~^ ERROR: this enum takes 2 type arguments but only 1 type argument was supplied //~| ERROR: the type placeholder `_` is not allowed within types on item signatures let mut ui = UI {}; ui.interact(); unimplemented!(); } pub fn interact(&mut self) -> Result<_> { //~^ ERROR: this enum takes 2 type arguments but only 1 type argument was supplied //~| ERROR: the type placeholder `_` is not allowed within types on item signatures unimplemented!(); } } fn main() {} </ins>

Discussion:
<!-- 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. --: Note: Same error on stable and beta. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
this works for me on latest nightly. If you update your version of the compiler, does it work for you?
Oh oops, I was missing , sorry:
Slightly smaller: If you change to , it works, so I think this is while trying to infer .
glacier ""
This issue has been fixed by , marking as .

<!-- 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. --Hi, it appears that I've stumbled upon an internal compiler error. I'm sorry that I can't provide a minimal example, but I'm not on a level to understand what is going on (at least for now, heh :P). I'm just here, because the compiler told me to go here. I have, however, pushed a commit of my project in the state that yields the error: The error occurs when running or , for that matter. <!-- 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. --: Also happens on nightly: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailsI hope this helps. Please tell me, if there's more you need me to do.
reduced: `
modify labels: -E-needs-mcve
Assigning as and removing .
This ICEs since modify labels: +regression-from-stable-to-stable
This issue has been fixed by , marking as .
Change:
#[derive(Diagnostic)] #[diag(resolve_module_only)] pub(crate) struct ModuleOnly(#[primary_span] pub(crate) Span); <ins> #[derive(Diagnostic, Default)] #[diag(resolve_macro_expected_found)] pub(crate) struct MacroExpectedFound<'a> { #[primary_span] pub(crate) span: Span, pub(crate) found: &'a str, pub(crate) expected: &'a str, pub(crate) macro_path: &'a str, #[subdiagnostic] pub(crate) remove_surrounding_derive: Option<RemoveSurroundingDerive>, #[subdiagnostic] pub(crate) add_as_non_derive: Option<AddAsNonDerive<'a>>, } #[derive(Subdiagnostic)] #[help(resolve_remove_surrounding_derive)] pub(crate) struct RemoveSurroundingDerive { #[primary_span] pub(crate) span: Span, } #[derive(Subdiagnostic)] #[help(resolve_add_as_non_derive)] pub(crate) struct AddAsNonDerive<'a> { pub(crate) macro_path: &'a str, } </ins>

Discussion:
(The actual desired output should have colours and minuses on the removed derive, but to give the idea) Many users are not familiar with the terminology being used by the compiler error (i.e. the different flavours of procedural macro, derive vs attribute) and might be confused as to what they need to do in order to fix the error. Since the fix is straight-forward (i.e. remove the ), the compiler should show a code snippet that fixes the issue. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I have a partially functional implementation of this, though I've run into a bit of trouble, some guidance would be appreciated. Currently I'm implementing this next to the existing error in in . My trouble comes with knowing what the macro is invoked on, (function, struct), and sending the help message selectively based on that. Is there a way to get this information in , or is my approach wrong and the error should be elsewhere? As far as I can tell I am trying to implement this in a place before the AST is fully parsed, so this may be unviable
Change:
mod rand_impls; /// A type that can be randomly generated using an `Rng`. <ins> #[doc(hidden)] </ins> pub trait Rand : Sized { /// Generates a random instance of this type using the specified source of /// randomness.

Discussion:
If you go to a place in the libstd docs that references the rand crate, such as , all the links (, , ) are broken. Looks like they need an extra "/rand/" in the URL. The same problem occurs in the nightly docs (not sure what the correct URL is for those, though). Since these links to trait impls are auto-generated by rustdoc, I'm assuming this is a bug in rustdoc, not just a typo in the documentation. Or it has something to do with the rand code existing in libstd but also librand.
I believe this is the cause. any ideas?
Ah yes this is just a private trait in the distribution, so it just needs to be marked .
Change:
TupleArgumentsFlag, }; use rustc_ast as ast; <del> use rustc_data_structures::fx::FxHashSet; </del> <ins> use rustc_data_structures::fx::FxIndexSet; </ins> use rustc_errors::{pluralize, Applicability, Diagnostic, DiagnosticId, MultiSpan}; use rustc_hir as hir; use rustc_hir::def::{CtorOf, DefKind, Res};

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: Diesel has a larger amount of compile test to check whether some constructs are rejected at compile time and to check for specific error messages. These tests are implemented using trybuild. We pin specific compiler versions as the output obviously might change with newer compiler versions. From time to time an update of the pinned version is required. While doing such an update we noticed that newer versions of rustc do emit non-deterministic error messages. These sometimes include more or less information. To reproduce this behaviour perform the following steps: We do not observe this behaviour with . I've observed this behaviour at least since (that's the earliest nightly I've checked, so there might be earlier versions as well) Exemplary changes between two runs (obviously that changes as well): <!-- 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 --
If you have time, it would be helpful to find exactly which commit regressed this (using ).
searched nightlies: from nightly-2022-08-12 to nightly-2022-09-15 regressed nightly: nightly-2022-08-23 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: : </detailscc as author of the relevant PR
I'll take a look. claim
Change:
cx.into_expr() } <ins> fn may_contain_yield_point(e: &ast::Expr) -> bool { struct MayContainYieldPoint(bool); impl Visitor<'_> for MayContainYieldPoint { fn visit_expr(&mut self, e: &ast::Expr) { if let ast::ExprKind::Await(_) | ast::ExprKind::Yield(_) = e.kind { self.0 = true; } else { visit::walk_expr(self, e); } } fn visit_mac_call(&mut self, _: &ast::MacCall) { self.0 = true; } fn visit_attribute(&mut self, _: &ast::Attribute) { // Conservatively assume this may be a proc macro attribute in // expression position. self.0 = true; } fn visit_item(&mut self, _: &ast::Item) { // Do not recurse into nested items. } } let mut visitor = MayContainYieldPoint(false); visitor.visit_expr(e); visitor.0 } </ins>

Discussion:
This has already tripped up some people which seem to get quite confused with this error message, so I'd rather we not regress here: I tried this code: I expected to see this happen: Code compiles fine: the type of is . Instead, this happened: The type of is not send, since the backing state-machine generator produced for it now captures part of the internals involving a reference to the , which is not . It most recently worked on: beta : modify labels: +regression-from-stable-to-nightly -regression-untriaged
Might be related to / ?
I was also suspecting one of those, although I have to admit not having looked into it any further
Does it work with btw ? That should completely disable drop range tracking. (I've launched a try build there so that we have artifacts ready for that soon). There were also recent changes in the formatting macros/machinery last week IIRC. That could be related as well. This should be easy enough to bisect, and make sure where the regression is coming from.
Answering my own questions: doesn't change this, my guess is that it's actually unrelated to initially landed as part of and that rollup's commit doesn't reproduce the issue the change I mentioned was and its commit does reproduce the issue. This PR seems to have caused it indeed.
Nice investigation
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
Change:
: "eax" ); # } } <ins> # #[cfg(not(any(target_arch = "x86", target_arch = "x86_64")))] # fn main() {} </ins> ``` Whitespace also doesn't matter:

Discussion:
Triggers an LLVM assertion when targeting Android:
Something that works on any host (i.e. you needn’t compile libstd for android to repro):
As the error says, isn't a supported calling convention for the ARM target in LLVM. Not really much we can do from the rustc side unless we want to error early based on cc/target combinations. In any case, it should not crash.
I'm hitting this when I tried to run tests for 1.10.0 on arm64 (aarch64-unknown-linux-gnu). The build succeeds otherwise. I'm just adding and to for the time being.
Neither example crashes today. Closing, since I don't see any good opportunity for a test here (it'd have to be something like and that's probably not worth it). With (original example): Updated example:
Change:
<ins> error[E0726]: implicit elided lifetime not allowed here --> $DIR/skip-reporting-if-references-err.rs:10:9 | LL | impl<T> ToUnit for T {} |         ^^^^^^ expected lifetime parameter | help: indicate the anonymous lifetime | LL | impl<T> ToUnit<'_> for T {} |               ++++ error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0726`. </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'downgradetodelayedbug: cannot downgrade Warning to DelayedBug: not an error'', 'thread 'rustc' panicked at 'downgradetodelayedbug: cannot downgrade Warning to DelayedBug: not an error'' 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: [specializationgraphof] building specialization graph of trait [coherent_trait] coherence checking all impls of trait [analysis] running analysis passes on this crate --
Regression in nightly-2023-03-22 commit[0] 2023-03-20: Auto merge of - euclio:windows-rs, r=ChrisDenton commit[1] 2023-03-20: Auto merge of - Zoxc:split-execute-job, r=cjgillot,michaelwoerister commit[2] 2023-03-21: Auto merge of - ChrisDenton:libntdll, r=Mark-Simulacrum commit[3] 2023-03-21: Auto merge of - TDecki:dec2flt-inline, r=thomcc commit[4] 2023-03-21: Auto merge of - saethlin:remove-vec-as-ptr-assume, r=thomcc commit[5] 2023-03-21: Auto merge of - Nilstrieb:rollup-seb5xsa, r=Nilstrieb commit[6] 2023-03-21: Auto merge of - ferrocene:pa-test-metrics, r=Mark-Simulacrum commit[7] 2023-03-21: Auto merge of - compiler-errors:local-key, r=cjgillot commit[8] 2023-03-21: Auto merge of - matthiaskrgr:rollup-odn02wu, r=matthiaskrgr ERROR: no CI builds available between and within last 167 days
oh nevermind, still crashes with next-solver-coherence :cryingcatface:
Change:
<ins> // check-pass #[derive(PartialEq)] struct NonMatchable; impl Eq for NonMatchable {} #[derive(PartialEq, Eq)] enum Foo { A(NonMatchable), B(*const u8), } const CONST: Foo = Foo::B(std::ptr::null()); fn main() { match CONST { CONST => 0, _ => 1, }; } </ins>

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. --I tried this code: The above code compiles fine on beta and stable, but fails on the latest nightly. It used to pass on nightly too (last I tested it). The errors is this: The error is claiming that we are using in the pattern when we are not. Interestingly if we change the value of to be something other then a pointer, this passes (though that should not make a difference). Also if we don't use a constant but instead match on directly, it passes as well. We only see this issue in the nightly compiler when we both using a constant and the variant in the constant is a pointer. Unless I am misunderstanding something here, this should not be an error. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: <!-- version --<!-- Provide the version you are using that has the regression. --: <!-- Did the compiler crash? If so, please provide a backtrace. --
I believe there has been a regression as per the pull request , and I plan to investigate it further at a later time.
bisection seems to confirm PR thanks for looking into that! WG-prioritization assigning priority (). label -I-prioritize +P-high -needs-triage
That does indeed bisect to
Change:
fn source_info(&self, cx: &CodegenCx<'ll, 'tcx>) -> Option<SourceInfo<'ll>> { match self { VariantInfo::Generator { def_id, variant_index, .. } => { <del> let span = cx.tcx.generator_layout(*def_id).variant_source_info[*variant_index].span; </del> <ins> let span = cx.tcx.generator_layout(*def_id).unwrap().variant_source_info [*variant_index] .span; </ins> if !span.is_dummy() { let loc = cx.lookup_debug_loc(span.lo()); return Some(SourceInfo {

Discussion:
See below:
Reduced to only use the task proc-macro: It seems important, that Foo isn't defined, if I define a , the ICE goes away.
searched nightlies: from nightly-2020-06-01 to nightly-2021-01-01 regressed nightly: nightly-2020-10-27 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: </detailsI'm pretty sure that isn't at fault here, but instead it just uncovers the problem.
MCVE:
Panic location: