jiebi/CodeConvo huggingface dataset:
Change:
TrBench(BenchSamples), } <ins> unsafe impl Send for TestResult {} </ins> enum OutputLocation<T> { Pretty(Box<term::Terminal<term::WriterWrapper> + Send>), Raw(T),

Discussion:
Compiling with works fine, definitely does not, though: And, if the bound in is removed, the code compiles fine with or without . So... somehow the test runner is causing a tuple of arity 3 specifically to be inferred to something completely ridiculous.
cc I guess?
points out that specifically having causes the problem.
cc me
FYI: discovered this problem while working on
Slightly more minimized:
contains: This causes the problem.
I'll take a look at it.
Oh, I see you tracked it down -- I thought it might be something like that. This is in fact something I was talking to about as a possible danger of the way we're treating builtin bounds right now, though in a different context.
In fact, I think that the for a tuple ought to be a coherence violation to begin with, actually.
(I think there was language about specifically this in the OIBIT RFC)
I agree with comments here and after a quick chat on IRC with him, we agreed that implementations of built-in traits (and likely default trait impls in the future) should be allowed just on and .
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:30 </del> <ins> --> $DIR/lint-ctypes-94223.rs:44:30 </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:
// If we forget this, compilation can succeed with an incomplete rmeta file, // causing an ICE when the rmeta file is read by another compilation. if let Err((path, err)) = ecx.opaque.finish() { <del> tcx.dcx().emit_err(FailWriteFile { path: &path, err }); </del> <ins> tcx.dcx().emit_fatal(FailWriteFile { path: &path, err }); </ins> } let file = ecx.opaque.file(); if let Err(err) = encode_root_position(file, root.position.get()) { <del> tcx.dcx().emit_err(FailWriteFile { path: ecx.opaque.path(), err }); </del> <ins> tcx.dcx().emit_fatal(FailWriteFile { path: ecx.opaque.path(), err }); </ins> } // Record metadata size for self-profiling

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. --With as a dependency. <!-- 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. --: This is repeated for what seems like every parallel compilation unit.
It appeared to be related to running out of space in the target directory.
Thank you for opening the issue and that explanation. This is probably fixed by (which will be in 1.76 but not 1.75) but I'll try to reproduce the crash just in case it isn't fixed by that.
The reproducer script I cooked up for reproduces this ICE backtrace on stable, so I'm linking this to that PR.
Change:
impl trait, self type, or predicates", kind, name <del> ) .span_label(span, format!("unconstrained {} parameter", kind)) .emit(); </del> <ins> ); err.span_label(span, format!("unconstrained {} parameter", kind)); if kind == "const" { err.note( "expressions using a const parameter must map each value to a distinct output value", ); err.note( "proving the result of expressions other than the parameter are unique is not supported", ); } err.emit(); </ins> } /// Enforce that we do not have two items in an impl with the same name.

Discussion:
The following code does NOT compile: it errors with: However, when using normal generics in the places of the const generics, wrapping the in an and sticking that into the struct does work: Is it intended that const generic dont mimmic this behaviour?
This is probably a decision that has to be made (although if it is disallowed, then we'd want a better error message). However, at present, this is a implementation limitation: we really only properly support const generics of the form at the moment (cc ).
Considering that anon consts are mostly just projections, wouldn't this be similar to which doesn't really make a lot of sense (we have to guarantee that the projection maps each value of to a unique type). While is injective, finding an intuitive subset of expressions for which this is the case is hard and imo not actually desirable rn. Not quite sure what's the best error message though :thinking: probably something like
That's a good point I think adding a note explaining the problem would be the best solution, though the tricky part is working out how to explain it concisely (rather than just stating what the problem is).
Change:
let spans = sess.parse_sess.gated_spans.spans.borrow(); macro_rules! gate_all { <ins> ($gate:ident, $msg:literal, $help:literal) => { if let Some(spans) = spans.get(&sym::$gate) { for span in spans { gate_feature_post!(&visitor, $gate, *span, $msg, $help); } } }; </ins> ($gate:ident, $msg:literal) => { if let Some(spans) = spans.get(&sym::$gate) { for span in spans {

Discussion:
This code (): prints out This is pretty unhelpful for beginners - normally this happens when they try to use in a closure, which tells them they need async: But when they do they get an error about async being unstable, which they have no idea how to solve. The fix is to remove the pipe symbols: However, this requires knowledge that async blocks desugar internally into closures, which is not at all clear from the syntax. It would be better for the compiler to suggest it:
Hey, I saw this and it looked like it might be easy so I took a shot with I haven't fixed the tests yet because I wasn't sure if this approach is reasonable or not. You end up with Re-ordering the note and help, or adding a nested span on to put the help would be considerably more involved.
Given the current is equivalent to , it may be preferable to suggest instead of .
the point of this is that the user didn't mean though. If you add then you can no longer await it: For context, the original code was something like , where the user tried to use outside of an async function.
Thanks for clarifying. What suggestion is preferable seems to depend on the expected return type. Perhaps it is preferable to have both notes?
Change:
<ins> #![feature(fn_delegation)] #![allow(incomplete_features)] struct S; impl S { reuse <u8>::*; //~ ERROR qualified path without a trait in glob delegation reuse <()>::*; //~ ERROR qualified path without a trait in glob delegation } fn main() {} </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'internal error: entered unreachable code'', 'thread 'rustc' panicked at 'internal error: entered unreachable code'' 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: [resolverforloweringraw] getting the resolver for lowering -- label +F-fndelegation
^_^
Fixed in
Change:
}) => MetaItemKind::list_from_tokens(tokens.clone()), AttrArgs::Delimited(..) => None, AttrArgs::Eq(_, AttrArgsEq::Ast(expr)) => match expr.kind { <del> ast::ExprKind::Lit(token_lit) => Some(MetaItemKind::NameValue( Lit::from_token_lit(token_lit, expr.span).expect("token_lit in from_attr_args"), )), </del> <ins> ast::ExprKind::Lit(token_lit) => { // Turn failures to `None`, we'll get parse errors elsewhere. Lit::from_token_lit(token_lit, expr.span) .ok() .map(|lit| MetaItemKind::NameValue(lit)) } </ins> _ => None, }, AttrArgs::Eq(_, AttrArgsEq::Hir(lit)) => Some(MetaItemKind::NameValue(lit.clone())),

Discussion:
<details<summary<strongBacktrace</strong</summary<p</p</detailsRegression in nightly-2022-11-18 from ()
This makes me wonder if we could just create a superset of a set of chars and feed these into rustc, hmm.
Can we just here?
cc
I'll take a look, thanks for the heads up.
I changed the test input to the following, to avoid an "expected item after attributes" error: With rust 1.64.0 I get these errors: If I change to return if fails, then I get these errors: Do you think that is reasonable behaviour?
Both seem fine, I'd do whatever is simpler to implement.
Change:
#[stable(feature = "rust1", since = "1.0.0")] #[allow(deprecated)] <del> impl<A: Step + One + Clone> Iterator for ops::Range<A> { </del> <ins> impl<A: Step + One> Iterator for ops::Range<A> where for<'a> &'a A: Add<&'a A, Output = A> { </ins> type Item = A; #[inline] fn next(&mut self) -> Option<A> { if self.start < self.end { <del> match self.start.step(&A::one()) { Some(mut n) => { mem::swap(&mut n, &mut self.start); Some(n) }, None => { let mut n = self.end.clone(); mem::swap(&mut n, &mut self.start); Some(n) } } </del> <ins> let mut n = &self.start + &A::one(); mem::swap(&mut n, &mut self.start); Some(n) </ins> } else { None }

Discussion:
I tried printing all valid s by doing and was surprised to find it only printed up to 254. I'm unsure if this is supposed to be this way ( can be used). If so, I'd propose adding this to the Iterators/Ranges section of the book.
The problem is the next method of RangeFrom: It returns the previous value, then updates itself to store the next one. The value 255 ends up being the value that represents a "done" state, so it can't return it. I can't think of any solution that doesn't involve adding a flag to RangeFrom.
Or impl IntoIter instead of Iterator (and use a helper struct to keep track of the range).
Seems similar to .
Question: What is the origin of this Rust behavior, or what is its justification? e.g.: Why an exclusive upper bound on ranges? This caught me by total surprise, coming from Haskell, and I don't know if any Rust I've written for my own cases is wrong now. It behaves differently from similar syntax in Haskell, Swift, and Go, so I'm wondering if it's fruitful to have behavior different from peer languages (in trying to attract people away from languages where syntax like this does not exist.)
Ruby has both exclusive and inclusive ranges
The origin is related to the for-loop idiom in C. corresponds to the range. It has some nice properties such as how it iterates over exactly elements, whereas an inclusive range does and would require you to say, for example, for the indices of a vector if were inclusive. Essentially, it seems like the exclusive behaviour is useful more often than inclusive in a systems language.
Exclusive behaviour is also a leaner implementation. For inclusive behaviour you need some kind of flag for "now yield the inclusive element". This issue is an exact example of why: How do you statefully write an iterator from to , inclusive?
cc , which adjusts this behavior by triggering an overflow on non-wrapped-arithmetic types; it makes the semantics equivalent to repeatedly updating .
so just to be clear, with the above PR merged, now panics. Is this the intended behavior?
Change:
#[inline] pub(super) const fn new_simple_message(m: &'static SimpleMessage) -> Self { // Safety: References are never null. <del> Self(unsafe { NonNull::new_unchecked(m as *const _ as *mut ()) }) </del> <ins> Self(unsafe { NonNull::new_unchecked(m as *const _ as *mut ()) }, PhantomData) </ins> } #[inline]

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: either it to compile or not compile. Instead, this happened: it compiled but only on 64-bit platforms. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Rust 1.59 (where it did not compile no matter what platform) <!-- Provide the version you are using that has the regression. --: <!-- Did the compiler crash? If so, please provide a backtrace. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</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 -- modify labels: +regression-from-stable-to-beta -regression-untriaged
Not sure what the best approach is here. We could just to restore consistency from which made auto-implement . cc
which non-64bit platform does reproduce the issue (not sure if this question matters a lot)?
All platforms that have and . For example, . This is caused by this code:
Ah, should have or something along those lines. I'll get a fix for this up later this evening or tomorrow.
Hmm, this should probably not be closed, unless prioritization will still see it if it is closed.
Yeah, for backports I think the issue stays open until the backport is landed or decided against. Reopened for tracking.
Change:
<ins> // only-wasm32 // compile-flags:-C target-feature=-simd128 // build-pass #![crate_type = "lib"] #[cfg(target_feature = "simd128")] compile_error!("simd128 target feature should be disabled"); // Calling functions with `#[target_feature]` is not unsound on WASM, see #84988 const A: () = simd128_fn(); #[target_feature(enable = "simd128")] const fn simd128_fn() {} </ins>

Discussion:
I tried this code on 1.73: Compiled it with , I expected it to compile fine as on previous 1.72.1, but it gave me these errors: It most recently worked on: 1.72.1 Output: : I read release notes for 1.73 and couldn't find anything that could be related to this, also tried to search for an existing issue about this - no luck. This issue also broke compilation of crate and transitively, Fyrox game engine.
Bisected to . cc
And then this was fixed by (or at least it started compiling since)
Hm, why does it think that the function requires that target feature? That function doesn't have any attribute... Cc
Ah, that's what changed in -- that from a bunch of functions. This was changed in Cc
That was changed in stdarch specifically in response to , to avoid breaking users who were using the already.
In principle we could probably silence this check on wasm, since we document wasm to be a target where calling functions with unsupported target features is safe.
What happens in wasm when you call a function that requires an unavailable target feature?
I am told that the wasm runtime will refuse to even load a module that contains invalid operations, so there are two options: the generated code makes no use of the target feature, and so everything just works the generated code makes use of the target feature, and we don't even ever get to the function call since loading the wasm module already failed
can you check on of the latest nightlies to verify if it works for you? (ref. )
We have a special exception for wasm that allows targetfeature functions to not be marked unsafe: We should probably have the same exception in the target-feature check in the interpreter. do you have the time for a follow-up PR implementing that?
I re-checked on latest nightly and seems to work fine:
I will do that
WG-prioritization assigning priority (). Issue is fixed on nightly+beta, leaving open to follow PR fixing label -I-prioritize +P-medium
In which version this fix will be included?
Should land in stable 1.74 (around mid November), iiuc. See or an
Change:
// compile-fail pub const unsafe fn fake_type<T>() -> T { <del> hint_unreachable() </del> <ins> hint_unreachable() //~ ERROR any use of this value will cause an error </ins> } pub const unsafe fn hint_unreachable() -> ! { <del> fake_type() //~ ERROR any use of this value will cause an error </del> <ins> fake_type() </ins> } trait Const {

Discussion:
Since we have a strange condition in the Miri/interpreter code that checks if a function got called with appropriate arguments: got replaced by . That's really strange, the layout should contain all the information we need for execution, and module boundaries certainly shouldn't matter for the call ABI. So I don't think this change is right, at least not for Miri. Unfortunately, there is 0 explanation of the "why" in that PR and in the code. It also does fix an ICE. Is this a case of running the interpreter on untyped code? Or why does looking at the layout not work? Cc
This is entirely my fault and also entirely unnecessary for fixing the ICE. I just believed this to be a useful cleanup: The reason is that computing the layout in a cached way (via ) requires that we actually have an IndexVec of locals, which we don't have for const prop. The previous code was so if you prefer that, I'm fine with moving there, I just thought it to be better to fix the problem at the layout checking place instead of at the layout computation place.
I'm afraid I disagree with that being a cleanup -- AFAIK the type-based tests exist for surface language stuff, like exhaustiveness check and whatnot, also taking into account semver considerations. But for the interpreter I'd like to be sure that we use the layout information that will also be used by codegen. constprop making a mess for everyone else, again. :( That other code seems okay to me, the comment is confusing though. What does that have to do with "constants being trivial"? And "don't allocate any locals" sounds like we wouldn't make them , which is not at all what this is about. But if that explains that might be empty when we are in constprop, I'd r+ that.
actually, has just made some changes there or is in the process of further changes. We may be able to revert after those changes are through because we'll have an actual stack frame available
That would be great! I thought there were some performance reasons for this.
There were strong performance reasons in the past. We alleviated most of them, but there are some left: not even 2% regression in artificial const eval benchmarks are fine with me for the enormous reduction in code complexity and duplication.

We may be able to find further improvements that help const prop and const eval now that they have started sharing more code.
Besides this issue here, do we carry existing hacks that we can remove with the more well-behaved const_prop?
I think there are some hacks about fallback behaviour on empty stacks
Change:
use syntax_pos::{self, Span, Pos}; use syntax::ast; use syntax::symbol::Symbol; <del> use rustc::ty::layout; </del> <ins> use rustc::ty::layout::{self, LayoutTyper}; </ins> pub mod gdb; mod utils;

Discussion:
Backstory in (comment 16 has dmajor's analysis). In summary: when building on windows, rustc can generate symbol names into the .pdb file that microsoft's DIA library doesn't like. In particular, it can result in calls to to crash with a divide-by-zero. This is a bug in the DIA library which I reported to a friend at Microsoft and which has been fixed. However, older versions of the DIA library still have this problem, so rustc should probably be updated to not generate such symbols. This bug results in the mozilla-central crashing which in turn generates a bad .sym file which causes windows debug tests to blow up. For now I have a workaround patch ready to land that catches the div-by-zero in suggested that if there is some runtime workaround (e.g. setting rustflags or something) that can avoid this problem, we should do that instead - so if there is anything I can try along those lines, please let me know. /cc
Thanks for the report. It looks like we are doing this on purpose for arrays we don't know the size of. I'll try to find out if we can do something else here.
So the real culprit here is the that is assigned to every function. It seems that MSDIA has a problem with fixed-size arrays of or anything zero-sized. Fixed-size arrays of any other type (including , interestingly) are handled without crashes. Here's a table of various types and sizes I've tested: My proposed fix/workaround is to adapt parameter types within , so that fixed-size arrays are replaced with pointers when compiling against MSVC. is anyway, so things don't get worse at least.