jiebi/CodeConvo huggingface dataset:
Change:
// At this point, the field's type is known to be nonnull and the parent enum is Option-like. // If the computed size for the field and the enum are different, the nonnull optimization isn't // being applied (and we've got a problem somewhere). <del> let compute_size_skeleton = |t| SizeSkeleton::compute(t, tcx, param_env).unwrap(); if !compute_size_skeleton(ty).same_size(compute_size_skeleton(field_ty)) { </del> <ins> let compute_size_skeleton = |t| SizeSkeleton::compute(t, tcx, param_env).ok(); if !compute_size_skeleton(ty)?.same_size(compute_size_skeleton(field_ty)?) { </ins> bug!("improper_ctypes: Option nonnull optimization not applied?"); }

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:
<ins> // This test checks that there is no ICE with this code // // check-pass // compile-flags:--check-cfg=names() -Z unstable-options fn main() { #[cfg(crossbeam_loom)] //~^ WARNING unexpected `cfg` condition name {} } </ins>

Discussion:
ICE encountered in a , will post more details when i trace it further:
I am able to reproduce the issue with this code and : And it's combination of ("introduce" the ICE, preexisting issue) and (trigger the lint which trigger the ICE).
Further reduced to:
Change:
"prim" | "primitive" => Primitive, _ => return Err((format!("unknown disambiguator `{prefix}`"), 0..idx)), }; <ins> for (suffix, kind) in suffixes { if let Some(path_str) = rest.strip_suffix(suffix) { if d.ns() != Kind(kind).ns() { return Err(( format!("unmatched disambiguator `{prefix}` and suffix `{suffix}`"), 0..idx, )); } else if path_str.len() > 1 { // path_str != "@" return Ok(Some((d, &path_str[1..], &rest[1..]))); } } } </ins> Ok(Some((d, &rest[1..], &rest[1..]))) } else { <del> let suffixes = [ // If you update this list, please also update the relevant rustdoc book section! ("!()", DefKind::Macro(MacroKind::Bang)), ("!{}", DefKind::Macro(MacroKind::Bang)), ("![]", DefKind::Macro(MacroKind::Bang)), ("()", DefKind::Fn), ("!", DefKind::Macro(MacroKind::Bang)), ]; </del> for (suffix, kind) in suffixes { if let Some(path_str) = link.strip_suffix(suffix) { // Avoid turning `!` or `()` into an empty string

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. --Occurs on stable + nightly : : i replaced backtrace with for readability since it's displayed without any flags: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
The combination of course seems invalid, but the compiler shouldn't panic, right?
That was quick, thank you!
Change:
unsafe fn spawn_unchecked_<'a, 'scope, F, T>( self, f: F, <del> scope_data: Option<&'scope scoped::ScopeData>, </del> <ins> scope_data: Option<Arc<scoped::ScopeData>>, </ins> ) -> io::Result<JoinInner<'scope, T>> where F: FnOnce() -> T,

Discussion:
The following code sometimes causes a data race to be reported by Miri: Miri reports: The deallocation occurs when returns and its local variable gets deallocated. The read occurs here (I am fairly sure): This reads the contents of the field after the . But the moment the is done, the memory backing might be deallocated. That makes the read a potential use-after-free, and a race with the deallocation. Cc
The following patch fixes this: However, even with this patch, we still run into a problem like the gets deallocated while still runs. This is still UB even after my proposed because contains a field that is not inside an (the field). So that part of what points to is expected to stay live for the entire duration of the function call. Another alternative might be to put the entire into an rather than allocating it on the stack frame of .
Going to attach this to the 1.63 milestone, since this is in a newly stabilized feature -- we may wish to back out stabilization for a cycle or backport fixes.
Re-opening for beta backport.
The fix was backported in .
Change:
more" match. Both forms optionally include a separator, which can be any token except `+` or `*`. <ins> This system is based on "[Macro-by-Example](http://www.cs.indiana.edu/ftp/techreports/TR206.pdf)" (PDF link). </ins> # Hygiene Some languages implement macros using simple text substitution, which leads to

Discussion:
As of the original docs on recursive macros are gone. We should have an example that clearly illustrates the increased power vs. the built-in repetition operator.
Change:
const LEFT: u32 = 0x10000b3u32.rotate_left(8); const RIGHT: u32 = 0xb301u32.rotate_right(8); <ins> // Rotating these should make no difference // // We test using 124 bits because to ensure that overlong bit shifts do // not cause undefined behaviour. See #10183. const LEFT_OVERFLOW: i16 = 0i16.rotate_left(124); const RIGHT_OVERFLOW: i16 = 0i16.rotate_right(124); const ONE_LEFT_OVERFLOW: u16 = 1u16.rotate_left(124); const ONE_RIGHT_OVERFLOW: u16 = 1u16.rotate_right(124); const NON_ZERO_LEFT_OVERFLOW: u16 = 0b10u16.rotate_left(124); const NON_ZERO_RIGHT_OVERFLOW: u16 = 0b10u16.rotate_right(124); // Rotating by 0 should have no effect const ZERO_ROTATE_LEFT: i8 = 0b0010_0001i8.rotate_left(0); const ZERO_ROTATE_RIGHT: i8 = 0b0111_1001i8.rotate_right(0); // Rotating by a multiple of word size should also have no effect const MULTIPLE_ROTATE_LEFT: i32 = 0b0010_0001i32.rotate_left(128); const MULTIPLE_ROTATE_RIGHT: i32 = 0b0010_0001i32.rotate_right(128); </ins> fn ident<T>(ident: T) -> T { ident } fn main() { assert_eq!(LEFT, ident(0xb301)); <del> assert_eq!(RIGHT, ident(0x10000b3)); </del> <ins> assert_eq!(RIGHT, ident(0x0100_00b3)); assert_eq!(LEFT_OVERFLOW, ident(0)); assert_eq!(RIGHT_OVERFLOW, ident(0)); assert_eq!(ONE_LEFT_OVERFLOW, ident(0b0001_0000_0000_0000)); assert_eq!(ONE_RIGHT_OVERFLOW, ident(0b0001_0000)); assert_eq!(NON_ZERO_LEFT_OVERFLOW, ident(0b0010_0000_0000_0000)); assert_eq!(NON_ZERO_RIGHT_OVERFLOW, ident(0b0000_0000_0010_0000)); assert_eq!(ZERO_ROTATE_LEFT, ident(0b0010_0001)); assert_eq!(ZERO_ROTATE_RIGHT, ident(0b0111_1001)); assert_eq!(MULTIPLE_ROTATE_LEFT, ident(0b0010_0001)); assert_eq!(MULTIPLE_ROTATE_RIGHT, ident(0b0010_0001)); </ins> }

Discussion:
The following code ICEs when compiled with a rustc with debug-assertions enabled: The problem is in the implementation of , specifically in this line: The subtraction overflows here. Cc
Fix should be:
Ya I'll take this on :+1:
awesome! above already pretty much gave the mentoring instructions, except for one thing: please also add a test case. Or rather, please extend the existing test case at . Let me know if you need any more assistance.
looks like you are both on this now? Not sure how that happened...
Change:
found type `{integer}` error[E0308]: mismatched types <del> --> $DIR/return-ty-mismatch-note.rs:8:9 </del> <ins> --> $DIR/return-ty-mismatch-note.rs:9:9 </ins> | LL | fn g<U, V>() -> (U, V) { |         - expected this type parameter

Discussion:
The statement "the caller chooses a type for which can be different from " is confusing because and are always different. I think it would be best to supress that note when the types only differ in reference-ness. The message was introduced in . No response No response
label +D-confusing
Thanks, that note definitely doesn't make sense. CC (). I suggested to move out of in order to catch more cases but that was a bit too aggressive as can be witnessed here — that's on me. We should replicate some parts of , namely checking that the type param in question does not occur in the return expression type. That did cross my mind back then but I didn't really follow up on that thought for some reason.
Thanks for the cc I'll take a look ~today/tomorrow
Opened to avoid making the note if found return type contains the expected return type (type parameter).
Change:
assert-css: ("#method.must_use", {"color": "rgb(197, 197, 197)", "background-color": "rgba(255, 236, 164, 0.06)"}, ALL) goto: file://|DOC_PATH|/test_docs/index.html <del> assert-css: (".section-header a", {"color": "rgb(197, 197, 197)"}, ALL) </del> <ins> assert-css: (".small-section-header a", {"color": "rgb(197, 197, 197)"}, ALL) goto: file://|DOC_PATH|/test_docs/struct.HeavilyDocumentedStruct.html assert-css: (".section-header a", {"color": "rgb(57, 175, 215)"}, ALL) </ins> // Dark theme local-storage: {"rustdoc-theme": "dark", "rustdoc-preferred-dark-theme": "dark", "rustdoc-use-system-theme": "false"}

Discussion:
They used to be blue and are now black. I don't think this change was intentional, although we have been thinking about migrating more headers to be black recently. I think this regressed very recently, since I probably would have noticed it otherwise. !
I wonder if this was caused by or ? Those were both merged recently, though the second one doesn't seem like it could have changed colors. cc
This regressed in , which as one of the rules for an anchor to be styled black. The goal with that change was to make the section headings on module pages black (e.g. ). Those have . However, headings generated from Markdown in a docblock also have . I think the right short-term fix is: Section headings on module pages get , like their peers on other pages. Remove the CSS rule for to be black. It's not really clear to me why Markdown gets , and Rustdoc-generated headings get , particularly given that the Rustdoc headings are almost always bigger. Probably we should rename these to and .
Since you figured out a way to fix this regression, do you want to assign yourself and open a PR with the fix?
Will do.
Change:
<ins> error[E0412]: cannot find type `Missing` in this scope --> $DIR/issue-110157.rs:6:12 | LL |     F: Fn(&Missing) -> Result<I, ()>, |            ^^^^^^^ not found in this scope error[E0412]: cannot find type `Missing` in this scope --> $DIR/issue-110157.rs:8:24 | LL |     I: Iterator<Item = Missing>, |                        ^^^^^^^ not found in this scope error[E0283]: type annotations needed --> $DIR/issue-110157.rs:3:31 | LL | impl<'tcx, F, I> Iterator for NeedsDropTypes<'tcx, F> |                               ^^^^^^^^^^^^^^^^^^^^^^^ cannot infer type for type parameter `I` | = note: cannot satisfy `_: Iterator` note: required for `NeedsDropTypes<'tcx, F>` to implement `Iterator` --> $DIR/issue-110157.rs:3:18 | LL | impl<'tcx, F, I> Iterator for NeedsDropTypes<'tcx, F> |                  ^^^^^^^^     ^^^^^^^^^^^^^^^^^^^^^^^ ... LL |     I: Iterator<Item = Missing>, |        ------------------------ unsatisfied trait bound introduced here error: aborting due to 3 previous errors Some errors have detailed explanations: E0283, E0412. For more information about an error, try `rustc --explain E0283`. </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
Correction: () (cc I'm not sure I'll be able to figure it out. searched nightlies: from nightly-2022-06-01 to nightly-2023-04-11 regressed nightly: nightly-2023-03-11 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Change:
CFG_LLC_FLAGS_i686-unknown-linux-gnu := CFG_INSTALL_NAME_i686-unknown-linux-gnu = CFG_LIBUV_LINK_FLAGS_i686-unknown-linux-gnu = <del> CFG_LLVM_BUILD_ENV_i686-unknown-linux-gnu="CXXFLAGS=-fno-omit-frame-pointer" </del> CFG_EXE_SUFFIX_i686-unknown-linux-gnu = CFG_WINDOWSY_i686-unknown-linux-gnu := CFG_UNIXY_i686-unknown-linux-gnu := 1

Discussion:
We currently build C++ code and Rust with frame pointers on, though we don't actually use them for anything (intended for GC). This is overhead that C and C++ don't usually have so it would be nice to turn on elimination.
I think we'll need them for gc, fwiw
on Linux x86_64 we should be using the DWARFv3 Call Frame Information for walking the stack, although I have no idea if we're emitting it correctly right now (likely on OS X and FreeBSD too). We might be, because gdb uses it and seems to work.
We'll leave it off until we have solutions for GC, which will probably end up being platform specific. libunwind should make it easy on linux and freebsd.
Reopening because this caused a regression in , so reverted in
Change:
} fn parent() { <del> let file = File::open("Makefile").unwrap(); </del> <ins> let file = File::open(file!()).unwrap(); </ins> let tcp1 = TcpListener::bind("127.0.0.1:0").unwrap(); let tcp2 = tcp1.try_clone().unwrap(); let addr = tcp1.local_addr().unwrap();

Discussion:
Under rustbuild no needs to exist, and this test tries to open that file. The test should be changed to open something else, preferably not a file on filesystem.
How about opening the test source file itself?
Change:
if self.missing_lifetimes() { "lifetime" } else { "generic" } } <ins> /// Returns true if the generic type is a trait /// and is being referred to from one of its trait impls fn is_in_trait_impl(&self) -> bool { if self.tcx.is_trait(self.def_id) { // Here we check if the reference to the generic type // is from the 'of_trait' field of the enclosing impl let parent = self.tcx.hir().get_parent(self.path_segment.hir_id); let parent_item = self .tcx .hir() .get_by_def_id(self.tcx.hir().get_parent_item(self.path_segment.hir_id).def_id); // Get the HIR id of the trait ref let hir::Node::TraitRef(hir::TraitRef { hir_ref_id: trait_ref_id, .. }) = parent else { return false; }; // Get the HIR id of the 'of_trait' field of the impl let hir::Node::Item(hir::Item { kind: hir::ItemKind::Impl(hir::Impl { of_trait: Some(hir::TraitRef { hir_ref_id: id_in_of_trait, .. }), .. }), .. }) = parent_item else { return false; }; // Check that trait is referred to from the of_trait field of impl trait_ref_id == id_in_of_trait } else { false } } </ins> fn num_provided_args(&self) -> usize { if self.missing_lifetimes() { self.num_provided_lifetime_args()

Discussion:
The suggestion is not valid syntax. Applying the original suggestion like so: to this error instead: Note also that a more naive suggestion to keep the parameter like so: fail because it's unconstrained: needs to be a concrete type or an associated type of an input type parameter. The diagnostic is identical in beta and nightly. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
<ins> // Copyright 2015 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. #[repr(C)] pub struct Foo(u32); // ICE trigger, bad handling of differing types between rust and external ABIs pub extern fn bar() -> Foo { Foo(0) } fn main() {} </ins>

Discussion:
Repro: ICE:
tracks a number of cases that throw the same error.
A couple of hints - it looks like it happens when structure size is actually smaller or equal to register of architecture. I had the similar report for failing on iOS with the following sample: It fails on and if + <= 64 bits, i.e. they are u16 or u32. When switching to armv7 it fails if + <= 32 bits
after 6 hours bisecting the verdict is - , part of
sigh I actually saw that when I was working on but didn't come up with a test case that would trigger a problem here and then forgot about it. Will look into this.
will fix hit the upcoming beta?
Sorry, fixing a few regressions in LLVM that affected rust had higher priority for me than this issue (because LLVM is very close to its 3.6 release), so I couldn't devote much time to this issue yet. But given that the beta is still ~3 weeks away, I'm positive that I'll get around to have it fixed by then.
Hmm, beta is on week of Feb 16 (i.e. next week), isn't it?
Yes. Although, as someone hitting that bug, I'd be okay if that were flagged as a known bug and would prefer if semantic issues were cared about first.
I have nothing against fixing regressions, still be extremely happy to see it fixed as I will be stuck on beta1 following 6 weeks till beta2 or rc1.
:tada: thanks a lot!
Change:
<ins> error: vtable entries for `<S as A>`: [ MetadataDropInPlace, MetadataSize, MetadataAlign, Method(<S as T>::method), ] --> $DIR/multiple-markers.rs:21:1 | LL | trait A: M0 + M1 + M2 + T {} | ^^^^^^^^^^^^^^^^^^^^^^^^^ error: vtable entries for `<S as B>`: [ MetadataDropInPlace, MetadataSize, MetadataAlign, Method(<S as T>::method), TraitVPtr(<S as M2>), ] --> $DIR/multiple-markers.rs:24:1 | LL | trait B: M0 + M1 + T + M2 {} | ^^^^^^^^^^^^^^^^^^^^^^^^^ error: vtable entries for `<S as C>`: [ MetadataDropInPlace, MetadataSize, MetadataAlign, Method(<S as T>::method), TraitVPtr(<S as M1>), TraitVPtr(<S as M2>), ] --> $DIR/multiple-markers.rs:27:1 | LL | trait C: M0 + T + M1 + M2 {} | ^^^^^^^^^^^^^^^^^^^^^^^^^ error: vtable entries for `<S as D>`: [ MetadataDropInPlace, MetadataSize, MetadataAlign, Method(<S as T>::method), TraitVPtr(<S as M0>), TraitVPtr(<S as M1>), TraitVPtr(<S as M2>), ] --> $DIR/multiple-markers.rs:30:1 | LL | trait D: T + M0 + M1 + M2 {} | ^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to 4 previous errors </ins>

Discussion:
While working on I think I found a bug. Given this program: rustc outputs the following vtable layout: Which is surprising, because is unnecessary — does not have any methods, so vtable can be inlined... I think we should be smarter here: (for the record, I'm pretty sure this happens in practice, I've found this with ) Originally posted by in
cc
sorry been slow a little recently... This is a nice improvement.
Change:
// PTHREAD_STACK_MIN bytes big.  Windows has no such lower limit, it's // just that below a certain threshold you can't do anything useful. // That threshold is application and architecture-specific, however. <del> // Round up to the next 64 kB because that's what the NT kernel does, // might as well make it explicit. let stack_size = (stack + 0xfffe) & (!0xfffe); </del> let ret = c::CreateThread( ptr::null_mut(), <del> stack_size, </del> <ins> stack, </ins> thread_start, p as *mut _, c::STACK_SIZE_PARAM_IS_A_RESERVATION,

Discussion:
The following code states that rounds up to the next 64 kB: However, if is any of (where x is a non-negative number) it will not properly round up. Additionally, the least significant byte is retained, I doubt that is intended either. Am I missing something? Otherwise I believe it's meant to be instead of to properly round up. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
To be honest, I think this line may as well be removed. As the comment says, the OS will do the rounding up in any case. And as the : So 64 KB isn't technically guaranteed. I'm not sure there's anything to be gained by doing the rounding up ourselves.
label +O-windows +T-libs
claim
Change:
continue; } <ins> if let Some(parent_def_id) = self.tcx.parent(def_id) { if let Some(parent_hir_id) = self.tcx.hir() .as_local_hir_id(parent_def_id) { // lifetimes in `derive` expansions don't count (Issue #53738) if self.tcx.hir().attrs_by_hir_id(parent_hir_id).iter() .any(|attr| attr.check_name(sym::automatically_derived)) { continue; } } } </ins> let mut err = self.tcx.struct_span_lint_hir( lint::builtin::SINGLE_USE_LIFETIMES, id,

Discussion:
When compiling this warning is generated: I think, in the derive does not consider this lint.
I tried to in the compiler but hit this bug, which makes it a non-starter. I'd almost change built-in deriving to not declare the lifetimes explicitly but I suspect that wouldn't work when using nested within a block where the shadowing from explicitness would be useful. (That's assuming built-in deriving actually uses these lifetimes in bounds, otherwise it could just use ) cc
cc
I don't think this seems high priority. I'll leave it nominated but I'm prioritizing it as P-medium.
The problem is that the above code expands to something similar to which correctly warns for the in the . But since in the original code the impl is derived and reusesthe from the struct declaration, the lint appears to trigger on the struct declaration. We may either just want to not trigger in derive expansions or explicitly allow this lint in derives expansions.
advertised at T-compiler meeting. removing nomination tag.
I'm going to ping in the hopes that they have a bit of time to look into this. My sense is that we ought to make a plan to finish up the Rust 2018 idiom lints -- but at the same time it's hard to justify a P-high label just now.
I tried an approach where I would look at the lifetime span to see if it came from a compiler desugaring, but the derived code doesn't keep any information about their context. A different approach will be needed in the parse step to make sure the debug subparser produced spans are appropriately marked. I won't have time to dig deeper, but wanted to share what I found.
AFAIK there's a perma-unstable attribute that is placed on derived s which some error reporting code might be checking. I should've given more context - it'd be good to fix this because it would unblock something like , but likely removing a far larger number of lifetimes, which may simplify e.g. the removal. But if we can't really soon, we can defer indefinitely, I think.
?
This seems to have regressed.