jiebi/CodeConvo huggingface dataset:
Change:
} else { let size = layout.size.bytes() - tag_size; write!(w, "{size} byte{pl}", pl = if size == 1 { "" } else { "s" },); <ins> if layout.abi.is_uninhabited() { write!( w, " (<a href="https://doc.rust-lang.org/stable/reference/glossary.html#uninhabited">uninhabited</a>)" ); } </ins> } }

Discussion:
Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc
I'm ambivalent, I don't think showing zero is necessarily wrong, especially since that's what's reported by .
In my opinion, I think that while size 0 is not wrong, that showing that it's uninhabited is more right, or at least more clear and makes the distinction.
I don't understand uninhabited when I first see it. It is a hard word compared to 0. I think 0 is easier. Why not both? What if we show ? Also, what if the enum is not empty but have a single/multiple ZST like phantom type?
I think displaying 0 is better as well, but we can do as suggested and simply display both.
0 is wrong. 0 means "this is a zero sized type", like or ; it can be created. Uninhabited types cannot be created, they are things like and . IMO posting 0 there is actively misleading. See also Ok, then we can link to some docs. I didn't see anything in the nomicon but I'm sure they'd take a PR adding it to "exotically sized types".
This is a bug imo, it allows transmuting from ZSTs to uninhabited types which is UB.
Even if they cannot be created, their size remain 0 as they don't "exist", however since they cannot be constructed, it makes sense to mention they're unhabited types. Well, I don't have a strong conviction on this in any case. I think we all agree for the mention of "unhabited" though.
Yeah, that solved the issue of 0 which is wrong. I do think it is better to link it to , but I think it's wrong to put that in "size" such that it should be in "type" instead, because it doesn't have a size to begin with. Well, there are parts where rust sacrificed correctness for ease of understanding, one example is which means uniqueness not exactly mutable all the time.
claim
Note that uninhabited is orthogonal to size. You can have an uninhabited type of any size.

So I think showing uninhabitedness is good, but in addition to the size+align, not instead.
Hmm, I think that will report that the size is always 0 for an uninhabited type though, unless that's changed recently.
That would surprise me, since that'd be different from what and do:
Change:
<ins> // This is a non-regression test for issue #116657, where NLL and `-Zpolonius=next` computed // different loan scopes when a member constraint was not ultimately applied. // revisions: nll polonius // [polonius] compile-flags: -Zpolonius=next #![feature(impl_trait_in_assoc_type)] trait Callable { type Output; fn call(x: Self) -> Self::Output; } trait PlusOne {} impl<'a> PlusOne for &'a mut i32 {} impl<T: PlusOne> Callable for T { //[nll]~^ ERROR not all trait items implemented //[polonius]~^^ ERROR not all trait items implemented type Output = impl PlusOne; //[nll]~^ ERROR unconstrained opaque type //[polonius]~^^ ERROR unconstrained opaque type } fn test<'a>(y: &'a mut i32) -> impl PlusOne { <&mut i32 as Callable>::call(y) //[nll]~^ ERROR hidden type for `impl PlusOne` captures lifetime //[polonius]~^^ ERROR hidden type for `impl PlusOne` captures lifetime } fn main() {} </ins>

Discussion:
File: reduced: original: Version information Command: Program output:
cc
Some notes dump: the original test fuzzed into this MCVE is . NLLs and do compute the same scopes on that original difference in scopes here is on a somewhat ambiguous case in the current implementation: the loan ultimately flows into via member constraints, not a regular outlives constraint. NLL still computes a scope for it, doesn't since it considers the loan to escape the we ignored the member constraint here and computed the scope anyways, it would result in the same results as NLLs and not trigger the assert. A handful of other tests would then fail of SCC member constraints difference between this test and these other 4 seems to me to be about applied member constraints. That is, in this test the member constraint is likely not applied, so maybe the loan should only be considered to escape via these. We had discussed this very subject before, but thought the distinction didn't matter for the purpose of computing scopes -- maybe we were wrong in these edge cases. That should be a correct fix and should work on these 5 tests. So I'll look into that next.
Change:
.suggestion = escape `box` to use it as an identifier parse_box_syntax_removed = `box_syntax` has been removed <del> .suggestion = use `Box::new()` instead </del> <ins> parse_box_syntax_removed_suggestion = use `Box::new()` instead </ins> parse_cannot_be_raw_ident = `{$ident}` cannot be a raw identifier

Discussion:
Found by grepping through the compiler via while reviewing an unrelated PR. File : File : : . or move source file . : . <details<summaryFull compiler output</summary</details:
Solution: Get rid of altogether and use a multi-part suggestion (, ).
Change:
= note: expected type `{integer}` found type `{float}` <del> error: aborting due to 76 previous errors </del> <ins> error: aborting due to 85 previous errors </ins> Some errors have detailed explanations: E0029, E0308. For more information about an error, try `rustc --explain E0029`.

Discussion:
The CI for started to fail today with this error: It appears as though the compiler doesn't see and only sees as the range expression and then generates this error. The expression is inside a expansion. You can reproduce this by cloning the repo and building it: The build succeeds on the stable channel and much older releases, so this appears to be a regression in the nightly. Here's the version on my windows system, but note that this also fails on linux and macos too:
Regression introduced in
More specifically the bug is in: which is called to see whether what follows is a valid start of a range pattern end expression. This is strange tho... in the case of e.g.: the call to in is used successfully to parse but somehow that doesn't work for . cc
Similarly, with: this does not trigger "error: range patterns are not supported" but it should.
Change:
<ins> error[E0391]: cycle detected when processing `Foo` --> $DIR/existential-types-with-cycle-error.rs:3:1 | LL | existential type Foo: Fn() -> Foo; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | note: ...which requires processing `crash`... --> $DIR/existential-types-with-cycle-error.rs:6:25 | LL |   fn crash(x: Foo) -> Foo { |  _________________________^ LL | |     x LL | | } | |_^ = note: ...which again requires processing `Foo`, completing the cycle note: cycle used when collecting item types in top-level module --> $DIR/existential-types-with-cycle-error.rs:1:1 | LL | / #![feature(existential_type)] LL | | LL | | existential type Foo: Fn() -> Foo; LL | | ...  | LL | | LL | | } | |_^ error: aborting due to previous error For more information about this error, try `rustc --explain E0391`. </ins>

Discussion:
Playing with the nighly's existential types, I stumbled upon a compiler stack overflow: Error message:
A better example might be this: removing the from the existential type decleration just compiles fine
Can you try running the compiler inside gdb and produce a backtrace?
<details<summaryBacktrace:</summary</details
It's recursing in Ideally this should cause cycle errors. But I'm assuming Manually computes this without a query. Maybe we should just make a query? This would solve both the FIXME and this issue.
Both examples now produce a cycle error. So we just need to add the two examples to (if there aren't already tests for these situations)
Change:
err.emit(); } CastError::CastToChar => { <del> type_error_struct!( </del> <ins> let mut err = type_error_struct!( </ins> fcx.tcx.sess, self.span, self.expr_ty, E0604, "only `u8` can be cast as `char`, not `{}`", self.expr_ty <del> ) .span_label(self.span, "invalid cast") .emit(); </del> <ins> ); err.span_label(self.span, "invalid cast"); if self.expr_ty.is_numeric() { err.span_help( self.span, if self.expr_ty == fcx.tcx.types.i8 { "try casting from `u8` instead" } else if self.expr_ty == fcx.tcx.types.u32 { "try `char::from_u32` instead" } else { "try `char::from_u32` instead (via a `u32`)" }, ); } err.emit(); </ins> } CastError::NonScalar => { let mut err = type_error_struct!(

Discussion:
Given the following code: The current output is: This is not very clear. There are two pieces of background information the user needs here: s are Unicode scalar values, which are any integer value from 0 to 0xD7FF and 0xE000 to 0x10FFFF. Only u8 can be statically guaranteed to meet this requirement so only u8 can be cast to char. is probably what the user wants, if they are interested in non-ASCII values. The user is directed to further information available at and , neither of which explains either of those two points. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think a good improvement would be to a) Add more detail about this to b) Add a to this error that suggests are you interested in working on one or both of those? :)
claim
While I was reading the docs I noticed a minor error in : This isn't true; a USV is a Code Point within either of two ranges, not one. It's also a bit cagey about what the ranges are numerically; I don't know if this is intentional. Personally I would re-write it to the below: Would I put that in the same PR (as they're both documentation) or a new issue?
A new PR would be better.
Change:
<ins> error[E0164]: expected tuple struct/variant, found method `<A>::new` --> $DIR/fn-in-pat.rs:11:9 | LL |         A::new() => (), |         ^^^^^^^^ not a tuple variant or struct error: aborting due to previous error For more information about this error, try `rustc --explain E0164`. </ins>

Discussion:
This one is very interesting IMHO. The "original" ICE was introduced between ..., but if I prepend the before (the outcommented line), there's a second ICE that is there forever (at least since Rust 1.11). modify labels: I-ICE C-bug
modify labels: I-ICE C-bug T-compiler (seems that I cannot ping rustbot from the thread start itself)
Reduced:
This issue exists all the way back to at least 1.7.0.
Change:
.insert(def_id, (vec![crate_name, prim.as_sym()], ItemType::Primitive)); } <del> krate = CacheBuilder { tcx, cache: &mut cx.cache }.fold_crate(krate); </del> <ins> let (krate, mut impl_ids) = { let mut cache_builder = CacheBuilder { tcx, cache: &mut cx.cache, impl_ids: FxHashMap::default() }; krate = cache_builder.fold_crate(krate); (krate, cache_builder.impl_ids) }; </ins> for (trait_did, dids, impl_) in cx.cache.orphan_trait_impls.drain(..) { if cx.cache.traits.contains_key(&trait_did) { for did in dids { <del> cx.cache.impls.entry(did).or_default().push(impl_.clone()); </del> <ins> if impl_ids.entry(did).or_default().insert(impl_.def_id()) { cx.cache.impls.entry(did).or_default().push(impl_.clone()); } </ins> } } }

Discussion:
! All pointing to the same impl: ! label +T-rustdoc
Actually, the never type , the trait and are not needed: It occurs with any type and any parameterized trait. Minimal reproducible example: The number of duplicates depends on the number of public types accessible in the target crate.
Taking a look.
code: Gives: !
Change:
<del> error[E0308]: mismatched types </del> <ins> error: concrete type differs from previous defining opaque type use </ins> --> $DIR/issue-99073-2.rs:9:22 | <del> LL | fn test<T: Display>(t: T, recurse: bool) -> impl Display { |                                             ------------ the expected opaque type LL |     let f = || { </del> LL |         let i: u32 = test::<i32>(-1, false); <del> |                      ^^^^^^^^^^^^^^^^^^^^^^ types differ </del> <ins> |                      ^^^^^^^^^^^^^^^^^^^^^^ expected `T`, got `u32` </ins> | <del> = note: expected opaque type `impl std::fmt::Display` found type `u32` </del> <ins> note: previous use here --> $DIR/issue-99073-2.rs:16:5 | LL |     t |     ^ </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:
($fmt:expr, $($args:tt)*) => {{ /* compiler built-in */ }}; } <del> /// Same as `format_args`, but can be used in some const contexts. </del> <ins> /// Same as [`format_args`], but can be used in some const contexts. </ins> /// /// This macro is used by the panic macros for the `const_panic` feature. ///

Discussion:
Initial title: formatargsnl! should link to formatargs! where they mention it currently contains: It would be nicer as: … although I also find which made it . It looks like that was undone at some point? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It seems that is removed in
claim
Was it intentional, though? The PR description says But that does not apply to which has: CC
After some discussion in that PR, it was deemed that a macro being did not warrant, on its own, marking the macro as . Hence why a bunch of such macros were unhidden by that PR, but maybe shouldn't have been part of those? I really don't have a strong opinion here myself, so lemme wash my hands , but: on the one hand, I do lean towards not hiding, in general, some of these macros since it may reduce a bit too much their the other hand, I'll grant that there is a difference, alas quite subtle / currently hard-to-express, between -and-expected-to-eventually-be-stabilized, and perma-; for the latter it seems more legitimate to mark them as . Given the description of the unstability of , it seems like it's the latter?
“On its own” is important here. is used for two categories of APIs: Those that are not stable yet, but have a tracking issue and might become stable at some point The "perma-unstable" APIs, that ideally should be private to a crate but need to be public typically to let some other standard library crate use them. I think that depending on its category each item with should either point to a tracking issue, or be . Here “only for internal language use” seems to point to the latter.
Yeah, I share the feeling: AFAIC, feel free to go and make it again then
One potential argument against hiding the macro from the docs is that it shows up in the compiler errors originating from the use of format strings (i.e. "note: this error originates in the macro "). Having it surfaced to the user this way but hidden from the docs might not be great.

This is being stabilized in , so I think the answer is pretty clearly "no" now (but the discussion here is interesting for other perma-unstable macros).
Change:
<ins> // run-rustfix #![allow(unused, nonstandard_style)] mod m { #[macro_export] macro_rules! nu { {} => {}; } pub struct other_item; pub use self::{nu, other_item as _}; //~^ ERROR unresolved import `self::nu` [E0432] //~| HELP a macro with this name exists at the root of the crate } 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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <details<summaryIf the starting order is reversed, the suggestion puts the macro first in the tree</summary</detailsThis is suggesting to change the code to itself It needs to move the import into a tree; the easy way is to make a new statement (and let rustfmt clean that up); the medium way is to find an existing context; the hard way is when a tree root doesn't already exist (or isn't immediately a tree at that point) determine what the code is using and match that. Related: label +D-confusing +D-incorrect
In this case, the ideal solution is actually to write just and get the import from legacy-lexical-macro-scope into the namespace. I originally hit this with just multiple macros in the use tree, and removing the was the correct fix. I "simplified" for the error report to use a second non-macro item here (to reduce the number of diagnostics). So bonus challenge: handle this case properly and only emit a single help: <details
label +D-invalid-suggestion It's not producing invalid code, but it's surely suggesting a fix which will cause an error (the identical one).
Change:
#[stable(feature = "collection_debug", since = "1.17.0")] impl<T: fmt::Debug> fmt::Debug for Iter<'_, T> { fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result { <del> f.debug_tuple("Iter").field(&self.len).finish() </del> <ins> f.debug_tuple("Iter") .field(&*mem::ManuallyDrop::new(LinkedList { head: self.head, tail: self.tail, len: self.len, marker: PhantomData, })) .field(&self.len) .finish() </ins> } }

Discussion:
(playground) label T-libs-impl, A-collections <hrCaused by violation of safety invariant as documented in yet implementation does I’m not sure where the field is really used at all, so maybe it can be replaced by a marker , similar to ’s implementation.
Assigning according to the and removing I-prioritize. modify labels -I-prioritize +P-critical
Good catch! Iterator debug implementations seem to be woefully under-audited in terms of soundness problems (this is such issue).
maybe you can help me out with how to run miri while hacking (a question that came up for the PR fixing this: ). I have no trouble compiling or testing a modified with , or linking a toolchain for usage (so that or are working) so that I can play around with it in a crate, but I don’t know how to run on such a local crate depending-on/using a modified .
Miri uses xargo for sysroot compilation, so setting will tell Miri which standard library to use. (It must be set to the folder in a rustc checkout.) You can then use a standard Miri, no rustup toolchain linking is required.
Oh, also, if you want to run the alloc/core test suites in Miri, see
Change:
if p.token != token::Eof { cx.dcx().emit_err(errors::OnlyOneArgument { span, name }); } <del> expr_to_spanned_string(cx, ret, "argument must be a string literal").map(|res| { res.map_err(|err| match err { Ok((err, _)) => err.emit(), Err(guar) => guar, }) .map(|(symbol, _style, span)| (symbol, span)) }) </del> <ins> ExpandResult::Ready(Ok(ret)) </ins> } /// Extracts comma-separated expressions from `tts`.

Discussion:
I tried this code: compiler with (using Bash shell syntax, any non-Unicode environment variable value for will work). I expected to see this happen: a value, as the currently states "If the named environment variable is present at compile time, this will expand into an expression of type whose value is of the value of the environment variable". Instead, this happened: The program outputted: Currently, the documentation doesn't consider the possibility of a non-Unicode environment variable value (as only Unicode values can be expressed as a &'static str), and the implementation emits , the same as for a non-existent environment variable. There are three possibilities that I can think of: current behaviour is a bug, and a compilation error should be emitted as it isn't possibly to represent a non-Unicode value as a , and the documentation should also be updated to reflect this. Note that this would be a breaking change to the compiler itself, but would be allowed as it would be a bugfix. current behaviour is not a bug, and the documentation should be updated to reflect the current behaviour. as 2, but the behaviour is unexpected enough to warrant a warn/deny-by-default lint. Personally, I believe 1 to be the case, as the current behaviour is unexpected and leads to code patterns like silently returning incorrect results. There doesn't seem to be a "correct" value to return, as is already taken by "does not exist" and cannot represent a non-Unicode value. It seems unlikely anyone is relying on the current behaviour given Rust's very UTF-8 everywhere design, the fact the same result can be achieved much more easily by just not setting the environment variable, and the platform-specific nature of what non-Unicode values can exist (Windows UTF-16 unpaired surrogates vs. Unix invalid UTF-8 bytes). It therefore seems to be more likely to occur when someone has mistyped something in their shell or due to data corruption, which the current output would make rather confusing to track down (as it would seem to say the variable was missing, rather than set incorrectly). : I believe the decision of what to do is down to libs-api, so label +T-libs-api
I've created a draft implementation of option 1 in .
Change:
<ins> // Copyright 2018 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. fn main() { let items = vec![1, 2, 3]; let ref_items: &[i32] = &items; let items_clone: Vec<i32> = ref_items.clone(); // in that case no suggestion will be triggered let items_clone_2:Vec<i32> = items.clone(); let s = "hi"; let string: String = s.clone(); // in that case no suggestion will be triggered let s2 = "hi"; let string_2: String = s2.to_string(); } </ins>

Discussion:
Let's say you have the following (simplified) code: () This results in the following error: The suggested fix will work, but already copies the data so the extra is wasteful. The error message should instead suggest . This is an error you can run into if was previously of type and you changed it to a slice after writing the rest of the code.
Note: this kind of improvement applies to too: Err: