jiebi/CodeConvo huggingface dataset:
Change:
<ins> // run-pass // only-32bit too impatient for 2⁶⁴ items // compile-flags: -C overflow-checks -C opt-level=3 fn main() { let i = (0..usize::max_value()).chain(0..10).skip(usize::max_value()); assert_eq!(i.count(), 10); } </ins>

Discussion:
currently calls on the inner iterator but that can overflow even if the itself doesn't return more that items. For example: This should return but currently triggers an (or returns if overflow checks are disabled). This is caused by which was in which was merged between versions 1.0 and 1.1.
This could probably be fixed by calling and then relying on .
I think it doesn't fix because is very slow, right?
Should be overridden for ranges though.
Change:
|             ^^^^^^ help: try using one of the enum's variants | <del> LL |     let x = std::prelude::v1::Option::None(1); |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ LL |     let x = std::prelude::v1::Option::Some(1); |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ </del> <ins> LL |     let x = std::option::Option::None(1); |             ^^^^^^^^^^^^^^^^^^^^^^^^^ LL |     let x = std::option::Option::Some(1); |             ^^^^^^^^^^^^^^^^^^^^^^^^^ </ins> error[E0532]: expected tuple struct/variant, found enum `Option` --> $DIR/issue-43871-enum-instead-of-variant.rs:21:12

Discussion:
The test appears to be intermittently changing its output. Usually, it prints: but sometimes it prints: See for an example of this happening. Here's a log snippet from a compiler build which prints (the current expected output): Note - this indicates that the chosen (which is what actually gets printed) is Output from a compiler which prints : Note - here, the is . There appears to be some non-determinism occuring, but I'm not sure where.
This is blocking - some builders are printing while others are printing , making it impossible to merge.
Change:
pub extra_io: Vec<Option<io::PipeStream>>, } <ins> /// A representation of environment variable name /// It compares case-insensitive on Windows and case-sensitive everywhere else. #[cfg(not(windows))] #[deriving(PartialEq, Eq, Hash, Clone, Show)] struct EnvKey(CString); #[doc(hidden)] #[cfg(windows)] #[deriving(Eq, Clone, Show)] struct EnvKey(CString); #[cfg(windows)] impl Hash for EnvKey { fn hash(&self, state: &mut SipState) { let &EnvKey(ref x) = self; match x.as_str() { Some(s) => for ch in s.chars() { (ch as u8 as char).to_lowercase().hash(state); }, None => x.hash(state) } } } #[cfg(windows)] impl PartialEq for EnvKey { fn eq(&self, other: &EnvKey) -> bool { let &EnvKey(ref x) = self; let &EnvKey(ref y) = other; match (x.as_str(), y.as_str()) { (Some(xs), Some(ys)) => { if xs.len() != ys.len() { return false } else { for (xch, ych) in xs.chars().zip(ys.chars()) { if xch.to_lowercase() != ych.to_lowercase() { return false; } } return true; } }, // If either is not a valid utf8 string, just compare them byte-wise _ => return x.eq(y) } } } </ins> /// A HashMap representation of environment variables. <del> pub type EnvMap = HashMap<CString, CString>; </del> <ins> pub type EnvMap = HashMap<EnvKey, CString>; </ins> /// The `Command` type acts as a process builder, providing fine-grained control /// over how a new process should be spawned. A default configuration can be

Discussion:
The following program demonstrates the problem: When compiled and executed on WIndows, it randomly displays either 'foo' or 'BAR'. This happens because process::Command represents environment block as a HasMap<CString, CString, so it treats "foo" and "FOO" as different variables, whereas Windows considers them to be the same one. When child process is spawned, both get into the environment block, however Windows keeps only the last one.
Change:
use rustc_unicode::str::Utf16Item; use borrow::{Cow, IntoCow}; <del> use str::{self, FromStr, Utf8Error}; </del> <ins> use range::RangeArgument; use str::{self, FromStr, Utf8Error, Chars}; </ins> use vec::{DerefVec, Vec, as_vec}; /// A growable string stored as a UTF-8 encoded buffer.

Discussion:
cc
The rfc says It also includes an example which depends on usize: However RangeArgument only implements the first four. Furthermore as things stand it does not appear possible to accept RangeArgument<usizeand usize simultaneously, because dispatch doesn't consider the trait bound and reports that conflicting implementations exist.
Yes, was explicit about these issues. I forsee a new RFC to finish off drain and maybe the RangeArgument trait.
I believe this has
Change:
<ins> error[E0425]: cannot find value `HashesEntryLEN` in this scope --> $DIR/issue-109141.rs:10:32 | LL | struct EntriesBuffer(Box<[[u8; HashesEntryLEN]; 5]>); |                                ^^^^^^^^^^^^^^ not found in this scope | help: you might be missing a const parameter | LL | struct EntriesBuffer<const HashesEntryLEN: /* Type */>(Box<[[u8; HashesEntryLEN]; 5]>); |                     ++++++++++++++++++++++++++++++++++ error[E0596]: cannot borrow `*self.0` as mutable, as it is behind a `&` reference --> $DIR/issue-109141.rs:6:9 | LL |         self.0.iter_mut() |         ^^^^^^^^^^^^^^^^^ `self` is a `&` reference, so the data it refers to cannot be borrowed as mutable | help: consider changing this to be a mutable reference | LL |     fn a(&mut self) -> impl Iterator { |          ~~~~~~~~~ error: aborting due to 2 previous errors Some errors have detailed explanations: E0425, E0596. For more information about an error, try `rustc --explain E0425`. </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
searched toolchains through Regression in
Triage: Fixed on the latest nightly, labels: +E-needs-test
Change:
ptr: &'a T, } <ins> #[derive(SmartPointer)] #[repr(transparent)] struct PointeeOnField<'a, #[pointee] T: ?Sized> { #[pointee] //~^ ERROR: the `#[pointee]` attribute may only be used on generic parameters ptr: &'a T } #[derive(SmartPointer)] #[repr(transparent)] struct PointeeInTypeConstBlock<'a, T: ?Sized = [u32; const { struct UhOh<#[pointee] T>(T); 10 }]> { //~^ ERROR: the `#[pointee]` attribute may only be used on generic parameters ptr: &'a T, } #[derive(SmartPointer)] #[repr(transparent)] struct PointeeInConstConstBlock< 'a, T: ?Sized, const V: u32 = { struct UhOh<#[pointee] T>(T); 10 }> //~^ ERROR: the `#[pointee]` attribute may only be used on generic parameters { ptr: &'a T, } #[derive(SmartPointer)] #[repr(transparent)] struct PointeeInAnotherTypeConstBlock<'a, #[pointee] T: ?Sized> { ptr: PointeeInConstConstBlock<'a, T, { struct UhOh<#[pointee] T>(T); 0 }> //~^ ERROR: the `#[pointee]` attribute may only be used on generic parameters } </ins> // However, reordering attributes should work nevertheless. #[repr(transparent)] #[derive(SmartPointer)]

Discussion:
I tried this code: I expected to see this happen: compilation failure Instead, this happened: compilation succeeded <!-- 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. --: cc see for where to fix this issue <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim
Oops sorry. You can continue with your PR.
Change:
<ins> // Copyright 2015 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. // error-pattern: too big for the current architecture #[cfg(target_pointer_width = "32")] fn main() { let x = [0usize; 0xffff_ffff]; } #[cfg(target_pointer_width = "64")] fn main() { let x = [0usize; 0xffff_ffff_ffff_ffff]; } </ins>

Discussion:
A fixed-length array expression with a repeat count with the high bit set and no suffix is incorrectly treated as a negative count. On a 64-bit machine: This results in
Can be easily fixed after landed
Seems that it is not an issue any more.
I'm thinking that if it behave differently on different platforms, is it making it an undefined behavior? And I think designating an exact behavior for UB cannot possibly be a breaking change?
This does not make it undefined behavior. It's very much defined behavior. If it were undefined behavior, then any or literal would be undefined behavior as well, because the range of valid values is architecture-dependent.
Change:
#[rustc_const_unstable(feature = "const_ascii_ctype_on_intrinsics", issue = "68983")] #[inline] pub const fn is_ascii_alphanumeric(&self) -> bool { <del> self.is_ascii() && (*self as u8).is_ascii_alphanumeric() </del> <ins> match *self { '0'..='9' | 'A'..='Z' | 'a'..='z' => true, _ => false, } </ins> } /// Checks if the value is an ASCII decimal 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:
if self.trait_has_sized_self(trait_def_id) { violations.push(ObjectSafetyViolation::SizedSelf); } <del> if self.supertraits_reference_self(trait_def_id) { </del> <ins> if self.predicates_reference_self(trait_def_id, false) { </ins> violations.push(ObjectSafetyViolation::SupertraitSelf); }

Discussion:
the following generates a compiler error on all current versions: RUST_BACKTRACE hangs for me, but emits: error: internal compiler error: Unexpected type in full type resolver: FreshTy(0) This is greatly cut down from a real world example, and a blocking issue for me
This is a regression of the release (over ) of rust.
triage: P-medium Pretty old regression, barely qualifies. =) However, says he has a fix.
Oh sorry, disregary my comment above, the issue is reproducible on 1.3.0 as well as on stable 1.0.0. Its not a regression, at least not one from a stable rust release.
Change:
// version of `debugging_opts.borrowck`, which is just a plain string. borrowck_mode: BorrowckMode [UNTRACKED], cg: CodegenOptions [TRACKED], <del> // FIXME(mw): We track this for now but it actually doesn't make too //            much sense: The value of this option can stay the same //            while the files they refer to might have changed on disk. externs: Externs [TRACKED], </del> <ins> externs: Externs [UNTRACKED], </ins> crate_name: Option<String> [TRACKED], // An optional name to use as the crate for std during std injection, // written `extern crate std = "name"`. Default to "std". Used by

Discussion:
I was trying to determine if sccache could cache crates built as dependencies of different root crates. When I looked into it I found that the rlibs were not bit-identical despite being built from the same source. Most of the differences were in the debug info because the current directory winds up encoded there. I tried using which removed most of the differences but not all. A small difference in the metadata remains, which from looking at the diff of the serialized metadata said was the . do you know why this would be? I built this twice in different directories using the script. The diff of the rlib from each build (I generated that using .) Presumably this would block and also
Lots of stuff goes into the SVH. It might well be that something directory related accidentally goes into it. The SVH is computed here:
cc This is similar to the GCC build-path issue where other programs (and in the past, GCC's DWATproducer) likes to embed CFLAGS into the output. Suggested options: out -Zremap-path-prefix away from that SVH calculation - but other programs that also embed RUSTFLAGS or similar, would also need similar logic the envvar or something similar cargo support a constant flag (whose value does not depend on build-path) that figures out the right -Zremap-path-prefix for rustc so they don't need to appear in RUSTFLAGS. you'd also need to implement (1) but at least the caveat (about other programs) doesn't apply.
addresses (1), which is kind of orthogonal to (2) and (3) because the SVH will always be part of the output binary and it must change if the result of the mapping changes.
With the latest Rust nightly: which includes the fix from , the outputs from are still not the same:
I think we may still be hashing arguments?
Yes, it seems we do: Good catch! Not sure if we have to hash those at this point. The tracking system should catch resulting changes later on, if we don't have any holes in the tracking. This needs some review.
Edit: never mind - seems fixed now that I've rebased to master. I found that (after implementing it) still affects the SVH, even if the mapping does nothing: will generate different metadata hashes if I change the mapping, even though it doesn't affect anything and nothing else changes.
Change:
<ins> #![feature(type_alias_impl_trait)] type Foo = impl Fn() -> Foo; fn foo() -> Foo { foo //~ ERROR: overflow evaluating the requirement `fn() -> Foo {foo}: Sized` } fn main() {} </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:
v.visit_expr(&**expr); let g = consts::trans_static(ccx, m, expr, item.id, &item.attrs); <ins> set_global_section(ccx, g, item); </ins> update_linkage(ccx, g, Some(item.id), OriginalTranslation); }, ast::ItemForeignMod(ref foreign_mod) => {

Discussion:
I compile the code below: using compiler version 1.3.0-nightly ( 2015-07-27) with the following command line: As result I get the following symbol inside a produced rlib:
How'd you verify this? I tried a few variants myself and it looks like it works.
It's broken in Nightly release. Try the following code in after choosing 'Asm' and 'Nightly'.
Aha, looks like I was using an older nightly. cc some informal bisecting turns up as a suspicious commit
Yes, that bisection is correct; PR coming up.
Change:
<del> command script import "$RUSTC_SYSROOT/lib/rustlib/etc/lldb_lookup.py" </del> type synthetic add -l lldb_lookup.synthetic_lookup -x ".*" --category Rust type summary add -F lldb_lookup.summary_lookup  -e -x -h "^(alloc::([a-z_]+::)+)String$" --category Rust type summary add -F lldb_lookup.summary_lookup  -e -x -h "^&str$" --category Rust

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: To be able to use lldb commands as I can if I use lldb directly Instead, this happened: error: file specified in --source (-s) option doesn't exist: 'lldbcommands' <!-- 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 same happens on a macOS machine I saw that is on directory together with shell script, and I also saw that script calls it directly, but I'm not sure how it should behaves in my machine since the is not there (rustup is not installing it) I've asked it on Rust users forum, and also in the discord chat, but no answers, so I'm considering it a bug, feel free to close it if it is something wrong with my installation and, if possible, guide me on where should I look to fix it.
cc who introduced in . I also notice the script references which isn't set anywhere.
The issue happens because expects and its dependencies resides on the current directory. Just to let you know that I got it working doing this: Cloned this repo on : Edit changing the first line to: Then run the following to link the files to the current directory:
Another important highlight, as mentioned, this is a recent change, so 1.45 was working fine and the issue appeared only on 1.46
Change:
<ins> // aux-build: issue_24843.rs // check-pass extern crate issue_24843; static _TEST_STR_2: &'static str = &issue_24843::TEST_STR; fn main() {} </ins>

Discussion:
When learning async/await feature I was struggling with running multiple tasks simultaneously. Loop causes compiler to crash Github Action crash output: I expected to see this happen: Error message if something goes wrong. Instead, this happened: Compiler crashed Crash happens on macOS rustc 1.40 / Linux rustc 1.40 / Linux rustc 1.39 ( github actions ) :
If you could provide an example that ICEs in e.g. the playground that would be helpful towards fixing the issue. :)
Provided example is pretty small, but it is dependent on tokio and actix-web. I do not know how to create such an example in playground, I do know know how I can replace async tokio::sync::mpsc with standard library which does not have async alternative as far as i know. I have tried to simplify code but then crash disappear. Just putting everything into one file and crash is gone, code wont compile and reasonable errors show up.
Visiting from triage.. we decided that as the first step we should reduce this reproducer to a more self-contained one.
Can repro. Will try and min.
Reduced version so far is here:
This no longer ICEs on the latest nightly.
Let's see if we can shrink further so that we can add a test. ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
I’ve reduced it quite a bit. Down to dependencies on only. Appears to need 2 crates.

I hit this problem while trying to make a task joining function. The problem occured when I started messing around with Arc<RwLock<FuturesUnordered. The nightly compiler crashes on this too. Problematic code: Clone the smtpbis repo on the rustice branch. : rustc 1.39.0 ( 2019-11-04) binary: rustc commit-hash: commit-date: 2019-11-04 host: x86_64-unknown-linux-gnu release: 1.39.0 LLVM version: 9.0 Backtrace:
for exact reproduction:
Does this reproduce on nightly?
yes, I get the error using rustc 1.41.0-nightly ( 2019-11-28)
line seems to be the culprit. It only exhibits when going over crate bound (at least I couldn't minify it further). in the binaries folder:
cc
triage: P-high, at least to identify whether this is a long-standing bug or a stable-to-stable regression. Removing nomination.
This won't build on 1.30:
Removing and as the bug's been fixed in , but leaving open to add a regression test.
I'm confused. Did you add a testcase for this or not?
As discussed in , we didn't add the test case there due to diffs of diagnostics on some environment.