jiebi/CodeConvo huggingface dataset:
Change:
<ins> // Regression test for #62504 #![feature(const_generics)] #![allow(incomplete_features)] trait HasSize { const SIZE: usize; } impl<const X: usize> HasSize for ArrayHolder<{ X }> { const SIZE: usize = X; } struct ArrayHolder<const X: usize>([u32; X]); impl<const X: usize> ArrayHolder<{ X }> { pub const fn new() -> Self { ArrayHolder([0; Self::SIZE]) //~^ ERROR: array lengths can't depend on generic parameters } } fn main() { let mut array = ArrayHolder::new(); } </ins>

Discussion:
results in: Removing the constgenerics feature flag gets the expected error message: (IIUC that itself is a bug related to ) Using directly outside of a const-context works, which I guess is something const_generics enables that isn't otherwise allowed. Finally, the error message is the same whether or not the code is in a provided method or a impl block; I actually ran into the bug in the later.
I believe this should be fixed by
Now, it shows different ICE(s) ():
Now ICE no longer occurs. I think it's fixed by .
Change:
/// # Examples /// /// Initialize static variables with `LazyLock`. <del> /// </del> /// ``` <del> /// use std::collections::HashMap; /// </del> /// use std::sync::LazyLock; /// <del> /// static HASHMAP: LazyLock<HashMap<i32, String>> = LazyLock::new(|| { ///     println!("initializing"); ///     let mut m = HashMap::new(); ///     m.insert(13, "Spica".to_string()); ///     m.insert(74, "Hoyten".to_string()); ///     m </del> <ins> /// // n.b. static items do not call [`Drop`] on program termination, so this won't be deallocated. /// // this is fine, as the OS can deallocate the terminated program faster than we can free memory /// // but tools like valgrind might report "memory leaks" as it isn't obvious this is intentional. /// static DEEP_THOUGHT: LazyLock<String> = LazyLock::new(|| { /// # mod another_crate { /// #     pub fn great_question() -> String { "42".to_string() } /// # } ///     // M3 Ultra takes about 16 million years in --release config ///     another_crate::great_question() </ins> /// }); /// <del> /// fn main() { ///     println!("ready"); ///     std::thread::spawn(|| { ///         println!("{:?}", HASHMAP.get(&13)); ///     }).join().unwrap(); ///     println!("{:?}", HASHMAP.get(&74)); /// ///     // Prints: ///     //   ready ///     //   initializing ///     //   Some("Spica") ///     //   Some("Hoyten") /// } </del> <ins> /// // The `String` is built, stored in the `LazyLock`, and returned as `&String`. /// let _ = &*DEEP_THOUGHT; /// // The `String` is retrieved from the `LazyLock` and returned as `&String`. /// let _ = &*DEEP_THOUGHT; </ins> /// ``` <ins> /// </ins> /// Initialize fields with `LazyLock`. /// ``` /// use std::sync::LazyLock;

Discussion:
These types are now, however, the docs don't properly mention them everywhere yet: lists OnceCell in the overview, but not LazyCell. The docs should also explain when I should use which of these types, as they are superficially pretty similar. lists Once and OnceLock, but not LazyLock. The same point about "when to use which type" applies. (It seems like is basically the same as , but I am not sure.) Cc
thatnks for the PR! The question of Once vs OnceLock seems to remain unresolved though. If Once is to OnceLock what is to Mutex, then it should probably be considered extremely niche as one can't even safely protect any data that way?
Yeah, I do indeed have nothing useful to say about Once, basically, because it doesn't seem very useful except as a raw implementation primitive of OnceLock. I suppose we could add a comment that soft-discourages it?
Yeah I think that would be useful.
Change:
<ins> // edition:2018 // compile-flags: -Z mir-opt-level=2 -Z unsound-mir-opts #[inline(always)] pub fn f(s: bool) -> String { let a = "Hello world!".to_string(); let b = a; let c = b; if s { c } else { String::new() } } </ins>

Discussion:
Compiling with I get since two nightlies:
Triage: It's now compiled fine with the latest nightly, I think it's fixed by .
It works now, thank you.
This should be open until the test is .

<!-- 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. --Code is from glaciers , original ticket: The code still ICEs when checking with <!-- 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. --repo is @ <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Triage: It's now compiled fine with the latest nightly, perhaps it's fixed by .

As , the MIR inliner seems to fail when dealing with opaque return types. Test case: Invocation: <details<summaryICE:</summary</details
I'm not sure how async closures desugar, so this could be way off base, but this looks very similar to the other ICEs tracked in . Does this look like another instance of that issue to you?
The immediate cause of this is the fact that we call during inlining: If we do this, we should also be normalizing the substs we pass to , so that we reveal any opaque types. However, it looks like the opaque type occurs within a binder (due the opaque type appearing in the return type of an fn pointer), so I think lazy normalization may be required to fix this in the general case.
Triage: It's now compiled fine with the latest nightly, I think it's fixed by .
Change:
$(foreach t,$(CFG_TARGET),$(eval $(call DEF_OSTYPE_VAR,$(t)))) $(foreach t,$(CFG_TARGET),$(info cfg: os for $(t) is $(OSTYPE_$(t)))) <del> # FIXME: no-omit-frame-pointer is just so that task_start_wrapper # has a frame pointer and the stack walker can understand it. Turning off # frame pointers everywhere is overkill CFG_GCCISH_CFLAGS += -fno-omit-frame-pointer </del> # On Darwin, we need to run dsymutil so the debugging information ends # up in the right place.  On other platforms, it automatically gets # embedded into the executable, so use a no-op command.

Discussion:
We currently build C++ code and Rust with frame pointers on, though we don't actually use them for anything (intended for GC). This is overhead that C and C++ don't usually have so it would be nice to turn on elimination.
I think we'll need them for gc, fwiw
on Linux x86_64 we should be using the DWARFv3 Call Frame Information for walking the stack, although I have no idea if we're emitting it correctly right now (likely on OS X and FreeBSD too). We might be, because gdb uses it and seems to work.
We'll leave it off until we have solutions for GC, which will probably end up being platform specific. libunwind should make it easy on linux and freebsd.
Reopening because this caused a regression in , so reverted in
Change:
<del> // check-pass </del> // edition: 2021 <ins> // known-bug: #105197 // failure-status:101 // dont-check-compiler-stderr </ins> #![feature(async_fn_in_trait)] #![feature(return_position_impl_trait_in_trait)]

