jiebi/CodeConvo huggingface dataset:
Change:
<!-- 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
modify labels: +regression-from-stable-to-stable Had to uninstall ~20 gigs of rustc releases again but since this code does not ICE on 1.20 but ices on 1.48.0, this is a stable-to-stable ice.
This started ICE'ing in 1.30.0. Error message in 1.29.0:
This is not supposed to work yet and it gives a good error message saying so -P-low Assigning and removing as in the prioritization working group.
The error message is helpful but it still panics in nightly. Do we want to fix the ICE at least or keep it?
A possible duplicate.
Fixed in

Discussion:
}); } }; <del> fragment_kind.expect_from_annotatables(items) </del> <ins> if fragment_kind == AstFragmentKind::Expr && items.is_empty() { let msg = "removing an expression is not supported in this position"; self.cx.span_err(span, msg); fragment_kind.dummy(span) } else { fragment_kind.expect_from_annotatables(items) } </ins> } Err(mut err) => { err.emit();

<ins> // AST-based macro attributes expanding to an empty expression produce an error and not ICE. #![feature(custom_test_frameworks)] #![feature(stmt_expr_attributes)] #![feature(test)] fn main() { let _ = #[test] 0; //~ ERROR removing an expression is not supported in this position let _ = #[bench] 1; //~ ERROR removing an expression is not supported in this position let _ = #[test_case] 2; //~ ERROR removing an expression is not supported in this position } </ins>

<ins> error: removing an expression is not supported in this position --> $DIR/attr-empty-expr.rs:8:13 | LL |     let _ = #[test] 0; |             ^^^^^^^ error: removing an expression is not supported in this position --> $DIR/attr-empty-expr.rs:9:13 | LL |     let _ = #[bench] 1; |             ^^^^^^^^ error: removing an expression is not supported in this position --> $DIR/attr-empty-expr.rs:10:13 | LL |     let _ = #[test_case] 2; |             ^^^^^^^^^^^^ error: aborting due to 3 previous errors </ins>
Change:
do you have the component installed? That adds a bunch more crates to the sysroot.
I believe these are required in rustc-dev as part of the need for (). I'll admit, I still don't fully understand the need for that, as it is quite mind-bending.
They are included in both rustc component and rustc-dev component. The latter are definitely used for example to build clippy, but I don't see reason for inclusion in rustc.

Discussion:
//! goes along from the output of the previous stage. use std::borrow::Cow; <ins> use std::collections::HashSet; </ins> use std::env; use std::fs; use std::io::prelude::*;

builder.info(&format!("Assembling stage{} compiler ({})", stage, host)); // Link in all dylibs to the libdir <ins> let stamp = librustc_stamp(builder, build_compiler, target_compiler.host); let proc_macros = builder .read_stamp_file(&stamp) .into_iter() .filter_map(|(path, dependency_type)| { if dependency_type == DependencyType::Host { Some(path.file_name().unwrap().to_owned().into_string().unwrap()) } else { None } }) .collect::<HashSet<_>>(); </ins> let sysroot = builder.sysroot(target_compiler); let rustc_libdir = builder.rustc_libdir(target_compiler); t!(fs::create_dir_all(&rustc_libdir)); let src_libdir = builder.sysroot_libdir(build_compiler, host); for f in builder.read_dir(&src_libdir) { let filename = f.file_name().into_string().unwrap(); <del> if is_dylib(&filename) { </del> <ins> if is_dylib(&filename) && !proc_macros.contains(&filename) { </ins> builder.copy(&f.path(), &rustc_libdir.join(&filename)); } }
Change:
I tried this code: When I run it under , I get this: Creating a reference from such pointer looks suspicious indeed. I could send a pull request that adds a condition there, but I want to ask first if this is being done because „we are , we can“, or if this is something that really should be fixed. : (but I've looked at the git sources and the thing is still there) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think it should only be UB to dereference the pointer you get from , so I'm not sure why Miri thinks there's UB happening. Just in case, prioritize
Because that pointer is being turned into a reference to feed to internally. And references are supposed to be always valid.
Looks like fixed this for but missed it in .
Yes, seems this needs to use .
I renamed the issue to reflect that the bug is actually in (which calls).
Cc
Assuming you use the default flags for Miri, that change should not be required to make Miri pass, so I'd be surprised if doing the same change for would make any difference here. If it does, that seems like a bug in Miri that I should investigate.
Ah, but the in is indeed a problem (the PR was mostly about so I got side-tracked; the is what should not have any effect here). Miri ensures that references are at least dereferencable, so yeah that would explain the problem here. Good catch!
Yep, I apparently missed this somehow in . Fixing the indicated line to use should be enough to fix it; I'm preparing the patch currently. claim
Hm, Miri still complains, even after the fix landed... it seems Miri doesn't like being called with dangling pointers. I'll have to look into this.
IIRC, when , I changed the type of the intrinsic to take a raw pointer rather than a reference, but miri wasn't touched, so that would make sense miri's still expecting a proper reference.
Patch arrived really fast, we are assigning "post-mortem" a priority of as discussed as part of the and removing .

Discussion:
use core::intrinsics::abort; use core::iter; use core::marker::{PhantomData, Unpin, Unsize}; <del> use core::mem::{self, align_of_val, size_of_val}; </del> <ins> use core::mem::{self, align_of_val_raw, size_of_val}; </ins> use core::ops::{CoerceUnsized, Deref, DispatchFromDyn, Receiver}; use core::pin::Pin; use core::ptr::{self, NonNull};

// Because it is `?Sized`, it will always be the last field in memory. // Note: This is a detail of the current implementation of the compiler, // and is not a guaranteed language detail. Do not rely on it outside of std. <del> unsafe { data_offset_align(align_of_val(&*ptr)) } </del> <ins> unsafe { data_offset_align(align_of_val_raw(ptr)) } </ins> } #[inline]
Change:
<!-- 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
According to Godbolt, this regressed in 1.39.0. Adding removes the ICE on latest nightly, which I think means this will be fixed by stabilization in . cc
Note that it doesn't ICE on the latest nightly (2020-12-25) with , but it still errors out because it's not supported under .
This is indeed fixed on master. I'll file a PR to add a regression test for this.

Discussion:
<ins> struct MyArray<const COUNT: usize>([u8; COUNT + 1]); //~^ ERROR generic parameters may not be used in const operations fn main() {} </ins>

<ins> error: generic parameters may not be used in const operations --> $DIR/issue-80375.rs:1:41 | LL | struct MyArray<const COUNT: usize>([u8; COUNT + 1]); |                                         ^^^^^ cannot perform const operation using `COUNT` | = help: const parameters may only be used as standalone arguments, i.e. `COUNT` = help: use `#![feature(const_generics)]` and `#![feature(const_evaluatable_checked)]` to allow generic const expressions error: aborting due to previous error </ins>
Change:
<!-- 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
modify labels: +regression-from-stable-to-stable This happens since rust
More minimal reproducer. Does not occur with just 1 variant. Or if one of the variants has a negative discriminant. Affects most targets if not all of them, despite the failure seemingly occurring inside the target-specific code.
Assigning P-medium as .20enum.20from.20an.20extern.20c.E2.80.A6) and removing I-prioritize.

Discussion:
} pub fn ext(&mut self, ext: ArgExtension) -> &mut Self { <del> assert!(self.arg_ext == ArgExtension::None || self.arg_ext == ext); </del> <ins> assert!( self.arg_ext == ArgExtension::None || self.arg_ext == ext, "cannot set {:?} when {:?} is already set", ext, self.arg_ext ); </ins> self.arg_ext = ext; self }

