jiebi/CodeConvo huggingface dataset:
Change:
<ins> #![feature(impl_trait_in_bindings)] #![allow(incomplete_features)] fn main() { const C: impl Copy = 0; match C { C | _ => {} //~ ERROR: opaque types cannot be used in patterns } } </ins>

Discussion:
ICE message: <details<summaryBacktrace</summary</summary
This should be erroring in exhaustiveness checking; shouldn't be allowed there. cc
It should be erroring earlier, when trying to create a pattern out of the constant. And it should also not be considered structural-match type-wise.
Triage: This is no longer ICE, seems that it's fixed by , marking as E-needs-test.

gives: My guess is that this has the same underlying cause as , but this one doesn't involve associated consts or arrays at all, so it might be different still.
This appears to be due to a bad interaction between and associated type projections involving lifetimes. When we normalize the function signature during type-checking, we project to . We then convert back to the 'generic' region for , which is . However, this is a distinct early bound region, different from the in (changing the regions to not all be called in the example makes this clearer). This causes issues during , since we've essentially pulled a region out of thin air. This issue doesn't seem to come up for type parameters ( with lifetimes replaced with types). I'm not sure if this is because our handling of type parameters is correct for this kind of projection, or if we need a more complicated example to break things.
The ICE no longer happens with the latest nightly (note that the playground's nightly isn't the latest). That was removed by . Marked as E-needs-test.

I got an internal compiler error at commit . I dont know how to minimize it. Relevant code is: If I remove the const field and directly put the array size like below, the ICE goes away and I get the expected compilation error that [u8; 68] is not . <details<summaryBacktrace:</summary</details<details<summaryVersion info</summary</details
The ICE also goes away if I change to
Ok. I minimized it to just: It ICEs on latest nightly:
triage: P-high, assiging to self, removing nomination label
Following example fails to compile: <details<summaryError</summary</detailsEven if I add , still issue: or <details<summaryError</summary</detailsBut this works:
Also just got this; no idea how to minimize it and the trace doesn't seem useful:-
If this is referring to the field , it's defined as where is defined inside the impl as .
Inlining resolves the error, ie changing buffer's definition to .
no longer happens with the latest nightly (note that the playground's nightly isn't the latest). That was removed by . Marked as E-needs-test.
Change:
let p = Path::new(file_dir); file_path.push(p); }; <ins> let _ = fs::create_dir_all(&file_path); </ins> let file_name = format!("rustc.node{}{}{}.{}.{}.mir", source.item_id(), promotion_id, pass_num, pass_name, disambiguator); file_path.push(&file_name);

