jiebi/CodeConvo huggingface dataset:
Change:
pub fn offset(&self, i: usize) -> Size { match *self { <del> FieldPlacement::Union(_) => Size::ZERO, </del> <ins> FieldPlacement::Union(count) => { assert!(i < count, "Tried to access field {} of union with {} fields", i, count); Size::ZERO }, </ins> FieldPlacement::Array { stride, count } => { let i = i as u64; assert!(i < count);

Discussion:
This ICEs on stable, probably since March 2018, but it requires the user to do UB in constants, so... I think a possible fix would be to enable validation in const eval (cc ), though we should benchmark the perf considerations around that first. Alternatively we can just not ICE here and instead emit an error. () Errors:
Interesting. ICEs in Miri with are also bugs, so I'd say doing more validation is not the right call. Do you have a backtrace? Which code is responsible for ICEing here and how hard/bad would it be to just error instead?
It's ICEing in and we could indeed just emit a UB error here, but it seems very... odd, since the field access check has very little to do with UB at a first glance. The layout is a union with zero fields, because it's essentially .
TBH this looks like a bug to me. That's the layout of which type, ? It should have a field, and it should not be a union. Cc
It's not a bug. Just like layout for a newtype with a single field is not a bug (E.g. ).
Precisely by analogy with , I think this is a bug. Your has a with exactly 1 field, matching what is declared. It does not have 2 fields which would be the case if it had a "pair layout". So, transparent layout changes the , but it does not change how many "fields" a type is considered to have. Similarly, has 3 fields in its layout, despite still being a . So, correspondingly, should have 1 field.
oh... right. Yea we should totally fix that
This being a layout bug would trivially break codegen, why is only miri affected?
Codegen might skip the field access because the type is uninhabited?
I wouldn't be so sure, codegen calls on layouts a lot without checking. Can the ICE print the whole ? That might be more useful here. EDIT: oh this might be why: we don't check the index at all:
yea but we can't use because that ICEs during const prop in the array case. I have a local branch that I'm playing with to get the entire picture
You can literally remove the assert to get the same effect.

But if the field count is wrong I'd rather have an assert in both places and fix the count (if possible).
The full is and so far I haven't figured out how that can happen
Ah, nevermind, I found it:
Ah so that's a micro-optimization. Maybe we should compute the right thing.
computes the layout for structs but keeps returning the never layout for enums without inhabited variants
Change:
} } <del> impl<'a, K, V> IntoIterator for &'a mut VecMap<K, V> { </del> <ins> impl<'a, K: 'a, V: 'a> IntoIterator for &'a mut VecMap<K, V> { </ins> type Item = (&'a K, &'a mut V); type IntoIter = impl Iterator<Item = Self::Item>;

Discussion:
() I would’ve expected rustc to complain about the not matching the with a suggestion to turn it into . modify labels: A-typesystem, A-lifetimes, A-traits, A-impl-trait, F-typealiasimpl_trait, T-compiler, requires-nightly and someone please add “I-unsound ” (and/or tell me if there is a way to do it myself).
One thing that is of note here is that we properly enforce type bounds, but not lifetime bounds, as the equivalent program with types fails to compile right where we expect that:
Aha! If we change to have an explicit bound, then we get the right error: so we're just missing a check of the implied bounds on the impl
Change:
<ins> error[E0277]: the trait bound `MyStruct: std::default::Default` is not satisfied --> $DIR/issue-59435.rs:11:5 | LL |     type MyType: Default; |     --------------------- required by `MyTrait::MyType` ... LL |     default type MyType = MyStruct; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `std::default::Default` is not implemented for `MyStruct` error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>

Discussion:
This snippet is found in . Reduced: :
Nitpick: There's no need to put the two into different functions, you can put them both in .
Like , when using an anonymous binding (), the above code :
No longer ICEs since

With specialization, it is possible to define a default associated type that does not fulfill its trait bounds. Here is a minimal example, that surely should not compile, but does with rustc 1.35.0-nightly: Unsurprisingly, adding the main function causes an ICE. Error message and backtrace (compiled at the playground):
Triage: the latest nightly rejects the code, marking as E-needs-test.

This code generates an ICE with this message. Replacing by makes the code to compile and run fine, which is strange because ! does not implements . By removing the specialization the compiler refuses to compile the code with the error:
The ICE has been fixed in the latest nightly, marked as E-needstest
Thanks Indeed, the example compiles fine in nightly ( 2019-11-12), however, replacing the main function by these two generates the same ICE.
ah, thanks for the update! I confirmed it ()
Triage: the ICE doesn't occur anymore with the latest nightly, marking as E-needs-test.

I was attempting to figure out the feature landscape for , and I found this ICE when playing with it and specialization:
The given code builds fine on current nightly.
This is still an ICE on current nightly when not .
This code compiles without a problem whether I do or using current nightly: . Tested on Windows 10 x64 and Ubuntu x64.
Really? But on the playground, the ICE still appears. Can you check the above link?
Yes, I get an ICE in the playground when I just build.
It does ICE when using instead of .
You need or , not . It seems like a still ICE to me.
Triage: the latest nightly rejects the code without an ICE. Marking as E-needs-test.
Change:
debug!("impossible_predicates(predicates={:?})", predicates); let result = tcx.infer_ctxt().enter(|infcx| { <del> // HACK: Set tainted by errors to gracefully exit in case of overflow. infcx.set_tainted_by_errors(); </del> let param_env = ty::ParamEnv::reveal_all(); let ocx = ObligationCtxt::new(&infcx); let predicates = ocx.normalize(ObligationCause::dummy(), param_env, predicates);

Discussion:
should be to guarantee that we emit an error when that flag is set. This is already done for of other types in rustc. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
renamed to to keep consistent.
Change:
if mode::is_dyn_thread_safe() { let oper_a = FromDyn::from(oper_a); let oper_b = FromDyn::from(oper_b); <del> let (a, b) = rayon::join( move || FromDyn::from(oper_a.into_inner()()), move || FromDyn::from(oper_b.into_inner()()), ); (a.into_inner(), b.into_inner()) </del> <ins> let (a, b) = parallel_guard(|guard| { rayon::join( move || guard.run(move || FromDyn::from(oper_a.into_inner()())), move || guard.run(move || FromDyn::from(oper_b.into_inner()())), ) }); (a.unwrap().into_inner(), b.unwrap().into_inner()) </ins> } else { super::disabled::join(oper_a, oper_b) }

Discussion:
found while checking with When you run the snipped above with , rustc panics, but the exit status is as if there was just a normal compiler error, instead of a . This tripped up automatic ice-reduction that relies on a somewhat familiar exit code when the program crashes :sweat_smile:
is the problematic line here that turns ICEs into "normal" fatal errors that call exit(1) though actually at least with the non parallel compiler i'm very surprised that we're ending up in a query in the first place after panicking.
It seems that current stable does correctly exit with here... I bisected the exit code 101 -exit code 1 change with a crashing file ( ) and got to Regression in nightly-2023-08-31 Regression in cc /
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
} fn lower_stmt(&mut self, s: &Stmt) -> SmallVec<[hir::Stmt; 1]> { <del> smallvec![match s.node { </del> <ins> let node = match s.node { </ins> StmtKind::Local(ref l) => { let (l, item_ids) = self.lower_local(l); let mut ids: SmallVec<[hir::Stmt; 1]> = item_ids

Discussion:
See:
for future reference: is referencing my PR which changed the r-value temporary rules with respect to the temporaries in the of
Even beside the part the loop desugaring is so complex. It would be nice to document what every employed trick changes compared to the naive desugaring.
PR itself was motivated (or at least spawned off of) PR . I'm actually trying to find out what the actual motivation for the described change was. The change, as described, was that the temporaries within would previously live until the end of the enclosing block. So if you consider the following code (): which, when it is accepted by the compiler (as written it requires NLL), it should print this: notably, we drop all of {, , } immediately after the for-statement, but before the at the end of the block. The breakage I would be concerned about, if we made for-loops no longer a terminating scope for their , is that all of the temps would live until the end of the block, and thus the drops of {, , } would happen after the "end of enclosing block", which would be an observable change. has relayed to me in private conversation that they tried examples like this under variants of their desugaring and did not witness any change in behavior. Our best guess as to why this is, is because the desugaring is, in the end, turning into a which is itself a terminating scope for the temporaries in the -input, and so you don't need to recreate such an effect by other means.
Note: it is nonetheless possible that the distinction here is more subtle and my above example isn't quite right. in particular, I'm a little worried that there may have been a reason that the example from PR puts the for-expression in the tail expression of a block, and that examples that don't take similar care might fail to pick up on a relevant distinction here...
Change:
_0 = const 3_i32;                // scope 0 at $DIR/match-arm-scopes.rs:15:59: 15:60 StorageDead(_10);                // scope 0 at $DIR/match-arm-scopes.rs:15:72: 15:73 StorageDead(_9);                 // scope 0 at $DIR/match-arm-scopes.rs:15:77: 15:78 <del> -         goto -> bb23;                    // scope 0 at $DIR/match-arm-scopes.rs:1:1: 1:1 +         goto -> bb20;                    // scope 0 at $DIR/match-arm-scopes.rs:1:1: 1:1 </del> <ins> -         goto -> bb23;                    // scope 0 at no-location +         goto -> bb20;                    // scope 0 at no-location </ins> } -     bb10: {

Discussion:
Sysroot has been compiled using to get set. Otherwise it is hard to guess a defid with encoded mir, now it is just taking the first exported symbol from:
I used to read the mir.
I think these are and printed as . If so it would be less confusing if the debug impl of would say or something like that instead.
I'm unsure how to reproduce the environment to reproduce this bug. It's easy to adjust the debug printing for , but without a test for that I'm not sure how to test it
Change:
<ins> const fn f<T>(_: Box<T>) {} //~^ ERROR destructors cannot be evaluated at compile-time fn main() {} </ins>

Discussion:
() Note that this works even if implements in a non- way. This seems hightly problematic, especially provided we eventually want to support constructing at compile time. Relevant PR: Of course that impl claims to be unstable, but as we all know trait implementations are never unstable, unless the trait is unstable. (For ordinary traits, implementations of are thus unstable merely due to the fact that no user can use any such implementations in stable code yet.) label regression-from-stable-to-stable The fix should be straightforward: Remove the implementation (i.e. revert it to be non-), and add a test.
cc
that impl should be illegal, shouldn't it? I would expect us to need an explicit here. But also, reverting and maybe even backporting that impl for now seems like the right choice to me
Good catch! Actually calling this leads to odd behavior: It doesn't even say what went wrong. I expected an error saying a non-const function was called as part of the drop glue.
Change:
) { let tcx = self.tcx(); let trait_ref = cache_fresh_trait_pred.skip_binder().trait_ref; <ins> if !self.can_cache_candidate(&candidate) { debug!("insert_candidate_cache(trait_ref={:?}, candidate={:?} - candidate is not cacheable", trait_ref, candidate); return; } </ins> if self.can_use_global_caches(param_env) { if let Err(Overflow) = candidate { // Don't cache overflow globally; we only produce this

Discussion:
When using the nightly with the bugfix for the problems with , this error happens when trying to document the crate: note: rustc 1.31.0-nightly ( 2018-10-01) running on x86_64-apple-darwin
cc: FYI
it seemed to document fine for me on the most recent nightly build
This is fixed as of
Closing then! Thanks! :D
Will this need backporting at all?
Change:
<ins> // Regression test for #69378: no type for node after struct parse recovery struct Foo { 0: u8 } //~ ERROR expected identifier fn test(f: Foo) { Foo{foo: 4, ..f}; } fn main() {} </ins>

Discussion:
I'm seeing an internal compiler error on the following input (found by ): The error happens on , , and .
I'm looking into this! But mostly as a learning exercise. Spent ~4 hours exploring typeck & error handling today to see why this exact combination of things triggers an error. My friend and I will probably have a solution at some point, but it might be a few weeks from now. If anyone has a good & quick solution, or if it is deemed high-priority, then feel free to ignore me.
~According to , this regressed between 2019-07-30 and 2019-07-31. Unfortunately, seems to be incapable of narrowing it down to a commit because that was more than 167 days ago.~ EDIT: gave me a misleading result. This error is at least as old as .
This error started happening in cc
The ICE goes away if I apply this patch: (Though I'd guess that making this change would cause us to regress on the problems that fixed.)
This change fixes the ICE and avoids regressing on : I'm unsure whether this respects the intended meaning of , though.
on a very cursory look that patch looks reasonable.
has some additional relevant context.
Unfortunately, the patch that I proposed above fails on this modification of :
triage: P-high. Removing nomination. Added regression stable-to-stable tag.
I think I found a way to resolve this without regressing on . The point of this PR is to not emit an error if it might be invalid to the user. But there are errors in context still. The patch I propose is this: This does pass every UI test. I'll open a PR so this can be discussed more easely.
Change:
TyKind::Infer } else if self.check_fn_front_matter(false, Case::Sensitive) { // Function pointer type <del> self.parse_ty_bare_fn(lo, Vec::new(), recover_return_sign)? </del> <ins> self.parse_ty_bare_fn(lo, Vec::new(), None, recover_return_sign)? </ins> } else if self.check_keyword(kw::For) { // Function pointer type or bound list (trait object type) starting with a poly-trait. //   `for<'lt> [unsafe] [extern "ABI"] fn (&'lt S) -> T` //   `for<'lt> Trait1<'lt> + Trait2 + 'a` let lifetime_defs = self.parse_late_bound_lifetime_defs()?; if self.check_fn_front_matter(false, Case::Sensitive) { <del> self.parse_ty_bare_fn(lo, lifetime_defs, recover_return_sign)? </del> <ins> self.parse_ty_bare_fn( lo, lifetime_defs, Some(self.prev_token.span.shrink_to_lo()), recover_return_sign, )? </ins> } else { let path = self.parse_path(PathStyle::Type)?; let parse_plus = allow_plus == AllowPlus::Yes && self.check_plus();

Discussion:
Newcomers might attempt to write a “generic” function pointer like . In such case, the compiler should provide a better error message. Inspired by a recent Reddit thread I sadly cannot find anymore. Given the following code: The compiler should mention that function pointers may not be generic or […] may not have generic parameters, suggest to move the lifetime(s) to a parameter list (this should be machine-applicable in my judgement) and be able to recover: For later reference, the current output is: Given the following code: The compiler should mention that function pointers may not be generic or […] may not have generic parameters and be able to recover emitting two diagnostics, one for each line. The compiler could also suggest moving the generic parameter list further up to the owning function, struct, etc. if available. Note that this might not be what the user intended (since there is a semantic difference between hypothetical higher-ranked generics and normal ones) and therefore shouldn't be machine-applicable. For later reference, the current output is: label A-parser A-suggestion-diagnostics D-newcomer-roadblock <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
envp: Option<&CStringArray>, ) -> io::Result<Option<Process>> { use crate::mem::MaybeUninit; <del> use crate::sys; </del> <ins> use crate::sys::{self, cvt_nz}; </ins> if self.get_gid().is_some() || self.get_uid().is_some()

Discussion:
In libstd/sys/unix there are numerous cases where return code is checked for error using following pattern: That means, that error checking is performed only when compiled in non-optimized mode or after explicitly enabling debug assertions. This is a little bit worrying, especially when used on platforms where those functions can indeed fail and break safety.
(For anyone who was confused by the given example, pthreadmutexattrinit can fail with ENOMEM.)
On some platforms types like pthreadmutext, pthreadcondt, etc., are "fat" structures that have sufficient size to hold everything necessary and their initialization will never fail (unless initialized incorrectly). But on others they are opaque pointers to and require an additional memory allocation. Search for those typedefs in libc crate, gives a rough approximation of affected platforms. Sadly this also affects static mutexes, so even lock / unlock could potentially fail. Either way you could end up with a mutex which is not mutually exclusive at all.
When mutex initialization fails this leads to non-functioning mutex and unsoundness. The pthreadmutexlock might also fail for recursive mutexes used in std::io and cause a mismatch in the number of locks / unlocks, but one needs to go out of the way to cause that. modify labels: C-bug I-unsound
Change:
<del> // Regression test for #130310 // Tests that we do not fall into infinite // recursion while checking FFI safety of // recursive types like `A<T>` below //@ build-pass use std::marker::PhantomData; #[repr(C)] struct A<T> { a: *const A<A<T>>, // Recursive because of this field p: PhantomData<T>, } extern "C" { fn f(a: *const A<()>); //~^ WARN `extern` block uses type `*const A<()>`, which is not FFI-safe } fn main() {} </del>

Discussion:
The windows-rs crate is getting a whole bunch of spurious FFI-safe warnings: See: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc which introduced the recursion limit.
Repro:
Anyways I'll put up a revert PR claim
Change:
<ins> // https://github.com/rust-lang/rust/issues/130591 #![deny(rustdoc::broken_intra_doc_links)] #![crate_name = "foo"] /// [value@Foo::X] //~ERROR broken pub enum Foo { X, } /// [tst][value@MyStruct] //~ERROR broken pub struct MyStruct; pub enum MyEnum { Internals, } pub use MyEnum::*; /// In this context, [a][type@Internals] is a struct, /// while [b][value@Internals] fails. //~ERROR broken /// Also, [c][struct@Internals] is a struct, /// while [d][variant@Internals] fails. //~ERROR broken pub struct Internals { foo: (), } pub mod inside { pub struct Internals2; } use inside::*; /// In this context, [a][type@Internals2] is an enum, /// while [b][value@Internals2] fails. //~ERROR broken pub enum Internals2 {} </ins>

Discussion:
I'm probably planning on working on this, I found it while I was working on . The issue is that rustdoc looks up in the value namespace, which returns a Ctor, not a Variant. Turns out giving doc comments unimpeded access to the rustc resolver might not be a perfect idea This seems slightly (but not very) tricky to fix, mainly an ironing out of semantics - do we pretend that in the value namespace doesn't exist? Or do we let you reference it, but taking care not to say that there's a conflict between (the constructor) and (the variant) and that you have to disambiguate 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. --(current master): <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
i'm not sure why we would want this - you can't document the constructor separately from the variant, so i would expect rustdoc to hide it from intra-doc links
(or alternatively we could make an alias for )
First of all, I can reproduce this problem with a unit-like struct. Second of all, This is an observable fact. To see it, use glob exports. Most crates probably won't do this... but most crates probably won't need disambiguators at all. These things are in the value namespace, and that's a fact that can be observed in the surface language, so we probably shouldn't pretend otherwise.
Change:
<del> use run_make_support::{htmldocck, rustc, rustdoc, source_path, tmp_dir}; </del> <ins> use run_make_support::{htmldocck, rustc, rustdoc, source_root, tmp_dir}; </ins> use std::fs::read_dir; use std::path::Path;

Discussion:
Some run-make tests refer to stdlib sources with which seems not ideal. suggested that we should introduce a helper to make this less fragile.
There is already the env var set by compiletest for the source root.
I'm actually dumb, we even already have in the support library:
That's a very descriptive environment variable name, lol
Change:
pub fn as_unsafe_cell(&self) -> &UnsafeCell<T> { &self.value } <ins> /// Returns a mutable reference to the underlying data. /// /// This call borrows `Cell` mutably (at compile-time) which guarantees /// that we possess the only reference. #[inline] #[unstable(feature = "cell_get_mut", issue = "33444")] pub fn get_mut(&mut self) -> &mut T { unsafe { &mut *self.value.get() } } </ins> } #[stable(feature = "rust1", since = "1.0.0")]

Discussion:
These methods allow one to obtain a mutable reference to the interior of these cells if you have a mutable reference to the cells themselves.
As stated in , I think that a better name for these methods would be .
This issue is now entering its final comment period for stabilization The libs team was unfortunately a little late on stabilizations this cycle, but we're thinking of probably doing a backport of stabilizations partway through the beta cycle. This API also follows existing conventions so should be an easy stabilization!
Looking through the naming convention again, it seems that is only used for conversions or functions that are not cheap or free, e.g. accessing elements of containers, slices, checking the poisoning state of a mutex and returning the element (with the exception of , which isn't stabilized yet). However, is often used for this kind of conversion, e.g. . I don't think fits here.
Ah yes I forgot to mention, but the libs team did indeed discuss the name and concluded that is the convention here. The prefix is used for containers such as vectors, maps, I/O wrappers, synchronization primitives, etc. The prefix is intended for conversions. Because these are "containers" and these methods aren't performing conversions, we concluded the appropriate name was
The libs team discussed this issue during triage yesterday and the decision was to stabilize. We realize that the FCP for this issue was pretty short, however, so please comment with any objections you might have! We're very willing to backport an un-stabilization for the few APIs we have this cycle.