Discussion:
Compiling the  from failed on nightly due to lifetime error while it works on stable. The code in question looks like this and is in taken from On nightly, this failed with: :
modify labels: +regression-from-stable-to-beta
labels +E-needs-bisection
searched nightlies: from nightly-2022-12-06 to nightly-2022-12-10 regressed nightly: nightly-2022-12-10 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: </details labels -E-needs-bisection
searched nightlies: from nightly-2022-12-09 to nightly-2022-12-27 regressed nightly: nightly-2022-12-10 searched commit range: regressed commit: () <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Sorry, false positive in bisect labels -E-needs-bisection Also raced, sorry :(
You can manually bisect the PRs in that rollup, contains the list of each of their artifacts. I'd start by looking at though.
Yep, it's cc
Possible other examples from beta crater: https://crater- https://crater- https://crater-
Any update on this? I've tested the code on: and it still failed.
AFAICS your bug report has been acknowledged and has an assignee, looks like it's a regression in the beta channel (). The new stable will be out in a few weeks, might be fixed by then.
Thanks, so looks like it's going to take quite some time. I might go ahead and release without waiting for this one.
WG-prioritization assigning priority (). label -I-prioritize +P-high +T-compiler
Change:
<ins> // run-rustfix struct A { } trait M { fn foo(_a: Self); fn bar(_a: Self); fn baz(_a: i32); } impl M for A { fn foo(_a: Self) {} fn bar(_a: A) {} fn baz(_a: i32) {} } fn main() { let _a = A {}; A::foo(_a); //~^ ERROR no method named `foo` found A::baz(0); //~^ ERROR no method named `baz` found let _b = A {}; A::bar(_b); //~^ ERROR no method named `bar` found } </ins>

Discussion:
We had solved case in , could do the same for No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
not a power of two"), Unsupported(ref msg) => write!(f, "{}", msg), <del> UninhabitedValue => write!(f, "tried to use an uninhabited value"), </del> } } }

Discussion:
This ICEs on stable, probably since March 2018, but it requires the user to do UB in constants, so... I think a possible fix would be to enable validation in const eval (cc ), though we should benchmark the perf considerations around that first. Alternatively we can just not ICE here and instead emit an error. () Errors:
Interesting. ICEs in Miri with are also bugs, so I'd say doing more validation is not the right call. Do you have a backtrace? Which code is responsible for ICEing here and how hard/bad would it be to just error instead?
It's ICEing in and we could indeed just emit a UB error here, but it seems very... odd, since the field access check has very little to do with UB at a first glance. The layout is a union with zero fields, because it's essentially .
TBH this looks like a bug to me. That's the layout of which type, ? It should have a field, and it should not be a union. Cc
It's not a bug. Just like layout for a newtype with a single field is not a bug (E.g. ).
Precisely by analogy with , I think this is a bug. Your has a with exactly 1 field, matching what is declared. It does not have 2 fields which would be the case if it had a "pair layout". So, transparent layout changes the , but it does not change how many "fields" a type is considered to have. Similarly, has 3 fields in its layout, despite still being a . So, correspondingly, should have 1 field.
oh... right. Yea we should totally fix that
This being a layout bug would trivially break codegen, why is only miri affected?
Codegen might skip the field access because the type is uninhabited?
I wouldn't be so sure, codegen calls on layouts a lot without checking. Can the ICE print the whole ? That might be more useful here. EDIT: oh this might be why: we don't check the index at all:
yea but we can't use because that ICEs during const prop in the array case. I have a local branch that I'm playing with to get the entire picture
You can literally remove the assert to get the same effect.

But if the field count is wrong I'd rather have an assert in both places and fix the count (if possible).
The full is and so far I haven't figured out how that can happen
Ah, nevermind, I found it:
Ah so that's a micro-optimization. Maybe we should compute the right thing.
computes the layout for structs but keeps returning the never layout for enums without inhabited variants
Change:
<ins> // Copyright 2016 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(advanced_slice_patterns, slice_patterns)] fn check(list: &[Option<()>]) { match list { //~^ ERROR `&[None, Some(_), None, _]` and `&[Some(_), Some(_), None, _]` not covered &[] => {}, &[_] => {}, &[_, _] => {}, &[_, None, ..] => {}, &[.., Some(_), _] => {}, } } fn main() {} </ins>

Discussion:
Hello, According to this , I have writted this example: But after the rustc 1.14.0-nightly version from 2016-10-25 --, I expected to see this happen:
Minimal example Fails with
regression introduced in .
How can this be a stable-nightly regression when this affects a gated feature?
Not sure what's the policy about it. It's a regression.
Yeah, I totally agree that this is a regression, although the label is inaccurate. I have wanted a label in the past (for eg. ), and think that once upon a time there even was such a label.
Change:
[[package]] name = "term" <del> version = "0.4.6" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "fa63644f74ce96fbeb9b794f66aff2a52d601cbd5e80f4b97123e3899f4570f1" dependencies = [ "kernel32-sys", "winapi 0.2.8", ] [[package]] name = "term" </del> version = "0.6.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "0dd90505d5006a4422d3520b30c781d480b3f36768c2fa2187c3e950bc110464"

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and -- nominating for prioritization.
I suspect miri just needs a compiletest update cc
triage: P-medium. Removing nomination label.
So, the compiletest-update was semver-breaking?
The failure seems to be a panic in cargo...?
not quite, nightly rustc broke compiletest and we play catch up with that since the nightly feature is "current nightly" the cargo panic you're seeing is an osx bug in cargo that got fixed
Is this a recent bug? It looks (in Miri CI) as if the bug occurred with stable cargo.
this bug appeared in nightly and got fixed on the next day. Could you cargo version from CI (after installing master toolchain)?
It's recent, but not on stable, maybe you're seeing something else.
FWIW, the trouble was that Travis on the auto branch used a beta cargo, not a stable one, due to caching.
Change:
<ins> trait A<Y, N> { type B; } type MaybeBox<T> = <T as A<T, Box<T>>>::B; struct P { t: MaybeBox<P>, //~ ERROR: overflow evaluating the requirement `P: Sized` } impl<Y, N> A<Y, N> for P { type B = N; } fn main() { let t: MaybeBox<P>; } </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</detailsThe bug happens in here: It happens due to an assertion that the error is a which it isn't i guess. I think it's related to a type being contained within itself, but not really.
This ICEs since 1.49.0. In 1.48.0, gives the following errors:
bisection result searched nightlies: from nightly-2020-08-01 to nightly-2021-03-10 regressed nightly: nightly-2020-10-07 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Assigning as discussed as part of the and removing . label -I-prioritize +P-medium
Slightly simplified:
No longer ICEs since
Change:
display: flex; padding: 3px; margin-bottom: 5px; <ins> align-items: center; vertical-align: text-bottom; </ins> } .item-name .stab { margin-left: 0.3125em;

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:
} } <ins> impl fmt::Debug for CommandEnv { fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result { let mut debug_command_env = f.debug_struct("CommandEnv"); debug_command_env.field("clear", &self.clear).field("vars", &self.vars); debug_command_env.finish() } } </ins> impl CommandEnv { // Capture the current environment with these changes applied pub fn capture(&self) -> BTreeMap<EnvKey, OsString> {

Discussion:
currently only outputs the program and it's arguments. It should also output the environment variables and the current path, as set by , and . This would help with figuring out what's going on :-)
We also currently have no way to extract most of this information without utilizing Debug, so out of tree implementations can't be implemented.
Would/should this be the specific additions to the environment set by , or the actual environment? The most straightforward implementation of this (debug-printing the individual fields of the internal struct) seems to do the latter. That is, this patch (in )— results in program behavior like this (scroll right to see the very bulky output; should be verbose, but how verbose is too verbose??):
I'd be fine with the verbose output. The debug output is only meant for debug purposes and generating the full environment saves us from oh-that's-why-it's-not-working-this-stupid-thing moments
Seems reasonable. I would be ready to consider a PR implementing this.
Triage: no changes here. I've actually wanted this too, but don't have the bandwidth to work on it, personally.
Change:
LL | fn test<T: Default<Id = U>, U>() {} |                    ^^^^^^ required by this bound in `test` <del> error[E0282]: type annotations needed --> $DIR/specialization-unconstrained.rs:14:22 | LL |    default type Id = T; |                      ^ cannot infer type for associated type `<T as Default>::Id` error: aborting due to 2 previous errors; 1 warning emitted </del> <ins> error: aborting due to previous error; 1 warning emitted </ins> <del> Some errors have detailed explanations: E0282, E0284. For more information about an error, try `rustc --explain E0282`. </del> <ins> For more information about this error, try `rustc --explain E0284`. </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: I expected to see this happen: compiles, or a helpful error message Instead, this happened: Confusing error message, there doesn't seem to be a future that could be awaited?... Interestingly if the default implementation is removed, it compiles. Playground: <!-- 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
The error message on the playground is a bit different, seems to be correlating with the actual problem more, but even more confusing: Expected and found are the same!
Minimal: Something funky going on with the default projection predicate installed for the GAT. I'll look into it
I'm impressed by the speedy handling of this issue! Was hoping this would get a fix in a few weeks . You're awesome!
Once the pr is merged, it will be available the next day on nightly, correct? Btw, the pr failed some tests.
Change:
return None; } <del> self.use_ecx(source_info, |this| this.ecx.eval_mir_constant(&c.literal, Some(c.span), None)) </del> <ins> // Normalization needed b/c const prop lint runs in // `mir_drops_elaborated_and_const_checked`, which happens before // optimized MIR. Only after optimizing the MIR can we guarantee // that the `RevealAll` pass has happened and that the body's consts // are normalized, so any call to resolve before that needs to be // manually normalized. let val = self.tcx.try_normalize_erasing_regions(self.param_env, c.literal).ok()?; self.use_ecx(source_info, |this| this.ecx.eval_mir_constant(&val, Some(c.span), None)) </ins> } /// Returns the value, if any, of evaluating `place`.

Discussion:
https://crater-
searched nightlies: from nightly-2023-01-24 to nightly-2023-03-30 regressed nightly: nightly-2023-02-05 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: </detailsThis looks related to , but wasn't fixed by
Let's notify the people involved in that bisection, it's cc author and reviewer A minimization would be helpful.
probably just allowed another existing bug to show up, like the other projection issues. I've reduced the regression to this it still depends on , if anyone has the time to also remove that.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
This seems to have disappeared in nightly. Bisect points to Maybe fixed by
Wasn't that PR already present in your previous bisection up to nightly-2023-03-30 ?
Ah, looks like the is fixed in , but not the .
label -E-needs-mcve +S-has-mcve