impl Scalar { pub fn is_bool(&self) -> bool { <del> if let Int(I8, _) = self.value { self.valid_range == (0..=1) } else { false } </del> <ins> matches!(self.value, Int(I8, false)) && self.valid_range == (0..=1) </ins> } /// Returns the valid range as a `x..y` range.

<ins> #![crate_type="lib"] #[repr(i8)] pub enum Type { Type1 = 0, Type2 = 1 } // CHECK: define signext i8 @test() #[no_mangle] pub extern "C" fn test() -> Type { Type::Type1 } </ins>
Change:
Hi, I was reading the when I stumbled upon this example (using the form with no hidden items): I think that the values for AtomicBool might be inverted, because this program never terminates when run in the playground. Should this be fixed or is there something I'm missing?
good catch, thanks! Would you like to fix it yourself? There are instructions at https://rustc-dev-; the command to test your changes is .
I'd love to! Do I just make a PR that references this issue then?
yup, that would be great :)

Discussion:
/// }; /// /// // Back on our current thread, we wait for the value to be set <del> /// while live.load(Ordering::Acquire) { </del> <ins> /// while !live.load(Ordering::Acquire) { </ins> ///     // The spin loop is a hint to the CPU that we're waiting, but probably ///     // not for very long ///     hint::spin_loop();
Change:
This the the of a proc macro crate : And here is the of another crate: When building, this outputs: 49.0, 1.50.0-beta.5 rustc 1.51.0-nightly ( 2021-01-05) binary: rustc commit-hash: commit-date: 2021-01-05 host: x86_64-unknown-linux-gnu release: 1.51.0-nightly
cc
cc
Assigning as discussed as part of the and removing .
assigning to self to confirm if is the cause of the breakage, and if so, revert the PR until it can be revised to handle this case.
This is caused by us not handling properly - I'm working on a fix.
Opened

