jiebi/CodeConvo huggingface dataset:
Change:
<ins> fn foo<const N: usize>() -> [u8; N] { bar::<N>() //~ ERROR mismatched types } fn bar<const N: u8>() -> [u8; N] {} //~^ ERROR mismatched types //~| ERROR mismatched types 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
's parameter doesn't have to have an error type; it appears it can be any type (that doesn't trip the full feature gate error.) This version ICEs without any prior diagnostics: Neither version ICEs on beta or stable. (const generics aren't stable on 1.50, but after reporting an error for use of unstable features the compiler reports the same errors as beta and doesn't ICE.) label A-const-generics regression-from-stable-to-nightly
Bisected, this is a weird one:
I've attempted a second bisection using the snippet from the , I got a different result (not sure why, unsure if it helps) searched nightlies: from nightly-2021-02-15 to nightly-2021-03-18 regressed nightly: nightly-2021-03-18 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
I guess that was a lie I'm looking into this
Assigning and removing as in the prioritization working group. label: +P-high -I-prioritize
Change:
<ins> error: <inline asm>:1:9: error: expected string in '.ascii' directive .ascii "Xen ^ --> $DIR/issue-69092.rs:8:14 | LL |     unsafe { asm!(".ascii "Xen0""); } |              ^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error </ins>

Discussion:
: <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'd like to work on this. claim
Now ICE no longer occurs, I think it's fixed by . Marked as E-needstest.

When executed in the : <details<summaryCompiler output</summary</detailsEDIT: Here's the updated and the new stack trace as of Jan 7, 2020: <details<summaryCompiler output</summary</details
cc
I think this is another instance of However, we can leave this issue open to remember to add a test case when it's fixed.
The original issue no longer ICEs and instead errors with: which is essentially correct. However, providing the type annotations produces a new ICE:
In Source: <details<summaryStack trace</summary<p</p</details
Now ICE no longer occurs. I think it's fixed by .

This occurs on 1.34.1 and 1.34.0, is a regression from 1.33.0, and does.. not occur on nightly? Reproduction: compiled with Yields: I found this in building crates like and but pared it down to this
I think this is fixed in which might explain why it doesn't occur on nightly
triage: Probably fixed by . Normally an ICE would lead me to tag this as P-high, but the fact that this is only exposed by leads me to prioritize this as P-medium.
assigning to self to confirm that is the reason this is fixed, and (if need be) add a regression test.
Here's a slightly smaller case of what appears to potentially be the same thing which shows up if you select the "show MIR" option in In particular the following error is observed:
I think this issue is fixed in all channels. I tried stable and nightly both locally and on , and couldn't get any ICEs. Should we add a test? Otherwise we can just close I think.
Adding a test with seems like a good idea.

Compiler crash when using cfgif and defining a macro with macrorules twice. I tried this code: In a repo: I expected to see this happen: error: a macro named has already been exported Instead, this happened: error: internal compiler error: unexpected panic : Backtrace:
Regression from stable to stable (works in 1.30). Reduced test case:
mode is implemented on best effort basis, generally unsupported and will be removed in some time.
Ah, I see, the original issue doesn't have it. I'll investigate.
Reproducer in no longer ICEs.
Change:
<ins> error: <inline asm>:1:9: error: expected string in '.ascii' directive .ascii "Xen ^ --> $DIR/issue-69092.rs:8:14 | LL |     unsafe { asm!(".ascii "Xen0""); } |              ^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error </ins>

Discussion:
results in: Removing the constgenerics feature flag gets the expected error message: (IIUC that itself is a bug related to ) Using directly outside of a const-context works, which I guess is something const_generics enables that isn't otherwise allowed. Finally, the error message is the same whether or not the code is in a provided method or a impl block; I actually ran into the bug in the later.
I believe this should be fixed by
Now, it shows different ICE(s) ():
Now ICE no longer occurs. I think it's fixed by .
Change:
<ins> // Copyright 2014 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. // Test that `&mut T` implements `DerefMut<T>` fn inc<T:DerefMut<int>>(mut t: T) { *t += 1; } fn main() { let mut x: int = 5; inc(&mut x); assert_eq!(x, 6); } </ins>

Discussion:
As titled. Add the following trait implementations: This allows generic code that accepts smart pointer can take references too, e.g.
cc
yes I want this :+1:
This would also allow code to be polymorphic over &T and &mut T by accepting . A huge win imho.
The branch creates some .
Change:
debug!("check_type_bounds: item_bounds={:?}", obligations); for mut obligation in util::elaborate(tcx, obligations) { <del> let normalized_predicate = ocx.normalize(&normalize_cause, normalize_param_env, obligation.predicate); </del> <ins> let normalized_predicate = ocx.normalize(&normalize_cause, param_env, obligation.predicate); </ins> debug!("compare_projection_bounds: normalized predicate = {:?}", normalized_predicate); obligation.predicate = normalized_predicate;

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: compiles, or a helpful error message Instead, this happened: Confusing error message, there doesn't seem to be a future that could be awaited?... Interestingly if the default implementation is removed, it compiles. Playground: <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details
The error message on the playground is a bit different, seems to be correlating with the actual problem more, but even more confusing: Expected and found are the same!
Minimal: Something funky going on with the default projection predicate installed for the GAT. I'll look into it
I'm impressed by the speedy handling of this issue! Was hoping this would get a fix in a few weeks . You're awesome!
Once the pr is merged, it will be available the next day on nightly, correct? Btw, the pr failed some tests.
Change:
<ins> // If the hidden type is a closure, we require the "outlives" bounds that appear on the // defining site to also appear on the opaque type. // // It's not clear if this is the desired behavior but at least // it's consistent and has no back-compat risk. // check-fail #![feature(type_alias_impl_trait)] #![allow(dead_code)] // requires `'a: 'b` bound mod test1 { type Opaque<'a, 'b> = impl Sized + 'a + 'b; //~^ ERROR lifetime bound not satisfied fn define<'a, 'b>() -> Opaque<'a, 'b> where 'a: 'b, { || {} } } // Same as the above but through indirection `'x` mod test2 { type Opaque<'a, 'b> = impl Sized + 'a + 'b; //~^ ERROR cannot infer an appropriate lifetime fn define<'a, 'b, 'x>() -> Opaque<'a, 'b> where 'a: 'x, 'x: 'b, { || {} } } // fixed version of the above mod test2_fixed { type Opaque<'a: 'b, 'b> = impl Sized + 'a + 'b; fn define<'a, 'b, 'x>() -> Opaque<'a, 'b> where 'a: 'x, 'x: 'b, { || {} } } // requires `T: 'static` mod test3 { type Opaque<T> = impl Sized; //~^ ERROR the parameter type `T` may not live long enough fn define<T>() -> Opaque<T> where T: 'static, { || {} } } fn main() {} </ins>

Discussion:
Since the nightly 2022-09-11, the following code doesn't compile anymore. <!-- 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
Minimized it a little
searched nightlies: from nightly-2022-01-01 to nightly-2022-09-30 regressed nightly: nightly-2022-09-11 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
cc
cc
I get the same ICE when using the current nightly in a complex Codebase. The works fine.
I think I minimized this to:

<!-- 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: <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I found this error occurred by this commit through
Probably cc
Minimized: claim label F-typealiasimpl_trait T-compiler
This has caused crate and docs fail to build.
This just upgraded from bad diagnostics to ICE on latest nightly.
Change:
use crate::prelude::*; use rustc_ast::expand::allocator::{AllocatorKind, AllocatorTy, ALLOCATOR_METHODS}; <ins> use rustc_codegen_ssa::base::allocator_kind_for_codegen; </ins> use rustc_session::config::OomStrategy; use rustc_span::symbol::sym;

Discussion:
Building Rust toolchain using latest leads to an error when compiling libtest at stage0: Error is coming from (Enable --no-undefined-version by default.), with the description indicating that our version scripts were not correct. Local workaround is to pass in Rustflags. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I ran into this too. I wonder why rustc is attempting to export those symbols from , but not ? I'm seeing that e.g. works but does not. I can't determine what's different between and that would cause only the latter to output an invalid version script.
This actually repros outside of . If you attempt to compile any crate as a dylib, and is available as a dylib and linked as such (e.g. with the ) flag, you can reproduce the error by simply passing . This was with stable rustc and my system . Hopefully reproducing it outside of Rust's bootstrap will make it easier to debug.
related discussion: https://rust-
I suspect I found the issue: First, early in compilation rustc determines if a crate needs an allocator (whether or not it comes from the crate itself, or a dep). This is filled in a crate metadata struct field: If , the field says whether the crate graph contains a or not, but that's not directly relevant to the bug. This field will usually be ; it's if and are not used. Later, rustc checks whether to codegen the et al functions: Notably, if any dependency is linked as a , it will not generate them and instead link to the implementations exported from another . Independently, rustc determines which symbols to export when generating a and provides this list to the linker. Part of this is deciding whether to export the allocator symbols: Notably it does not perform the check from the last step. Even if a dependency is linked whose allocator symbols this crate should use, the export list still contains these symbol names. So when building a that links another , rustc tells the linker to export symbols that weren't actually defined. The build failure is just one instance of this bug. who helped in the Zulip discussion. Can you confirm this explanation makes sense?
Most of it.

There is a further complication that you can specify multiple crate types for a single compilation. It is then possible for some crate types to generate the allocator shim while others don't generate it. The list of exported symbols however is for all crate types at the same time. One way to fix this would be to have a separate list of exported symbols for each crate type. Another option would be to move the addition of the symbols to the actual code that invokes the linker.
Listing exported symbols per crate type seems like the most correct fix in principle, but the lists will be almost the same except for the allocator symbols. I'll try to find a clean way to do the latter.
claim
Change:
} } <del> pub fn ty_to_def_id(&self) -> Option<DefId> { match self.sty { TyDynamic(ref tt, ..) => tt.principal().map(|p| p.def_id()), TyAdt(def, _) => Some(def.did), TyForeign(did) => Some(did), TyClosure(id, _) => Some(id), TyFnDef(id, _) => Some(id), _ => None, } } </del> pub fn ty_adt_def(&self) -> Option<&'tcx AdtDef> { match self.sty { TyAdt(adt, _) => Some(adt),

Discussion:
I don't know if this is really problem, but e.g. the reimplements this function (and yields a bunch of other s, too. This needs some looking at Mostly leaving this here so I don't forget
is probably a hack for cache keying, and should ideally be removed?
Change:
<ins> // compile-flags: -Zvalidate-mir -C opt-level=3 // build-pass #![feature(let_chains)] struct TupleIter<T, I: Iterator<Item = T>> { inner: I, } impl<T, I: Iterator<Item = T>> Iterator for TupleIter<T, I> { type Item = (T, T, T); fn next(&mut self) -> Option<Self::Item> { let inner = &mut self.inner; if let Some(first) = inner.next() && let Some(second) = inner.next() && let Some(third) = inner.next() { Some((first, second, third)) } else { None } } } fn main() { let vec: Vec<u8> = Vec::new(); let mut tup_iter = TupleIter { inner: vec.into_iter(), }; tup_iter.next(); } </ins>

Discussion:
Recently I played with the newly stabilized (tracker for issue , stabilized in Rust 1.64 ) and found that in some cases it gives . Below is a minimal example. It compiles fine with or , but does not compile with . It also compiles if you replace with nested . <!-- 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. --:
Thank you for you report, but this is probably a duplicate of
Can confirm this no longer ICEs on most recent nightly:
label +E-needs-test
Yeah likely this was fixed by . I wonder if it's worth adding a test for this, or it can just be closed as a dupe of .
We just hit this during the Clippy sync in The offending code was this: Pulling the if line out of the chain fixed the issue, see , so this works:
your issue is different, can you file a bug for it? This issue does not reproduce any more on latest nightly, it should be closed (or a test for it before closure, but had tests already.
Hmm, I can do this, but I think that is actually the same issue. While the above reproducer might be fixed, the fix doesn't seem to generally apply. The above code produced the exact same ICE/error message as posted in this issue.
I think this might be some MIR optimization gone wrong, maybe caused by wrong codegen, but your issue requires optimizations to be turned on, it can't just be reproduced by . The original ICE was also reproducible by (as well as with -O, as well as with both params), I've just verified using . I would thus recommend you file a new issue, but your choice. Some additional info to your issue, this is a reproducer: Interestingly, the issue is a regression, as it didn't ICE on . Edit: I very much appreciate the notion of not wanting to file multiple issues, after all this very issue is a dupe, but the clippy bug is separate.
This isn't because of MIR opts, it only happens under because storage markers, which are needed to get this ICE, are only emitted in optimized builds.
is this storage markers emitting only in release a new feature? Because I can reproduce the ICE with the original reproducer from this issue's author, with and and no flag whatsoever.
Change:
if cnt == 0 { escape_str(self.writer, name) } else { <ins> try!(write!(self.writer, "{{n")); </ins> self.curr_indent += self.indent; <del> try!(write!(self.writer, "[n")); </del> try!(spaces(self.writer, self.curr_indent)); <ins> try!(write!(self.writer, ""variant": ")); </ins> try!(escape_str(self.writer, name)); try!(write!(self.writer, ",n")); <ins> try!(spaces(self.writer, self.curr_indent)); try!(write!(self.writer, ""fields": [n")); self.curr_indent += self.indent; </ins> try!(f(self)); self.curr_indent -= self.indent; try!(write!(self.writer, "n")); try!(spaces(self.writer, self.curr_indent)); <del> write!(self.writer, "]") </del> <ins> self.curr_indent -= self.indent; try!(write!(self.writer, "]n")); try!(spaces(self.writer, self.curr_indent)); write!(self.writer, "}}") </ins> } }

Discussion:
Encoding an enum field with the pretty encoder results in an ExpectedError when decoding. In emitenumvariant of the pretty encoder, "variants" and "fields" need to be to behave the same way as the normal encoder.
Do you have a simple test case?
Taking a look
Closed by
Thank you for fixing this!
Change:
.arg("--component-name=rust-src") .arg("--legacy-manifest-dirs=rustlib,cargo"); <ins> builder.info("Dist src"); let _time = timeit(builder); </ins> builder.run(&mut cmd); builder.remove_dir(&image);

Discussion:
Since we run cargo vendor unconditionally to vendor libtest in libstd. We should either pass it '--offline' or add a way to conditionally do so to avoid using network when unnecessary
I am happy to accept a patch for this; if it is not small (e.g., just adding offline) we will likely end up wanting to revert on beta.
Is this really P-critical? I would think this is P-high since P-critical is usually reserved for severe user-facing bugs.
I consider inability for distros to build a particular version of Rust to be a release blocker.
Here what i've tried so far: - - None of those worked out, last failure:
With just the (without the generate-lockfile):
Ah, I didn't realize it was that bad! Sorry about that.
cc -- do we expect cargo vendor to work without network when vendoring a subset of a workspace? It looks like we're running into some trouble here to get it working, though I've not personally had time yet to test. cc as well
I believe Cargo is working as intended here, when you run in the workspace root it doesn't actually vendor the crates from because they're patched locally to the in-tree versions. Then when Cargo later vendors for libtest, it doesn't see the annotations so it tries to download them from the network. If you've passed and you're using a vendor directory that means Cargo can't download any more packages, so it provides this error. I think the fix here is to either get Cargo to see the for these crates during the libtest vendoring process or somehow get those crates vendored in whatever does the original vendor.
Will give the approach a try, thanks a lot for the explanation edit: assuming adding the patch section to e.g. libtest can work
I have posted a revert for the current release () since there were several issues on the Cargo side, too. Hopefully we'll try to avoid these issues when we try again.
Change:
} #[inline] <del> fn count(self) -> usize { self.iter.count().saturating_sub(self.n) </del> <ins> fn count(mut self) -> usize { if self.n > 0 { // nth(n) skips n+1 if self.iter.nth(self.n - 1).is_none() { return 0; } } self.iter.count() </ins> } #[inline]

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:
#![cfg_attr(feature = "deny-warnings", deny(warnings))] #![feature(rustc_private)] <del> #![feature(str_strip)] </del> // FIXME: switch to something more ergonomic here, once available. // (Currently there is no way to opt into sysroot crates without `extern crate`.)

Discussion:
Cc Will fill the content later. Creating this so that can be merged and tracked.
The code generated by is really complicated and inefficient. Godbolt link: Should we add / method directly to or trait?
Oof that does indeed look pretty bad.
I whipped up that fix here: Not sure if it's actually the ideal fix, but figured it would be a good point to launch the discussion from.
Ok, the code should be far more optimized now. What remains to be done? The main issue description has yet to be filled in.
On , I'm seeing that is much faster than , at least for newlines only. Is this only because I'm stripping off a very small amount of text, or is this function more optimized than (assuming that I didn't screw something up)? See "Standard strip suffix" versus "Standard trim end", with "unix" having the input of and "win" being : !
Ah, yeah, looks the optimizations I made to stripprefix/stripsuffix in are optimizations that don't exist for : I wonder if could be reimplemented as a loop over ... By the way, since I'm here, (or anyone else on the Rust team), what remains to be done for this issue?
If you want to change the implementation this is a good time. Else, the thing left is stabilisation with the libs team approving it (if needed) but i'd wait for some time to check if there are any other issues.
The implementation is now faster than the existing similar stable functions and , so I think we're in a good spot implementation wise. Would you be able to add a note about the progress and when we expect to start the stabilization discussion in the issue description? (Or whatever normally goes in there?)
you can submit a stabilisation PR by following the instructions here:
Change:
#[derive(Debug)] pub struct Error { <del> file: PathBuf, error: io::Error, </del> <ins> pub file: PathBuf, pub error: io::Error, </ins> } impl error::Error for Error {

Discussion:
When running cargo doc, rustc panics if disk is full. Not a huge issue, just an invalid call of and since the message says it's a bug, I'm filling a report. Error message (with removed file path): Might be related to somehow?
This also happened with me today. The compiler starts panicing if you try to, Generate Documentation, Run, Compile or run . Maybe It should print a clear message and exit instead of panicing like that. Rust Version: