jiebi/CodeConvo huggingface dataset:
Change:
} // @has foo/fn.b_sink.html '//pre[@class="rust fn"]'  <del> //      'pub async fn b_sink<const N: usize>(__arg0: impl Trait<N>)' // FIXME(const_generics): This should be `_` not `__arg0`. </del> <ins> //      'pub async fn b_sink<const N: usize>(_: impl Trait<N>)' </ins> pub async fn b_sink<const N: usize>(_: impl Trait<N>) {} // @has foo/fn.concrete.html '//pre[@class="rust fn"]' 

Discussion:
<img width="1016" alt="rustdoc output screenshot" src="https://user-"This example was tested on Rust 1.46.0, but it has been broken for quite a while. For example, see ).
Relevant code: Not sure what's going wrong.
Thanks for the helpful hint, However, I'm not convinced this is the root cause because it's happening to all mutable by-value function arguments, not just to functions with as the first argument. For example, this free function emits similar results: <img width="1004" alt="Screen Shot 2020-09-15 at 9 56 26 AM" src="https://user-"I think the actual root cause may be deeper than the interpretation of types, but I can't tell for sure.
This example confirms that the behavior appears to be per-argument instead of per-function. It's not like one bad argument ruins the formatting of the entire function. <img width="983" alt="Screen Shot 2020-09-15 at 10 04 39 AM" src="https://user-"Perhaps we could investigate where in the code the text is being generated and work our way backwards to see what is triggering it?
Hmm, the only relevant location I could find through GitHub search is in in : Is operating on a desugared form of the AST? I don't think this is the case, since is being successfully displayed here. Is there something else I'm missing?
Here's the issue: Looks like it should use  instead. Are you interested in making a PR? ;)
Yes, rustdoc works on a desugared version and has to reconstruct the by hand.
Sure, I will prepare one right away. Thanks for investigating with me.
Change:
<del> error[E0308]: mismatched types --> $DIR/issue-99073.rs:6:13 </del> <ins> error: concrete type differs from previous defining opaque type use --> $DIR/issue-99073.rs:6:11 </ins> | <del> LL | fn fix<F: Fn(G), G: Fn()>(f: F) -> impl Fn() { |                                    --------- the expected opaque type LL |     move || f(fix(&f)) |             ^^^^^^^^^^ types differ </del> <ins> LL |   move || f(fix(&f)) |           ^^^^^^^^^^ expected `[closure@$DIR/issue-99073.rs:6:3: 6:10]`, got `G` </ins> | <del> = note: expected opaque type `impl Fn()` found type parameter `G` </del> <ins> note: previous use here --> $DIR/issue-99073.rs:6:3 | LL |   move || f(fix(&f)) |   ^^^^^^^^^^^^^^^^^^ </ins> error: aborting due to previous error <del> For more information about this error, try `rustc --explain E0308`. </del>

Discussion:
Messing around with a Haskell-like implementation of , I encountered two presumably similar ICEs (would think they're the same, but the error messages are obviously different). The other one is . I'm pretty sure this should be an error, based on the reasoning that returns an opaque type, so, while the output of might be , it also might not (and in this case, isn't), and since only accepts s, should be an error. Note that this implementation throws the ICE even without the main method, but I'm leaving it there for contrast to the other ICE. : Same ICE on nightly: <details<summary<strongBacktrace</strong</summary<p</p</details
This regressed in
I was able to "weaponize" this into a transmute, lol: So the issue here is that, at least in the case of RPITs, we are not checking for opaque type mismatches in closures correctly. The closure, in this example, is able to incorrectly constrain even though in the enclosing function, we define . During mir borrowck, we never check these two together, so we never report a type mismatch. I think I have a fix, though.
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Change:
<ins> // run-pass // ignore-windows - this is a unix-specific test // ignore-cloudabi // ignore-emscripten // ignore-sgx #![feature(rustc_private)] #![feature(setgroups)] extern crate libc; use std::process::Command; use std::os::unix::process::CommandExt; fn main() { #[cfg(unix)] run() } #[cfg(unix)] fn run() { let max_ngroups = unsafe { libc::sysconf(libc::_SC_NGROUPS_MAX) }; let max_ngroups = max_ngroups as u32 + 1; let vec: Vec<u32> = (0..max_ngroups).collect(); let p = Command::new("/bin/id").groups(&vec[..]).spawn(); assert!(p.is_err()); } </ins>

Discussion:
already offers and methods to control the user identity of the child process (calling respectively). For complete control of Unix credentials, there should also be a way to call and the concept of the supplementary group list are; I would expect this not to be a portability concern.) This feature would eliminate a use of and an unsafe block (to call ) from the program I'm currently writing, which is a port to Rust of a setuid C program. For illustration, this function exists in the C version: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I would be prepared to consider a PR to add .
claim
Change:
LL |     A(A), LL |     B(inner::Wrapper<B>), |     - not covered <ins> = note: pattern `Either::B(_)` is currently uninhabited, but this variant contains private fields which may become inhabited in the future </ins> = note: the matched value is of type `Either<(), !>` help: you might want to use `if let` to ignore the variant that isn't matched |

Discussion:
The following code compiles on nightly (): But if the wrapper type is moved into a module to make the field private, then it does not: (): Making the field makes it compile again. Is this expected? I suppose I could understand if it is; the private fields could change to make actually be constructable and therefore make the pattern refutable. But if that's the case, then I think the compiler should point this out, like . If indeed this is expected, is there any way for me as a library author to somehow convince the compiler that I will never change the fields to make the type constructable? I want users of my library to be able to elide match arms when I give them an . label +T-compiler +F-never_type +D-confusing +requires-nightly +S-bug-has-mcve
label +F-exhaustive_patterns
are we sure this is actually a bug? As I said, I could understand how it's not:
I'm not sure either way - however at the very least, as you point out, it makes sense to have some better diagnostics
This is definitely intentional. But yeah, it should have a better error message. Not currently I don't think. It would probably require us to add an trait, eg. something like: This trait would then need to be a lang item so that the exhaustiveness check could make use of it. Adding this trait would require an RFC but I doubt there'll be much enthusiasm for adding another special trait for such a niche use-case. Alternatively, you could give an or method to expose the uninhabitedness of the inner value. It's not quite what you're asking for but it's still concise-ish:
Is supposed to be “injected” where an otherwise required match arm was omitted? Wouldn't that run into the same discussions project-deref-patterns had about impure code (code with side effects) inside patterns? Their existence would heavily hinder optimizations of match expressions (like translation to jump tables or reordering).
If the type implementing really is uninhabited then there won't actually be any impure code in the match. The call to would only need to be injected for types that fake uninhabitedness with an impl that panics/aborts. We could also rule that out be instead making -only like .

Making a trait isn't straightforward exactly because inhabitedness depends on visibility questions. It would probably have to mean "Uninhabited as far as the outside world is concerned", or it could use a trick like the in to make it depend on the module.
Change:
<ins> // Here, there are two types with the same name. One of these has a `derive` annotation, but in the // expansion these `impl`s are associated to the the *other* type. There is a suggestion to remove // unneded type parameters, but because we're now point at a type with no type parameters, the // suggestion would suggest removing code from an empty span, which would ICE in nightly. // // issue: rust-lang/rust#108748 struct NotSM; #[derive(PartialEq, Eq)] //~^ ERROR struct takes 0 generic arguments //~| ERROR struct takes 0 generic arguments //~| ERROR struct takes 0 generic arguments //~| ERROR struct takes 0 generic arguments struct NotSM<T>(T); //~^ ERROR the name `NotSM` is defined multiple times //~| ERROR no field `0` 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. --: The message is kinda bad and trying to highlighting code that only exists behind the derive (is not visible to the user) Debug ice: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Change:
struct VaListImpl { gp_offset: i32, fp_offset: i32, <del> overflow_arg_area: *mut (), reg_save_area: *mut (), </del> <ins> overflow_arg_area: *mut c_void, reg_save_area: *mut c_void, </ins> } /// A wrapper for a `va_list`

Discussion:
On x8664, Aarch64, and PowerPC will not pass the lint, but it should. Given the following: The compiler will yield: The implementation of for the x8664, Aarch64, and PowerPC architectures uses or as the pointer type for the pointers to the architecture specific save areas (e.g., ).
defines . Perhaps should be used instead of
It would be fine to just special-case the language item in the lint implementation.
This seems reasonable to me too. The structure should (for obvious reasons) always be FFI safe.
Change:
--> $DIR/numeric-cast.rs:138:16 | LL |     foo::<i32>(x_u16); <del> |                ^^^^^ expected `i32`, found `u16` | help: you can convert an `u16` to `i32` and panic if the converted value wouldn't fit | LL |     foo::<i32>(x_u16.try_into().unwrap()); |                ^^^^^^^^^^^^^^^^^^^^^^^^^ </del> <ins> |                ^^^^^ |                | |                expected `i32`, found `u16` |                help: you can convert an `u16` to `i32`: `x_u16.into()` </ins> error[E0308]: mismatched types --> $DIR/numeric-cast.rs:140:16 | LL |     foo::<i32>(x_u8); <del> |                ^^^^ expected `i32`, found `u8` | help: you can convert an `u8` to `i32` and panic if the converted value wouldn't fit | LL |     foo::<i32>(x_u8.try_into().unwrap()); |                ^^^^^^^^^^^^^^^^^^^^^^^^ </del> <ins> |                ^^^^ |                | |                expected `i32`, found `u8` |                help: you can convert an `u8` to `i32`: `x_u8.into()` </ins> error[E0308]: mismatched types --> $DIR/numeric-cast.rs:142:16

Discussion:
() Errors: I would’ve expected something like: Edit: What actually should happen is the same as currently already with , i.e. it would look like modify labels: A-diagnostics, T-compiler, D-papercut, C-enhancement, E-easy <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Okay, lots of cases that already work got me confused into thinking this was fixed in nightly for a moment. What currently already works is the hint about converting where < where < What currently suggest even though works where < where ≤16 where ≤16
I reported a similar issue not long ago. Maybe it would be more robust and also more general to rewrite this suggestion code to actually look for the impl in question instead of having just a hard-coded list?
claim
I've created a PR augmenting the existing code to change the suggestions for the cases listed. However, I would like to explore the approach suggested(perhaps as part of a separate PR?). Any advice on how I could get the code to look for the impl so it can make the appropriate suggestion? Is the crate the right place to be looking at for this?
Yeah. I believe you'll need to create an and and then call , but there might be other/better ways to do this. You might want to ask for advice on Zulip.
Change:
//! //! The corresponding [`Sync`] version of `OnceCell<T>` is [`OnceLock<T>`]. //! <ins> //! ## `LazyCell<T, F>` //! //! A common pattern with OnceCell is, for a given OnceCell, to use the same function on every //! call to [`OnceCell::get_or_init`] with that cell. This is what is offered by [`LazyCell`], //! which pairs cells of `T` with functions of `F`, and always calls `F` before it yields `&T`. //! This happens implicitly by simply attempting to dereference the LazyCell to get its contents, //! so its use is much more transparent with a place which has been initialized by a constant. //! //! More complicated patterns that don't fit this description can be built on `OnceCell<T>` instead. //! //! `LazyCell` works by providing an implementation of `impl Deref` that calls the function, //! so you can just use it by dereference (e.g. `*lazy_cell` or `lazy_cell.deref()`). //! //! The corresponding [`Sync`] version of `LazyCell<T, F>` is [`LazyLock<T, F>`]. </ins> //! //! # When to choose interior mutability //!

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:
} } diag.emit(); ty::Binder::bind(fn_sig) } None => AstConv::ty_of_fn(

Discussion:
Hello, While trying to figure out how to keep a JoinHandle in a thread-local variable, I tried compiling this incorrect code, and rust crashed. It will not panic if I use a regular static var instead of in a block. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
The ICE happens since 1.44 label: +regression-from-stable-to-stable
ping icebreakers-cleanup-crew can we add a bit more detail and trace where this starts?
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
Assigning as discussed as part of the and removing . label -I-prioritize +P-medium
Regression between ... If I had to guess, I would say
Reduced testcase:
Not sure if of any help, but the thread_local macro is not needed:
const : Option<= map(value); ;)
Change:
<ins> #![feature(const_generics)] //~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash struct Bad<const N: usize, T> { //~ ERROR type parameters must be declared prior arr: [u8; { N }], another: T, } fn main() { } </ins>

Discussion:
: <details<summary<strongBacktrace</strong</summary<p</p</details
It doesn't require feature flag.
I am currently working on this
my first idea was to fix this ICE locally by offsetting in line 1318 for each wrongly placed const param. This only moves the error further back. I currently think that it would be best to actually fix the param order if order fails. Is this a good approach? And how should this be done, as is used in , which only receives an immutable reference to .
I think the right fix for this would be to make sure we can handle generic parameters in any order — there's no technical reason the parameters should be in a fixed order; it's just historical. This would involve doing what you started with, and fixing each problem in turn. However, I don't know how many things still rely on this order, so it could be an involved task. For a shorter-term fix, we could just make sure that generics are sorted if they're in the wrong order. We could probably do this in and sort the before creating the . This might be more pragmatic, though we should leave a to address later if we do this. Thanks for looking into this
Change:
<ins> //@ edition: 2021 //@ check-pass #![feature(async_closure)] // Make sure we don't ICE if an async closure has a macro body. // This happened because we were calling walk instead of visit // in the def collector, oops! fn main() { let _ = async || println!(); } </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 --
cc
I found the bug claim
Change:
use crate::json; use crate::util::get_pointer_width; use crate::util::{logv, PathBufExt}; <ins> use crate::ColorConfig; </ins> use regex::{Captures, Regex}; use rustfix::{apply_suggestions, get_suggestions_from_json, Filter};

Discussion:
When running on Linux and a failure happens, a really nice diff of the output vs rustdoc-nightly is produced which very clearly shows the issue. This does not work on Windows for multiple reasons. One the call to fails: Second, the output from rustdoc-nightly seems to exactly match that from the local compiler making it not possible to do manual diffs.
How do you diff directories recursively on Windows? On Linux I would be very surprised for not to be installed. Oh I just thought of something - do you have a rustup overide that defaults to your local toolchain? Right now compiletest assumes the default is nightly, I've been meaning to change it.
No, I only set overrides on specific projects (and rust-lang/rust is not one of them). My default is the stable compiler.
Git for Windows provides : Are you building Rust using Git Bash prompt?
I don't think it'd be a good idea to require testing rustdoc in the Git for Windows bash shell. I'd like for this to work in and PowerShell if possible.
Change:
<ins> // check-pass #![feature(generic_associated_types)] trait SomeTrait {} trait OtherTrait { type Item; } trait ErrorSimpleExample { type AssociatedType: SomeTrait; type GatBounded<T: SomeTrait>; type ErrorMinimal: OtherTrait<Item = Self::GatBounded<Self::AssociatedType>>; } fn main() {} </ins>

Discussion:
Using an associated type as an argument to a GAT will sometimes fail with an incorrect "trait bound is not satisfied" error, when that type is used to constrain an associated type of another trait. This code should compile fine. In particular, should be valid because is constrained to implement . However, the compilation fails with the following error: The trait bound is obviously satisfied, so something is wrong here. The suggested clause does not fix the error, instead the compiler will suggest you add another one. <details<summaryAdding the same bound again and again</summary<p</p</detailsThis error occurs even if the first two s, and , are part of other traits (implemented either by or some generic type arguments). The error seems to be affected by the presence and ordering of other items in the trait. This code happily compiles: But swapping the two items causes the above error: Make sure to write each test in a separate trait to avoid other items messing with your testing. I initially thought the example did not produce an error because I had put it into the same trait as other working examples. I found another issue, , that produces the same error message. However, I'm not sure if that is the same bug because I could not get to error in only the return type position. That issue's example also uses the TAIT feature (which I'm unfamiliar with) so I was unable to reduce it enough to see similarities to my example. : As well as rust playground label +T-compiler +F-genericassociatedtypes +A-Traits +requires-nightly
I just re-ran the playground example and noticed that the issue seems to have vanished. The playground is running and my local installation is this: I have no idea if this was an intentional fix or these issues just randomly vanished and the TAIT bug I linked still reproduces. I didn't find mentions of how to handle this case in any docs, so I will simply close this issue.
Isn't it worth keeping this issue open so we can add a proper test, so this bug doesn't regress?

I tried this code: I expected to see this happen: It compiles or gives me a detailed error. Instead, this happened: Compiler suggests to add an already existing trait bound. Adding it one more time leads to compiler suggesting adding it once more and so on. While the code example uses GAT and TAIT, I'm not entirely sure both of those features are required to reproduce the issue. label +T-compiler +F-typealiasimpltrait +F-genericassociated_types +A-traits +requires-nightly
This compiles fine on the latest nightly, perhaps related to .
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(); //~^ ERROR no method named `foo` found _a.baz(0); //~^ ERROR no method named `baz` found let _b = A {}; _b.bar(); //~^ 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:
} <del> fn test_X() { </del> <ins> pub fn main() { </ins> constants!(); }

Discussion:
The following code... ...results in the following error: Both and are loans of , so it should be safe to update to new loan of as updating doesn't cause to be freed.
This works now; I'll check in the test case.
Test case checked in in . Closing

Leaks.
this got worse; it now ICEs with an 'assertion failed: adt::is_newtypeish(repr)'
non-critical for 0.6, de-milestoning
Works now; I'll check in the test case.
Test case checked in in . Closing