jiebi/CodeConvo huggingface dataset:
Change:
(&ty::Infer(ty::TyVar(a_vid)), &ty::Infer(ty::TyVar(b_vid))) => { return Err((a_vid, b_vid)); } <del> // We don't silently want to constrain hidden types here, so we assert that either one side is // an infer var, so it'll get constrained to whatever the other side is, or there are no opaque // types involved. // We don't expect this to actually get hit, but if it does, we now at least know how to write // a test for it. (_, ty::Infer(ty::TyVar(_))) => {} (ty::Infer(ty::TyVar(_)), _) => {} _ if r_a != r_b && (r_a, r_b).has_opaque_types() => { span_bug!( cause.span(), "opaque types got hidden types registered from within subtype predicate: {r_a:?} vs {r_b:?}" ) } </del> _ => {} } self.enter_forall(predicate, |ty::SubtypePredicate { a_is_expected, a, b }| { if a_is_expected { <del> Ok(self.at(cause, param_env).sub(DefineOpaqueTypes::Yes, a, b)) </del> <ins> Ok(self.at(cause, param_env).sub(DefineOpaqueTypes::No, a, b)) </ins> } else { <del> Ok(self.at(cause, param_env).sup(DefineOpaqueTypes::Yes, b, a)) </del> <ins> Ok(self.at(cause, param_env).sup(DefineOpaqueTypes::No, b, a)) </ins> } }) }

Discussion:
https://crater- https://crater- https://crater- https://crater- https://crater- https://crater- probably cc
Yeah Matthias also found . Think it hasn't been fixed b/c oli is on holiday -- I assume he will investigate when he's back next week.
MCVE in
WG-prioritization assigning priority (). I'll mark this as because it seems an unintended breaking change and therefore should probably be fixed before entering into stable. label -I-prioritize +P-critical

<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: opaque types got hidden types registered from within subtype predicate: Alias(Opaque, AliasTy { args: [], defid: DefId(0:25 ~ ice[ee90]::Tait::{opaque}) }) vs Continuation', 'error: internal compiler error: opaque types got hidden types registered from within subtype predicate: Alias(Opaque, AliasTy { args: [], defid: DefId(0:25 ~ ice[ee90]::Tait::{opaque}) }) vs Continuation' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion 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 [typeofopaque] computing type of opaque [typeof] computing type of [checkwellformed] checking that is well-formed [checkmodtypewf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate -- label +F-typealiasimpl_trait
bit smaller
Change:
<ins> error: features `const_generics` and `min_const_generics` are incompatible, using them at the same time is not allowed --> $DIR/min-and-full-same-time.rs:1:12 | LL | #![feature(const_generics)] |            ^^^^^^^^^^^^^^ ... LL | #![feature(min_const_generics)] |            ^^^^^^^^^^^^^^^^^^ | = help: remove one of these features error: aborting due to previous error </ins>

