jiebi/CodeConvo huggingface dataset:
Change:
} } <del> pub fn demand_eqtype_pat( </del> <ins> pub fn demand_eqtype_pat_diag( </ins> &self, cause_span: Span, expected: Ty<'tcx>, actual: Ty<'tcx>, match_expr_span: Option<Span>, <del> ) { </del> <ins> ) -> Option<DiagnosticBuilder<'tcx>> { </ins> let cause = if let Some(span) = match_expr_span { self.cause( cause_span,

Discussion:
Source code:
Please provide the source code needed to reproduce this (or preferably a reduced version of that)
Sourced code provided at the end of the document. I'm willing to provide more info if needed.
Reconstructed from first principles:
The problem occurs here:
triage: has PR. P-high, removing nomination.
Change:
#[test] fn profile_user_dist() { fn get_toml(file: &Path) -> TomlConfig { <del> let contents = if file.ends_with("config.toml") { "profile = "user"".to_owned() } else { assert!(file.ends_with("config.dist.toml")); std::fs::read_to_string(file).unwrap() }; </del> <ins> let contents = if file.ends_with("config.toml") || env::var_os("RUST_BOOTSTRAP_CONFIG").is_some() { "profile = "user"".to_owned() } else { assert!(file.ends_with("config.dist.toml")); std::fs::read_to_string(file).unwrap() }; </ins> toml::from_str(&contents) .and_then(|table: toml::Value| TomlConfig::deserialize(table)) .unwrap()

Discussion:
When setting (for x.py) to a path that doesn't end in a file named (or ) the test fails, due to explicitly asserting that the config file has one of these names (test is ) This could be indicitive of a larger issue, as which is used in many bootstrap tests seems to rely on a concerning amount of external state (this could cause more issues in the future if not resolved, and/or make bootstrap's tests fail when a users config is invalid) If this behavior is intentional, there is a bug in , because the sets which triggers this bug Alternately, could emit an error if RUSTBOOTSTRAPCONFIG is set to an invalid path, with a suggestion on how to fix it (though this seems like a questionable fix) label +C-bug +T-bootstrap
if is accepted, this would be somewhat lower priority (though not fixed)
No, it's not. It's just a logical bug in the test that I will fix quickly.
Change:
<ins> error: function `a` is never used --> $DIR/in-closure.rs:7:12 | LL |         fn a() {} |            ^ | note: the lint level is defined here --> $DIR/in-closure.rs:3:9 | LL | #![deny(dead_code)] |         ^^^^^^^^^ error: constant `A` is never used --> $DIR/in-closure.rs:13:11 | LL |     const A: usize = 1; |           ^ error: aborting due to 2 previous errors </ins>

Discussion:
I tried this code: I expected to see the warning: Instead no warning was reported by the compiler. Observed in nightly, 1.67. Seems like the warning was shown in 1.63 and stopped showing in 1.64.
Bisected to CI has expired so I couldn't automatically bisect further, but looks like a likely candidate
It looks like the issue is that dead code detection doesn't work inside closures and generators (which async functions use in their desugaring) This is denied by 1.63 but allowed on 1.64+. label +regression-from-stable-to-stable Here, the parent of the closure is so checking dead code is skipped.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
<ins> // check-pass #![feature(generators, generator_trait)] #![feature(type_alias_impl_trait)] use std::ops::{Generator, GeneratorState}; use std::pin::Pin; type RandGenerator<'a> = impl Generator<Return = (), Yield = u64> + 'a; fn rand_generator<'a>(rng: &'a ()) -> RandGenerator<'a> { move || { let _rng = rng; loop { yield 0; } } } pub type RandGeneratorWithIndirection<'a> = impl Generator<Return = (), Yield = u64> + 'a; pub fn rand_generator_with_indirection<'a>(rng: &'a ()) -> RandGeneratorWithIndirection<'a> { fn helper<'b>(rng: &'b ()) -> impl 'b + Generator<Return = (), Yield = u64> { move || { let _rng = rng; loop { yield 0; } } } helper(rng) } fn main() { let mut gen = rand_generator(&()); match unsafe { Pin::new_unchecked(&mut gen) }.resume(()) { GeneratorState::Yielded(_) => {} GeneratorState::Complete(_) => {} }; } </ins>

Discussion:
Possibly related to as both ICEs arise from , but this ICE occurs on a different line. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
No longer ICEs since

I tried this code: I expected to see this happen: code compiles successfully Instead, this happened: : : modify labels: +requires-nightly +F-typealiasimpl_trait
This is fixed now

I'm writing a simple Generator that takes a reference to an RNG, and yields values from it. This makes sense as long as the generator doesn't outlive the RNG which it references. I want to name the type of the generator with an existential type, but I can't do so unless I wrap a version of the function that uses an formulation. Here's the direct version which doesn't work and here's the more convoluted version which does and here's a playground link containing both versions, as well as a bit of scaffolding The full error message I'm seeing looks like this
I don't know if this properly counts as a compiler bug, but it feels like one because the "fix" is a very mechanical code transformation.
cc
Yea that's definitely a bug. I'll investigate where this unnamed lifetime is coming from. Maybe I'm accidentally erasing lifetimes somewhere
This is fixed in master. A more minimal example that probably still failed previously (needs to be checked) that doesn't depend on or never type:

I assumed that the following code would be legal, as it does not require indefinitely sized types, but apparently somewhere the existential type is revealed too early: () Errors:
Updated version: This still doesn't compile.
Using min-type-alias-impl-trait (), you get an error. I think this is ok, though, as it is we don't support cyclic types like this. I'm going to mark this as E-needs-test.
If we adopted a different model of impl trait, one where they were more "nominal" and hence could be cyclic, that'd be a different thing.
Change:
#[rustc_const_unstable(feature = "const_ascii_ctype_on_intrinsics", issue = "68983")] #[inline] pub const fn is_ascii_digit(&self) -> bool { <del> self.is_ascii() && (*self as u8).is_ascii_digit() </del> <ins> match *self { '0'..='9' => true, _ => false, } </ins> } /// Checks if the value is an ASCII hexadecimal digit:

Discussion:
I noticed this check: and wondered why it's there. Then someone told me it's there because of the . If you pass a non-ASCII char, the would corrupt that char. That's why the check is there before it. But then I wondered: why isn't this just cast to a bigger data type that includes all Unicode code points? This method (and others) are slower than they have to be. Also see this discussion in Discord with more valuable information:
(I can’t seem to find the relevant part in the middle of this discord stream…) I’m not sure what you mean by “corrupt”. is well defined: it takes the numerical value of the code point (same as ), then truncates to keep the lower 8 bits. equals 0x41, but so does . We want to reject the latter since U+1F041 is not an ASCII upper-case letter. If is implemented in terms of , the ASCII range check is necessary. (It could be a range check to, for example with .) But maybe doesn’t need to be implemented in terms of . Maybe it could duplicate the logic instead. Once upon a time was implemented with a lookup table of 256 entries. A flat lookup table for all of Unicode would be way too big. But these days it’s based on matching a range pattern. Doing the same with a range pattern could also work. That said, would it actually be faster? Maybe the optimizer already does its job well. If you want to work on this, consider adding some benchmark to show that code duplication is worth it.
Oh it seems the Discord link is a bit buggy. Try searching for in the search bar on the Discord server. Then you should get to my message with the discussion below it. One guy also posted this comparison of the instructions generated:
I think the minimal standard here should be a benchmark before we change the implementation. Can you provide that?
I'm not that experienced with Rust yet, sorry. I just wanted to point out this possible performance regression. Shouldn't the instruction amount difference as shown on Godbolt suffice to know that it's slower? vs.
Looking at the assembly, it seems that the problem is the check. These three functions produce : So, it seems that the check is unnecessary. I could make a PR for this.

Here are some benchmarks: So it seems that removing the check has a measurable performance difference.
is incorrect. The conversion should happen not for the ASCII check but for the , and the pattern use byte literals like . (Though I expect this won’t affect results much.)
Change:
assert_eq!("foon        bar", s); ``` <del> The second, with a ``, does not trim the spaces: </del> <ins> The second, with a ``, trims the spaces and the newline: </ins> ```rust let s = "foo