Discussion:
let tokens = match *nt { Nonterminal::NtItem(ref item) => prepend_attrs(sess, &item.attrs, nt, item.tokens.as_ref()), Nonterminal::NtBlock(ref block) => convert_tokens(block.tokens.as_ref()), <del> Nonterminal::NtStmt(ref stmt) => prepend_attrs(sess, stmt.attrs(), nt, stmt.tokens()), </del> <ins> Nonterminal::NtStmt(ref stmt) => { let do_prepend = |tokens| prepend_attrs(sess, stmt.attrs(), nt, tokens); if let ast::StmtKind::Empty = stmt.kind { let tokens: TokenStream = tokenstream::TokenTree::token(token::Semi, stmt.span).into(); do_prepend(Some(&LazyTokenStream::new(tokens))) } else { do_prepend(stmt.tokens()) } } </ins> Nonterminal::NtPat(ref pat) => convert_tokens(pat.tokens.as_ref()), Nonterminal::NtTy(ref ty) => convert_tokens(ty.tokens.as_ref()), Nonterminal::NtIdent(ident, is_raw) => {

<ins> // check-pass // aux-build:test-macros.rs // compile-flags: -Z span-debug #![no_std] // Don't load unnecessary hygiene information from std extern crate std; #[macro_use] extern crate test_macros; macro_rules! empty_stmt { ($s:stmt) => { print_bang!($s); // Currently, all attributes are ignored // on an empty statement #[print_attr] #[rustc_dummy(first)] #[rustc_dummy(second)] $s } } fn main() { empty_stmt!(;); } </ins>

<ins> PRINT-BANG INPUT (DISPLAY): ; PRINT-BANG INPUT (DEBUG): TokenStream [ Group { delimiter: None, stream: TokenStream [ Punct { ch: ';', spacing: Alone, span: $DIR/issue-80760-empty-stmt.rs:25:17: 25:18 (#0), }, ], span: $DIR/issue-80760-empty-stmt.rs:13:21: 13:23 (#4), }, ] </ins>
Change:
<!-- 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. --: Also happens on 1.48.0 and nightly. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
On taking another look at the issues I found before filing this one, it looks like might be the same thing, as it has a similar stack trace. That code sample requires nightly, however, and this one does not. From a superficial examination (I know nothing about the compiler internals), both issues involve: multiple subexpressions (an array expression or a match) where the problem is sensitive to the number of them even if they're seemingly irrelevant a closure in one or more of the subexpressions calling a method on a literal in a constant context
This also reproduces the ICE:
Regression was too long ago to bisect to an individual commit, but the commit range is ....
Assigning as discussed as part of the and removing .
It looks like the ICE was introduced with / . The that triggers the ICE is at the end of . Issue , mentioned above by is triggered by a on the same but the error was already happening earlier in history. I observed it with the immediate parent commit .
Actually it looks like is the first commit with this issue
This is no longer ICE with the latest nightly, I think is the fix. Marking as .

Discussion:
<ins> // check-pass trait SomeTrait {} pub struct Exhibit { constant: usize, factory: fn(&usize) -> Box<dyn SomeTrait>, } pub const A_CONSTANT: &[Exhibit] = &[ Exhibit { constant: 1, factory: |_| unimplemented!(), }, Exhibit { constant: "Hello world".len(), factory: |_| unimplemented!(), }, ]; fn main() {} </ins>
Change:
At line 393, the guard object's field is incremented by the value returned from a read implementation. If a questionable returns a value larger than the buffer size, it will take that value and set the length of the vector over the boundary. This bug is reachable from and . Here is a that demonstrates the bug. It segfaults with .
This is definitely broken - nice find. A simple fix would be to just add an in the drop impl: You can still get weird behavior in readtoendwithreservation, but it should be memory safe and it seems best to avoid a bunch of extra logic in the main loop.
It looks like the bug was introduced in
Assigning as and removing .

Discussion:
{ let start_len = buf.len(); let mut g = Guard { len: buf.len(), buf }; <del> let ret; </del> loop { if g.len == g.buf.len() { unsafe {

} } <del> match r.read(&mut g.buf[g.len..]) { Ok(0) => { ret = Ok(g.len - start_len); break; </del> <ins> let buf = &mut g.buf[g.len..]; match r.read(buf) { Ok(0) => return Ok(g.len - start_len), Ok(n) => { // We can't allow bogus values from read. If it is too large, the returned vec could have its length // set past its capacity, or if it overflows the vec could be shortened which could create an invalid // string if this is called via read_to_string. assert!(n <= buf.len()); g.len += n; </ins> } <del> Ok(n) => g.len += n, </del> Err(ref e) if e.kind() == ErrorKind::Interrupted => {} <del> Err(e) => { ret = Err(e); break; } </del> <ins> Err(e) => return Err(e), </ins> } } <del> ret </del> } pub(crate) fn default_read_vectored<F>(read: F, bufs: &mut [IoSliceMut<'_>]) -> Result<usize>
Change:
On master branch with commit , replace with actual value and apply this diff: </detailsRun after that. Then run to check status of the repo. I expected to see this happen: Nothing should change. Instead, this happened: Many files changed dues to using wrong rustfmt. cc as in label T-infra <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I think custom rustc also overrides rustfmt, though probably shouldn't. Will investigate fixing.
Yeah, if you configure a rustc we currently default to the sibling rustfmt - that's probably a bug, we should use the python-downloaded rustfmt. The likely correct thing here is to move to setting RUSTFMT from on download, and then detecting that in similarly to rustc/cargo. We should probably treat it as an optional env variable for now though.
claim If no one has claimed it yet :)
Any starting point that I can get? Like the right file or something similar? :

Discussion:
} else { RustfmtState::Unavailable }; <del> } else { // If using a system toolchain for bootstrapping, see if that has rustfmt available. let host = config.build; let rustfmt_path = config.initial_rustc.with_file_name(exe("rustfmt", host)); let bin_root = config.out.join(host.triple).join("stage0"); if !rustfmt_path.starts_with(&bin_root) { // Using a system-provided toolchain; we shouldn't download rustfmt. *config.initial_rustfmt.borrow_mut() = RustfmtState::SystemToolchain(rustfmt_path); } </del> } // Now that we've reached the end of our configuration, infer the
Change:
Hello, I've tested the feature and encountered an ICE: If tried this code (): I've used the "current" playground nighty compiler, but I can reproduce locally. : and also on <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
label: +requires-nightly +A-allocators
Slightly minimized: Doesn't ICE anymore if you either remove the field or if it is not an array.
Duplicate of ?
No, not really a duplicate (but possibly related). This issue and the linked one have completely different backtraces.
Just by the way, using inline storage in an allocator is actually unsafe unless the impl of the trait is using a reference. See the Allocator safety notes: (Emphasis mine) ()
FWIW this is also triggered with uninhabited types. Though looks like only when drop glue is involved. Eg works but doesn't.
Another MCVE that leads to this ICE: found in
claim

Discussion:
}; for elem in place_ref.projection[base..].iter() { cg_base = match elem.clone() { <del> mir::ProjectionElem::Deref => bx.load_operand(cg_base).deref(bx.cx()), </del> <ins> mir::ProjectionElem::Deref => { // custom allocators can change box's abi, making it unable to be derefed directly if cg_base.layout.ty.is_box() && matches!(cg_base.layout.abi, Abi::Aggregate { .. } | Abi::Uninhabited) { let ptr = cg_base.project_field(bx, 0).project_field(bx, 0); bx.load_operand(ptr).deref(bx.cx()) } else { bx.load_operand(cg_base).deref(bx.cx()) } } </ins> mir::ProjectionElem::Field(ref field, _) => { cg_base.project_field(bx, field.index()) }

<del> // check-pass #![feature(allocator_api)] fn main() { Box::new_in((), &std::alloc::Global); } </del>

<ins> // build-pass #![feature(allocator_api)] use std::alloc::Allocator; struct BigAllocator([usize; 2]); unsafe impl Allocator for BigAllocator { fn allocate( &self, _: std::alloc::Layout, ) -> Result<std::ptr::NonNull<[u8]>, std::alloc::AllocError> { todo!() } unsafe fn deallocate(&self, _: std::ptr::NonNull<u8>, _: std::alloc::Layout) { todo!() } } fn main() { Box::new_in((), &std::alloc::Global); Box::new_in((), BigAllocator([0; 2])); } </ins>
Change:
The trait on 1.49.0 (current stable) doesn't contain modifier in function declaration of that trait. ! However, on and nightly, there is modifier. ! This is wrong because you cannot use modifier for each method/function in Trait definition. Why is this important? People copy the method/function declaration in the documentation to their code and see the compiler error: . : cc I think this might relate to some changes in visibility around macros ? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Yes, this needs the same fix as (in particular should work).
Self-assigning because this is a beta regression.
Note that this also occurs for the impl's docs.
Removed since this was fixed.
, trait methods still rendered as : ! Is there something wrong to Rust release or the bug still exists ?
Hmm, maybe it was only fixed for items in the local crate. do you have time to come up with an MCVE? I expect it's related to cross-crate re-exports.
Your guess sounds right. With core link (), things are normal.
I don't think I'll have time to fix this second part soon, so unassigning myself.
Assigning and removing as in the prioritization working group.
Removing E-mentor + E-easy labels since we don't have guides for cross-crate linking: label -E-easy -E-mentor
I think is the cross-crate case.
Fix backported to 1.50.0 and landed in 1.51.0, closing this.
Please reopen. The issue is not entirely fixed for cross-crate trait reexport case.
The cross-crate issue is now on stable. label: +regression-from-stable-to-stable -regression-from-stable-to-beta
claim

Discussion:
use crate::core::DocContext; use crate::formats::item_type::ItemType; <del> use super::Clean; </del> <ins> use super::{Clean, Visibility}; </ins> type Attrs<'hir> = rustc_middle::ty::Attributes<'hir>;

} crate fn build_external_trait(cx: &mut DocContext<'_>, did: DefId) -> clean::Trait { <del> let trait_items = cx.tcx.associated_items(did).in_definition_order().map(|item| item.clean(cx)).collect(); </del> <ins> let trait_items = cx .tcx .associated_items(did) .in_definition_order() .map(|item| { // When building an external trait, the cleaned trait will have all items public, // which causes methods to have a `pub` prefix, which is invalid since items in traits // can not have a visibility prefix. Thus we override the visibility here manually. // See https://github.com/rust-lang/rust/issues/81274 clean::Item { visibility: Visibility::Inherited, ..item.clean(cx) } }) .collect(); </ins> let predicates = cx.tcx.predicates_of(did); let generics = (cx.tcx.generics_of(did), predicates).clean(cx);

<ins> // aux-build:trait-visibility.rs #![crate_name = "foo"] extern crate trait_visibility; // @has foo/trait.Bar.html '//a[@href="#tymethod.foo"]/..' "fn foo()" pub use trait_visibility::Bar; </ins>