jiebi/CodeConvo huggingface dataset:
Change:
#![feature(doc_notable_trait)] #![feature(effects)] #![feature(extern_types)] <ins> #![feature(f128)] #![feature(f16)] </ins> #![feature(freeze_impls)] #![feature(fundamental)] #![feature(generic_arg_infer)]

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. --Playground nightly version: 1.79.0-nightly (2024-03-25 ) This isn't expected since it doesn't seem to hit a label +T-compiler +f-f16andf128 +I-ICE +requires-incomplete-features +S-has-mcve claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label -needs-triage
Minimized:
Looks like it just expects primitives to be . I'm not sure where exactly this assumption comes from, but might as well fix it before the rest of libs support can get merged.
Change:
command.arg("-p").arg(name); } <ins> command.arg("--"); command.args(filters); </ins> let status = command // Disable rust-lang/cargo's cross-compile tests .env("CFG_DISABLE_CROSS_TESTS", "1")

Discussion:
As part of our CI we run "cargotest" on a variety of ecosystem crates, making sure they successfully build and run tests. Unfortunately, some of use stochastic tests like quickcheck, which means that a crate passing our CI one day may not necessarily mean it passes CI the next. Perhaps we should audit the tests being run and filter out ones like these? See and cc
Yeah I think we've discussed this to some extent previously within infra team as part of our "what to do about cargotest" discussions. cc in particular Not sure that we came to any conclusions though.
Related:
The test from xsv fails occasionally:
This just bit me and took a lot of time as I triple-checked that after bors failing twice (!) in xsv, the same test actually works fine on my system.
The xsv test suite seems to be full of quickcheck tests, so I think the only way to fix this is to remove xsv from cargotest (or to only run a short list of curated tests).
See where there is some discussion fo changing the cargotest set. I think implies dropping xsv.
Hm, that discussion seems to have stalled though. So to fix the immediate problem, I propose we do something like
Change:
canonical_goal: CanonicalPredicateGoal<'tcx>, ) -> Result<EvaluationResult, OverflowError> { debug!("evaluate_obligation(canonical_goal={:#?})", canonical_goal); <del> tcx.infer_ctxt().enter_with_canonical( </del> <ins> // HACK This bubble is required for this tests to pass: // impl-trait/issue99642.rs tcx.infer_ctxt().with_opaque_type_inference(DefiningAnchor::Bubble).enter_with_canonical( </ins> DUMMY_SP, &canonical_goal, |ref infcx, goal, _canonical_inference_vars| {

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. -- Regressed between ( 2022-07-17) .. ( 2022-07-21). ~Probably ~. Cc Edit: Regressed in Minimized from . Cc label regression-from-stable-to-nightly A-impl-trait <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Duplicate of
No wait, huh? That's another issue
This must've been broken before. That revert should not be able to cause a stable to nightly regression
I was wrong, bisection points to . I guess it is . Cc
claim
Change:
endif CFG_LIB_NAME_armv7-apple-ios = lib$(1).a CFG_LIB_GLOB_armv7-apple-ios = lib$(1)-*.a <del> CFG_LIB_SKIP_INSTALL_armv7-apple-ios = 1 #lib$(1)-*.a </del> <ins> CFG_INSTALL_ONLY_RLIB_armv7-apple-ios = 1 </ins> CFG_STATIC_LIB_NAME_armv7-apple-ios=lib$(1).a CFG_LIB_DSYM_GLOB_armv7-apple-ios = lib$(1)-*.a.dSYM CFG_JEMALLOC_CFLAGS_armv7-apple-ios := -arch armv7 -mfpu=vfp3 $(CFG_IOS_SDK_FLAGS_armv7-apple-ios)

Discussion:
Full gist:
cc
cc since you've been contributing iOS patches. This same error still repros after with: Are you able to successfully build a cross-compiler?
there are 2 different things: building and installing. What fails is phase and I believe I have kind of dirty hack for it in my fork, but will try to find a correct solution and issue PR soon.
this one ?
yep
cool, would you mind submitting that PR?
since PR is going to be open for a while considering current bors queue, I have to mention that in general when you need up-to-date Rust for iOS you can either built it by yourself from or use a prebuilt version from It may lag a bit (usually <= 1 day) but it is guaranteed to build (as iOS is not on Rust official buildbots and master is broken sometimes).
Change:
<ins> // Copyright 2018 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. // aux-build:issue_54059.rs // ignore-stage1 // ignore-wasm32-bare no libc for ffi testing // ignore-windows - dealing with weird symbols issues on dylibs isn't worth it // revisions: rpass1 extern crate issue_54059; fn main() {} </ins>

Discussion:
: : Steps to reproduce: This is failing when the crate attempts to import the crate (which is a crate). That is, if I modify 's file to only contain: rustc will ICE. <details<summaryBacktrace:</summary</details
I suspect this is a duplicate of , but I only count 2 #[procmacro] and 1 #[procmacro_attribute] in the repository.
The crate only has 1 and 1 . If I comment both of them out, the compiler still ICEs. The crate used to compile a couple weeks ago, so this was a fairly recent change.
To give some bounds on this: the crate compiles with . It fails with . I would bisect this with rustup to determine which nightly the issue started with, but .
Derp, I just remembered I could remove the component. Okay, doing that, I was able to bisect the nightlies: Last working version: First failing version:
I just did a git bisect, and it looks like commit (from PR ) is the source of the breakage. cc
visited for triage. Going to try to followup with . Assigning to self to keep myself honest about that claim.
also, P-high
Am looking at this.
Minified: // #[allow(unused)] // enum ProcMacroHack { // Input = (stringify!(ARGS), 0).1, // } // The problem is caused by containing "host" defids and being used in [trans]. I don't think that this field has any business containing host libraries when compiling a proc macro, but I'll ask for confirmation. [trans]:
visited for triage. Seems like PR handles this. Leaving as P-high
Change:
#[inline] pub fn ctxt(self) -> SyntaxContext { let ctxt_or_tag = self.ctxt_or_tag as u32; <del> if ctxt_or_tag <= MAX_CTXT { if self.len_or_tag == LEN_TAG || self.len_or_tag & PARENT_MASK == 0 { // Inline format or interned format with inline ctxt. SyntaxContext::from_u32(ctxt_or_tag) </del> <ins> // Check for interned format. if self.len_or_tag == LEN_TAG { if ctxt_or_tag == CTXT_TAG { // Fully interned format. let index = self.base_or_index; with_span_interner(|interner| interner.spans[index as usize].ctxt) </ins> } else { <del> // Inline format or interned format with inline parent. // We know that the SyntaxContext is root. SyntaxContext::root() </del> <ins> // Interned format with inline ctxt. SyntaxContext::from_u32(ctxt_or_tag) </ins> } <ins> } else if self.len_or_tag & PARENT_MASK == 0 { // Inline format with inline ctxt. SyntaxContext::from_u32(ctxt_or_tag) </ins> } else { <del> // Interned format. let index = self.base_or_index; with_span_interner(|interner| interner.spans[index as usize].ctxt) </del> <ins> // Inline format with inline parent. // We know that the SyntaxContext is root. SyntaxContext::root() </ins> } } }

Discussion:
Put the following code in a new crate's and call 'cargo init'. Then 'cargo c' will ICE. I've tried to reduce further but it seems like if I remove any random line (even if it is a comment) the ICE goes away. <!-- 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
I noticed there is an older bug that is probably the same: .
So like I said this ICE is extremely sensitive to the exact number of characters and lines. The contents of those lines seems to matter less; it is possible to replace most comment and identifier characters with another character (I tried 'x') as long as the total number of characters stays the same. Likewise, a tab can be replaced with a space. The code that triggers is the last code line in this function (from ): withspaninterner calls a function on the SpanInterner it gets from withsessionglobals which gets it from thread-local-storage A SpanInterner wraps a FxIndexSet of SpanData: which is just an indexmap::IndexSet with the FxHasher () The indexmap version is "1.9.2" () The latest version is 1.9.3, but it does not seem to contain any relevant changes (). indexmap uses hashbrown for its hashtable, which may mean that this bug ultimately comes from hashbrown.
A bug in hashbrown is very unlikely. Do you have a backtrace with symbol names? This may also come from incorrect logic in .
Are you able to reproduce the issue given my test case? Can you explain what goes wrong?
Change:
#[derive(Clone, Encodable, Decodable, Debug)] pub enum VisibilityKind { Public, <del> Restricted { path: P<Path>, id: NodeId }, </del> <ins> Restricted { path: P<Path>, id: NodeId, shorthand: bool }, </ins> Inherited, }

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see this happen: it to print . Instead, this happened: it prints . <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: 1.62.1 <!-- Provide the version you are using that has the regression. --: <!-- Did the compiler crash? If so, please provide a backtrace. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-beta -regression-untriaged -- modify labels: +regression-from-stable-to-beta -regression-untriaged
Similar effect can already be observed on stable too prints already. But it is indeed a (small?) behavior change in this beta for the case.
I would expect to see this issue in 2020, but not now when we are collecting tokens in (almost) all cases instead of converting them from AST. Apparently for visibilities they are collected incorrectly for some reason. cc (in case you have time for this)
bisection points to searched nightlies: from nightly-2022-01-01 to nightly-2022-08-03 regressed nightly: nightly-2022-05-24 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </detailsThe commit is a rollup so I think_ it's in cc ?
Without even looking at the rest of the rollup, it's definitely my PR. Short of storing whether was used, I'm not sure what could be done.
This will slip into 1.63.