Discussion:
I expect the code below code to compile, but it fails. should allow more than just the types whitelisted in , but it seems rustc only looks at the flag in this case. The error message is:
You are right But why would you want to use the two of them?
I imagine this to happen whenever at first you only decide to use , but then later also switch to . You might just follow rustc, which tells you to add to your project, so you do, but then you get the behaviour as described in this issue. This could also perhaps get triggered in a more subtle way where you write a library that uses to enable or disable features.
what do you think ?
It probably makes sense to instead check if we are not using here, but there are a quite a few places were we check for , we maybe want to instead emit an error/warning when using both and in the same crate.
Created a way to produce an error in case of incompatible features, like this one
I have one question, how does using 'incompatible feature' cause maybe undefined behavior? Are there other incompatible features? In this case, wouldn't it be better to produce an error message like "feature(constgenerics) is a superset of feature(minconst_generics)"?
Note that: results in a : So currently is not a superset of .
You are missing a in your feature. I still think constgenerics are a superset of minconstgenerics, but rustc just suggest using the smaller one in this case becouse that's the subset aiming to be stabilized for now
Ah of course, my bad I was confused looking at some ui tests for const generics, and missed that those now have support differentiating between expected behavior under and , and thought a particular error was always being thrown, instead of only under .
Change:
if def.is_union() { if def.repr.pack.is_some() && def.repr.align.is_some() { <del> bug!("union cannot be packed and aligned"); </del> <ins> self.tcx.sess.delay_span_bug( tcx.def_span(def.did), "union cannot be packed and aligned", ); return Err(LayoutError::Unknown(ty)); </ins> } let mut align =

Discussion:
: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Can't reproduce, can you provide the full code that's needed to reproduce this?
Sure
MCVE:
Assigning as discussed as part of the and removing . label -I-prioritize +P-medium
bisection: searched nightlies: from nightly-2020-06-01 to nightly-2021-03-17 regressed nightly: nightly-2020-10-27 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Change:
pub fn span_err(&self, sp: Span, m: &str) { self.sess.span_diagnostic.span_err(sp, m) } <ins> pub fn struct_span_err(&self, sp: Span, m: &str) -> DiagnosticBuilder<'a> { self.sess.span_diagnostic.struct_span_err(sp, m) } </ins> pub fn span_err_help(&self, sp: Span, m: &str, h: &str) { let mut err = self.sess.span_diagnostic.mut_span_err(sp, m); err.help(h);

Discussion:
Consider the following code: If you try to compile this, you get the following errors: See the bug? Its because I used when I should have used It would be nice if the compiler, in its ever friendly manner, suggested the latter to me.
I volunteer.
Change:
{}n ------------------------------------------n n", <del> expected, actual </del> <ins> expected, actual) </ins> ); } }

Discussion:
Since the check no longer panics on failure. It is obvious in the commit that the invocation is removed from the check, and no other changes are made in the function to remedy it. It can be verified by adding a new pretty test case like: The resulting pretty printed file is slightly different, the comparison fails and the message is logged, but the test continues into the type check, which fails for a different reason and then panics. If you fix the type check (by adding the module and fn main) then the whole test passes and the error message is swallowed even though the source comparison is still not matching.
Change:
} (VarValue::Empty(a_ui), VarValue::Value(b)) => { match *b { <del> ReLateBound(..) | ReErased | ReError(_) => { </del> <ins> // this is always on an error path, // so it doesn't really matter if it's shorter or longer than an empty region ReError(_) => false, ReLateBound(..) | ReErased => { </ins> bug!("cannot relate region: {:?}", b); }

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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
are you working on this?
yes
Change:
fn next(&mut self) -> Option<T> { self.rx.recv().ok() } } <ins> #[unstable(feature = "receiver_try_iter", issue = "34931")] impl<'a, T> Iterator for TryIter<'a, T> { type Item = T; fn next(&mut self) -> Option<T> { self.rx.try_recv().ok() } } </ins> #[stable(feature = "receiver_into_iter", since = "1.1.0")] impl<'a, T> IntoIterator for &'a Receiver<T> { type Item = T;

Discussion:
Tracking issue for the new non-blocking iterator API introduced in . The API is currently gated behind the unstable feature. The API includes: - cc
Hey folks, just thought I'd ping this and ask if there's anything I can do to help guide this towards stable? Would love to start using it, but no worries if it's just low on the priority list :+1:
I'd like to know the same thing as mitchmindtree. Is this being guide towards stable?
fcp merge Seems like a nifty API to have!
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, 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: psst I wasn't able to add the label, please do so.
The final comment period is now complete.
Change:
use std::str::FromStr; use crate::core::build_steps::compile::CODEGEN_BACKEND_PREFIX; <ins> use crate::core::build_steps::llvm; </ins> use crate::core::config::flags::{Color, Flags, Warnings}; use crate::utils::cache::{Interned, INTERNER}; use crate::utils::channel::{self, GitInfo};

Discussion:
The profile is intended not just for people working on LLVM itself, but also anyone who touches codegen but not LLVM. For example, anyone who modifies or is only changing the IR we send to LLVM, not LLVM itself. We should keep on for them but not for , but ideally we wouldn't build LLVM from source if it's unmodified. points out some things that we should fix before enabling that option by default for the profile: Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim Should all 3 tasks be in one PR or is it 3 separate PR's?
I'd say it depends how challenging they are - if it's simple to fix all three in one PR that seems fine, but if it takes a more than a day to do one of the tasks, it probably makes sense to open a PR for it early.
I think I can tackle points 1 and 3 by tonight so I'll make that into one PR. I'll open a separate PR for the second point, since I think it has more work involved, if that's alright :)
release-assignment
Change:
<ins> // Do not try to evaluate static initalizers that reference // ill-defined types. This used to be an ICE. // See issues #125842 and #124464. struct Struct { field: Option<u8>, field: u8, //~^ ERROR field `field` is already declared } static STATIC_A: Struct = Struct { field: 1 }; static STATIC_B: Struct = { let field = 1; Struct { field, } }; fn main() {} </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. --:
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:
<del> Subproject commit 52a6a4d7087d14a35d44a11c39c77fa79d71378d </del> <ins> Subproject commit d549d85b1735dc5066b2973f8549557a813bb9c8 </ins>

Discussion:
LLVM 7.0 has been branched as of 2018-08-01, with the final tag probably a couple weeks away. The first release candidate will be tagged in a couple of days. is the llvm-dev announcement, and is a view of the commits on the branch. Once the final release has been tagged, Rust should be updated to LLVM 7.0.
Great! I've started our branches: I'm hoping that this'll be pretty smooth since we upgraded most of the way through the cycle! I'm testing locally now and will send a PR once green.
Change:
<ins> #![feature(existential_type)] pub trait Bar<T> { type Item; } existential type Foo: Bar<Foo, Item = Foo>; //~^ ERROR: cycle detected when processing `Foo` fn crash(x: Foo) -> Foo { x } fn main() { } </ins>

Discussion:
Playing with the nighly's existential types, I stumbled upon a compiler stack overflow: Error message:
A better example might be this: removing the from the existential type decleration just compiles fine
Can you try running the compiler inside gdb and produce a backtrace?
<details<summaryBacktrace:</summary</details
It's recursing in Ideally this should cause cycle errors. But I'm assuming Manually computes this without a query. Maybe we should just make a query? This would solve both the FIXME and this issue.
Both examples now produce a cycle error. So we just need to add the two examples to (if there aren't already tests for these situations)
Change:
/// /// # Errors /// <del> /// Errors if the environment variable is not present. /// Errors if the environment variable is not valid Unicode. If this is not desired, consider using /// [`var_os`]. /// /// # Panics /// /// This function may panic if `key` is empty, contains an ASCII equals sign /// `'='` or the NUL character `'0'`, or when the value contains the NUL /// character. </del> <ins> /// Returns `[None]` if the environment variable isn't set. /// Returns `[None]` if the environment variable is not valid Unicode. If this is not /// desired, consider using [`var_os`]. </ins> /// /// # Examples ///

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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Simplified. The other malformed-looking bytes don't matter, do they?
You are right, they don't. I should have simplified it before submit.
Going to have a go at this. If I can't figure it out, I'll either ask for help or unassign myself. claim
Still working on this, but I figured an update may be helpful. My research indicates that the two characters that are potentially problematic are and . The work that needs to be done consists of 1) updating the macro expansion functions in to error in these cases; and 2) updating the macro documentation in to mention the new errors. Edit: It just occurred to me that I also need to add UI tests. Haven't figured out where to do that yet, but I will.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
I don't think just adding a check to raise error in these cases would be enough. The function shouldn't really panic (from the internals discussion). Another problem is when the OS supports this kind of environment variable. e.g. as key. would deny it while it can be valid i.e. a false positive. You should still keep your work though (and eventually open a PR) as this must be changes to which would take a while.
If this is going to be fixed upstream in in even the mid-term future, I'm not sure fixing it here makes sense. Sure, it generates an ICE, but the ICE has an unusually helpful error message.
Actually, simple solution: I'll do the fix.

Working on that now.
Was this fuzzer output? If so, which fuzzer were you using
Yes, I am using kira, a work-in-progress fuzzing tool
Have you considered sorry using structure-aware fuzzing? That could help find bugs not just in the lexer and parser, but also in the middle and back ends.
Yes, actually kira is structure-aware.
Change:
mod issue9909 { #![allow(clippy::identity_op, clippy::unwrap_used, dead_code)] <ins> #[allow(unconditional_panic)] </ins> fn reduced() { let f = &[1, 2, 3];

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: Instead, this happened: Apparently, taking a shared reference of will suppress the lint. This seems like a false negative. While false negatives can't be avoided entirely, this case seems to be avoidable as taking a shared reference shouldn't change the type of (which is ) or modify any data in this example. Note that will trigger the lint properly. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
See also .
claim
Note this is a problem because which is supposed to fail to compile but this bug makes it fail at runtime instead
In case no one has dug into it yet, the error is suppressed in but not in and before:
label +regression-from-stable-to-stable
WG-prioritization assigning priority (). label -I-prioritize +P-medium
This is caused by . It only ever worked because the lint ran after optimizations. I made a fix . It specializes the length of arrays as constant, even if the array isn't. I'm going to open a PR when I have time, probably tomorrow. In the long term, I'd like to implement some more extensive tracking of "what parts of a value are constant". For example, the compiler currently assumes that anything that had its reference taken can change, but actually, this can only happen inside (as I understand it).
Labels from the closed duplicate , label A-diagnostics, A-lint, A-mir-opt, T-compiler.
Fixed on stable label E-needs-test
I claim the add test part
This lint only appears on full builds (not check), but this will be fixed once lands.
Reopening because I feel this is not yet solved, see on . As per the , should nail down this issue?
MRE: Also, duplicate of
Another variant of this same issue:
Change:
<ins> #![feature(intrinsics)] #![feature(staged_api)] #![crate_name = "foo"] #![stable(since="1.0.0", feature="rust1")] extern "rust-intrinsic" { // @has 'foo/fn.transmute.html' // @has - '//pre[@class="rust fn"]' 'pub const unsafe extern "rust-intrinsic" fn transmute<T, U>(_: T) -> U' #[stable(since="1.0.0", feature="rust1")] #[rustc_const_stable(feature = "const_transmute", since = "1.56.0")] pub fn transmute<T, U>(_: T) -> U; // @has 'foo/fn.unreachable.html' // @has - '//pre[@class="rust fn"]' 'pub unsafe extern "rust-intrinsic" fn unreachable() -> !' #[stable(since="1.0.0", feature="rust1")] pub fn unreachable() -> !; } extern "C" { // @has 'foo/fn.needs_drop.html' // @has - '//pre[@class="rust fn"]' 'pub unsafe extern "C" fn needs_drop() -> !' #[stable(since="1.0.0", feature="rust1")] pub fn needs_drop() -> !; } </ins>

Discussion:
and are both listed as const in 1.56 according to the "since" info on the right, but only the version lists in the actual signature. core: std:
I took this screenshot in : ! So it's fixed. Closing then.
I don't think this has been fixed yet. (note that this issue is about , not ) <img width="1009" alt="core" src="https://user-"
Oh you're right. Re-opening.
Change:
<ins> // check-pass // edition:2021 #![feature(async_fn_in_trait)] #![allow(incomplete_features)] pub trait Foo { async fn foo(&mut self); } impl<T: Foo> Foo for &mut T { async fn foo(&mut self) {} } fn main() {} </ins>

Discussion:
gives Build using the Nightly version: 1.67.0-nightly (2022-10-31 ) label F-asyncfnin_traits C-bug requires-nightly
searched nightlies: from nightly-2022-10-22 to nightly-2022-11-01 regressed nightly: nightly-2022-10-29 searched commit range: regressed commit: ' likely
Another repro which I believe is the same bug:
Change:
super::ConstEvalFailure(ref err) => tcx.lift(&**err).map(|err| super::ConstEvalFailure( err.into(), )), <del> super::Overflow => bug!(), // FIXME: ape ConstEvalFailure? </del> <ins> super::Overflow => Some(super::Overflow), </ins> } } }

Discussion:
Steps to reproduce:
I assume this is the same as
Running into this as well when running on 1.30.0-nightly ( 2018-08-05)
Hit this on the newest nightly ( 2018-08-18)
Same issue, slightly different line number Filtered log:
any idea what's going on here? let us know if you need T-compiler help :)
I didn't check yet, still on my todo list. I'll give it a look this week-end.
It would be great to have a minimized example here =)
True, I'll try to make one.
I think this is the same as as well
visited for triage. PR just needs to be landed.
Reopening; since we never backported , rustdoc ICE's on typenum again.
visiting for triage. It looks like PR is on target to be backported to stable. (In fact, the recent update of the labels to say just leads me to assume that the backport has occurred... yes, it was part of PR )
So, only two questions I have now: I openly mused to myself during this triage session that the failure to backport to beta sooner may represent a process failure of some sort. But there may be a very simple fix: Can/should we revise bors to not autoclose issues that are tagged as stable-to-beta or stable-to-stable regressions? Filed as barosl/homu On the subject of closing: Can we close this issue in light of ? Or do we need to wait until the 1.30.1 point release has officially been deployed?
Closed since 1.30.1 was released already.
Change:
<ins> error[E0282]: type annotations needed --> $DIR/one-param-uninferred.rs:15:23 | LL |     let _: [u8; 17] = foo(); |                       ^^^ cannot infer the value of const parameter `M` declared on the function `foo` | help: consider specifying the const argument | LL |     let _: [u8; 17] = foo::<M>(); |                       ^^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0282`. </ins>

Discussion:
At the moment, we simply emit errors like: It would be good to suggest to the user how to fix this, like with uninferred type arguments.
cc
Stu over has picked this issue up.