jiebi/CodeConvo huggingface dataset:
Change:
<ins> #![feature(generic_associated_types)] #![feature(associated_type_defaults)] #![allow(incomplete_features)] use std::ops::Deref; trait UnsafeCopy { type Copy<T>: Copy = Box<T>; //~^ ERROR the trait bound `Box<T>: Copy` is not satisfied //~^^ ERROR the trait bound `T: Clone` is not satisfied fn copy<T>(x: &Self::Copy<T>) -> Self::Copy<T> { *x } } impl<T> UnsafeCopy for T {} fn main() { let b = Box::new(42usize); let copy = <()>::copy(&b); let raw_b = Box::deref(&b) as *const _; let raw_copy = Box::deref(&copy) as *const _; // assert the addresses. assert_eq!(raw_b, raw_copy); } </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: I expected to see this happen: Getting some errors that does not satisfy the bound. Instead, this happened: The program compiled and resulted in a double free, and both are of type and point to the same memory... <!-- 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<summaryBacktrace</summary<p</p</detailsThis seems like some variation of and <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I guess, this duplicates . (Especially with the comment that I pretty much at the exact same time you created this issue).
Yes, I noticed it haha. Perhaps splitting your original issue up in several issues is a good idea, though
Triage: this given an error, on nightly. modify labels +E-needs-test claim
Change:
<ins> // check-pass #![feature(adt_const_params)] #![allow(incomplete_features)] pub trait GetType<const N: &'static str> { type Ty; fn get(&self) -> &Self::Ty; } pub fn get_val<T>(value: &T) -> &T::Ty where T: GetType<"hello">, { value.get() } fn main() {} </ins>

Discussion:
I tried this code: I expected the code to compile successfully(like it did in previous nightly versions) Instead, the code failed to compile with this error: Tried this on rustc 1.44.0-nightly (2020-04-24 ) The way I work around this bug is to write the function like this:
Interestingly none of these additional bounds fix the issue:
searched nightlies: from nightly-2020-04-03 to nightly-2020-04-10 regressed nightly: nightly-2020-04-08 searched commits: from to regressed commit: modify labels:-E-needs-bisection
this has now been fixed
Change:
<ins> error[E0308]: mismatched types --> $DIR/return-dyn-type-mismatch-2.rs:7:5 | LL | fn foo<T>() -> dyn Trait<T> |                ------------ expected `(dyn Trait<T> + 'static)` because of return type ... LL |     42 |     ^^ expected `dyn Trait`, found integer | = note: expected trait object `(dyn Trait<T> + 'static)` found type `{integer}` error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </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
bisected to cc
This can be made to ICE on stable as well:
duplicate of