I'll work on this this evening to get it resolved quickly, even if it is too late to patch the beta. I don't think it'll be too difficult.
PR is up: . This also fixes to be , which is certainly better than the status quo of .
Change:
test_transparent!(large_array, [i32; 16]); test_transparent!(enum_, Option<i32>); test_transparent!(enum_niched, Option<&'static i32>); <del> // Pure-float types that are not ScalarPair seem to be tricky. // FIXME: <https://github.com/rust-lang/rust/issues/115664> #[cfg(not(any(target_arch = "arm", target_arch = "aarch64")))] mod tricky { use super::*; test_transparent!(triple_f32, (f32, f32, f32)); test_transparent!(triple_f64, (f64, f64, f64)); } </del> // RFC 3391 <https://rust-lang.github.io/rfcs/3391-result_ffi_guarantees.html>. macro_rules! test_nonnull {

Discussion:
On aarch64-unknown-linux-gnu (a tier 1 target), consider this testcase: passes its argument as uses IOW, uses float registers and uses int registers. This violates our promise that types are ABI-compatible. I think this might indicate a bug in the function? At least I don't see anything in the aarch64 adjustment that would be obviously wrong.
This also affects arm32 targets like arm-unknown-linux-gnueabihf.
Yes, that is definitely the issue -- that is heterogeneous.
Should be fixed by
Change:
} #[derive(PartialEq)] <del> struct Bar; </del> <ins> pub struct Bar; </ins> impl Foo for int { type A = uint;

Discussion:
AFAIK, you can't put private types in "public" items (public as in marked with ). is not explicitly marked with , but for all intent and purposes all the methods in a trait are public if the trait is public. So, I think the should be rejected by the privacy checker. (Or, I could be wrong and this is "correct" behavior - and this wouldn't be the first time that the privacy/module system allows things that I find ) cc
I agree, I think this may have just been accidentally overlooked when implementing associated types.
On Sat, Feb 28, 2015 at 10:59:14PM -0800, Alex Crichton wrote: Yes, that. There was language in the RFC describing trait item signatures and how they should be treated, and I think we just failed to extend that to associated types. Definitely a bug.
triage: P-backcompat-lang (1.0 beta)
Note also that is still open.
Change:
CFG_LLC_FLAGS_x86_64-unknown-linux-gnu := CFG_INSTALL_NAME_x86_64-unknown-linux-gnu = CFG_LIBUV_LINK_FLAGS_x86_64-unknown-linux-gnu = <del> CFG_LLVM_BUILD_ENV_x86_64-unknown-linux-gnu="CXXFLAGS=-fno-omit-frame-pointer" </del> CFG_EXE_SUFFIX_x86_64-unknown-linux-gnu = CFG_WINDOWSY_x86_64-unknown-linux-gnu := CFG_UNIXY_x86_64-unknown-linux-gnu := 1

Discussion:
We currently build C++ code and Rust with frame pointers on, though we don't actually use them for anything (intended for GC). This is overhead that C and C++ don't usually have so it would be nice to turn on elimination.
I think we'll need them for gc, fwiw
on Linux x86_64 we should be using the DWARFv3 Call Frame Information for walking the stack, although I have no idea if we're emitting it correctly right now (likely on OS X and FreeBSD too). We might be, because gdb uses it and seems to work.
We'll leave it off until we have solutions for GC, which will probably end up being platform specific. libunwind should make it easy on linux and freebsd.
Reopening because this caused a regression in , so reverted in
Change:
<ins> // check-pass #![allow(incomplete_features)] #![feature(adt_const_params, const_ptr_read, generic_const_exprs)] #![allow(dead_code)] const fn catone<const M: usize>(_a: &[u8; M]) -> [u8; M + 1] where [(); M + 1]:, { unimplemented!() } struct Catter<const A: &'static [u8]>; impl<const A: &'static [u8]> Catter<A> where [(); A.len() + 1]:, { const ZEROS: &'static [u8; A.len()] = &[0_u8; A.len()]; const R: &'static [u8] = &catone(Self::ZEROS); } fn main() {} </ins>