Discussion:
I have tried this command to dump MIR things : But it won't create the directory for me, I need to create the directory before running the command. If the directory doesn't exist, it won't show any error message and it won't generate any MIR file. I think we should create the directory automatically. Even not doing so, we should show some error message. Addtionally, I wonder what are other people's opinions on setting default MIR dumping directory to somewhere like instead of current directory. Using : rustc 1.12.0-nightly ( 2016-08-05) cargo 0.13.0-nightly ( 2016-08-05)
I'm marking this as E-easy and E-mentor; we need to add a call on the parent directory of the file path. Let me know if you'd like to work on this.
sure, I can work on this :)
Go ahead! Please cc me on the PR when you create it, and let us know if you need any help; leaving a comment here works, or you can find help on IRC (#rust-internals on ).
Change:
LL | const MUTABLE_BEHIND_RAW: *mut i32 = &UnsafeCell::new(42) as *const _ as *mut _; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ <del> thread 'rustc' panicked at 'no errors encountered even though `delay_span_bug` issued', src/librustc_errors/lib.rs:356:17 </del> <ins> thread 'rustc' panicked at 'no errors encountered even though `delay_span_bug` issued', src/librustc_errors/lib.rs:357:17 </ins> note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace error: internal compiler error: unexpected panic

Discussion:
I was using the latest version of  and tried to store a reference without a lifetime annotated in a macro-generated error. This shouldn't (and doesn't) work, but rustc should at least throw an error instead of blowing up, right? Code sample: I expected an error of some sort about lifetimes or macros, but instead, the compiler ed: thread 'rustc' panicked at 'called on an value: DistinctSources(DistinctSources { begin: (Real(""), BytePos(0)), end: (Macros("::quickerror::quickerror"), BytePos()) })', This rustc was compiled on Gentoo from a recent . $ rustc --version --verbose rustc 1.42.0-dev ( 2020-01-21) binary: rustc commit-hash: commit-date: 2020-01-21 host: x8664-unknown-linux-gnu release: 1.42.0-dev LLVM version: 9.0 Minimal example: Backtrace:
rustc in playpen isn't the latest compiler. reopen
cc
Backtrace:
triage: P-high, assigning to . (It would be good to confirm it is indeed due to the CC'ed PR via bisection...)
Full backtrace: From a quick look it seems like might tackle this. Rebuilding a recent master to confirm.
Change:
}, Primitive::F32 => types::F32, Primitive::F64 => types::F64, <del> Primitive::Pointer => pointer_ty(tcx), </del> <ins> // FIXME(erikdesjardins): handle non-default addrspace ptr sizes Primitive::Pointer(_) => pointer_ty(tcx), </ins> } }