Discussion:
From "Strings" chapter: The problem is that a beginner who reads these lines can make a false conclusion that "string slice" and "string literal" mean the same thing, and string slices always has a static lifetime. Comment from newcomer:
To be clear: a string literal is just a string slice that lives forever (because it's a pointer into the binary's rodata or whatever).
yep, but looks like it is not obvious for newcomers. I think we should make these lines in the book more clear.
Yep, always a great thing to do! Just clarifying for whoever wants to fix this up.
Change:
<ins> #[derive(Clone)] struct S; // without Clone struct T; fn foo(_: S) {} fn test1() { let s = &S; foo(s); //~ ERROR mismatched types } fn bar(_: T) {} fn test2() { let t = &T; bar(t); //~ ERROR mismatched types } fn main() { test1(); test2(); } </ins>

Discussion:
we should suggest cloning. Also, we should suggest <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
If we suggest add bound, we don't need dervie , This code will compile:
Change:
} } } <del> hir::ExprKind::Struct(hir::QPath::Resolved(_, path), ..) => { </del> <ins> hir::ExprKind::Struct(qpath, ..) => { let segment = match qpath { hir::QPath::Resolved(_, path) => path.segments.last().unwrap(), hir::QPath::TypeRelative(_, segment) => segment, }; </ins> match self.tables.expr_ty_adjusted(&hir_node).kind { ty::Adt(def, _) if !def.is_enum() => { <del> let sub_span = path.segments.last().unwrap().ident.span; </del> <ins> let sub_span = segment.ident.span; </ins> filter!(self.span_utils, sub_span); let span = self.span_from_span(sub_span); Some(Data::RefData(Ref {

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</detailsThis is a recent regression, since we run this command every day in automation.
Almost certainly a regression from /cc
looks like a 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. --reduced from <!-- 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. --repo @ <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Its a regression from but fortunately the fix is relatively easy. I'll provide a PR soon,

<!-- 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. --code from <!-- 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. --repo is @ <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
another one: another one:
I am on it
Same issue happened after upgraded to the latest version today.
Yes the has not landed yet.
Change:
E0029, "only `char` and numeric types are allowed in range patterns" ); <del> let msg = |ty| format!("this is of type `{}` but it should be `char` or numeric", ty); </del> <ins> let msg = |ty| { let ty = self.resolve_vars_if_possible(ty); format!("this is of type `{}` but it should be `char` or numeric", ty) }; </ins> let mut one_side_err = |first_span, first_ty, second: Option<(bool, Ty<'tcx>, Span)>| { err.span_label(first_span, &msg(first_ty)); if let Some((_, ty, sp)) = second { <ins> let ty = self.resolve_vars_if_possible(ty); </ins> self.endpoint_has_type(&mut err, sp, ty); } };

Discussion:
currently throws E0029: while it should infer the constant to be . modify labels: +T-compiler +A-inference claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I don't think this is incorrect. doesn't refer to a specific constant, it's just an abstract associated constant. works fine.
Hmm, does work, though. But does not. It does seem inconsistent that works and doesn't.
is just , so type inference should kick in here. In fact you can write and inference works just fine. The issue only happens when used in range patterns. I am prototyping a fix right now and it seems that the issue is just that E0029 check happens a little bit early (before unification is performed).
Change:
result::ok(p) { [p] } result::err(p) { [] } } <del> + [fs::connect(fs::connect(self.sysroot, ".cargo"), libdir())] </del> } fn get_target_lib_path() -> fs::path { make_target_lib_path(self.sysroot, self.target_triple)

Discussion:
There's some code for this in cargo now, but it doesn't quite do the right thing. See .
Also worth considering the difference between sysroot and the install prefix - they are not the same. For instance, I never install cargo, always running it out of the build directory, in which case the build directory is sysroot.
I think this is resolved.
Change:
use rustc_middle::mir::visit::{PlaceContext, Visitor}; use rustc_middle::mir::{ AggregateKind, BasicBlock, Body, BorrowKind, Local, Location, MirPhase, Operand, PlaceRef, <del> Rvalue, SourceScope, Statement, StatementKind, Terminator, TerminatorKind, VarDebugInfo, </del> <ins> Rvalue, SourceScope, Statement, StatementKind, Terminator, TerminatorKind, </ins> }; use rustc_middle::ty::fold::BottomUpFolder; use rustc_middle::ty::{self, ParamEnv, Ty, TyCtxt, TypeFoldable};

Discussion:
MIR may contain debuginfo like this after inlining: Here, the field access is treated like a use of the local in MIR visitors (using ), even though it is not an actual use of . Instead, it should be using .
Can you describe where the change needs to be made? The visit method for debuginfo seems to be correct: It shells out to with , and then shells out through some other methods to . isn't getting the PlaceContext that was called with (I guess because the context of a projection is potentially different than that of the local it's projecting), but it seems to do nothing for field accesses: So what part should I change? Thanks!
Looks like the problem is here:
Okay, thank you!
Change:
<ins> error[E0597]: `v` does not live long enough --> $DIR/dropck-union.rs:49:19 | LL |     v.0.set(Some(&v)); //~ ERROR: `v` does not live long enough |                   ^ borrowed value does not live long enough LL | } | - `v` dropped here while still borrowed | = note: values in a scope are dropped in the opposite order they are created error: aborting due to previous error For more information about this error, try `rustc --explain E0597`. </ins>

Discussion:
So it turns out that is a problem: The following code should be rejected by dropck, but . This is a nightly-only (because implementing for unions is unstable) soundness issue. I need unsafe code to exploit it, but above should be a perfectly safe to use type.
regression.
Not without guarantees on union validity :) Remember how third parties can legally write garbage into that's not a valid ? This means neither deref nor drop are safe operation in that interpretation.
No, that's not at all what I was saying. We were discussing basic layout invariants. These are invariants the compiler knows about and exploits for enum layout optimizations; violating them is insta-UB. For example, a reference must be non-NULL and aligned. Even a reference being valid is already not covered here as it cannot expressed in terms of just its bit pattern. However, for private fields, types may have arbitrary additional invariants. I hope we agree that the layout invariant for is simple: Just looking at the type , the only layout invariants we have is that none of the fields can be undef and that the first field must not be NULL. Still, a third party cannot legally write any garbage conforming with these invariants into those fields, like setting to ! Doing this is not insta-UB, but can easily lead to UB on the next call to . This is an example for an extra invariant that the compiler does not know about, that the data structure upholds through privacy and that unsafe code in this module can hence rely on. works the same way, its only field is private for this very reason.
Answered in to avoid offtopic here.
Change:
<ins> #![feature(generic_associated_types)] use std::fmt::Debug; use std::marker::PhantomData; #[derive(Debug)] pub struct TransactionImpl<'db> { _marker: PhantomData<&'db ()>, } #[derive(Debug)] pub struct CursorImpl<'txn> { _marker: PhantomData<&'txn ()>, } pub trait Cursor<'txn> {} pub trait Transaction<'db>: Send + Sync + Debug + Sized { type Cursor<'tx>: Cursor<'tx> where 'db: 'tx, Self: 'tx; fn cursor<'tx>(&'tx self) -> Result<Self::Cursor<'tx>, ()> where 'db: 'tx; } impl<'tx> Cursor<'tx> for CursorImpl<'tx> {} impl<'db> Transaction<'db> for TransactionImpl<'db> { type Cursor<'tx> = CursorImpl<'tx>; //~ ERROR lifetime bound not satisfied fn cursor<'tx>(&'tx self) -> Result<Self::Cursor<'tx>, ()> where 'db: 'tx, { loop {} } } fn main() {} </ins>

Discussion:
Given the following code: The current output is: Error is fixed by adding a where clause to associated type in impl, which is not immediately clear:
GATs issue triage: not blocking. Poor diagnostic, but not a miscompile.
label +D-papercut +D-terse
Current output is I think that's pretty helpful. Going to mark as needs-test
Change:
<ins> error[E0220]: associated type `Cursor` not found for `Lexer<T>` in the current scope --> $DIR/issue-109299-1.rs:10:40 | LL | struct Lexer<T>(T); | --------------- associated item `Cursor` not found for this struct ... LL | type X = impl for<T> Fn() -> Lexer<T>::Cursor; |                                        ^^^^^^ associated item not found in `Lexer<T>` | = note: the associated type was found for - `Lexer<i32>` error: aborting due to previous error For more information about this error, try `rustc --explain E0220`. </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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
searched nightlies: from nightly-2023-02-17 to nightly-2023-03-18 regressed nightly: nightly-2023-02-21 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
cc is this fixed by your branch?
No, it's not. The stacktrace does indeed contain but that's not the root cause of the problem. It just calls which ices (changing it to doesn't help either). The actual (?) bug is probably inside of the code I assume.
Ah, wait. If it's a bug to pass s to the type relating functions then it is the fault of and it should probably return early if a type . Edit: But it that case?
Hm, actually I think we should just fix the relate code instead.
Sure. I also feel like I've seen this ICE message pop up several times already on this issue tracker. I might be mistaken tho.
More minimal:
Reassigning to myself since the approach involving region erasure during selection we talked about fixes this issue (obviously) and since I'd like to integrate this into my PR to be able to write UI tests that exercise the bound region code used during IAT confirmation (otherwise we would never go past selection in those cases). claim label F-inherentassociatedtypes
Change:
error: Undefined Behavior: using uninitialized data, but this operation requires initialized memory --> $DIR/uninit_byte_read.rs:LL:CC | <del> LL |     let undef = unsafe { *v.get_unchecked(5) }; |                          ^^^^^^^^^^^^^^^^^^^ using uninitialized data, but this operation requires initialized memory </del> <ins> LL |     let undef = unsafe { *v.as_ptr().add(5) }; |                          ^^^^^^^^^^^^^^^^^^ using uninitialized data, but this operation requires initialized memory </ins> | = help: this indicates a bug in the program: it performed an invalid operation, and caused Undefined Behavior = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information

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: Compile with on () I expected to see this happen: Both functions should compile to approximately the same thing, with no bounds check on the since the optimizer should be able to see that the slice is at least of length 2 due to the previous unchecked indexing. Instead, this happened: contains a bounds check (only does not contain a bounds check). rustc stable (1.73.0), nightly (2023-10-17), and 1.58.0 (when was stabilized) all have approximately the same codegen. : (no backtrace) label +C-optimization -C-bug
contains an assume intrinsic, doesn't. Might be worth adding it to the latter and see how that impacts perf, it's not guaranteed that it would actually improve things since we'd be emitting more IR and llvm would have to work harder. Commonly it's the case that if one uses one does so for all accesses on the slice, so this seems like an unusual pattern.
Change:
<ins> emulator emulator-linux-5264690.zip 48c1cda2bdf3095d9d9d5c010fbfb3d6d673e3ea patcher;v4 3534162-studio.sdk-patcher.zip 046699c5e2716ae11d77e0bad814f7f33fab261e platform-tools platform-tools_r28.0.2-linux.zip 46a4c02a9b8e4e2121eddf6025da3c979bf02e28 platforms;android-18 android-18_r03.zip e6b09b3505754cbbeb4a5622008b907262ee91cb system-images;android-18;default;armeabi-v7a sys-img/android/armeabi-v7a-18_r05.zip 580b583720f7de671040d5917c8c9db0c7aa03fd tools sdk-tools-linux-4333796.zip 8c7c28554a32318461802c1291d76fccfafde054 </ins>

Discussion:
We already had at least two different CI issues caused by the Android SDK's sdkmanager: a new license was and sdkmanager failed to accept it with the old command the emulator was updated to a broken (at least for us) version, causing all builds to fail The root cause of those issues is that sdkmanager doesn't support any kind of pinning (as far as I can tell), and any change Google makes can break our CI. Should we develop a pinning mechanism and use it for all the Android SDK components? cc