jiebi/CodeConvo huggingface dataset:
Change:
<ins> #![feature(type_alias_impl_trait)] type Tait = impl Copy; // Make sure that this TAIT isn't considered unconstrained... fn empty_opaque() -> Tait { if false { match empty_opaque() {} //~^ ERROR non-empty } 0u8 } fn main() {} </ins>

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 (): Somehow in the second case we think that is unconstrained even though it doesn't seem to contain more or less type information than the first case. Note also that this does not error if I use RPIT instead.
I think in the second example mir building doesn't generate code for the trailing expression because it's statically known as dead code. But I thought we were keeping around the typeck types nowadays, and typeck should be the same for both functions
I don't think that's it, same error if I put the match in a branch ():
In fact this doesn't need an empty type at all:
I think we're generating bogus MIR or THIR because of that empty match -- Are you sure the bug doesn't exist on the THIR/MIR building side, (hacked to dump the instead of )
Oh I'm sure of nothing I just assumed an unreachable in a branch would not affect anything else
So: If there's a match error, we end up constructing a failure MIR body. This will prevent us from inferring the opaque later on. edit: that last sentence was a lie Let me see if I can cook up a quick fix.
Change:
NonMutatingUse(NonMutatingUseContext::Copy) | NonMutatingUse(NonMutatingUseContext::Move) | NonMutatingUse(NonMutatingUseContext::Inspect) <del> | NonMutatingUse(NonMutatingUseContext::Projection) </del> | NonMutatingUse(NonMutatingUseContext::PlaceMention) | NonUse(_) => {}

Discussion:
This code has UB under Stacked Borrows in Miri, but is fine with , and it should print However, under and above, it prints : cc
Here's a pure-surface Rust reproduction
any guess which MIR opt might be the culprit here?
Even more minimized reproducer: My first guess would be that some MIR analysis assumes that means that no pointer to can exist any more -- with Stacked Borrows that was true, but not with Tree Borrows. I usually push back against making Stacked Borrows assumptions in optimizations but looks like something slipped through? Cc
Even stranger, with Rust 1.69 we get . This goes back all the way to ; before that, we didn't have . Only beta and nightly without optimizations seem to do this correctly.
Does this look like the bad optimization?
yes, very much so. Specifically the is wrong, the rest then follows from that. Did ConstProp never learn that locals that have their address taken cannot be propagated?
I'm about to be busy for a few hours, so if someone else wants to bisect what changed with they should do that. I'll check back later.
I've been suspecting such a bug without managing to reproduce it for a few months. The bug is in the visitor, which mistreats place context. I can make a targeted fix in the hour.
I'm curious, how did you come up with this example?
I'm making a fuzzer targeting custom MIR :D It's still quite incomplete and currently hosted on an ETH Zürich private GitLab instance I guess I should make a public mirror on GitHub soon...
That is awesome! This is exactly the kind of stuff I was hoping to find with one.
Ah so should we report these? I think I read somewhere that custom mir is likely to get wrong and would always cause crashes then or something which is why I have ignored all of the / ICEs that I came across.
This isn't an ICE, this is a change in behavior due to enabling an optimization.
ah right sorry, I was confused with
Change:
<ins> error: `let` expressions are not supported here --> $DIR/issue-92893.rs:1:22 | LL | struct Bug<A = [(); (let a = (), 1).1]> { |                      ^^^^^^^^^^ | = note: only supported directly in conditions of `if` and `while` expressions error[E0658]: `let` expressions in this position are unstable --> $DIR/issue-92893.rs:1:22 | LL | struct Bug<A = [(); (let a = (), 1).1]> { |                      ^^^^^^^^^^ | = note: see issue #53667 <https://github.com/rust-lang/rust/issues/53667> for more information = help: add `#![feature(let_chains)]` to the crate attributes to enable error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0658`. </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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I was just looking at the parsing code for const generic exprs.. claim
actually, so this isn't related to incorrectly parsing , since we're parsing in expr position to allow if-let chains.. -- this is due to const eval lowering to MIR and the fact that const generic parameters have no enclosing scope. Adding around the generic args works, but I don't know where exactly to hack in a scope for these params. release-assignment label A-const-eval A-mir
Maybe fixing this also fixes :slightlysmilingface:
This gives an error without ICE in 1.55
It was unclear to me - I think meant that changing to gives a compile error instead of an ICE. So the proper fix here is probably to add somewhere instead of panicking.
Then this should be easy. claim
Change:
str::from_utf8(&child_output.stdout).unwrap(), str::from_utf8(&child_output.stderr).unwrap())); <del> fs::remove_dir_all(&child_dir).unwrap(); </del> <ins> let res = fs::remove_dir_all(&child_dir); if res.is_err() { // On Windows deleting just executed mytest.exe can fail because it's still locked std::thread::sleep_ms(1000); fs::remove_dir_all(&child_dir).unwrap(); } </ins> }

Discussion:
Here's the problematic piece: On my machine usually can't delete file with "access denied" error. If I insert something like before then the test consistently passes. Supposedly we are trying to delete it too soon when it's still locked after execution.
Change:
<ins> // If a struct is packed and its last field has drop glue, then that // field needs to be Sized (to allow it to be destroyed out-of-place). // // This is checked by the compiler during wfcheck. That check used // to have problems with associated types in the last field - test // that this doesn't ICE. #![allow(unused_imports, dead_code)] pub struct S; pub trait Trait<R> { type Assoc; } impl<X> Trait<X> for S { type Assoc = X; } #[repr(C, packed)] struct PackedAssocSized { pos: Box<<S as Trait<usize>>::Assoc>, } fn main() { println!("Hello, world!"); } </ins>

Discussion:
Given the following source code in both and , I encounter an internal compiler error using nalgebra 0.18.0. The code is probably not legal to begin with as I ran into it as I was moving from my own homebrewn math code to nalgebra. I have the impression that the compiler probably shouldn't ICE regardless of what junk you feed it, so I'm still reporting this. Build output from : I unfortunately do not have a newer nightly to test with due to the lack of a more recent RLS blocking the rustup attempt.
Still encountering this in . Indepent of the issue, you can install specific compiler versions with necessary components and .
This ICE itself arises from this line:
triage: P-high, assigning to self. Removing nomination.
Okay I've narrowed the test case down <details<summaryclick for first reduction</summaryHere is a standalone file (): </detailsUpdate: Got a better reduction now ():
This is a stable-to-stable regression, injected between rust 1.23 and 1.24.
the fact that the bug goes away if you take away the on leads me to hypothesize that the bug is caused by some internal layout code for checking the validity (or just computing the effects) of that use of )
(Also, bisection on my mac has shown this was injected by PR )
Change:
kind: DepKind, name: &'static str, ) -> QueryStackFrame { <ins> // If reduced queries are requested, we may be printing a query stack due // to a panic. Avoid using `default_span` and `def_kind` in that case. let reduce_queries = with_reduced_queries(); </ins> // Avoid calling queries while formatting the description let description = ty::print::with_no_queries!(do_describe(tcx, key)); let description = if tcx.sess.verbose_internals() {

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. --from Rustc will crash "normally" (expected as the bug is not fixed) but when trying to print the query stack, rustc will eat up all available memory which is BAD. <!-- 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
Its very likely hat this was caused by cc
This looks like again. It was fixed in , but the doesn't actually test what it's supposed to, because it doesn't check for the "end of query stack" line. (This also means that we currently have an UI that will fill up your entire RAM and then get killed.) The / calls are needed to fix this, not sure why they got removed.
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Change:
// We always need an unwinder currently for backtraces extern crate unwind; <del> #[cfg(stage0)] </del> <ins> #[cfg(any(stage0, feature = "force_alloc_system"))] </ins> extern crate alloc_system; // compiler-rt intrinsics

Discussion:
Edit: see Seems to get past there fine if I remove .
Ok, works. That's the version rustbuild will download if left to its own devices. Bisecting built nightlies as my local rust gives this: nightly-2016-12-19 () - works [no nightlies] nightly-2016-12-29 - unrelated errors on some i128/u128 stuff before it gets to the relevant point [no nightlies] nightly-2017-01-04 () - broken
Note that this is really quick to reproduce (~1min), as it happens on the initial build of stage0 std. Here's the full log from : This issue may get a lot more attention once the stage0 downloaded compiler has its version bumped, as I suspect will be totally broken. Applying seems to fix it.
Ah I see, the more recent compiler is being detected as a local rebuild compiler, so rustbuild assumes it has a compiler with stage1 features and therefore performs a stage1 build, which seems to assume that jemalloc is available. On a positive note, this should never affect someone not using .
Ok I have a more solid understanding of the issue. Currently, a stage0-out libstd will never link against jemalloc. stage1-out is left to its own devices, linking against the default allocator for the compiler that's just been created (stage0-out) which is , system otherwise. However, a local rebuild uses for building the stage0 libstd, which means it uses the default allocator for the local rust. This tends to be we've disabled jemalloc, so it hasn't been built! Something along the lines of seems like the right approach, but I think some elaboration around the logic in this area is necessary in comments or something.
Change:
branches: - 'master' schedule: <del> - cron: '5 15 * * *' # At 15:05 UTC every day. </del> <ins> - cron: '6 6 * * *' # At 6:06 UTC every day. </ins> env: CARGO_UNSTABLE_SPARSE_REGISTRY: 'true'

Discussion:
Specifically, this manifested with indexing into a dvec. Not all of the code that was manipulating s was handling the case. Already fixed it, about to check in a fix. Thanks to for the test case.

It's currently ignored on Windows.
The code in question looks like: When I commented-out the ignore and a then this test passed on my Windows machine (Mingw32 + 64 bit Windows 7). So perhaps this particular issue is no more?
Fixed in

A comment suggests the type should be something richer, perhaps, than just .
Blocked on or something similar
Definitely not backwards incompatible for 1.0 if this depends on Rust 2.0 features. Renominating.
Nominating for "far-future" (does that require nomination?)
FIXME is gone, bug is too vague, closing

as per a FIXME.
Ok, so, the strings "globalenv" and "getglobalenvchan" don't appear in the source anymore, so I'm going to close this bug...
Change:
LL |     let unconstrained = break; |                         ^^^^^ cannot `break` outside of a loop <del> error: aborting due to 5 previous errors </del> <ins> error[E0267]: `break` inside of a closure --> $DIR/break-outside-loop.rs:30:13 | LL |         || { |         -- enclosing closure LL |             break 'lab; |             ^^^^^^^^^^ cannot `break` inside of a closure error: aborting due to 6 previous errors </ins> Some errors have detailed explanations: E0267, E0268. For more information about an error, try `rustc --explain E0267`.

Discussion:
I tried to compile some massive project and the rust compiler unexpectedly panicked. Luckily, I have managed to replicate the error in a small, reproducible example (still panics on rust playground online, 11 lines of code): I expected a regular error without a panic, but the compiler simply halted. Output of RUSTBACKTRACE=1 rustc -o -C debuginfo=2: Output of :
Maximal reduction: This didn't ICE in 1.37.0 (checked with godbolt).
triage: P-medium (based on assumption that one will always see something like that error message, with its span, before the ICE). Assigning to self for now (but I welcome others who would like to work-steal it). Removing nomination label.
assigning to as well based on insight that this ICE may be arising from diagnostics.
I believe I have a fix. I'll post it after lunch. Edit: faster than I thought.
Change:
<ins> //compile-pass #![feature(nll)] fn main() { let _: &'static usize = &(loop {}, 1).1; } </ins>

Discussion:
This takes a while to compile. I presume because needs to hit the loop checker in miri. Changing the foofoo&(loop{}, 1).1'staticlifetime. () Errors:
The following code times out with either borrow checker:
The reason that foo matters is because of
I don't think this is an NLL issue in particular?
Based on 's identification of a test that reproduces the issue on either borrow-checker, I am going to remove the A-NLL label.
That example is not problematic, because nothing is promoted at all. I now don't even think my example is problematic anymore, because it seems to be perfectly alright to promote anything if we diverge before we give the user access to the value. I guess this just needs a test now (just a ui test with a comment, not a run-pass test, as that would hang forever)
Can I work on this? I'm a newbie to rust.
Sure! You can take the example from the issue message and create a new file in and add the comment at the top. Then, when running it should succeed to run the tests.
Change:
#![crate_name = "dependency"] #![crate_type = "rlib"] <del> pub struct Type(pub i32); pub trait Trait {} impl Trait for Type {} </del> <ins> pub struct Type; pub trait Trait { fn foo(&self); fn bar(); } impl Trait for Type { fn foo(&self) {} fn bar() {} } </ins> pub fn do_something<X: Trait>(_: X) {}

Discussion:
I'm writing code for a programming language that uses two libraries: one for a (very simple) parser, and another for a lower level byte code, which also uses the same parser library. The parser library (TSPL) defines the trait, with the byte code library (HVM) defining a that implements that trait through a macro from TSPL. Then, a third library does something like this, where is a method from that trait: This works as expected if the dependencies in are defined like this: If we change to use the version from the latest git commit like this: Then the code does not compile anymore, even though the version in the main branch in git has the exact same code as the published version . We get an error and a warning: Notice that the compiler error tells us the function has been found from the package, and we do as the error message tells us (), but the compiler does not recognize the trait is being used even so. While writing this issue, I figured out the problem: uses the version from crates-io and our library doesn't and, even though they have the exact same code, the two versions of clash and the compiler does not compile. If we do something like this it works as expected: I still want to open this issue because I believe the error message could be more descriptive: in other cases where dependencies have clashing versions of other dependencies, usually Rust specifies it as such. The current error message is not very descriptive - the solution it gives to the problem does not work at all and may push users into the wrong direction. <!-- 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<summaryBacktrace</summary<p</p</details

Consider three crates High, Mid and Low, where: Mid depends on Low; High depends on both Mid and Low. This is a quite common case. Now, it sometimes happens that the dependency of Mid is bumped to a more recent version of Low. If, however, the developer fails to bump the dependency of High to a more recent version of Low, surprising error messages arise. In particular, may arise, without any change to the code of either or . It would be great if the compiler could detect the error and somehow print something along the liens of
Triage: I feel like this has gotten better in certain cases, but not all. It would be nice to make a way to reproduce this more easily, but it's non-trivial.
Change:
color: var(--main-color); background-color: var(--stab-background-color); width: fit-content; <del> align-items: center; </del> white-space: pre-wrap; border-radius: 3px; <del> display: inline-flex; vertical-align: text-bottom; </del> <ins> display: inline; </ins> } .stab.portability > code {

Discussion:
see <img width="1728" alt="image" src=""- Arc 0.108.1 () MacOS 13.2.1 (22D68)
this seems like a rustdoc issue, cc ?
( I couldn't quickly reproduce locally yet, need to figure out the arguments first )
Yep, rustdoc issue, I'll transfer it across. This should be improved by just reducing the number of features shown here with , since a lot of them are already active for the module, but that won't help with the compression/decompression modules in the top-level list. !
Actually, rather than this made me realise there's another issue around how we deal with inlined re-exports, opened for that.
It's also kinda related to

I think long cfg expressions should be broken across multiple lines. I saw this cause issues : !
Do you have an idea on how to improve this maybe
What if we inserted zero width spaces after the keywords? So after each we insert a zero width space (see the ). Maybe we would have to wrap each name in a too but I would have to experiment a bit. Then each expression would try to stay as an inline-block and then break the line on the keywords (like , , , ...)
If we start having "groups", not sure if it'll work well. But definitely worth a try!
I started a test case with a long and complicated expression that results in this image: ! Currently combining a lot of short features is very unreadable and not's are hard to spot. With just it gets a lot more readable, but since the braces get lost in translation it is not clear which flags are binding with , or respectively. ! What if we display a little tree diagram? For most cases that would probably result in a short list with an or an in the beginning. Another idea could be to not draw the tree but to have visible boxes encasing the respective flags. What do you think?
I need to see things to be able to make my own opinion on which approach is better. :smile: But maybe has an idea?
Maybe it could show "any of"/"all of" on longer chains (say 3+)? I don't think there's a ton that can realistically be done here — a long cfg is going to result in a long doc cfg.
There are a lot of things that can be done. For example, for more than 3 items, we could show only the 3 first and show the rest on click. It's mostly about how to display things.
The original case has gotten a lot better, the actual doc string now gets ~60% of the horizontal space rather than ~30%: !
Rendering has degraded again (even though the documented cfg expressions themselves have become shorter): !
Change:
CC_x86_64_unknown_redox=x86_64-unknown-redox-gcc  CC_thumbv7neon_unknown_linux_gnueabihf=arm-linux-gnueabihf-gcc  AR_thumbv7neon_unknown_linux_gnueabihf=arm-linux-gnueabihf-ar  <del> CXX_thumbv7neon_unknown_linux_gnueabihf=arm-linux-gnueabihf-g++ </del> <ins> CXX_thumbv7neon_unknown_linux_gnueabihf=arm-linux-gnueabihf-g++  CC_riscv32i_unknown_none_elf=false  CC_riscv32imc_unknown_none_elf=false  CC_riscv32imac_unknown_none_elf=false  CC_riscv64imac_unknown_none_elf=false  CC_riscv64gc_unknown_none_elf=false </ins> ENV RUST_CONFIGURE_ARGS  --musl-root-armv5te=/musl-armv5te 

Discussion:
Do we have plan to get rid of this restriction recently? A newer version of cc-rs is needed for VxWorks
can't currently be updated due to a build problem with riscv. More info at I think the issue is that rustbuild uses cc to discover cc toolchains, and gained riscv support, and so now it thinks it should use a gcc toolchain that doesn't exist. The detection is in and Alex mentioned just setting a env var in the riscv container might be enough. It's been on my todo list for a while, but I haven't had a chance to look at it. I can maybe try to look at it this weekend.
Thanks for working on this issue. Enjoy your weekend, it is not that urgent.
Change:
#[label] pub testing_span: Span, } <ins> #[derive(Diagnostic)] #[diag(builtin_macros_non_generic_pointee)] pub(crate) struct NonGenericPointee { #[primary_span] pub span: Span, } </ins>

Discussion:
I tried this code: I expected to see this happen: compilation failure Instead, this happened: compilation succeeded <!-- 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 see for where to fix this issue <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim
Oops sorry. You can continue with your PR.