jiebi/CodeConvo huggingface dataset:
Change:
<ins> // compile-pass </ins> #![feature(const_generics)] //~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash <del> // We should probably be able to infer the types here. However, this test is checking that we don't // get an ICE in this case. It may be modified later to not be an error. </del> <ins> // This test confirms that the types can be inferred correctly for this example with const // generics. Previously this would ICE, and more recently error. </ins> struct Foo<const NUM_BYTES: usize>(pub [u8; NUM_BYTES]);

Discussion:
This very simple example (): results in: . Changing it to use curly braces around does not help.
This does work:
I was actually just experimenting locally to see if I could fix this and I think I have, I could put a PR up in a few minutes.
Change:
set-window-size: (600, 600) go-to: "file://" + |DOC_PATH| + "/lib2/too_long/struct.SuperIncrediblyLongLongLongLongLongLongLongGigaGigaGigaMegaLongLongLongStructName.html" // It shouldn't have an overflow in the topbar either. <del> store-property: (".mobile-topbar h2", {"scrollWidth": scrollWidth}) assert-property: (".mobile-topbar h2", {"clientWidth": |scrollWidth|}) </del> <ins> store-property: (".mobile-topbar", {"scrollWidth": scrollWidth}) assert-property: (".mobile-topbar", {"clientWidth": |scrollWidth|}) </ins> assert-css: (".mobile-topbar h2", {"overflow-x": "hidden"}) // Check wrapping for top main-heading h1 and out-of-band.

Discussion:
On mobile using both firefox and Brave. !
This is presumably a rustdoc issue, unless our css somehow affects it, but I doubt it.
Taking a look.
Change:
<ins> // compile-flags: --test --crate-name=empty_fn --extern=empty_fn --test-args=--test-threads=1 // aux-build:empty-fn.rs // check-pass // normalize-stdout-test: "src/test/rustdoc-ui" -> "$$DIR" // normalize-stdout-test "finished in d+.d+s" -> "finished in $$TIME" // edition:2021 /// <https://github.com/rust-lang/rust/issues/91134> /// /// ``` /// extern crate empty_fn; /// empty_fn::empty(); /// ``` pub struct Something; </ins>

Discussion:
We have a Rust-2015 doc test which has an which started failing to build on nightly 2021-11-21 (but passes on stable/2021-11-20). It now fails with
Probably caused by (; no rollup?).
That seems unlikely, is more plausible. doesn't affect doctests.
Oh, I think I got misled by the "rustdoc" bit.
I can't reproduce this. I tried /// extern crate inner; /// and running , but all the tests passed fine. can you link the original code?
The failure is You can see the first failure in CI at
The following seems like a minimal reproduction when used with 2015: /// extern crate mycrate; /// mycrate::foo(); /// Bisected to .
cc , I think it might make sense to revert temporarily unless you already have an idea for a fix.
Change:
<ins> // ignore-tidy-trailing-newlines // // error-pattern: this file contains an unclosed delimiter // error-pattern: this file contains an unclosed delimiter // error-pattern: this file contains an unclosed delimiter // error-pattern: format argument must be a string literal // // Verify that unused parens lint does not try to create a span // which points in the middle of a multibyte character. fn f(){(print!(á </ins>  No newline at end of file