Discussion:
It seems that the prefix is used more often than , so we should swap the function names before 0.1.
We're probably going the other direction -
Done.
Change:
} }; <del> let ty_to = match ty.kind() { ty::RawPtr(ty::TypeAndMut { mutbl: hir::Mutability::Not, ty: ty_to, }) => ty_to, </del> <ins> let (ty_to, ty_to_mut) = match ty.kind() { ty::RawPtr(ty::TypeAndMut { mutbl: ty_to_mut, ty: ty_to }) => { (ty_to, *ty_to_mut) } </ins> _ => { span_mirbug!( self,

Discussion:
cc is this a coercion that's expected to work?
triage: I-nominated
The first cast is from to , the second is from to . I'm not actually sure if this is meant to work, I guess it should. The intention here is to give a way to treat arrays like C-arrays and get a pointer to the start of the array. It seems that if the array is mutable, then the pointer should be too. I recommend this is P-low - it is backwards compatible, rare, and just a bug by omission, really. The fix should be pretty easy though.
Ah I wasn't sure if this was intended, if it's actually intended then I don't mind removing the nomination as well!
I'm not sure how intended this is, but it doesn't seem too harmful. ;)
P-low, (perhaps "just a bug", perhaps a minor feature.)
Triage: no change
This still happens today (with ), but the error message is slightly different: is another -related issue.
Change:
/// The current stamp. stamp: AtomicUsize, <del> /// The message in this slot. </del> <ins> /// The message in this slot. Either read out in `read` or dropped through /// `discard_all_messages`. </ins> msg: UnsafeCell<MaybeUninit<T>>, }

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: I expected to see this happen: I expected to see the struct in the Sender buffer get dropped after the Receiver is dropped during the unwind of the panicking thread. Instead, this happened: The data in the Sender buffer is not dropped until the whole process ends. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: 1.66.1 <!-- Provide the version you are using that has the regression. --: <!-- Did the compiler crash? If so, please provide a backtrace. --</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 --
bisection seems to point to cc searched nightlies: from nightly-2022-11-01 to nightly-2023-02-01 regressed nightly: nightly-2022-11-14 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:
In crossbeam, the unbounded channel does this (), but the bounded channel does not. There is no particular intent, it just hasn't been implemented. cc
Change:
target_sp.open = source_sp.open.with_ctxt(ctxt); target_sp.close = source_sp.close.with_ctxt(ctxt); } <ins> ( TokenTree::Delimited(target_sp, ..), mbe::TokenTree::MetaVar(source_sp, ..), ) => { target_sp.open = source_sp.with_ctxt(ctxt); target_sp.close = source_sp.with_ctxt(ctxt).shrink_to_hi(); } </ins> _ => { let sp = rhs_tt.span().with_ctxt(ctxt); tt.set_span(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. --<!-- 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 problem seems to be this: But it looks like rustc already gets the span wrong: !
<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p<!-- Include a backtrace in the code block by setting in your environment. E.g. RU &lt;!-- Include a backtrace in the code block by setting in your environment. E.g. . --&lt;details&lt;summary&lt;strongBacktrace&lt;/strong&lt;/summary&lt;p&lt;/p&lt;/detailsSTBACKTRACE=1 cargo build. --<details<summary<strongBacktrace</strong</summary<p</p</details</p</details
This appears to stem from the span for the delimited block being changed . I will work on a fix now and submit it.
Change:
LowerBound(Result<'blk, 'tcx>) } <del> #[derive(Clone, Copy)] </del> <ins> #[derive(Clone, Copy, PartialEq)] </ins> pub enum TransBindingMode { TrByCopy(/* llbinding */ ValueRef), TrByMove,

Discussion:
I've tried to write: The line above gives LLVM assertion. I think this must show some syntax error.
Change:
argument_scope: region::Scope, ast_body: &'tcx hir::Expr<'tcx>, ) -> BlockAnd<()> { <ins> let tcx = self.hir.tcx(); let attrs = tcx.codegen_fn_attrs(fn_def_id); let naked = attrs.flags.contains(CodegenFnAttrFlags::NAKED); </ins> // Allocate locals for the function arguments for &ArgInfo(ty, _, arg_opt, _) in arguments.iter() { let source_info = SourceInfo::outermost(arg_opt.map_or(self.fn_span, |arg| arg.pat.span)); let arg_local = self.local_decls.push(LocalDecl::with_source_info(ty, source_info)); <ins> // Emit function argument debuginfo only for non-naked functions. // See: https://github.com/rust-lang/rust/issues/42779 if naked { continue; } </ins> // If this is a simple binding pattern, give debuginfo a nice name. if let Some(arg) = arg_opt { if let Some(ident) = arg.pat.simple_ident() {

Discussion:
When compiling () The generated assembly includes a prologue with unexpected 's (as well as a trailing , already reported in ) Expected behaviour would be to have no prologue (and prevent compilation of a function that is not as this would require implementing an undefined ABI, contrarily to what seems to happen ). This is treacherous, as it dereferences some memory locations that may not be accessible, as happened to me and led to hours of debugging to finally figure out the compiled function was not the one defined. cc
IIRC this is invalid and rustc should reject such a function, naked functions can't take arguments and the compiler should probably enforce that.
Hmm, my understanding of the RFC (“The following variant is not an error because the C calling convention is well-defined and it is thus possible for the programmer to write a conforming function”, even if the example is not with an argument) would mean that if the function is declared , then the function can actually respect the said ABI, thus should be well-formed?
Is there an update on this? I was hit by this issue as well. I hit the problem when compiling a tock app (baremetal-ish and jumped to by the tock OS) A naked function with arguments would produce this prolog (RV32): Which would result in an invalid access as s0 would be 0. Removing the arguments would remove the prologue and fix the problem. Removing the naked cfg would also work as teh stack pointer was already setup by the OS and result in this. If arguments with naked functions aren't supported rustc should generate an error as this is a difficult problem to debug.
This is an LLVM bug. Has it been reported upstream?
Change:
<ins> error: `extern` fn uses type `Option<&T>`, which is not FFI-safe --> $DIR/lint-ctypes-option-nonnull-unsized.rs:3:45 | LL | extern "C" fn foo<T: ?Sized + 'static>() -> Option<&'static T> { |                                             ^^^^^^^^^^^^^^^^^^ not FFI-safe | = help: consider adding a `#[repr(C)]`, `#[repr(transparent)]`, or integer `#[repr(...)]` attribute to this enum = note: enum has no representation hint note: the lint level is defined here --> $DIR/lint-ctypes-option-nonnull-unsized.rs:1:9 | LL | #![deny(improper_ctypes_definitions)] |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error </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
build-pass -ice in nightly-2020-07-31 commit[0] 2020-07-29: Auto merge of - richkadel:llvm-coverage-map-gen-5, r=tmandry commit[1] 2020-07-29: Auto merge of - P1n3appl3:rustdoc-formats, r=tmandry commit[2] 2020-07-30: Auto merge of - Manishearth:rollup-z2vflrp, r=Manishearth commit[3] 2020-07-30: Auto merge of - ehuss:update-cargo, r=Mark-Simulacrum commit[4] 2020-07-30: Auto merge of - oli-obk:lumberjack_disable, r=RalfJung commit[5] 2020-07-30: Auto merge of - npmccallum:naked, r=matthewjasper commit[6] 2020-07-30: Auto merge of - ecstatic-morse:const-size-align-of-val, r=oli-obk commit[7] 2020-07-30: Auto merge of - jumbatm:clashing-extern-decl, r=nagisa commit[8] 2020-07-30: Auto merge of - RalfJung:miri, r=RalfJung commit[9] 2020-07-30: Auto merge of - Manishearth:rollup-3wudwlg, r=Manishearth ERROR: no CI builds available between and
probably ?
why did you mark this as P-critical if it's a stable-to-stable regression from 2020?

Minimal:
its a regression build pass -ice which is critical according to the rustc dev guide
According to (not the dev guide, which I was confused since the dev guide doesn't really mention criteria for priority): This is a regression since like 1.47, so I don't think it necessarily needs to block a release to fix :smiley_cat:
Ah sorry that's what i meant, right guess its p high then.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
free_regions: &FreeRegionMap, subject_node_id: ast::NodeId) { let errors = self.region_vars.resolve_regions(free_regions, subject_node_id); <del> self.report_region_errors(&errors); // see error_reporting.rs </del> <ins> if !self.errors_since_creation() { // As a heuristic, just skip reporting region errors // altogether if other errors have been reported while // this infcx was in use.  This is totally hokey but // otherwise we have a hard time separating legit region // errors from silly ones. self.report_region_errors(&errors); // see error_reporting.rs } </ins> } pub fn ty_to_string(&self, t: Ty<'tcx>) -> String {

Discussion:
I have encountered this problem several times while compiling versions of rustc with errors, but this is the first self-contained example I have found. A single error as the field does not exist Note the fat cascading region error. This reproduces on 1.5/1.6 and current nightly.
cc
Change:
<ins> //@ check-pass //@ compile-flags: -Csymbol-mangling-version=v0 #![allow(incomplete_features)] #![feature(unsized_const_params)] // Regression test for #116303 #[derive(PartialEq, Eq)] struct MyStr(str); impl std::marker::UnsizedConstParamTy for MyStr {} fn function_with_my_str<const S: &'static MyStr>() -> &'static MyStr { S } impl MyStr { const fn new(s: &'static str) -> &'static MyStr { unsafe { std::mem::transmute(s) } } } pub fn main() { let f = function_with_my_str::<{ MyStr::new("hello") }>(); } </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 --
Regression in nightly-2023-05-04 Regression in Regression in
I tracked this down to the fact that implicitly sets : I can reproduce with just on its own, without . Conversely, if I modify the wrapper function to pretend that coverage is always off, then the problem still occurs. So I believe this is actually an incompatibility between and v0 symbol mangling.
claim
With , the original code causing the ICE should be updated as:
Also the label for this issue should be replaced with . Cc
Change:
<ins> trait Trait<T> {} struct Bar(Box<dyn Trait<T>>); //~^ ERROR cannot find type `T` in this scope fn main() { let x: Bar = unsafe { std::mem::transmute(()) }; } </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. --This is a fuzzed test case, found with and minimized with , but found no similar issues. <!-- 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 nightlies: from nightly-2021-01-01 to nightly-2023-03-12 regressed nightly: nightly-2023-01-05 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: </detailsNote that this requires edition 2015/2018, as edition 2021 hard errors on the bare trait object before ever getting to layout code. cc
claim
Change:
-> ConstEvalRawResult<'tcx> { desc { |tcx| "const-evaluating `{}`", <del> tcx.def_path_str(key.value.instance.def.def_id()) </del> <ins> key.value.display(tcx) </ins> } }

Discussion:
Evaluating of promoteds currently looks very confusing in the query stack: is not a const, so "const-evaluating " is just nonsense. I presume that this is easy to fix but only would know how. ;) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Also see
Let's give a try :wink:
claim
awesome. :) Let us know if you need any help. I am not very familiar with that specific code, but can still help with more general questions, and I hope can help with the specifics. :D
Change:
<del> Subproject commit b123ab4754127d822ffb38349ce0fbf561f1b2fd </del> <ins> Subproject commit 08bb147d51e815b96e8db7ba4cf870f201c11ff8 </ins>

Discussion:
Results in a crash (after a perfectly reasonable error message): This was tested with rustc 0.1. Building from HEAD on nyus now to try to get a more helpful backtrace and to verify that it hasn't since been fixed.
Here's a more helpful backtrace. Repros at .
Looks exactly like to me.

On the pull request for (), had a good suggestion for what I think would make a good additional function: "a version of frombytes which doesn't fail on invalid input but rather offers some sort of error recovery options. Like maybe it can return the partly converted string with an index to the invalid position. Or perhaps, a callback function to handle the error, etc." At a glance the easy way to do this would be with a callback to, e.g., drop, replace, or coerce offending sequences into UTF-8 or else return a ... But is this a recipe for complex callbacks? Perhaps providing sensible callback functions like , , , and so on would make this simple enough to use. Maybe those should just be simple functions for whole byte vector conversion, anyways. What do you think?
I don't have a strong opinion about it, but I guess I would prefer to wait until somebody actually needs something like this.
Not RFC-level proposal. Just a library wishlist item. Might accept a patch; but it seems a bit overwrought. Anyone need such a thing yet?
I think this is subsumed in ; we might well adopt a dynamic-handler mechanism while working through that bug. This would be a special case.
Change:
self.struct_span_err(span_of_tilde, "`~` cannot be used as a unary operator") .span_suggestion_short( span_of_tilde, <del> "use `!` to perform bitwise negation", </del> <ins> "use `!` to perform bitwise not", </ins> "!".to_owned(), Applicability::MachineApplicable )

Discussion:
I find the error message confusing and possibly incorrect when attempting to use as a unary operator: In current Rust stable and nightly, I get: The "help" is misleading because it is suggesting using to "perform bitwise negation." But this is not really what ~ performs. which perform different things. I think this message would be best changed to "perform bitwise NOT" or "perform bitwise one's complement"
is referred to as “bitwise not”, “binary complement” and “bitwise negation” among many other names, so the current diagnostic is valid. Not sure where the confusion might arise here, because “bitwise” implies that the operation is… well… bitwise.
would be my preferred phrasing...
Change:
use monomorphize::Instance; use rustc::hir; use rustc::hir::def_id::DefId; <ins> use rustc::traits; </ins> use rustc::ty::{self, Ty, TyCtxt, TypeFoldable}; <del> use rustc::ty::subst::Substs; </del> <ins> use rustc::ty::subst::{Subst, Substs}; </ins> use syntax::ast::{self, NodeId}; use syntax::attr; use syntax_pos::Span;

Discussion:
Compiler panicks instead of showing an appropriate error message in case boundaries are not satisfied. I tried this code: In the result compiler panicked with the following message:
Minimal repr:
Still panics on stable 1.15.1