jiebi/CodeConvo huggingface dataset:
Change:
<ins> // Test that the `'a` from the impl doesn't // prevent us from creating a `'a` parameter // on the `blah` function. // // check-pass #![feature(in_band_lifetimes)] struct Foo<'a> { x: &'a u32 } impl Foo<'a> { fn method(&self) { fn blah(f: Foo<'a>) { } } } fn main() { } </ins>

Discussion:
The following breaks on nightly (see ) With: CC: dtolnay/async-trait
Reduced:
Forgot to mention in case this helps, giving the inner fn a matching lifetime avoids this issue for some reason:
The reason this is happening is that the desugared version of applies all in-scope lifetimes to the returned existential type, which in this case is creating , which is invalid. I'm not sure exactly what the best fix is for this, though, since elided lifetimes in the impl signature are intentionally unnameable. The closest idea I have would be to create some special new lifetime that is but can refer to lifetimes originating from the impl header. cc who may have opinions.
Hmm wouldn't you expect the nested to not inherit anything from its enclosing scopes? Seems like a bug to me that it does? Am I confused about something?
The function in the middle is actually a bit of a source of confusion here, although it does indicate that there's a second bug since we shouldn't be inheriting generics since the nested isn't part of the . The bug I was focusing on is better illustrated by this example: which produces this error: This is because the code is transformed into and in that case does not refer back to the usage from the header.
I see. Indeed, I would expect that, internally, we'd have some way to refer back to the from the impl header. I believe this should be possible, no? In particular, the in impls expands (internally) to for some integer N, which I believe is basically treated like any other named lifetime.
Yep, I would've expected so as well-- I'm not sure why that isn't working, I'd have to take a look.
I was looking and I think the bug lies here: Probably needs to be a instead, or we need to use something else for this purpose.
A closer reading suggests I was mistaken. The lifetimes from the impl should show up in -- includes only the explicitly declared lifetimes written by the user on the impl. I'm not quite sure what the problem is yet.
OK, no, I was correct. When processing impl items, we convert the lifetimes into entries. EDIT: Er, I'm still not entirely sure. Reading more. =)
OK, I have a fix for the method issue, but not the nested async fn item issue.

