jiebi/CodeConvo huggingface dataset:
Change:
<ins> // build-pass // Regression test for #56870: Internal compiler error (traits & associated consts) use std::fmt::Debug; pub trait Foo<T> { const FOO: *const u8; } impl <T: Debug> Foo<T> for dyn Debug { const FOO: *const u8 = <T as Debug>::fmt as *const u8; } pub trait Bar { const BAR: *const u8; } pub trait Baz { type Data: Debug; } pub struct BarStruct<S: Baz>(S); impl<S: Baz> Bar for BarStruct<S> { const BAR: *const u8 = <dyn Debug as Foo<<S as Baz>::Data>>::FOO; } struct AnotherStruct; #[derive(Debug)] struct SomeStruct; impl Baz for AnotherStruct { type Data = SomeStruct; } fn main() { let _x = <BarStruct<AnotherStruct> as Bar>::BAR; } </ins>

Discussion:
Internal compiler error happens compiling weird code with traits and associated consts. I tried this code: I expected to see this happen: compiler not to crash Instead, this happened: compiler crashed with: Playground nightly: Playground stable:
Regression seems to have happened in 1.26; Testing this with works but it doesn't with 1.26.
error: internal compiler error: Type parameter (T/1) out of range when substituting (root type=Some(T)) substs=[T] thread 'main' panicked at 'Box<Any', note: Run with for a backtrace.
the example do not ICE any more from version 1.34.0 see
I'd like to work on this (specifically to add the tests). I've tested and can confirm as that the example does not trigger an ICE anymore. Tested on:
Change:
[repo]: https://github.com/rust-lang/rust [tarball]: https://static.rust-lang.org/dist/rustc-nightly-src.tar.gz <del> [trpl]: http://doc.rust-lang.org/book/index.html </del> ## Notes

Discussion:
There are a few issues of polish that I want to fix here: Although the installer internally supports multiple components there is no interface for actually selecting individual components. This is important because it allows to not install docs, which are 250 MB of the 50 MB install. Uninstallation can only be done through the original installer, which in many cases means the user is going to have to download the installer again. I want to put an uninstall script in the installation. This will require some refactoring and an upgrade of the installer manifest format.
This is a prereq for my plan to fix the .pkg uninstall issue
cc
cc
Change:
Encodable<EBWriter::Encoder> + Decodable<EBReader::Decoder> >(a1: &A) { <del> let bytes = do io::with_bytes_writer |wr| { let mut ebml_w = EBWriter::Encoder(wr); a1.encode(&mut ebml_w) }; </del> <ins> let mut wr = @mut std::io::mem::MemWriter::new(); let mut ebml_w = EBWriter::Encoder(wr); a1.encode(&mut ebml_w); let bytes = wr.inner_ref().to_owned(); </ins> let d = EBReader::Doc(@bytes); let mut decoder = EBReader::Decoder(d); let a2: A = Decodable::decode(&mut decoder); <del> if !(*a1 == a2) { ::std::sys::FailWithCause::fail_with(~"explicit failure" + "foo", "auto-encode.rs", 43u); } </del> assert!(*a1 == a2); }

Discussion:
The bots are currently failing like so I bisected to , which changes how works.
Closing since I'm almost certain that test is either gone, or passes.
This continues to be a source of breakage on incoming. Right now the failure is in rpass/auto-encode
run-pass/auto-encode is xfailed now
my branch contains a reduced test case under run-pass/issue-6122
incoming has been poofed, so I'm not sure what the status of this is. Bors has been churning away and the tree is green, so does the problem still arise?
The test passes locally for me with some updating. Pushed it to try, will see how it falls.
Change:
<ins> - // MIR for `f` before GVN + // MIR for `f` after GVN fn f() -> u32 { let mut _0: u32; let _1: u32; let mut _2: E; let mut _3: &U; let _4: U; scope 1 { debug i => _1; } scope 2 { let mut _5: &U; } bb0: { StorageLive(_2); StorageLive(_3); _5 = const _; _3 = &(*_5); _2 = ((*_3).1: E); StorageLive(_1); -         _1 = ((_2 as A).1: u32); +         _1 = const 0_u32; StorageDead(_3); StorageDead(_2); -         _0 = _1; +         _0 = const 0_u32; StorageDead(_1); return; } } </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
seem like options that when paired together would cause issues... At first glance, I'm actually not sure why this is filed as a bug.
I agree. Nobody should be testing , I don't know why those passes are even in the codebase. But this is a bug. I've found this in real code with a much smaller set of flags: And this bisects to Bisected by hand, there's no nightly with that PR yet. Don't know where Matthias got that toolchain.
Afaict likes to do ICE testing against master
We just hit this on Fuchsia as well. I think we should revert the PR until we fix this issue and reland it.
Another one with
Also here's a list of files from the rustc repo that all seem to trigger the problem in one way or another
Looks like there is one more issue in GVN ():
There is no basis for the assumption that interpreter will never downcast to an uninhabited variant:
nice example! That assert was as an experiment to see if we ever hit that codepath, and it seems like the answer is yes. It should thus be removed, with a suitable const-eval test case.
I wonder if that code shouldn't have a read somewhere though... it is conceptually a match after all. Still, the assertion should go: That adds test, but not the others.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
<ins> error: concrete type differs from previous defining existential type use --> $DIR/issue-52843-closure-constrain.rs:8:5 | LL |     fn _unused() -> Existential { String::new() } |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `i32`, got `std::string::String` | note: previous use here --> $DIR/issue-52843-closure-constrain.rs:6:1 | LL | / fn main() { LL | |     existential type Existential: Debug; LL | |     fn _unused() -> Existential { String::new() } LL | | LL | |     let null = || -> Existential { 0 }; LL | |     println!("{:?}", null()); LL | | } | |_^ error: aborting due to previous error </ins>

Discussion:
Mentioning the existential types tracking issue Mentioning and
O_o I don't think I considered closures at all. Should closures be defining uses? Or just uses (and thus only be able to return that type by calling a function that defines the existential)?
As a motivating use case, existential types defined by a closure are required if we want to extend to support referring to local variables.
Yeah, any in-scope use (including in a binding) can be a defining use.
A binding like this? It looks like this is not currently picked up. It is why I had to write rather than simply in my previous comment.
Yeah, the RFC specifies that that should work.
I chose a simpler logic: any in scope use must be a defining use.
We've moved from segmentation faults to an ICE:
Change:
return true; } <ins> // We sometimes have to use `defining_opaque_types` for subtyping // to succeed here and figuring out how exactly that should work // is annoying. It is harmless enough to just not validate anything // in that case. We still check this after analysis as all opque // types have been revealed at this point. if (src, dest).has_opaque_types() { return true; } </ins> crate::util::is_subtype(self.tcx, self.param_env, src, dest) } }

Discussion:
[ ] Previous Stable [ ] Current Stable [ ] Current Beta [ ] Current Nightly No response
searched toolchains through Regression in
I wonder if this is cc ?
very likely :thinking: will revert if we don't figure out how to fix this in the near future
<details<summarycompiler logs</summary</detailsedit: my bad I'm experiencing
WG-prioritization assigning priority (). label -I-prioritize +P-medium
bisection tested with , seems to point to commit searched nightlies: from nightly-2023-01-15 to nightly-2023-02-09 regressed nightly: nightly-2023-01-27 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsit's a rollup of:
I already bisected this one (see second comment :D) any should we revert now? it's still ICEing
yeah, wanted to revert this since looking at this a few days ago :sweat_smile: but for that I want to update the comment for why we're avoiding opaque types which is effort, so I've put it off for a while. Should get to it over the next few days
Change:
once: Once, // Whether or not the value is initialized is tracked by `state_and_queue`. value: UnsafeCell<MaybeUninit<T>>, <ins> /// `PhantomData` to make sure dropck understands we're dropping T in our Drop impl. /// /// ```compile_fail,E0597 /// #![feature(once_cell)] /// /// use std::lazy::SyncOnceCell; /// /// struct A<'a>(&'a str); /// /// impl<'a> Drop for A<'a> { ///     fn drop(&mut self) {} /// } /// /// let cell = SyncOnceCell::new(); /// { ///     let s = String::new(); ///     let _ = cell.set(A(&s)); /// } /// ``` _marker: PhantomData<T>, </ins> } // Why do we need `T: Send`?

Discussion:
to in the implementation of . This is correct for simple types like , but when 's implementation accesses borrowed data, this might lead to accessing already dropped data:
and also use in their impl. But I can't reproduce this problem with either of those instead of . Not sure why only seems to have this problem. Edit: Probably because contains in a , which doesn't implement . Adding a should fix that. (Testing that now.)
I think the problem is that puts no lifetime constraint on , so you can write any arbitrarily short-lived to the cell. It would have to at least outlive the reference.
Cc likely this affects upstream once_cell as well?
That's also the case for a Vec: This compiles fine. (As it should.) Replacing with from above here does give an error though, like it should. Looks like dropck does understand that 's is going to drop s. Looks like is what made that work properly for Vec and Box:
Oh, yeah, you're right
Doesn't look like it: the crate uses instead of :
Change:
prelude: RefCell::new(None), glob_importers: RefCell::new(Vec::new()), globs: RefCell::new((Vec::new())), <ins> traits: RefCell::new(None), </ins> populated: Cell::new(!external), arenas: arenas }

Discussion:
Before (on librustc): After (on same librustc): cc
The extra RAM usage seems to be because of the AST not getting freed after the early lint checks. Not sure if this is intentional.
The AST should definitely still get freed, nobody touched , so it's not intentional (unless something about the command line options has changed?)
The performance regression in looks like it was caused by . I'll work on a fix now. I'm not sure what caused the RAM increase.
Resolution used to take about 1 seconds a few months ago in winapi and now it takes 9 seconds.
I fixed the performance regression in .
Change:
load_self().and_then(|path| Path::new_opt(path).map(|mut p| { p.pop(); p })) } <del> /** * Returns the path to the user's home directory, if known. } </del> /** * Returns the path to the user's home directory, if known. *

Discussion:
Currently we don't support nested block comments. This allows lexing to be regular, but it widely seen as an inconvenience. Modify the lexer to keep track of comment nesting. Nominating backcompat.
I thought we were going to grow a macro to handle block quotes. Did that ever get implemented?
I don't know what you mean by block quotes.
Accepted for feature-complete
Don't line comments address pretty much all uses of nested block comments?
by block quote, I mean in the style of CPP's to allow for nesting comments. Something like this:
From what I've gathered from the code, there are two implementations of the comment parsing, one of which supports nested comments, so I guess should be fixed before this bug.
That's pretty funny that the pretty printer already supports nested comments. I don't think they necessarily have to be merged to fix this bug, though our lexing is a bit of a mess.
Are you going to tackle this?
If there's no massive refactoring to do, I can try! Expect a PR soon.
The reference manual says "Comments in Rust code follow the general C++ style of line and block-comment forms, with no nesting of block-comment delimiters" ... right after production rules for nested comments.
looks like it was forgotten to be updated, thanks for noticing! (I opened )
Change:
//! will want to make use of some form of **interior mutability** through the //! [`Cell`] or [`RefCell`] types. //! <ins> //! ## Naming threads //! //! Threads are able to have associated names for identification purposes. By default, spawned //! threads are unnamed. To specify a name for a thread, build the thread with [`Builder`] and pass //! the desired thread name to [`Builder::name`]. To retrieve the thread name from within the //! thread, use [`Thread::name`]. A couple examples of where the name of a thread gets used: //! //! * If a panic occurs in a named thread, the thread name will be printed in the panic message. //! * The thread name is provided to the OS where applicable (e.g. `pthread_setname_np` in //!   unix-like platforms). //! //! ## Stack size //! //! The default stack size for spawned threads is 2 MiB, though this particular stack size is //! subject to change in the future. There are two ways to manually specify the stack size for //! spawned threads: //! //! * Build the thread with [`Builder`] and pass the desired stack size to [`Builder::stack_size`]. //! * Set the `RUST_MIN_STACK` environment variable to an integer representing the desired stack //!   size (in bytes). Note that setting [`Builder::stack_size`] will override this. //! //! Note that the stack size of the main thread is *not* determined by Rust. //! </ins> //! [channels]: ../../std/sync/mpsc/index.html //! [`Arc`]: ../../std/sync/struct.Arc.html //! [`spawn`]: ../../std/thread/fn.spawn.html

Discussion:
One can specify the stack size of a thread via . It looks like looks at the env var and attempts to parse it into an integer. If it's not specified or can't parse, it falls back to 2MB. Should we update the thread documentation to mention what the default stack size is and mention that environment variable?
Relevant discussion on IRC
Don't forget that the stack size of the main thread is not determined by Rust.
Opened a PR:
Change:
<ins> // compile-flags: --crate-type lib -O -C debug-assertions=yes // Regression test for issue 118786 macro_rules! make_macro { ($macro_name:tt) => { macro_rules! $macro_name { //~^ ERROR macros that expand to items must be delimited with braces or followed by a semicolon //~| ERROR macro expansion ignores token `{` and any following //~| ERROR cannot find macro `macro_rules` in this scope () => {} } } } make_macro!((meow)); </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. --: The problem seems to be this: But it looks like rustc already gets the span wrong: !
<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p<!-- Include a backtrace in the code block by setting in your environment. E.g. RU &lt;!-- Include a backtrace in the code block by setting in your environment. E.g. . --&lt;details&lt;summary&lt;strongBacktrace&lt;/strong&lt;/summary&lt;p&lt;/p&lt;/detailsSTBACKTRACE=1 cargo build. --<details<summary<strongBacktrace</strong</summary<p</p</details</p</details
This appears to stem from the span for the delimited block being changed . I will work on a fix now and submit it.
Change:
#[inline] fn split_at_mut(&mut self, mid: usize) -> (&mut [T], &mut [T]) { <ins> let len = self.len(); let ptr = self.as_mut_ptr(); assert!(mid <= len); </ins> unsafe { <del> let self2: &mut [T] = mem::transmute_copy(&self); (ops::IndexMut::index_mut(self, ops::RangeTo { end: mid } ), ops::IndexMut::index_mut(self2, ops::RangeFrom { start: mid } )) </del> <ins> (from_raw_parts_mut(ptr, mid), from_raw_parts_mut(ptr.offset(mid as isize), len - mid)) </ins> } }

Discussion:
The problematic function: the first field return value is very much alive when is called on . This doesn't strictly violate LLVM's aliasing rules (AFAICT), because the overlapping part isn't directly accessed, but is still very sketchy (I can think of optimizers screwing it up).
Change:
TomlConfig::default() }; <ins> if cfg!(test) { // When configuring bootstrap for tests, make sure to set the rustc and Cargo to the // same ones used to call the tests (if custom ones are not defined in the toml). If we // don't do that, bootstrap will use its own detection logic to find a suitable rustc // and Cargo, which doesn't work when the caller is specìfying a custom local rustc or // Cargo in their config.toml. let build = toml.build.get_or_insert_with(Default::default); build.rustc = build.rustc.take().or(std::env::var_os("RUSTC").map(|p| p.into())); build.cargo = build.cargo.take().or(std::env::var_os("CARGO").map(|p| p.into())); } </ins> if let Some(include) = &toml.profile { // Allows creating alias for profile names, allowing // profiles to be renamed while maintaining back compatibility

Discussion:
I tried this with Rust 1.66.0, simplified from my build for Fedora: I expected to see this happen: passing tests Instead, this happened: 20 failures, all of this sort: My stage0 should be using . It most recently worked on: Rust 1.65.0 : I bisected this to , commit , which stopped using and environment variables when building a . <details<summaryBacktrace</summary<p</p</details modify labels: +regression-from-stable-to-stable -regression-untriaged +A-bootstrap <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
FYI we had the same problem on Debian, worked around with a custom patch:
Change:
#[stable(feature = "rust1", since = "1.0.0")] pub fn split_off(&mut self, at: usize) -> DList<T> { let len = self.len(); <del> assert!(at < len, "Cannot split off at a nonexistent index"); </del> <ins> assert!(at <= len, "Cannot split off at a nonexistent index"); </ins> if at == 0 { return mem::replace(self, DList::new()); <ins> } else if at == len { return DList::new(); </ins> } // Below, we iterate towards the `i-1`th node, either from the start or the end,

Discussion:
Currently, requires its argument to be strictly less than the length of the list, which means the following function panics when passed a one-element list. Instead, it should leave the original list unmodified and return an empty list: In contrast, does allow as a valid argument, so the above code works as desired if you replace DList with Vec.
Vec was actually like this until a few days ago when I happened to notice it and change the check. I must've mis-specified it in the RFC, or this went viral from the first mis-write.
Change:
// Try alternative arbitrary self types that could fulfill this call. // FIXME: probe for all types that *could* be arbitrary self-types, not // just this whitelist. <del> let box_rcvr_t = self.tcx.mk_box(rcvr_t); try_alt_rcvr(&mut err, box_rcvr_t); let pin_rcvr_t = self.tcx.mk_lang_item( rcvr_t, lang_items::PinTypeLangItem, ); try_alt_rcvr(&mut err, pin_rcvr_t); let arc_rcvr_t = self.tcx.mk_lang_item(rcvr_t, lang_items::Arc); try_alt_rcvr(&mut err, arc_rcvr_t); let rc_rcvr_t = self.tcx.mk_lang_item(rcvr_t, lang_items::Rc); try_alt_rcvr(&mut err, rc_rcvr_t); </del> <ins> try_alt_rcvr(&mut err, rcvr_t, lang_items::OwnedBoxLangItem); try_alt_rcvr(&mut err, rcvr_t, lang_items::PinTypeLangItem); try_alt_rcvr(&mut err, rcvr_t, lang_items::Arc); try_alt_rcvr(&mut err, rcvr_t, lang_items::Rc); </ins> } err.emit(); }

Discussion:
Test Program: Error message on nightly [ 2019-09-02] and before: Error message since nightly [ 2019-09-03]: Diff Between the Nightlies: Reported by and in
I'm testing this with regression in Maybe cause it
cc -- I think we need to be more graceful by checking if liballoc exists or not or not requiring the language items.
PR show more suggestions on method take ,, or when method not found However, , and don't exist in , but in . Error message of this code:
Mentoring instructions: Change to return and use instead of .Make take in and call instead and return early . Also be sure to not use .Include tests like above and make sure to check for Box, Rc, and Arc.Use to update the tests.
Change:
// Use an inherent impl so that imports are not required: #[cfg(stage1)] #[cfg(stage2)] <ins> #[cfg(stage3)] </ins> pub impl<T:Owned> PortSet<T> { fn recv(&self) -> T { port_set_recv(self) } fn try_recv(&self) -> Option<T> { port_set_try_recv(self) }

Discussion:
Kind of annoying to not have this imported by default.
Would it be an option to implement WriterUtils functionality as default methods on Writer? A similar situation exists with ReaderUtil too.
yes, that is a good use case for default methods, but they don't work yet.
Change:
"src/tools/rust-installer", "src/tools/rust-demangler", "src/tools/cargo", <ins> "src/tools/cargo/crates/credential/cargo-credential-1password", "src/tools/cargo/crates/credential/cargo-credential-macos-keychain", "src/tools/cargo/crates/credential/cargo-credential-wincred", </ins> "src/tools/rustdoc", "src/tools/rls", "src/tools/rustfmt",

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. --<!-- The steps to reproduce the bug. --(The actual target doesn't seem to matter, the feature just requires that we pass a argument.) The following error occurs: I think this issue occurs because already landed, while the cargo-side revert in did not. So this issue will likely go away after the next cargo update. I still decided to open this issue in case other people encounter the same problem. <!-- 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 for
This will be fixed by .
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(rustc_attrs)] #![allow(unused)] fn f() { let x: Vec<()> = Vec::new(); || { || { x.len() } }; } #[rustc_error] fn main() {} //~ ERROR compilation successful </ins>

Discussion:
This works: This does not and gives a confusing error: The error:
This also gives a confusing error: The following works:
None of these examples don't compile today, so I'm presuming this is fixed and marking E-needstest.
Can I take this issue and put this into a run-pass test?
Sounds good to me, though compile-pass would probably be sufficient - grep for .
Ok. Will do. Btw, it looks like this commit was fixed by .