jiebi/CodeConvo huggingface dataset:
Code change:
<ins> error[E0185]: method `example` has a `&self` declaration in the impl, but not in the trait --> $DIR/argument_number_mismatch_ice.rs:8:5 | LL |     fn example(val: ()); |     -------------------- trait method declared without `&self` ... LL |     fn example(&self, input: &i32) { |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `&self` used in impl error[E0594]: cannot assign to `*input`, which is behind a `&` reference --> $DIR/argument_number_mismatch_ice.rs:10:9 | LL |         *input = self.0; |         ^^^^^^^^^^^^^^^ `input` is a `&` reference, so the data it refers to cannot be written error: aborting due to 2 previous errors Some errors have detailed explanations: E0185, E0594. For more information about an error, try `rustc --explain E0185`. </ins>

Related discussion:
text: <!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'index out of bounds: the len is 1 but the index is 1'', 'thread 'rustc' panicked at 'index out of bounds: the len is 1 but the index is 1'' 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: [mirborrowck] borrow-checking [analysis] running analysis passes on this crate --
cc
label +D-diagnostic-infra -needs-triage
Code change:
<ins> // Doc links in `Trait`'s methods are resolved because it has a local impl. // aux-build:issue-103463-aux.rs extern crate issue_103463_aux; use issue_103463_aux::Trait; pub struct LocalType; impl Trait for LocalType { fn method() {} } fn main() {} </ins>

Related discussion:
text: <!-- 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. --Nightly 2022-08-11 worked fine, trying to upgrade from it. : <details<summary<strongBacktrace</strong</summary<p</p</details
, same rustc version
label E-needs-mcve -T-compiler +T-rustdoc
Error: Label needs-mcve can only be set by Rust team members Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
I don't have a MCVE but the same problem on the same nightly version happens with a dependency of . Sounds awfully similar to also involving deps, but that one's definitely fixed.
Pinging since they're the last one who worked on this. Maybe you have an idea?
Somewhat minimal example: Removing the impl avoids the bug.
This happens with beta too:
Fixed in
Code change:
<ins> pub trait Bar: Super<SuperAssoc: Bound> {} pub trait Super { type SuperAssoc; } pub trait Bound {} </ins>

Related discussion:
text: <!-- 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: This compiles fine, however if crateb is a separate crate instead of a local module_, it errors with: This is not fixed by the next solver (). <!-- 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. --:
I was able to narrow this down even further:
yep yep makes sense i'll fix it, sorry
Code change:
fn read_le_u16(r: &mut dyn io::Read) -> io::Result<u16> { let mut b = [0; 2]; <del> let mut amt = 0; while amt < b.len() { match r.read(&mut b[amt..])? { 0 => return Err(io::Error::new(io::ErrorKind::Other, "end of file")), n => amt += n, } } </del> <ins> r.read_exact(&mut b)?; </ins> Ok((b[0] as u16) | ((b[1] as u16) << 8)) } <ins> fn read_le_u32(r: &mut dyn io::Read) -> io::Result<u32> { let mut b = [0; 4]; r.read_exact(&mut b)?; Ok((b[0] as u32) | ((b[1] as u32) << 8) | ((b[2] as u32) << 16) | ((b[3] as u32) << 24)) } </ins> fn read_byte(r: &mut dyn io::Read) -> io::Result<u8> { match r.bytes().next() { Some(s) => s,

Related discussion:
text: does not emit color output when running under a tmux session with set correctly to (supported by the latest versions of ncurses) even with when is set to . On the machine in question (macOS) the term file for is installed and returns the following: Per cargo should be invoking rustc with the flag, and indeed, returns 'Option color given more than once. Executing also does not produce color output, but does.
I have a similar bug on Archlinux. I used to get colored output on this system, but that recently stopped working for rustc. (Cargo is still fine for me.) If I add in and run in , I get Result::unwrap()Err/lib/terminfo/x/xterm-256colorncursesNEWS file does mention a new (incompatible) file format with a different magic number: Could rustc switch to whatever Cargo uses for colored terminal output?
A work-around for my machine was temporarily downgrading the packages, and copying the old file to .
Yes rustc should be able to switch at any time
Thanks for the workaround!
Changing from to also seems to work as a temporary workaround. (note: this may affect other terminal applications)
Another work-around if you're using sh: This sets to a possibly incorrect value, but limits its impact to only the output of a command.
That worked for me as well. I had no colour with . I downgraded to , which was what I had in , and now I have colour again.
I have a similar issue: In my regular terminal emulator (not tmux), there are no colors from rustc (as executed with ), colors from cargo itself are working fine. The default setting for there is: . The problem is fixed by setting to . Inside tmux however, colors work just fine, there seems to be by default.
Colors are fixed in the latest nightly (thanks to o/)
This is fixed for me in today’s nigthly, presumably by
With the current nightly I still have no colors with and have to use as a work around. What might still be broken?
Terminal colors are still broken with . however, does use colors, so there's clearly still a discrepancy between how and use termcolor
It works fine for me with ncurses 6.1, even rustup has colors again since the last version .
Code change:
fn read_le_u16(r: &mut dyn io::Read) -> io::Result<u16> { let mut b = [0; 2]; <del> let mut amt = 0; while amt < b.len() { match r.read(&mut b[amt..])? { 0 => return Err(io::Error::new(io::ErrorKind::Other, "end of file")), n => amt += n, } } </del> <ins> r.read_exact(&mut b)?; </ins> Ok((b[0] as u16) | ((b[1] as u16) << 8)) } <ins> fn read_le_u32(r: &mut dyn io::Read) -> io::Result<u32> { let mut b = [0; 4]; r.read_exact(&mut b)?; Ok((b[0] as u32) | ((b[1] as u32) << 8) | ((b[2] as u32) << 16) | ((b[3] as u32) << 24)) } </ins> fn read_byte(r: &mut dyn io::Read) -> io::Result<u8> { match r.bytes().next() { Some(s) => s,

Related discussion:
text: I’d like to note though that things like destroy this for some reason (even if is set). It took me some time to figure that out
I'm using ncurses 6.1 on Fedora 28 and everything appears to be working fine except for test colors. In mentioned that a bit tricky due to how the build works, but we can always tackle that later. What is the barrier to migrating libtest from to ? For now, it's leaving my test output looking like this. !
I have an in-progress patch for libtest but I ran into I'm guessing that's the build issue that is referring to. I don't know how linking libtest works, but I'm happy to try to fix the build if someone can point me in the right direction.
Code change:
<ins> // run-rustfix fn main() { for _ in 0..=255 as u8 {} //~ ERROR range endpoint is out of range for _ in 0..=(255 as u8) {} //~ ERROR range endpoint is out of range } </ins>

Related discussion:
text: <!-- 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: printing all numbers from 0 to 255 (inclusive) Instead, this happened: : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The error is correct, 256 is indeed out of range for u8. You need to use .
You can run that code if you want, by allowing the lint: if you do you'll see that it will print nothing because the overflows and becomes , so it's which is empty. Examples like this where allowing the literal overflow would do something you don't want are exactly why this lint is deny-by-default
I've renamed this issue because the lint is correct. If there's anything to be done here, it would be to add a range-specific suggestion for this situation to help guide towards the correct code.
claim
Code change:
}, lt_op: |region| { match region { <del> // ignore static regions ty::ReStatic => region, </del> <ins> // Skip static and bound regions: they don't // require substitution. ty::ReStatic | ty::ReLateBound(..) => region, </ins> _ => { trace!("checking {:?}", region); for (subst, p) in opaque_defn.substs.iter().zip(&generics.params) {

Related discussion:
text: cc
Am I correct in assuming that this should not compile, but report an error about returning a reference to the local variable ? Or is the self-borrowing generator part what makes this work? so the is part of the generator struct and the is the yielded thing? I'll try pretty printing to the expanded HIR, since I'm not sure what's going on there
Expanded version:
No, this should definitely compile. isn't yielded, but yes, it's a local variable inside the generator (that references another local variable in the generator).
Hmm, so because the generator contains references, it has lifetimes, but these lifetimes actually refer to the generator again? Do we have a special kind of lifetime that we use for this? We should just ignore those generator lifetimes for existential types.
There's no special lifetime afaik (cc
We should ignore all bound regions. Function pointers have the same issue:
Code change:
// ensure struct variants get warning for their fields enum IJK { <del> I, //~ ERROR variant is never used </del> <ins> I, //~ ERROR variant is never constructed </ins> J { a: String, b: i32, //~ ERROR field is never used c: i32, //~ ERROR field is never used }, <del> K //~ ERROR variant is never used </del> <ins> K //~ ERROR variant is never constructed </ins> }

Related discussion:
text: I was changing some code from integer constants to a proper enum and was greeted by the following warning: The warning sounded weird to me because I was pattern-matching on that damn variant in various places of the code; but I was pointed out to the fact that I wasn't actually creating that value. Maybe the warning should be rewritten to explicitly mention value creation? Cc
cc that looks like your thing
duplicate of
Yup! Closing in favor of that.
Code change:
<ins> // run-rustfix pub enum struct Range { //~^ ERROR `enum` and `struct` are mutually exclusive Valid { begin: u32, len: u32, }, Out, } fn main() { } </ins>

Related discussion:
text: <!-- 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: <!-- The following is not always necessary. --Ideally the output should look like: Highlight to the user that the keywords and are mutually exclusive. Replace with . <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Code change:
<del> Subproject commit d1ddc34c4b23468f6d2bf553084834b104e16dde </del> <ins> Subproject commit 8b6b5014fdad3a750f7242a6bfdcad83619498d4 </ins>

Related discussion:
text: <!-- 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 on AVR (arduino Uno = atmega328p) with opt-level="z": I expected to see this happen: Instead, this happened: An alternate code that emits the correct output is This compiler error is corrupting the pixel stream transmitted via SPI to an ST7789 display from an Arduino Uno. What appears to be happening is that instead of the bytes being swapped, the LSB is being copied to the MSB. I do not have the expertise to decompile and examine the assembly code. : The malfunction also occurs with . The full code can be cloned from <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Since I looked it up, here's the expected/actual in hex, which makes the bug more clear: input: expected: actual:
Hi, Could you please check with ? It feels like a bug nonetheless, but I'm curious about the result
Also: claim
I'm analyzing the codegen bug - simplest reproduction so far:
Got it! The simplest reproduction: This prints ( in hex) instead of ( in hex), because the generated binary accidentally overwrites the high-order byte with the low-order one: ! After calling ( on the screenshot), the returned number - ( in hex) - gets stored into r23:r24 (you can see that r23=0x39, r24=0x30, and AVR being little-endian means the number is reconstructed from r24 first, r23 second). expects its parameter to be stored in , so right before calling , the codegen has a simple job: move into ; and that's where the bug comes into play. What the code generator says is: ... which always sets and to the same value () - what it should generate instead is: Overall, that's an omission on the LLVM's side (when moving register pairs, it should consider whether the registers are overlapping or not) - I'll try to prepare a patch Edit:
I just updated to nightly-2022-07-08 and some weirdness I was seeing with seems to have been fixed.
Code change:
<del> Subproject commit d1ddc34c4b23468f6d2bf553084834b104e16dde </del> <ins> Subproject commit 8b6b5014fdad3a750f7242a6bfdcad83619498d4 </ins>

Related discussion:
text: Under nightly-2022-05-10 I would see this in the serial log: Under nightly-2022-07-08 I get It also fixed the problems I was having with the st7789 crate that led me to file this bug.
Code change:
wShowWindow: 0, cbReserved2: 0, lpReserved2: ptr::null_mut(), <del> hStdInput: c::INVALID_HANDLE_VALUE, hStdOutput: c::INVALID_HANDLE_VALUE, hStdError: c::INVALID_HANDLE_VALUE, </del> <ins> hStdInput: ptr::null_mut(), hStdOutput: ptr::null_mut(), hStdError: ptr::null_mut(), </ins> } }

Related discussion:
text: <!-- 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: App P: App C: Build this in Windows. Since has "windows" subsystem, it will create no console window (i.e. no process). Since is a console app, when the process is created, I expect to see one console window that prints "Hello World" infinitely. App creates its console window but no text is printed. In Windows, spawn() eventually calls to with a , whose  is hard coded to . Additionally, it also with , and set them to the . Since app uses "windows" subsystem, it does not have console. stdout is always . Combining with in causes the unexpected behavior. If I make a call to with same parameters except a "zeroed" , it exhibits the correct behavior. spawn() should only conditionally set the flag if it can obtain those device handles, and never set any of those handles . Like this (pseudo code): <!-- 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. --:
I think this will need a T-libs-api decision as the current documentation for  (and stdin/stderr) is: I would guess that this "inherit by default" is why it's implemented the way it is. But perhaps there's some wiggle room with what it means to inherit handles that don't exist so we can change it. In either case it would be good to have some way to use platform default behaviour here. label -T-libs +T-libs-api
That's exactly my point. If there is nothing to inherit in the first place, just inherit nothing. The current behavior () is simply wrong. I believe fixing it doesn't violate the current specification.
Basically, currently there are only two options when handling the stdout/stderr: inherit or pipe. I think there should be a third option: isolated - make the child handle its console by itself. For example, if user calls and , he basically says "the parent process doesn't care about the child's output". It is the same as the "windows" subsystem case above. In this case, the flag should never be set, regardless if or is called.
Code change:
wShowWindow: 0, cbReserved2: 0, lpReserved2: ptr::null_mut(), <del> hStdInput: c::INVALID_HANDLE_VALUE, hStdOutput: c::INVALID_HANDLE_VALUE, hStdError: c::INVALID_HANDLE_VALUE, </del> <ins> hStdInput: ptr::null_mut(), hStdOutput: ptr::null_mut(), hStdError: ptr::null_mut(), </ins> } }

Related discussion:
text: More importantly, this is de facto the default way of how a process is created in Windows. Defaulting to really makes me confused before reading the internal source code.
Not always. Parent process can still set those handles to something other than . For example, if you launch App P from IntelliJ it actually prints "Hello World!" in a loop but not in the spawned console which is empty, but in IntelliJ internal terminal. returns non invalid handle. This solution would make behaviour different depending on how you launch your app. Also, you can explicitly ask to create new console with even if your app already uses console subsystem. In this case you also likely want to avoid inheriting handles because you want output of the spawned process to be displayed in the new console, not in the existing one. This solution doesn't help with this.
I can't verify your statements since I don't have IntelliJ atm, but even it's true, isn't it IntelliJ setting up the console with maybe some special debugging API? How to you modify the code of P to achieve the same? And realistically speaking, do people actually do that with GUI apps? I think in this case, it's impossible to be 100% sure where the user wants the output at. New option might be the way to go.
Your prediction was dead-on, as it came true in While we can do this, as is proposing, it seems best here that we create a function, or set of functions, that explicitly handle this kind of situation rather than guessing.
Even with new APIs, we still need reasonable default behaviour. And the Command API is documented as inheriting handles by default. However, currently the API neglects the "no handle set" case entirely as that's not really a thing in POSIX or ISO C (well, you can close stdio but that's usually considered a Bad Thing unless you're being very very careful).
Code change:
debug!("Checking must_not_suspend for {}", ty); match *ty.kind() { <del> ty::Adt(..) if ty.is_box() => { let boxed_ty = ty.boxed_ty(); let descr_pre = &format!("{}boxed ", data.descr_pre); </del> <ins> ty::Adt(_, args) if ty.is_box() => { let boxed_ty = args.type_at(0); let allocator_ty = args.type_at(1); </ins> check_must_not_suspend_ty( tcx, boxed_ty, hir_id, param_env, <del> SuspendCheckData { descr_pre, ..data }, </del> <ins> SuspendCheckData { descr_pre: &format!("{}boxed ", data.descr_pre), ..data }, ) || check_must_not_suspend_ty( tcx, allocator_ty, hir_id, param_env, SuspendCheckData { descr_pre: &format!("{}allocator ", data.descr_pre), ..data }, </ins> ) } ty::Adt(def, _) => check_must_not_suspend_def(tcx, def.did(), hir_id, data),

Related discussion:
text: This code here has a potential issue: If the Box has a custom allocator, then that will not be checked at all. So whatever is used for, it ignores anything stored in custom allocators. It seems like this is just for a lint, so this is probably not critical, but I guess should still be fixed. Cc -- not sure whom else to ping for coroutine state machine transform things?
Cc (also a regular occurrence in this file's )
Lol sorry, I thought I had clicked enter on a comment but I must've not. Let me rewrite it. Yeah, this is approximately the level of urgency you determined. This code exists for an unstable lint, . I don't expect people to be writing , but technically they could.
Code change:
impl_from!(u32 => f64, #[stable(feature = "lossless_float_conv", since = "1.6.0")]); // float -> float <del> impl_from!(f16 => f32, #[stable(feature = "lossless_float_conv", since = "1.6.0")]); impl_from!(f16 => f64, #[stable(feature = "lossless_float_conv", since = "1.6.0")]); </del> <ins> // FIXME(f16_f128): adding additional `From` impls for existing types breaks inference. See // <https://github.com/rust-lang/rust/issues/123824> </ins> impl_from!(f16 => f128, #[stable(feature = "lossless_float_conv", since = "1.6.0")]); impl_from!(f32 => f64, #[stable(feature = "lossless_float_conv", since = "1.6.0")]); impl_from!(f32 => f128, #[stable(feature = "lossless_float_conv", since = "1.6.0")]);

Related discussion:
text: After we started seeing the following compile failure: I repro'd this locally on but we have so we're fairly sure that it started with . Of the changes in that rollup is the only one that seemed to touch float stuff, but I'm not sure how adding some extra impls for and would break inference in this case.
cc is it possible that adding the the impls for / may have caused type inference regression here?
It must be, but I don't know why since wasn't touched. Also reproduced locally
When there is only one applicable impl it can guide inference, as soon as there are multiple it can't use those and instead goes to default-numeric-fallback which appears to be for floating point.
Correct.
Just coming to the same conclusion - the literal is getting guided to f32 on stable since that's the only type that fits the , but when there are more options it gets the default float literal type of f64
I'll put up a PR to remove these impls for now but what is the correct longer term fix? cc
label -needs-triage +A-inference +F-f16andf128
Race condition <img width="497" alt="image" src=""
I did not remove the feature label lol (it wasn't even in the list), welldone GitHub
Theoretically, type inference regressions are permitted as part of Rust's 1.0 stability guarantees. In practice, if the regressions are too bad, the changes usually get reverted and are subsequently blocked indefinitely iirc. However, we could make use of editions if the worst comes to the worst. See arrays & . I think we have something similar queued up for Rust 2024. On mobile, can't link.
I put a fix up at and opened to further discuss what we want to do here. Thanks for identifying this so quick!
if you get the chance, could you link some of the places that caused this failure? It would be good to have some references for how this behavior is being relied on in the wild.
that we caught it on. It's a pretty simple case (that type is just an type alias) and seems reasonable to break on an edition boundary (or even just on a release as long as there's a machine applicable suggestion to fix it).
Hi! I'm from the Bevy project.