<!-- 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
almost exactly 3 years old :cake: :partying_face: :pinata: searched toolchains nightly-2020-04-17 through nightly-2023-04-22 Regression in nightly-2020-04-23 found 7 bors merge commits in the specified range commit[0] 2020-04-21: Auto merge of - spastorino:dyn-fnonce-alignment, r=nikomatsakis commit[1] 2020-04-22: Auto merge of - ehuss:update-cargo, r=ehuss commit[2] 2020-04-22: Auto merge of - JohnTitor:rollup-vh6dut5, r=JohnTitor commit[3] 2020-04-22: Auto merge of - nnethercote:bitcode-in-rlib, r=alexcrichton commit[4] 2020-04-22: Auto merge of - Dylan-DPC:rollup-iunh61a, r=Dylan-DPC commit[5] 2020-04-22: Auto merge of - nnethercote:alphabetize-C-and-Z-options, r=petrochenkov commit[6] 2020-04-22: Auto merge of - Dylan-DPC:rollup-rvm6tfy, r=Dylan-DPC probably ? cc
I feel like i've seen this before -- probably a dupe? Or at least I think I've chatted with about this.
Could be :D probably 90% of the ICEs I am seeing are already reported in some way or another and sometimes one might slip through
different stacktrace with debug assertions: `
Change:
} layout::Univariant { ref variant, .. } => { assert_eq!(discr, Disr(0)); <del> let contents = build_const_struct(ccx, &variant, vals); </del> <ins> let contents = build_const_struct(ccx, &variant, vals); </ins> C_struct(ccx, &contents[..], variant.packed) } layout::Vector { .. } => {

Discussion:
This code () gives me a segfault on the current beta: I've reduced it as much as I can, even removing the constructor on the enum causes it to work. I expect the output to be (which it is on stable), but instead I get
Appears to be broken on nightly as well - I get a stack overflow on x86_64 darwin.
FWIW, I don't get a segfault on beta or nightly with the playpen, I just get this output for both:
The stackoverflow on x86_64 darwin goes away for me on any .
This strongly reminds me of and .
Change:
LL |     let x =  3.40282357e+38_f32; |              ^^^^^^^^^^^^^^^^^^ | <del> = note: the literal `3.40282357e+38_f32` does not fit into the type `f32` and will be converted to `std::f32::INFINITY` </del> <ins> = note: the literal `3.40282357e+38_f32` does not fit into the type `f32` and will be converted to `f32::INFINITY` </ins> error: literal out of range for `f64` --> $DIR/lint-type-overflow2.rs:11:14

Discussion:
This program: Produces this output: Note the references to ; these symbols have been superseded by associated consts at (). the error message to suggest the new symbols if any of the other old symbols are contained in any error messages. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
See also .
I am working on this. claim
: I've gone and grepped through for , , etc. and found no accidental uses there. I then grepped for each of the individual symbols listed in RFC 2700 (, , etc.) and didn't notice anything out of place. I also grepped for (as seen in this issue) and found only a hint message for things like etc which only triggers when an item isn't found at all, which won't trigger for any of the new consts. Probably safe to close this once merges.
You are right. I was thinking of cases like this one but this can likely be closed with the merge of that PR. I was operating with an abundance of caution.
Yeah, that's the aforementioned case that only shows up in the event of an error, so (AFAICT) that path won't be taken for the new constants since they resolve successfully.
Change:
<ins> // ignore-tidy-linelength #![feature(type_alias_impl_trait)] use std::fmt::Debug; pub trait Foo { type Item: Debug; fn foo<T: Debug>(_: T) -> Self::Item; } #[derive(Debug)] pub struct S<T>(std::marker::PhantomData<T>); pub struct S2; impl Foo for S2 { type Item = impl Debug; fn foo<T: Debug>(_: T) -> Self::Item { //~^ Error type parameter `T` is part of concrete type but not used in parameter list for the `impl Trait` type alias S::<T>(Default::default()) } } fn main() { S2::foo(123); } </ins>

Discussion:
here is the example: this example will compile well if you remove
Backtrace: `
Hmm I reproduced same ICE with next snippet without :
Smaller repro: Edit: AFAICT the problem is the existential assoc type is being made dependent on the type parameter of the trait method ('s in this repro, 's in the OP). So it would be a compile error if it weren't for the ICE.
compiles without ICE.
sorry it needs to be feature or used 2018 edition. Here is complete one which fails to compile regardless feature:
Right, 2015 doesn't hit the error until you actually try to use the type. Regardless, as I said in my previous comment, this code should be a compile error anyway regardless of edition, since it's trying to declare an associated type that depends on the type parameters of the trait method rather than the trait.
hey have you had a chance to look into this yet? Do you think you will be looking at it in the near term, or should we unassign you?
Removed my assignment. Unfortunately I'm running behind on the not-time-critical issues I assigned to myself.
Discussed in T-compiler meeting. This is a blocker for the existential type feature. But there is no schedule yet set for stabilizing that feature. Thus, downgrading fixing this to P-medium.
This no longer produces an ICE on the latest nightly.
Yes, it was fixed by
Change:
<ins> error[E0425]: cannot find value `_y` in this scope --> $DIR/issue-105946.rs:6:10 | LL |     let [_y..] = [box 1, box 2]; |          ^^ not found in this scope error[E0658]: `X..` patterns in slices are experimental --> $DIR/issue-105946.rs:6:10 | LL |     let [_y..] = [box 1, box 2]; |          ^^^^ | = note: see issue #67264 <https://github.com/rust-lang/rust/issues/67264> for more information = help: add `#![feature(half_open_range_patterns_in_slices)]` to the crate attributes to enable error[E0658]: box expression syntax is experimental; you can call `Box::new` instead --> $DIR/issue-105946.rs:6:19 | LL |     let [_y..] = [box 1, box 2]; |                   ^^^^^ | = note: see issue #49733 <https://github.com/rust-lang/rust/issues/49733> for more information = help: add `#![feature(box_syntax)]` to the crate attributes to enable error[E0658]: box expression syntax is experimental; you can call `Box::new` instead --> $DIR/issue-105946.rs:6:26 | LL |     let [_y..] = [box 1, box 2]; |                          ^^^^^ | = note: see issue #49733 <https://github.com/rust-lang/rust/issues/49733> for more information = help: add `#![feature(box_syntax)]` to the crate attributes to enable error[E0308]: mismatched types --> $DIR/issue-105946.rs:2:10 | LL |   return {}; |          ^^ expected `str`, found `()` error[E0527]: pattern requires 1 element but array has 2 --> $DIR/issue-105946.rs:6:9 | LL |     let [_y..] = [box 1, box 2]; |         ^^^^^^ expected 2 elements error: aborting due to 6 previous errors Some errors have detailed explanations: E0308, E0425, E0527, E0658. For more information about an error, try `rustc --explain E0308`. </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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: <!-- Please provide a link to --The current output is: We shouldn't show here. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
without
another one 
What ideal output would you suggest? Should we remove the suggestion line like:
Ideally we should be checking that the return type . If it's not suggestable, don't mention it.
claim
I actually believe that neither the E0029 nor the E0277 should have been emitted. I would check explicitly for and change the error to be (that way the error isn't printed out, but rustc will ICE if no other error is emitted, which should have happened).
The PR will prevent E0029 and E0277 from printing out after checking the type references.
Change:
<del> #![stable(feature = "os_fd", since = "1.66.0")] </del> <ins> #![stable(feature = "rust1", since = "1.0.0")] </ins> <del> mod net; #[path = "../../fd/owned.rs"] mod owned; #[path = "../../fd/raw.rs"] mod raw; // Export the types and traits for the public API. #[stable(feature = "os_fd", since = "1.66.0")] pub use owned::*; #[stable(feature = "os_fd", since = "1.66.0")] pub use raw::*; </del> <ins> #[stable(feature = "rust1", since = "1.0.0")] pub use crate::os::fd::*; </ins>

Discussion:
I tried this code: With . I expected to see this happen: code to compile Instead, this happened: failed to compile with Looking at the relevant code: It seems is imply missed from the . Inside of the module there is already code for hermit: I think this is just an oversight, but I since I don't develop for Hermit I'm not sure. (I hit this while updating Mio) /cc :
label -needs-triage +O-hermit +A-cross +T-libs
I agree, the module is missing. I will create a PR.
Change:
<ins> // edition: 2021 fn test<'s: 's>(s: &'s str) -> impl std::future::Future<Output = impl Sized> { async move { let _s = s; } //~^ ERROR hidden type for `impl Future<Output = impl Sized>` captures lifetime that does not appear in bounds } fn main() {} </ins>

Discussion:
The following compiles on the current nightly (1.67.0-nightly (2022-12-03 )) although it shouldn't: It is correctly rejected by the current beta: 1.66.0-beta.2 (2022-11-20 ). This is most likely (I haven't bisected though!). Cc label C-bug T-compiler I-unsound regression-from-stable-to-nightly A-impl-trait
WG-prioritization assigning priority (). label -I-prioritize +P-high
Change:
rotate!(rotate_16_usize_5, 16, |i| [i; 5]); rotate!(rotate_64_usize_4, 64, |i| [i; 4]); rotate!(rotate_64_usize_5, 64, |i| [i; 5]); <ins> #[bench] fn fill_byte_sized(b: &mut Bencher) { #[derive(Copy, Clone)] struct NewType(u8); let mut ary = [NewType(0); 1024]; b.iter(|| { let slice = &mut ary[..]; black_box(slice.fill(black_box(NewType(42)))); }); } </ins>

Discussion:
Specialized slice::fill implementations are not inlined even though they would compile down to pretty much just a single memset-call. The function below represents manual inlining of . () I haven’t tested it in any way, but I suspect that this can be fixed by marking as . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
modify labels: C-enhancement, T-libs-impl, I-slow, E-easy
claim
Don't you need at the very least (but not necessarily ) to actually guarantee cross-crate-inlining eligibility with the default no-LTO profile? It'd certainly make sense to add that to all of the impls in IMO.
It being generic is sufficient for being eligible because the monomorphized function is only created in the consuming crate once all the generics have been filled in. Adding on top just encourages it further.
Change:
} } diagnostics_builder.note("for more information, see <https://doc.rust-lang.org/nightly/edition-guide/rust-2021/disjoint-capture-in-closures.html>"); <del> let closure_body_span = self.tcx.hir().span(body_id.hir_id); let (sugg, app) = </del> <ins> let mut closure_body_span = self.tcx.hir().span(body_id.hir_id); // If the body was entirely expanded from a macro // invocation, i.e. the body is not contained inside the // closure span, then we walk up the expansion until we // find the span before the expansion. while !closure_body_span.is_dummy() && !closure_span.contains(closure_body_span) { closure_body_span = closure_body_span.parent().unwrap_or(DUMMY_SP); } let (span, sugg, app) = </ins> match self.tcx.sess.source_map().span_to_snippet(closure_body_span) { Ok(s) => { let trimmed = s.trim_start();

Discussion:
produces: It expanded the macro. This only happens when the macro invocation is the entire body of the closure.
cc
Working on a fix.
Change:
<ins> // MIR optimizations can create expansions after the TyCtxt has been created. // This test verifies that those expansions can be decoded correctly. // revisions:rpass1 rpass2 // compile-flags: -Z query-dep-graph -Z mir-opt-level=3 fn main() { if std::env::var("a").is_ok() { println!("b"); } } </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. --Assuming that you copied to . <!-- 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
I reproduced this ICE locally. On my end I did it by copying the git checkout of into , because I wasn't able to figure out the right invocation to get it setup with files in (Oh, whoops, I think I was accidentally passing instead of . Of course that wasn't going to work.) well, not 100%, my query stack was a little different: but it seemed like a similar bug, nonetheless.
modify labels: +I-prioritize
Assigning as discussed as part of the and removing .
Now happens for when retrying the repro. (with replaced with as it was changed in rustc) <details<summarybacktrace</summary</detailsIt also gives an unstable fingerprint ICE for when compiling : <details<summarybacktrace</summary</details
The compilation now fails when accessing session in : It looks that decodes which in turn decodes which in turn requires access to a session, but by the time of call, the session in no longer threaded through. cc
I can confirm it works now. Pushed to re-enable incremental compilation for compiling the sysroot.
Change:
using namespace llvm; <ins> static codegen::RegisterCodeGenFlags CGF; </ins> typedef struct LLVMOpaquePass *LLVMPassRef; typedef struct LLVMOpaqueTargetMachine *LLVMTargetMachineRef;

Discussion:
Please see this StackOverflow <a href=""question</a.
Interesting: rustc -C llvm-args='--list' gives the option list for LLC you might expect llvm-args would be passed to clang (which has the options described in the stack overflow page), and indeed to which these arguments were formerly passed. edit: but it also doesn't seem to be the case recently, as both stable and nightly seem to pass args to llc, not clang.
I think this may actually be a real thing. See . It throws the error: But llc definitely takes this argument. I've traced the argument parsing to . And now that I try it, doesn't seem to work for me either. I'm running . Btw, I ran into this trying to work around .
Added code to print the argv passed to . It prints the args from . So I guess the problem is that llc args != whatever arguments that function expects.
Yes, that appears to be the case. The arguments recognized by and the arguments recognized by the API are different. The Rust compiler uses the LLVM API, so it doesn't recognize certain LLVM options even though they may be valid for . Consider the following: Compile with and execute with . It will print the following: Compare that with the output for (an exercise left to the reader). I need the and for my target, as . I don't know what the solution is here. Is it something for LLVM to solve, or something for rustc to solve?
I'm leaving this open because it's not clear to me how a user should pass arguments directly to llc if they want to; perhaps that's not possible or even something we want. Could you comment on whether we think it's a good idea to allow passing arguments into llc directly? Do we run llc at all? If we don't then it seems that this is not a bug.
Nominating to decide whether we want to expose llc or not (and if we can -- I don't know that we run it directly today). If not, we should close.
I'm moving this to T-dev-tools; it seems like they've put some energy into how to think about the stability of well.
cc this seems like something that would be a tooling/platform team issue if that team existed.

Briefly discussed at the dev-tools meeting: verdict was that this did not seem urgent to address.
Related
Leaving this here in case it's helpful to anyone who comes across this issue: I was able to get what appears to be the full list of the arguments LLVM will accept by way of with: Caution: sharp edges abound.
Exposing these flags would be a matter of using , if we really want to.
Change:
<ins> // build-pass fn main() { println!("{}", [(); std::usize::MAX].len()); } </ins>

Discussion:
Test case: I left it compiling for just over half an hour, and it sat at constant memory usage and 100% of a CPU core for the entire time. Originally tested on . Checking through some different versions, these all take over a minute (I didn't bother sitting around for the full 30 minutes): Going back a little further it works and compiles in about a second on: Going back even further it ICEs with on: (this may be a duplicate of one of the existing large array compile time issues, but I didn't find one it fit exactly with, especially given it worked on at least two stable releases).
I've tried to compile this with , but it's been running for two hours and it didn't complete, so I had to cut it off. Maybe someone else can try? I think my computer is getting old :D So I tried compiling using the compiler for the last commit (installed with ): Here's what I got: <details<summary<strongStandard output</strong(if that even matters)</summary<p</p</details<details<summary<strongStandard error</strong</summary<p</p</detailsThis last line: Is emitted in here: So I believe this is a const eval bug? cc do you have any idea what may be happening?
Hm, not off the top of my head. Cc I take it it keeps going after that last line without outputting anything any more? Then that's just the last thing it completed, which might or might not have anything to do with the next thing it is doing. Could you use to capture a backtrace of what code it is running then? (Let me know if you need help with that.)
is the LLDB output for the command with latest nightly ().
Okay so this is interning walking every single field of that array... and taking forever to do that, obviously.
Letting it run a bit longer gave me an additional frame:
How did you originally find this? Did it impact a real code you had?
Assigning .
the context was , I was just trying to find out whether you could have a ZST array with length , so no, not real code.
Alright, it is fine being then
For arrays and slices we could make interning check the relocation map for relocations within the array, compute the indices which have relocations and only look at those indices.

This way we don't have to walk all elements, but only those that interning cares about. Not sure what validation will do after interning is finished, maybe that'll also run forever? I thought we had some optimizations in there. Oh yea, and interning can skip any zst type in general.
Change:
<ins> // Copyright 2017 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. #![feature(conservative_impl_trait, generators, generator_trait)] use std::ops::Generator; fn msg() -> u32 { 0 } pub fn foo() -> impl Generator<Yield=(), Return=u32> { || { yield; return msg(); } } </ins>

Discussion:
I've hit an ICE with the new generator support that has just landed (nightly 2017-08-29). I've reduced it to the following : This is essentially the same issue as . I can't reproduce the original ICE with closures as described there, but I run into it with generators.
I believe this ICE is more related to "impl Trait" rather than generators, but we'll find out!
I think also needs to be adapted for generators.
looks like ! Thanks for the pointer!