jiebi/CodeConvo huggingface dataset:
Change:
install::Miri, install::LlvmTools, install::Src, <del> install::Rustc, </del> ), Kind::Run => describe!( run::ExpandYamlAnchors,

Discussion:
In a fresh install of 1.72.0 there are some files: The same thing happens with 1.71.1.
Performed a test on 1.72.0 and was able to reproduce the problem. With HEAD: , it is no longer present(most probably fixed on the cargo side since it doesn't have anything to do with bootstrapping). If you encounter the problem again, please feel free to re-open the issue.
I'm still hitting this with 1.73.0.
Perhaps it's related to my setting. I'll do more experiments tomorrow and report back...
Still happens with 1.74.0. The terminal output of (I've removed the lines):
Would be nice if you can share your Last time I tried I couldn't reproduce it.
I think I see the same with Rust 1.76:
Are you building multiple targets?
No. I just set following in : and .
should handle this problem.
Change:
use rustc_hir::def::CtorKind; use rustc_hir::def_id::DefId; use rustc_middle::middle::stability; <ins> use rustc_middle::span_bug; </ins> use rustc_middle::ty::layout::LayoutError; <del> use rustc_middle::ty::TyCtxt; </del> <ins> use rustc_middle::ty::{Adt, TyCtxt}; </ins> use rustc_span::hygiene::MacroKind; use rustc_span::symbol::{kw, sym, Symbol}; <ins> use rustc_target::abi::{Layout, Primitive, TagEncoding, Variants}; </ins> use super::{ collect_paths_for_type, document, ensure_trailing_slash, item_ty_to_strs, notable_traits_decl,

Discussion:
introduced a basic section on layout information, with only one piece of information: the total size of the type. I think one useful but easy extension to this is reporting the size of each variant for an enum. cc The "Layout" section is rendered in The variable is a .In that case we have access to an . The part will give us the size of the variant To get the name of the variant, we'll need the stored in , which we can hopefully get from . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think we could just look up the to find the name (there's probably a function for that). Also, it might be worth showing the sizes of each union field.
claim
Change:
relocations .iter() .map(|&(offset, reloc)| { <del> (offset + dest.offset - src.offset + (i * size * relocations.len() as u64), reloc) </del> <ins> // compute offset for current repetition let dest_offset = dest.offset + (i * size); ( // shift offsets from source allocation to destination allocation offset + dest_offset - src.offset, reloc, ) </ins> }) ); }

Discussion:
Minimized as best I could: With Full error:
cc
Cc
Even more minimal example:
Const eval is drunk (note the gap of relocations between the second and fourth element and again after the fourth elemen): Validation is doing everything correctly
Change:
<ins> error[E0308]: mismatched types --> $DIR/ice-self-mismatch-const-generics.rs:11:9 | LL | impl<T> GenericStruct<0, T> { |         ------------------- this is the type of the `Self` literal LL |     pub fn new(thing: T) -> GenericStruct<1, T> { |                             ------------------- expected `GenericStruct<1, T>` because of return type LL |         Self { thing } |         ^^^^^^^^^^^^^^ expected `1`, found `0` | = note: expected struct `GenericStruct<_, 1>` found struct `GenericStruct<_, 0>` help: use the type name directly | LL |         GenericStruct::<1, T> { thing } |         ~~~~~~~~~~~~~~~~~~~~~ error[E0308]: mismatched types --> $DIR/ice-self-mismatch-const-generics.rs:20:9 | LL | impl<T> GenericStruct2<0, T> { |         -------------------- this is the type of the `Self` literal LL |     pub fn new(thing: T) -> GenericStruct2<1, T> { |                             -------------------- expected `GenericStruct2<1, T>` because of return type LL |         Self { 0: thing } |         ^^^^^^^^^^^^^^^^^ expected `1`, found `0` | = note: expected struct `GenericStruct2<_, 1>` found struct `GenericStruct2<_, 0>` help: use the type name directly | LL |         GenericStruct2::<1, T> { 0: thing } |         ~~~~~~~~~~~~~~~~~~~~~~ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0308`. </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. --Strangely enough, the following does not ICE: <!-- 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 occured on nightly However, it appeared to not happen on rustc stable 1.75.0 <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I'm pretty sure this is from , cc
I would also like to add this also causes an ICE, so it's likely that it has to do with type constructors
Change:
/// result. After this, no more unification operations should be /// done -- or the compiler will panic -- but it is legal to use /// `resolve_vars_if_possible` as well as `fully_resolve`. <ins> /// /// Make sure to call [`InferCtxt::process_registered_region_obligations`] /// first, or preferrably use [`InferCtxt::check_region_obligations_and_report_errors`] /// to do both of these operations together. </ins> pub fn resolve_regions_and_report_errors( &self, generic_param_scope: LocalDefId,

Discussion:
into causes an internal compiler panic This causes an internal compiler error: This seems related to , except this is using
:
This is not specific to . The following produces the same kind of error.
modify labels: +regression-from-stable-to-stable The ICE happens on stable regardless of having the feature gate or not (the ICE does not requires a nightly compiler to reproduce)
Change:
use convert::TryFrom; use fmt::{self, Write}; use slice; <del> use str::from_utf8_unchecked_mut; </del> <ins> use str::{from_utf8_unchecked_mut, FromStr}; </ins> use iter::FusedIterator; use mem::transmute;

Discussion:
I'm not sure if this is an oversight. But the implementation should be trivial. I'll add tests and implement it, if it is fine.
Strings aren't indexable and .len() doesn't count the number of chars. :smile: What comes to mind first is an iterator inspecting the two first chars:
xD I didn't test my code, but you get the gist. I had a impl at first, but then edited it
cc
Triage: this has not been .
PRs welcome!
I can take this. I was also thinking of adding a impl for , but unsure if it would be better to wait for to get closer to stabilization and use that instead of adding another empty enum to std
wait, that wouldn't work bc of lifetime issues regardless, right? :(
Change:
pub fn flush_delayed(&self) { let mut inner = self.inner.lock(); let bugs = std::mem::replace(&mut inner.delayed_span_bugs, Vec::new()); <del> inner.flush_delayed(bugs, "no errors encountered even though `delay_span_bug` issued"); </del> <ins> inner.flush_delayed( bugs, "no errors encountered even though `delay_span_bug` issued", ExplicitBug, ); </ins> } }

Discussion:
With beta but nightly does not show backtraces: edits this is with prioritize
can you share your example code, as it doesn't seem that all ICEs are missing backtraces: on the same nightly and beta, and which has a backtrace on both. (if you have the time to do so and a master checkout, it'd be interesting to know whether ThinLTO could be involved like in ; bisection would also be worthwhile)
Hmm interesting, maybe its' something that only happens with :thinking: does not show a backtrace for me ! I also can't force it with or anything :(
This backtrace was removed on purpose in because it's useless. It just points at the place in the error machinery where delayed bugs get flushed, which is either just noise or misleading at worse.
This also affects explicit calls too -- these should be restored in . Regarding s backtraces being useless, see .
Change:
/// the operating system. Platform sources: /// /// - Unix-like systems (Linux, Android, Mac OSX): read directly from <del> ///   `/dev/urandom`. </del> <ins> ///   `/dev/urandom`, or from `getrandom(2)` system call if available. </ins> /// - Windows: calls `CryptGenRandom`, using the default cryptographic ///   service provider with the `PROV_RSA_FULL` type. <del> /// </del> <ins> /// - iOS: calls SecRandomCopyBytes as /dev/(u)random is sandboxed </ins> /// This does not block. pub struct OsRng { hcryptprov: HCRYPTPROV

Discussion:
This can just be done by attempting the system call and falling back if it fails at runtime.
IIRC, getrandom() is not about speed (I-slow label), but about security from file description exhaustion attacks. It uses the urandom pool. See patch:
I'm aware that it's the same pool. The I-slow label is sensible for an improvement that would reduce the number of system calls and necessary file descriptors.
thanks, now I got it. I'll try to fix it tomorrow if it'll still be open/untouched.
Relevant Go patch:
Change:
diag_handler.emit_err(LtoDylib); return Err(FatalError); } <ins> } else if *crate_type == CrateType::ProcMacro { if !cgcx.opts.unstable_opts.dylib_lto { diag_handler.emit_err(LtoProcMacro); return Err(FatalError); } </ins> } }

Discussion:
I'm trying to cross-compile the rust compiler to x86_64 on an M1 macOS machine with LTO enabled and ran into a compile error while building the stage2 compiler artifact: I also tried cross-compiling aarch64 on an Intel Mac and ran into the same issue. Here is the I used: It seems that is enabling LTO for proc-macro crates, but only when cross-compiling?
sorry for pinging, are there any updates on this issue? This bug is easily reproducible, and is preventing cross compiling the toolchain with LTO enabled.
I haven't had time to look into this, no. You can always disable LTO as a workaround.
This problem also appears when just the vendor of the target tripple changes (i.e. ).
Thank you for the additional feedback, will look into this issue in couple weeks.
Change:
<ins> // compile-flags: -Z mir-opt-level=0 // EMIT_MIR issue_91633.hey.mir_map.0.mir fn hey<T> (it: &[T]) where [T] : std::ops::Index<usize>, { let _ = &it[0]; } // EMIT_MIR issue_91633.bar.mir_map.0.mir fn bar<T> (it: Box<[T]>) where [T] : std::ops::Index<usize>, { let _ = it[0]; } // EMIT_MIR issue_91633.fun.mir_map.0.mir fn fun<T> (it: &[T]) -> &T { let f = &it[0]; f } // EMIT_MIR issue_91633.foo.mir_map.0.mir fn foo<T: Clone> (it: Box<[T]>) -> T { let f = it[0].clone(); f } 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
Minimized a bit more:
It started ICE-ing in 1.41.0:
This compiles successfully without the bound. It also compiles if you change the bound to constrain the associated type:
I bisected it to be between and : I've tried to bisect between these commits, but I'm getting a compilation error in llvm.
It'll be , which changed the coherence rules to allow . The impl in this code is intentionally allowed under the new rules and should be fine, so it didn't really regress in that PR so much as it was newly permitted but likely surfaced a pre-existing bug. I tried to replicate this issue with a local trait but compiles successfully, so this does seem to involve the built-in trait and operator (the error message complains about the MIR statement which is a built-in index).
Further reduced to: , but not on 1.24.0 I agree with assessment:
So it could be considered a stable-to-stable regression? I don't how or who could add this label.
Yeah, I guess we could modify labels +regression-from-stable-to-stable although it's a regression from a very old stable
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Change:
Reveal::All => { let args = data.args.try_fold_with(self)?; let recursion_limit = self.interner().recursion_limit(); if !recursion_limit.value_within_limit(self.anon_depth) { <del> // A closure or coroutine may have itself as in its upvars. // This should be checked handled by the recursion check for opaque // types, but we may end up here before that check can happen. // In that case, we delay a bug to mark the trip, and continue without // revealing the opaque. self.infcx </del> <ins> let guar = self .infcx </ins> .err_ctxt() .build_overflow_error(&ty, self.cause.span, true) .delay_as_bug(); <del> return ty.try_super_fold_with(self); </del> <ins> return Ok(Ty::new_error(self.interner(), guar)); </ins> } let generic_ty = self.interner().type_of(data.def_id);

Discussion:
This triggers a stack overflow of rustc (even without the TAIT feature gate, i.e. on stable too) (): <details<summaryBacktrace</summary<p</p</details
(side-note: doesn't overflow in the new trait solver )
I'm gonna look into this
Change:
<ins> error: incorrect function inside `extern` block --> $DIR/issue-91370-foreign-fn-block-impl.rs:5:8 | LL |   extern { |   ------ `extern` blocks define existing foreign functions and functions inside of them cannot have a body LL | LL |       fn f() { |  ________^___- | |        | | |        cannot have a body LL | | LL | | LL | |         impl Copy for u8 {} LL | |     } | |_____- help: remove the invalid body: `;` | = help: you might have meant to write a function accessible through FFI, which can be done by writing `extern fn` outside of the `extern` block = note: for more information, visit https://doc.rust-lang.org/std/keyword.extern.html error: aborting due to previous error </ins>

Discussion:
I'm seeing an internal compiler error on the following input, found by : Affected versions: I tried nightly 2021-11-28 and stable 1.56.1 and they both ICE. In stable 1.56.1 the error message is different though, I would say it's better: <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
In one of the recent nightlies the error message has changed to <details<summary<strongBacktrace</strong</summary<p</p</details
Change:
} #[test] <ins> fn issue_108453() { let mut deque = VecDeque::with_capacity(10); deque.push_back(1u8); deque.push_back(2); deque.push_back(3); deque.push_front(10); deque.push_front(9); deque.shrink_to(9); assert_eq!(deque.into_iter().collect::<Vec<_>>(), vec![9, 10, 1, 2, 3]); } #[test] fn test_shrink_to() { // test deques with capacity 16 with all possible head positions, lengths and target capacities. let cap = 16; for len in 0..cap { for head in 0..cap { let expected = (1..=len).collect::<VecDeque<_>>(); for target_cap in len..cap { let mut deque = VecDeque::with_capacity(cap); // currently, `with_capacity` always allocates the exact capacity if it's greater than 8. assert_eq!(deque.capacity(), cap); // we can let the head point anywhere in the buffer since the deque is empty. deque.head = head; deque.extend(1..=len); deque.shrink_to(target_cap); assert_eq!(deque, expected); } } } } #[test] </ins> fn test_shrink_to_fit() { // This test checks that every single combination of head and tail position, // is tested. Capacity 15 should be large enough to cover every case.

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: no error Instead, this happened: note: no zero was pushed, this is reading an undefined byte. <!-- 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. --: I believe this happens because the following case is not handled in In this case, , so two of the "cases of interest" are not a match, and , so the last case isn't matched either.
cc
I can submit a PR to fix it later today. I was under the impression that the tests covered all cases for but apparently not.
Change:
color: #000; background: transparent; } <del> p a { color: #4e8bca; } p a:hover { text-decoration: underline; } </del> <ins> .docblock a { color: #4e8bca; } .docblock a:hover { text-decoration: underline; } </ins> .content span.trait, .content a.trait, .block a.current.trait { color: #ed9603; } .content span.mod, .content a.mod, block a.current.mod { color: #4d76ae; }

Discussion:
Markdown list items separated by blank lines are wrapped in p tags within li tags ("loose" list). formatting. List items not separated by blank lines use only li tags ("tight" list). Links in loose lists are displayed in blue and are easily distinguishable as links. Links in tight lists are normal text colored and do not appear as links (although clicking them still works). Examples of both list types follow: Adding the missing formatting to loose lists is difference appears to be straight-forward CSS change. In , two rules control link appearance in loose lists (lines 377 & 378 in the commit): Adding a second selector to each rule colors the links: There are only two other li rules and these do not affect color. So, the change above may be all that is needed to fix this issue.
Just patched locally and can confirm it works. Thanks! R/Scott
Change:
item: &'tcx hir::Item<'_>, renamed: Option<Symbol>, import_id: Option<LocalDefId>, <del> ) -> bool { </del> <ins> ) { </ins> debug!("visiting item {:?}", item); let name = renamed.unwrap_or(item.ident.name); let tcx = self.cx.tcx;

Discussion:
If we run with the option on this code: Both and are documented, but not being accessible outside of , it shouldn't be documented.
probably knows this, but for others seeing this issue, I think it's probably due to (which was reverted in , and later re-applied in ). It has to do with the fact that we're using a HIR visitor now, so we're visiting nested items unconditionally.
Yes I know where it's coming from. :smile: I was just thinking today that since we were going through the whole HIR without checking whether or not we were in a block, all elements inside the block could be visible. Tested and... :fearful: Should be pretty easy to fix.
For reference, I put up because this was causing documentation to become really verbose with serde + . If you fix this such that we no longer document those items, we could probably revert that PR.
Indeed. Don't hesitate to come to me if you have such issues with rustdoc. Such problems should definitely not go unnoticed.
The thing is, it was not particularly clear from the PRs whether this was intentional or not.
Unfortunately it wasn't. The goal was to retrieve the missing impl blocks. But if anything isn't clear, don't hesitate to ask too. :wink:
Change:
<ins> // check-pass #![feature(adt_const_params, generic_const_exprs)] //~^ WARN the feature `adt_const_params` is incomplete and may not be safe to use and/or cause compiler crashes [incomplete_features] //~^^ WARN the feature `generic_const_exprs` is incomplete and may not be safe to use and/or cause compiler crashes [incomplete_features] pub struct Changes<const CHANGES: &'static [&'static str]> where [(); CHANGES.len()]:, { changes: [usize; CHANGES.len()], } impl<const CHANGES: &'static [&'static str]> Changes<CHANGES> where [(); CHANGES.len()]:, { pub fn combine(&mut self, other: &Self) { for _change in &self.changes {} } } pub 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
A reduced version: Tested in using
The other ICE block is also standalone
for the first example: ` Regression in :thinking: EDIT: same for the second snippet.
This is caused by Seems as if this issue takes care of FIXME ^^. Not sure what the right solution is, we originally tried to skip reborrows because implicit autorefs/autoderefs lead to confusing error messages given that we don't support derefs and refs in abstract consts. Maybe the right solution is to just clarify that autorefs/autoderefs happen there. Thoughts
No longer ICEs since (perhaps due to ?)
Change:
<ins> error[E0605]: non-primitive cast: `&&[i32; 1]` as `&[_]` --> $DIR/issue-73886.rs:2:13 | LL |     let _ = &&[0] as &[_]; |             ^^^^^^^^^^^^^ an `as` expression can only be used to convert between primitive types or to coerce to a specific trait object error[E0605]: non-primitive cast: `u32` as `std::option::Option<_>` --> $DIR/issue-73886.rs:4:13 | LL |     let _ = 7u32 as Option<_>; |             ^^^^^^^^^^^^^^^^^ an `as` expression can only be used to convert between primitive types or to coerce to a specific trait object error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0605`. </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. --When trying to cast a slice, I encountered an ICE in nightly rust. It works in at least two different nightly versions: rustc 1.46.0-nightly ( 2020-06-26) and rustc 1.46.0-nightly ( 2020-06-29). I haven't tested any other versions. In stable rust (1.44.1), no ICE occurs. A minimal example to reproduce this is here: I expected the following result: Instead, I encountered an ICE. From the little testing I have done, it seems to require slices for the ICE to occur. Replacing the slices with structs causes the ICE to disappear. I got the ICE to work with the following two versions: : and It might work with earlier versions of nightly as well, but I haven't checked this. It does not occur with the latest stable version (1.44.1). <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Let’s try to find the culprit for this. ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
searched nightlies: from nightly-2020-06-19 to nightly-2020-06-27 regressed nightly: nightly-2020-06-20 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details modify labels: -E-needs-bisection
Probably cc
Prioritized as as per .