Discussion:
I'm back. This time I tried concatenating non-literal s. Why? Excellent question, next please. <!-- 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
I got another instance of this here: (sorry for the large producer) And this is the error:
Shorter variant that avoids and hits the same ICE: Regression in nightly-2021-12-06. In earlier versions, the compiler reported "error: overly complex generic constant". <details<summaryCommits in range</summary</details
Just to clarify, the issue is almost certainly just in . I have functioning (compiling, at least) code that does array concatenation, extension, etc. using the same pattern as in the first post for array concatenation when the arrays are function arguments instead of const generic parameters.
Update: the issue is somewhere in the use of . I rewrote it without using any and this actually compiles and works: This was as part of trying to confirm the issue was not in . However, as soon as I put the method of joining arrays back in, e.g. and then I get the exact same issue as in what was initially reported.
No longer ICEs since
Change:
parent_module: None, doc: Symbol::intern(s), kind: DocFragmentKind::SugaredDoc, <del> need_backline: false, </del> indent: 0, }] }

Discussion:
I expected this change to work: But it causes to panic: <details<summaryBacktrace</summary</detailsI don't have time to look into it right now, but I wouldn't expect it to be too hard to fix and it would reduce the memory usage of rustdoc by quite a lot. I'd suggest starting by adding a bunch of assertions that the old and new behavior of is the same and investigating the assertion failures. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Since would unconditionally add a final newline, shouldn't the note say that (instead of "this can") and the 'pop's be unconditional? Across the entire codebase, there's just one other invocation of 'adddocfragment' (currently line 1087 ); it seems that that doesn't need a newline popped. Instead, I think the last function you modified () should only have a newline popped for the last , as would only be false for the last , as far as I can tell. I made a commit to that effect in the PR above, though I have to resolve the merge conflict somehow.
feel free to try that out and see if it works :) like I said, I don't have time to work on it right now.
Change:
<ins> // Copyright 2017 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. #![feature(nll)] struct Bar; struct Foo<'s> { bar: &'s mut Bar, } impl Foo<'_> { fn new(bar: &mut Bar) -> Self { Foo { bar } } } fn main() { } </ins>

Discussion:
Hi, I'm not sure if this has been reported or is known at all. If it has feel free to close it out. This example: causes an ICE on rustc 1.31.0-nightly ( 2018-10-25) This is the error I'm getting, backtrace included:
Okay, the good news here is that I only see this ICE with ; it does not arise with the NLL migration mode being deployed as part of the 2018 edition. See e.g. this .
The code in question is rejected by AST-borrowck. It looks like it is being rejected by NLL as well, and the problem is that we hit an error when trying to generated our diagnostic. Therefore, I'm going to tag this as NLL-sound (since this seems like a case where we want to reject the code in question) and NLL-diagnostics (since the ICE itself is stemming from diagnostics code). And I think I'm going to make it P-high, because 1. ICE's are super annoying and 2. I bet its not hard to fix. But I'm not going to tag it with the Release milestone, because its not something we need to worry about backporting to the beta channel (because it does not arise with NLL migration mode).
actually I'll remove NLL-sound; this isn't a case where NLL is incorrectly accepting the code. Its just incorrectly behaving while generating the diagnostics.
Change:
// substitutions. use crate::FnCtxt; <del> use hir::def_id::LocalDefId; </del> use rustc_data_structures::unord::ExtendUnord; use rustc_errors::{ErrorGuaranteed, StashKey}; use rustc_hir as hir;

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: compile error that said the return type is wrong. Instead, this happened: compiled without error <!-- 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

edit: minimized see for more details <!-- 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: Compilation should fail, because different generator types should be generated by calling , meaning and should not share the same type . Instead, compilation passes, and occurs during runtime: More context: <!-- 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<summaryNo Backtrace from running it</summary<p</p</details
label +F-typealiasimpl_trait +I-unsound +T-compiler
Only possible with unstable feature label -I-prioritize
it would be good to have an example which does not depend on external crates or macros here.
slightly minimized completely minimized: + incorrectly ignoring recursive definitions, writing a clean MVCE rn
constrains to , which gets ignored because of I am not totally sure how this all interacts, would have to look at the code, but it feels like the same root cause as