Discussion:
Reported by here: (Note that but does not fix this bug.)
searched nightlies: from nightly-2021-01-07 to nightly-2021-12-24 regressed nightly: nightly-2021-09-12 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
This regression was introduced in . cc
Not a fix, but if I make this change then there is no longer an ICE and I get
Thanks for opening the issue If someone finds a fix but doesn't know how to add the test, this pull request which solves a similar ICE has an example of how to add a test when there is a missing newline:
Change:
ExprKind::Index(ref base, ref idx) => { self.check_expr_index(base, idx, needs, expr) } <del> ExprKind::Yield(ref value, _) => { self.check_expr_yield(value, expr) </del> <ins> ExprKind::Yield(ref value, ref src) => { self.check_expr_yield(value, expr, src) </ins> } hir::ExprKind::Err => { tcx.types.err

Discussion:
Hi I'm pretty new to rust and programming in general. I was trying (failing) to write some toy async code and I got this internal compiler error, the theme seems to be always report ICEs so here we go This was from cargo: ~ The code I was trying was this code: ~ <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Minimized:
ICEs with any statement between while inside a function that isn't async ICE Error without and without the ICE statement inside async function
claim
This is actually the same as . I think I've got a fix for both.
do you have a PR for this open?
Closing as a duplicate of , both of which are fixed by

<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Not had a lot of time to look at this unfortunately and it appears has come up with a fix in in the meantime. release-assignment
claim
assign (Sorry for the noise, testing a new GH feature)
Change:
<del> Subproject commit 329923edec41d0ddbea7f30ab12fca0436d459ae </del> <ins> Subproject commit 8485d40a3264b15b92d391e99cb3d1abf8f25025 </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! And nominating for compiler team prioritization.
Change:
AbsPathWithModule(Span), ProcMacroDeriveResolutionFallback(Span), MacroExpandedMacroExportsAccessedByAbsolutePaths(Span), <del> ElidedLifetimesInPaths(usize, Span, bool, Span, String), </del> UnknownCrateTypes(Span, String, String), UnusedImports(String, Vec<(Span, String)>), RedundantImport(Vec<(Span, bool)>, Ident),

Discussion:
<details<summary<strongBacktrace</strong</summary<p</p</details
This bisects to &mdash; regressed nightly: nightly-2021-12-03 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
There was an issue with similar ICE that has been fixed recently Does this problem still repro with latest nightly ?
Yes this one still reproduces as of that nightly, which contains .
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Change:
return } let compiler = Compiler::new(0, &build.config.build); <del> let compiler = build.compiler_path(&compiler); </del> <ins> let compiler_path = build.compiler_path(&compiler); </ins> for file in t!(fs::read_dir(build.src.join("src/rtstartup"))) { let file = t!(file); <del> build.run(Command::new(&compiler) .arg("--emit=obj") .arg("--out-dir").arg(into) .arg(file.path())); </del> <ins> let mut cmd = Command::new(&compiler_path); build.add_bootstrap_key(&compiler, &mut cmd); build.run(cmd.arg("--target").arg(target) .arg("--emit=obj") .arg("--out-dir").arg(into) .arg(file.path())); </ins> } for obj in ["crt2.o", "dllcrt2.o"].iter() {

Discussion:
This looks weird. Isn't a .dll the right thing for this target? cc
Could you try passing ? Seems like may not be making its way to Cargo, or the shim is really messing up here (probably the latter)

Because that's what the old build system does: but rustbuild and rsbegin.o ends up being an ELF on linux: The fix should be simple in theory. You just have to pass to the in the code linked above. But then you run in problems with the order of the operations: " not found for $TARGET". cc
FWIW, trying to cross compile to i686-pc-windows-gnu I get this: Trying to cross compile to x86_64-pc-windows-gnu results in
Yeah not passing would do it, should be easy to add though! (I think that's all that's necessary)
Actually, the solution is the opposite. rustbuild is building these startup files for linux but it should compile them for windows hence the has to be .
Oh right sorry "it" there was "would cause this problem", we should indeed pass !
Change:
for p in underline_start - 1..underline_start + 1 { buffer.putc( row_num, <del> max_line_num_len + 3 + p as usize, </del> <ins> ((max_line_num_len + 3) as isize + p) as usize, </ins> '-', Style::UnderlineSecondary, );

Discussion:
Hi, i have made some changes for a crate to support a generic type that implements from , but suddenly the code can't compile because it runs out of memory with 6, 8, 10 GB. This is the code i'm trying to compile: if changed the type for or it then compiles and runs fine. Source: It fails to compile on x86_64-unknown-linux-gnu with , . I'm attaching the Heaptrack files for further analysis.
It seems a problem with utilized in the , unfortunately memory report is strange, the execution time tracked is wrong besides the graph shows up the memory grow. I'm thinking ways to better troubleshoot, but the side effects of the issue is hard.
It'd be helpful to try and simplify the code, ideally to something that doesn't have dependencies (beyond std or so), or at least as few dependencies as possible. As a start putting up a github repository with a and as simple a crate as possible would be helpful for reproducing on our side (i.e., extracting the file you've linked from that crate -- or, if the crate is really necessary, then indicating as such). The heaptrack profile looks pretty useless unfortunately -- rustc on linux is shipped with jemalloc as the allocator which likely makes heaptrack tracking not really work too well.
Thank you, sorry for the late response (working) but i get it working on playground. I'm now trying to minimize them to focus on the issue.
Got it down to 18 lines. Still produces the same error. I have not tested if this goes out-of-memory. But receiving a would signal that. EDIT: After taking some more time, I got rid of Tokio and reduced it to 6 lines: Additionally, I advise to rename this issue to something like to make it very clear and concise.
One liner: . Strangely, this no longer crashes if you remove any of , , , or .

There's nothing special about Send or Sync, this also crashes: Even weirder, this does not crash: (I didn't come up with the one-liner, that was
I stopped rustc (SIGSTOP) and got a backtrace with gdb, it looks like it's trying to generate infinite errors: <details<summarybacktrace</summary</details
It looks like this is a problem with the error reporter itself: it's affected by the length of the name (!!) OOM: No OOM:
I figured out the issue has to do with how the error printer places the annotations, adding a newline after the trait names and before the plus solves the issue.
Probably caused by some code in here:
Change:
//! on the generated test harness. //@ check-pass <del> //@ compile-flags: --test -Dmissing_docs </del> <ins> //@ compile-flags: --test #![forbid(missing_docs)] #[test] fn test() {} </ins>

Discussion:
I tried this code: I expected to see this happen: no errors Instead, this happened: : Very likely to be related
Looks like allowed missing docs on the generated function, but didn't test having any actual s. cc
Attempt fix in
Change:
<del> Subproject commit b5ddc94bf02c641e5acbb08ae742014f40347f10 </del> <ins> Subproject commit b269bb07078446c9c153e0f2acaf83bf8f19b935 </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and -- nominating for prioritization.
Change:
} } } <del> ty::ReError(_) => return r, </del> }; let existing_bound_var = match self.canonicalize_mode {

Discussion:
<!-- [31mICE[0m: Rustc '-Znext-solver=coherence -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: did not expect successful goal when collecting ambiguity errors', 'error: internal compiler error: did not expect successful goal when collecting ambiguity errors' File: --snippet: 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: [specializationgraphof] building specialization graph of trait [coherenttrait] coherence checking all impls of trait [checkwellformed] checking that is well-formed [checkmodtype_wf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --
regression in
Change:
self.substitutions .iter() <ins> .filter(|subst| { // Suggestions coming from macros can have malformed spans. This is a heavy // handed approach to avoid ICEs by ignoring the suggestion outright. let invalid = subst.parts.iter().any(|item| cm.is_valid_span(item.span).is_err()); if invalid { debug!("splice_lines: suggestion contains an invalid span: {:?}", subst); } !invalid }) </ins> .cloned() .map(|mut substitution| { // Assumption: all spans are in the same file, and all spans

Discussion:
(reduced sample courtesy of Output:
triage: diagnostics produced prior to ICE seem like they probably help user fix problem (maybe)? So calling this P-medium. Removing nomination label.
Change:
//! //! [`PointerCoercion::Unsize`]: `rustc_middle::ty::adjustment::PointerCoercion::Unsize` <ins> use rustc_codegen_ssa::base::validate_trivial_unsize; </ins> use rustc_middle::ty::print::{with_no_trimmed_paths, with_no_visible_paths}; use crate::base::codegen_panic_nounwind;

Discussion:
I believe this is caused by . Does that look like anything to you? This doesn't seem to happen with the dist artifacts, only the settings used when testing in CI. The config used in CI is: EDIT: Almost certainly since it comes from . This is causing the reference test suite to fail. Using which is currently unreleased.
Yeah, it's a debug assertion after all. I'll look into it and relax the assertion
Change:
// Fresh lifetimes in APIT used to be allowed in async fns and forbidden in // regular fns. if let Some(hir::PredicateOrigin::ImplTrait) = where_bound_origin <del> && let hir::LifetimeName::Param(_) = lifetime_ref.res && lifetime_ref.is_anonymous() </del> <ins> && let hir::LifetimeName::Param(param_id) = lifetime_ref.res && let Some(generics) = self.tcx.hir().get_generics(self.tcx.local_parent(param_id)) && let Some(param) = generics.params.iter().find(|p| p.def_id == param_id) && param.is_elided_lifetime() </ins> && let hir::IsAsync::NotAsync = self.tcx.asyncness(lifetime_ref.hir_id.owner.def_id) && !self.tcx.features().anonymous_lifetime_in_impl_trait {

Discussion:
https://crater- https://crater- https://crater- https://crater- cc as possible root cause,
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Change:
mod std { pub use core::ops; // RangeFull } <ins> #[doc(hidden)] #[unstable(feature = "liballoc_internals", issue = "0", reason = "implementation detail")] pub mod __export { pub use core::format_args; } </ins>

Discussion:
Caused by . To be precise the change. It basically does: Because uses to refer to , it will try to resolve it in , which doen't contain .
cc
This regression affects another project I am working on as well. is there any status on this?
I'm not sure what the details of were, but this feels like a bug to me -- in particular it feels like the behavior here is less hygienic, not more? perhaps you can clarify your view on the situation, that'd be great.
Well, it's more hygienic than before because previously used whatever was closest in scope at the call site, while now it certainly uses from the crate named . (That doesn't make the change less breaking.) What really wants is to use def-site hygiene so that "the crate named " is searched from the 's definition point of view. (Not possible right now due to def-site hygiene for crates not being implemented.) In the meantime the change to can be reverted to fix the regression.
I see -- just not necessarily the core that was in scope at the point of definition. Seems right. Is there a tracking issue to cc or something?
That said, the constructions or (same, but from command line) really require some responsibility since they effectively override and . If you override them you should be able to provide all the necessary services expected from and , since for any third party macro is the only reliable way to refer to the standard library, at least until def-site hygiene is fully implemented and stabilized.
Is there a tracking issue to cc or something? This is supposed to be the tracking issue for the regression?
While most of the changes in 's PR have increased hygiene, the specific change linked by didn't do any increase (or decrease) as both times the macro is being resolved in an unhygienic way. From a pragmatic point of view, lots of people seem to shadow the core crate but few people want to (saying "want to" and not "do" because of selection bias) shadow the macro while wanting to use the builtin one for which is what the change now allows you to do. Furthermore, not breaking downstream users should always be a priority. It's not their fault that the format macro uses something in an unhygienic way. IMO the specific change should be reverted.

There is a pattern to use std or any other third party crate in a hygienic way. You define a in and then use to refer to std items in the macro.
Fixed in
check-in from compiler triage: marking as p-high, but has a pending fix already
Change:
<ins> // check-pass // compile-flags: -Znormalize-docs trait Woo<T> { type Assoc; } impl<T> Woo<T> for () { type Assoc = (); } type Alias<P> = <() as Woo<P>>::Assoc; pub fn hello<S>() -> Alias<S> {} </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. --Original code Auto reduced but does no longer compile: <!-- 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. --: `rustdoc -Znormalize-docs <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
can you share the stack trace? the part that says is actually what's needed to debug this lol
nvm, found it
Change:
let (lp, hp) = (lo.as_ref().map(|(x, _)| x), hi.as_ref().map(|(x, _)| x)); let mut kind = match self.normalize_range_pattern_ends(ty, lp, hp) { <del> Some((lc, hc)) => self.lower_pattern_range(ty, lc, hc, end, lo_span), </del> <ins> Some((lc, hc)) => { self.lower_pattern_range(ty, lc, hc, end, lo_span, lo_expr, hi_expr) } </ins> None => { let msg = &format!( "found bad range pattern `{:?}` outside of error recovery",

Discussion:
For a match where I'm matching on a , I put on accident, and then rather than saying that 256 is out of range for , it decided to wrap 256 to 0 and then error that 251 is lower than the end of the range: Clearly this is not a good situation. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'd like to fix this claim
Triage: I'm going to release assignment due to inactivity. If you're still interested in this, feel free to re-claim. release-assignment
Explanation on how to solve this in
Change:
if let GenericParamKind::Lifetime = param.kind { // Record lifetime res, so lowering knows there is something fishy. self.record_lifetime_param(param.id, LifetimeRes::Error); <del> continue; </del> } <ins> continue; </ins> } Entry::Vacant(entry) => { entry.insert(param.ident.span);

Discussion:
Found with a <details<summaryFull output including backtrace</summary</detailsRegression in nightly-2021-04-26, possibly from ( label +A-const-generics
Here's a simpler case that ICEs in a similar way. It ICEd at least as far back as nightly-2018-01-01 (with the keyword removed for older versions). Output: <details<summaryFull output</summary</details
A similar thing was fixed a week ago in but maybe a more general fix is needed.
This fix probably needs to go into the resolver -- Using to distinguish the identifers in the example: I think the issue is that is resolving to , instead of , so when we do the partial substitution of default const params, we end up trying to look for while is being created.
Similar ICE with struct instead of impl trait:
This would be inconsistent with how lifetimes work. You can have . I suggest a check in astconv, replacing the self-referential type/const by error type/const.
Change:
fn str_slice_arg<'a>(bcx: &'a Block<'a>, s: InternedString) -> ValueRef { let ccx = bcx.ccx(); <del> let t = ty::mk_str_slice(bcx.tcx(), ty::ReStatic, ast::MutImmutable); </del> let s = C_str_slice(ccx, s); let slot = alloca(bcx, val_ty(s), "__temp"); Store(bcx, s, slot); <del> // The type of C_str_slice is { i8*, i64 }, but the type of the &str is // %str_slice, so we do a bitcast here to the right type. BitCast(bcx, slot, type_of::type_of(ccx, t).ptr_to()) </del> <ins> slot </ins> } pub fn trans_fail<'a>(

Discussion:
This code: crashes rustc with the following error message: If I remove the first match arm, the program compiles correctly. I was able to reproduce this only with &'static str constants. Other types of constants I have used seem to work fine. This happens on Rust 0.9. I cannot check it on master version because I can't compile it for some reason.
Compiling with a build of rust from yesterday () I get a different error:
I was just editing the issue to add a note that I'm using Rust 0.9 because for some reason I can't build the compiler from master.
I got bit by this today with a master build (): If you replace the static variable with its string literal things work again
Change:
<ins> //! Ensure #[unstable] doesn't accept already stable features #![feature(staged_api)] #![stable(feature = "rust_test", since = "1.0.0")] #[unstable(feature = "arbitrary_enum_discriminant", issue = "42")] //~ ERROR can't mark as unstable using an already stable feature #[rustc_const_unstable(feature = "arbitrary_enum_discriminant", issue = "42")] //~ ERROR can't mark as unstable using an already stable feature const fn my_fun() {} fn main() {} </ins>

Discussion:
This should probably not be accepted: is already stable, so having an unstable function under this feature makes no sense. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Should we also reject features that don't exist? Right now, this test would fail (because it would compile without problems)
"unstable" attributes is how library features come into existence. So yes we should accept features that do not yet exist.
Change:
passes_doc_keyword_only_impl = `#[doc(keyword = "...")]` should be used on impl blocks <ins> passes_doc_test_literal = `#![doc(test(...)]` does not take a literal </ins> passes_doc_test_takes_list = `#[doc(test(...)]` takes a list of attributes

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. --This is a fuzzed test case, found with and minimized with , and did not find any related issues. I was able to reproduce with a compiler I compiled 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. --: <!-- 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 --<!-- TRIAGEBOT_END --
claim
label +S-bug-has-mcve