I forked off for the method issue
I didn't prep a fix for this one yet. It seems obvious that some internal state is not being reset when we enter a new item.
but if you have a chance to investigate, would be appreciated
Presumably the problem is that doesn't "reset" the vector -- it only seems to extend it...
Indeed, in-band lifetimes are broken in the same way. This fails to compile ():
Working on a possible fix
Yep, have a fix.
Inband lifetimes looks similar to fwiw
thanks
Change:
<ins> error[E0277]: the size for values of type `[u8]` cannot be known at compilation time --> $DIR/unsized-union-ice.rs:6:10 | LL |     val: std::mem::ManuallyDrop<[u8]>, |          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ doesn't have a size known at compile-time | = help: within `ManuallyDrop<[u8]>`, the trait `Sized` is not implemented for `[u8]`, which is required by `ManuallyDrop<[u8]>: Sized` note: required because it appears within the type `ManuallyDrop<[u8]>` --> $SRC_DIR/core/src/mem/manually_drop.rs:LL:COL = note: no field of a union may have a dynamically sized type = help: change the field's type to have a statically known size help: borrowed types always have a statically known size | LL |     val: &std::mem::ManuallyDrop<[u8]>, |          + help: the `Box` type always has a statically known size and allocates its contents in the heap | LL |     val: Box<std::mem::ManuallyDrop<[u8]>>, |          ++++                            + error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0277`. </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: should be sized but is not?', 'error: internal compiler error: should be sized but is not?' 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: [typeck] type-checking [analysis] running analysis passes on this crate --
cc
This is incidentally fixed by by making unions always sized.
smaller: The union is currently in fact not sized, but this code assumes that non-struct ADTs must be sized:
Change:
use crate::traits::*; use crate::{CachedModuleCodegen, CompiledModule, CrateInfo, MemFlags, ModuleCodegen, ModuleKind}; <del> use rustc_ast::expand::allocator::AllocatorKind; </del> <ins> use rustc_ast::expand::allocator::{global_fn_name, AllocatorKind, ALLOCATOR_METHODS}; </ins> use rustc_attr as attr; use rustc_data_structures::fx::{FxHashMap, FxHashSet}; use rustc_data_structures::profiling::{get_resident_set_size, print_time_passes_entry};

Discussion:
I have a project that overrides the global allocator in , and recently noticed that I can no longer link the test binary for my project with recent beta/nightly compilers. points to which certainly looks relevant. I reproduced the error using a slightly modified example from the global allocator documentation: If I move the allocator definition from to , I no longer have a problem. Is that the right thing to do? If so, do I need to do anything else to make sure my tests use the desired allocator? I tried this code: I expected to see this happen: Instead, this happened: searched nightlies: from nightly-2023-05-25 to nightly-2023-06-16 regressed nightly: nightly-2023-05-26 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 modify labels: +regression-from-stable-to-beta -regression-untriaged
Adding the full linker error output here in case it's of interest.
I tried adding based on a brief look at the change that pointed to. It doesn't seem to make any difference, but that's why it's in my repro above.
I can reproduce this. and such are properly defined in the library rlib. It seems to be caused by the library order. Traditional linkers require symbols to have their uses in object files before their definition. So for circular dependencies and has to be used or libraries have to be mentioned multiple times. And indeed which doesn't have this restriction is entirely fine with this. I think registering a circular dependency between the defining crate of and liballoc (and every crate that depends on it) at would work. Edit: Reading the code it references closer, I think adding to would be enough to fix this. I can't work on this tomorrow, but unless someone else picks it up, I will work on this.
Finished some work early. fixes the issue.
thank you for the quick fix!
WG-prioritization assigning priority (). label -I-prioritize +P-high
Change:
match ni.node { ast::ForeignItemFn(..) => { let abi = ccx.tcx.map.get_foreign_abi(id); <del> foreign::register_foreign_item_fn(ccx, abi, ni) </del> <ins> let ty = ty::node_id_to_type(ccx.tcx(), ni.id); let name = foreign::link_name(ni); foreign::register_foreign_item_fn(ccx, abi, ty, name.get().as_slice(), Some(ni.span)) </ins> } ast::ForeignItemStatic(..) => { foreign::register_static(ccx, ni)

Discussion:
Spidermonkey's type is a union of size 64 bits. We represent this as in Rust. This works great on 64bit platforms. On 32bit platforms, the values get mangled when passed to the C library functions. This seems to be an ABI issue. We've encountered this before with which was about 32bit ARM. This gist contains sample programs and the generated IR for minimal test programs using rust-mozjs: Note that you will need my 32bit branch of rust-mozjs: You can put debugging printfs in in to see the value on the C side. The only notable thing I see in the IR is that the clang IR has when passing the . This seems like a Rust bug, but I'd also be interested if there is a workaround that will work on all platforms.
cc
cc me
Change:
Operand::Copy(..) | Operand::Constant(..) => { // These are always okay: direct use of a const, or a value that can evidently be copied. } <del> Operand::Move(_) => { </del> <ins> Operand::Move(place) => { </ins> // Make sure that repeated elements implement `Copy`. let span = body.source_info(location).span; let ty = operand.ty(body, tcx); if !self.infcx.type_is_copy_modulo_regions(self.param_env, ty, span) { <ins> let ccx = ConstCx::new_with_param_env(tcx, body, self.param_env); let is_const_fn = is_const_fn_in_array_repeat_expression(&ccx, &place, &body); debug!("check_rvalue: is_const_fn={:?}", is_const_fn); </ins> let def_id = body.source.def_id().expect_local(); self.infcx.report_selection_error( &traits::Obligation::new( ObligationCause::new( span, self.tcx().hir().local_def_id_to_hir_id(def_id), <del> traits::ObligationCauseCode::RepeatVec, </del> <ins> traits::ObligationCauseCode::RepeatVec(is_const_fn), </ins> ), self.param_env, ty::Binder::bind(ty::TraitRef::new(

Discussion:
The following code: gives the following error: However, is a , so this code can be made to compile by creating a new item: We should suggest this to user when a function is being called in the array initializer. <strikeAssuming that is accepted, we could eventually suggest an inline block.</strikeOn Nightly, we could suggest an inline block. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think this would make a good first issue for someone looking to get started contributing. I'd be happy to mentor anyone who wants to work on this.
claim
Is this still an issue that I can work on?
Yes, assuming that is no longer working on this.
Should I claim it?
It looks like DavidHusicka hasn't had any activity this month, so I think it would be fine for you to take the issue. Feel free to reach out to me if you have any questions about how to get started implementing this.
claim
Change:
<ins> error[E0728]: `await` is only allowed inside `async` functions and blocks --> $DIR/issue-70594.rs:4:9 | LL | async fn fun() { |          --- this is not `async` LL |     [1; ().await]; |         ^^^^^^^^ only allowed inside `async` functions and blocks error[E0744]: `.await` is not allowed in a `const` --> $DIR/issue-70594.rs:4:9 | LL |     [1; ().await]; |         ^^^^^^^^ error[E0658]: `loop` is not allowed in a `const` --> $DIR/issue-70594.rs:4:9 | LL |     [1; ().await]; |         ^^^^^^^^ | = note: see issue #52000 <https://github.com/rust-lang/rust/issues/52000> for more information = help: add `#![feature(const_loop)]` to the crate attributes to enable error[E0744]: `.await` is not allowed in a `const` --> $DIR/issue-70594.rs:4:9 | LL |     [1; ().await]; |         ^^^^^^^^ error[E0277]: the trait bound `(): std::future::Future` is not satisfied --> $DIR/issue-70594.rs:4:9 | LL |     [1; ().await]; |         ^^^^^^^^ the trait `std::future::Future` is not implemented for `()` | ::: $SRC_DIR/libcore/future/mod.rs:LL:COL | LL |     F: Future, |        ------ required by this bound in `std::future::poll_with_context` error: aborting due to 5 previous errors Some errors have detailed explanations: E0277, E0658, E0728, E0744. For more information about an error, try `rustc --explain E0277`. </ins>

Discussion:
I'm seeing an internal compiler error on the following input (found by ):
Report from : searched nightlies: from nightly-2020-03-09 to nightly-2020-03-31 regressed nightly: nightly-2020-03-22 searched commits: from to regressed commit:
Simplified: and cc ()
Fix up at
Change:
<ins> #![deny(single_use_lifetimes)] pub enum Data<'a> { Borrowed(&'a str), Owned(String), } impl<'a> Data<'a> { pub fn get<'b: 'a>(&'b self) -> &'a str { //~^ ERROR lifetime parameter `'b` only used once match &self { Self::Borrowed(val) => val, Self::Owned(val) => &val, } } } fn main() {} </ins>

Discussion:
This code, as expected, triggers the lint. This is the compiler output: Applying the suggested change, we then get a lifetime error. In this specific instance, must also be changed to . That'll then trigger the lint on , with no ensuing issues. I have not checked this, but I my suspicion is any place where a lifetime bound is also present in the return type (or possibly even a parameter) will result in a similar failure to compile the suggested code. Figuring out which lifetimes to suggest removal of in other parts of the function signature probably isn't straightforward. This example is not theoretical, unfortunately. I ran into this in real-world code and it caused me quite a bit of time to figure out. The example is the minimal reproduction of the bad suggestion.
Should the lint even trigger for ? It's only "used" once directly, but it's also linked to another lifetime through the bound .
cc label +F-lint-singleuselifetimes
Change:
<ins> // needs-sanitizer-support // only-x86_64 // // compile-flags: -Z sanitizer=address -O // // run-fail // error-pattern: AddressSanitizer: SEGV use std::ffi::c_void; extern "C" { fn free(ptr: *mut c_void); } fn main() { unsafe { free(1 as *mut c_void); } } </ins>

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: and compiled it with: I expected to see asan report a bad pointer use and give a backtrace. Instead I just got a raw sigsegv: Running with verbose output shows that AddressSanitizer is intercepting the signal. It looks like is also installing a signal handler, which is overriding the AddressSanitizer one. <!-- 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. --: </p</details
(set handler and prevent override) is a workaround, but I think the Rust runtime shouldn't stomp SIGSEGV in the sanitizer case.
cc
Change:
<del> //@ known-bug: rust-lang/rust #124464 enum TestOption<T> { TestSome(T), TestSome(T), } pub struct Request { bar: TestOption<u64>, bar: u8, } fn default_instance() -> &'static Request { static instance: Request = Request { bar: 17 }; &instance } pub fn main() {} </del>

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. --:
with debug assertions: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
without: --<details<summary<strongBacktrace</strong</summary<p</p</details

<!-- 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. --(reduced) <details<summary<strongOriginal Code</strong</summary<p</p</details<!-- 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- has the same ICE location, but this one doesn't require any feature to make ICE. ICE-loc: Original ICE-triggering code is mutated from test-file
bisects to searched nightlies: from nightly-2024-01-01 to nightly-2024-04-30 regressed nightly: nightly-2024-02-21 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.8</summaryHost triple: x86_64-apple-darwin Reproduce with: </details
The following already reproduces on 1.77 stable
Change:
#![feature(vecdeque_binary_search)] #![feature(slice_group_by)] #![feature(slice_partition_dedup)] <del> #![feature(vec_extend_from_within)] </del> #![feature(vec_spare_capacity)] #![feature(string_remove_matches)]

Discussion:
Feature gate: This is a tracking issue for , which allows copying elements from a range to the end: <!-- For larger features, more steps might be involved. If the feature is changed later, please add those PRs here as well. --- [x] Implementation: [x] Final commenting period (FCP) [x] yet.
merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
Change:
<ins> // compile-flags: -Ztreat-err-as-bug // build-fail // failure-status: 101 // rustc-env:RUST_BACKTRACE=1 // normalize-stderr-test "nerror: internal compiler error.*nn" -> "" // normalize-stderr-test "note:.*unexpectedly panicked.*nn" -> "" // normalize-stderr-test "note: we would appreciate a bug report.*nn" -> "" // normalize-stderr-test "note: compiler flags.*nn" -> "" // normalize-stderr-test "note: rustc.*running on.*nn" -> "" // normalize-stderr-test "thread.*panicked.*n" -> "" // normalize-stderr-test "stack backtrace:n" -> "" // normalize-stderr-test "  d{1,}: .*n" -> "" // normalize-stderr-test ".*note: Some details.*n" -> "" #![allow(unconditional_panic)] fn main() { let x: &'static i32 = &(1 / 0); //~^ ERROR reaching this expression at runtime will panic or abort [const_err] println!("x={}", x); } </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:
box-shadow: 0 0 8px #078dd8; } <del> .module-item .stab { </del> <ins> .module-item .stab, .import-item .stab { </ins> color: #000; }

Discussion:
See is unstable, however there is no unstable tag showing that, it would be nice if it would, just so it can be seen at a glance without going to their respective pages. cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Note that rustdoc already does something similar for : ! It could use a similar format for re-exports.
Really could just copy the existing tags (see -asm) and put em after the path.
claim
Change:
<ins> struct B<const I: u8>; //~ ERROR const generics are unstable impl B<0> { fn bug() -> Self { panic!() } } fn main() {} </ins>

Discussion:
The following ICE's on nightly only: Notice I didn't specify the feature <details<summaryBacktrace:</summary</details
In general, presence or absence of shouldn't affect compiler's behavior in any way beside reporting the "feature is unstable" error, so ICEs like this need to fixed unconditionally.
Strongly related (not sure why two issues though) with and therefore with and I already pinged you in because of this ;)
2 issue's because the ICE messages are different, sorry for the confusion! To clearify, on both issue's there are 2 things wrong: Being able to get the ICE's, without specifying the feature The ICE's themselves (Which was likely to happen, given the incompleteness. Consider these as test-cases, or something :) )
This should be fixed on the next nightly, but will add a regression test for it.
Change:
<ins> error: `let` expressions are not supported here --> $DIR/issue-82290.rs:4:16 | LL |     if true && let x = 1 { |                ^^^^^^^^^ | = note: only supported directly in conditions of `if`- and `while`-expressions = note: as well as when nested within `&&` and parenthesis in those conditions warning: the feature `let_chains` is incomplete and may not be safe to use and/or cause compiler crashes --> $DIR/issue-82290.rs:1:12 | LL | #![feature(let_chains)] |            ^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default = note: see issue #53667 <https://github.com/rust-lang/rust/issues/53667> for more information error: aborting due to previous error; 1 warning emitted </ins>

Discussion:
I tried this code: : Note: A simpler program does not crash, but does not compile.
Is it possible for you to share the code?
It might be better for you to share the code which reproduces the issue on your nightly, 2021-02-11, so that I can try to reproduce it on the latest nightly build and possibly find the commit that might have introduced this issue.
Okay, I'll trim down my base and share it later today.
I deleted my whole project and got this
Thanks label: -E-needs-mcve
Not sure if this helps: I ran on my host target , and it is shown that it ICEd back in 2018 (even before the initial implementation of the feature.
Duplicate of
Change:
/// /// The two configurations available are: /// <del> /// - [`name`]: allows to give a name to the thread which is currently ///   only used in `panic` messages. /// - [`stack_size`]: specifies the desired stack size. Note that this can ///   be overridden by the OS. /// /// If the [`stack_size`] field is not specified, the stack size /// will be the `RUST_MIN_STACK` environment variable. If it is /// not specified either, a sensible default will be set. /// /// If the [`name`] field is not specified, the thread will not be named. </del> <ins> /// - [`name`]: specifies an [associated name for the thread][naming-threads] /// - [`stack_size`]: specifies the [desired stack size for the thread][stack-size] </ins> /// /// The [`spawn`] method will take ownership of the builder and create an /// [`io::Result`] to the thread handle with the given configuration.

Discussion:
One can specify the stack size of a thread via . It looks like looks at the env var and attempts to parse it into an integer. If it's not specified or can't parse, it falls back to 2MB. Should we update the thread documentation to mention what the default stack size is and mention that environment variable?
Relevant discussion on IRC
Don't forget that the stack size of the main thread is not determined by Rust.
Opened a PR: