jiebi/CodeConvo huggingface dataset:
Change:
## Tips and tricks <del> To see the results of expanding syntax extensions, run `rustc --pretty expanded`. The output represents a whole crate, so you can also feed it back in to `rustc`, which will sometimes produce better error messages than the original compilation. Note that the `--pretty expanded` output may have a different meaning if multiple variables of the same name (but different syntax contexts) are in play in the same scope. In this case `--pretty expanded,hygiene` will tell you about the syntax contexts. </del> <ins> Some of the [macro debugging tips](macros.html#debugging-macro-code) are applicable. </ins> You can use [`syntax::parse`](../syntax/parse/index.html) to turn token trees into higher-level syntax elements like expressions:

Discussion:
As of the original docs on recursive macros are gone. We should have an example that clearly illustrates the increased power vs. the built-in repetition operator.
Change:
<ins> error: cannot implement trait on type alias impl trait --> $DIR/issue-65384.rs:11:1 | LL | impl MyTrait for Bar {} | ^^^^^^^^^^^^^^^^^^^^ | note: type alias impl trait defined here --> $DIR/issue-65384.rs:9:12 | LL | type Bar = impl MyTrait; |            ^^^^^^^^^^^^ error: aborting due to previous error </ins>

Discussion:
As requested in , here's a follow up. The following code below implements the trait for an alias , which is an alias to . It doesnt really make sense to implement a that same trait. doesn't mention anything about this, however the previous notes: Im not sure this should be allowed. cc
This is fixed on master.
Change:
} // (*) This is a horrible concession to reality. I think it'd be <del> // better to just ban unconstrianed lifetimes outright, but in </del> <ins> // better to just ban unconstrained lifetimes outright, but in </ins> // practice people do non-hygenic macros like: // // ```

Discussion:
The following code does NOT compile: it errors with: However, when using normal generics in the places of the const generics, wrapping the in an and sticking that into the struct does work: Is it intended that const generic dont mimmic this behaviour?
This is probably a decision that has to be made (although if it is disallowed, then we'd want a better error message). However, at present, this is a implementation limitation: we really only properly support const generics of the form at the moment (cc ).
Considering that anon consts are mostly just projections, wouldn't this be similar to which doesn't really make a lot of sense (we have to guarantee that the projection maps each value of to a unique type). While is injective, finding an intuitive subset of expressions for which this is the case is hard and imo not actually desirable rn. Not quite sure what's the best error message though :thinking: probably something like
That's a good point I think adding a note explaining the problem would be the best solution, though the tricky part is working out how to explain it concisely (rather than just stating what the problem is).
Change:
fn clean(&self, cx: &DocContext<'_>) -> Constant { Constant { type_: self.ty.clean(cx), <del> expr: match self.val { ConstValue::Param(ty::ParamConst { name, .. }) => format!("{}", name), e => format!("{:?}", e), // FIXME generic consts with expressions }, </del> <ins> expr: format!("{}", self), </ins> } } }

Discussion:
When playing around with const generics, I found some weird generated docs: How to reproduce: and go to the documentation on the VecSet struct (inside the vecset module), and find the auto impls.
My guess is that rustdoc just doesn't yet handle const generics properly
Support for const generics in rustdoc has not been tested very thoroughly at all (I don't think there are any tests in the test suite for it at all yet). We also have a number of issues with pretty-printing consts (). That said, I imagine this would not be too difficult to fix: we're getting the right parameter — we're just debug printing it instead of pretty-printing it.
Change:
<ins> // check-pass #![feature(type_alias_impl_trait)] trait SomeTrait {} impl SomeTrait for () {} trait MyFuture { type Output; } impl<T> MyFuture for T { type Output = T; } trait ReturnsFuture { type Output: SomeTrait; type Future: MyFuture<Output = Result<Self::Output, ()>>; fn func() -> Self::Future; } struct Foo; impl ReturnsFuture for Foo { type Output = impl SomeTrait; type Future = impl MyFuture<Output = Result<Self::Output, ()>>; fn func() -> Self::Future { Result::<(), ()>::Err(()) } } fn main() {} </ins>

Discussion:
Possibly related to as both ICEs arise from , but this ICE occurs on a different line. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
No longer ICEs since

I tried this code: I expected to see this happen: code compiles successfully Instead, this happened: : : modify labels: +requires-nightly +F-typealiasimpl_trait
This is fixed now

I'm writing a simple Generator that takes a reference to an RNG, and yields values from it. This makes sense as long as the generator doesn't outlive the RNG which it references. I want to name the type of the generator with an existential type, but I can't do so unless I wrap a version of the function that uses an formulation. Here's the direct version which doesn't work and here's the more convoluted version which does and here's a playground link containing both versions, as well as a bit of scaffolding The full error message I'm seeing looks like this
I don't know if this properly counts as a compiler bug, but it feels like one because the "fix" is a very mechanical code transformation.
cc
Yea that's definitely a bug. I'll investigate where this unnamed lifetime is coming from. Maybe I'm accidentally erasing lifetimes somewhere
This is fixed in master. A more minimal example that probably still failed previously (needs to be checked) that doesn't depend on or never type:

I assumed that the following code would be legal, as it does not require indefinitely sized types, but apparently somewhere the existential type is revealed too early: () Errors:
Updated version: This still doesn't compile.
Using min-type-alias-impl-trait (), you get an error. I think this is ok, though, as it is we don't support cyclic types like this. I'm going to mark this as E-needs-test.
If we adopted a different model of impl trait, one where they were more "nominal" and hence could be cyclic, that'd be a different thing.
Change:
<ins> error[E0369]: binary operation `+` cannot be applied to type `&str` --> $DIR/non-1-width-unicode-multiline-label.rs:5:260 | LL | ...ཽཾཿ྄ཱྀྀྂྃ྅྆྇ྈྉྊྋྌྍྎྏྐྑྒྒྷྔྕྖྗ྘ྙྚྛྜྜྷྞྟྠྡྡྷྣྤྥྦྦྷྨྩྪྫྫྷྭྮྯྰྱྲླྴྵྶྷྸྐྵྺྻྼ྽྾྿࿀࿁࿂࿃࿄࿅࿆࿇...࿋࿌࿍࿎࿏࿐࿑࿒࿓࿔࿕࿖࿗࿘࿙࿚"; let _a = unicode_is_fun + " really fun!"; |                                                  -------------- ^ -------------- &str |                                                  |              | |                                                  |              `+` cannot be used to concatenate two `&str` strings |                                                  &str | help: `to_owned()` can be used to create an owned `String` from a string reference. String concatenation appends the string on the right to the string on the left and may require reallocation. This requires ownership of the string on the left | LL |     let _ = "ༀ༁༂༃༄༅༆༇༈༉༊་༌།༎༏༐༑༒༓༔༕༖༗༘༙༚༛༜༝༞༟༠༡༢༣༤༥༦༧༨༩༪༫༬༭༮༯༰༱༲༳༴༵༶༷༸༹༺༻༼༽༾༿ཀཁགགྷངཅཆཇ཈ཉཊཋཌཌྷཎཏཐདདྷནཔཕབབྷམཙཚཛཛྷཝཞཟའཡརལཤཥསཧཨཀྵཪཫཬ཭཮཯཰ཱཱཱིིུུྲྀཷླྀཹེཻོཽཾཿ྄ཱྀྀྂྃ྅྆྇ྈྉྊྋྌྍྎྏྐྑྒྒྷྔྕྖྗ྘ྙྚྛྜྜྷྞྟྠྡྡྷྣྤྥྦྦྷྨྩྪྫྫྷྭྮྯྰྱྲླྴྵྶྷྸྐྵྺྻྼ྽྾྿࿀࿁࿂࿃࿄࿅࿆࿇࿈࿉࿊࿋࿌࿍࿎࿏࿐࿑࿒࿓࿔࿕࿖࿗࿘࿙࿚"; let _a = unicode_is_fun.to_owned() + " really fun!"; |                                                                                                                                                                           ^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0369`. </ins>

Discussion:
In we account for the visible char width when calculating the label and span positions, but we do not do so for the vertical bar tying them together, causing the following output: where it should be (Found during )
I would like to solve this as a first time issue. Best with some pointers where to start :)
the code that draws the vertical lines is at and the one that draws the span labels is right below I think the error might be using instead of , but I'm not entirely certain. If this is your first time compiling , you probably want to read the , but the TL;DR: is "run to build the compiler up to the first stage and update the test output files". You might also want to wait until the linked PR is merged so you have a test case, unless you wish to come up with a new one (look for a test that has multiple labels in the same span and pad the source to the left with unicode chars on non-1 width).
Thank you! I did read the rustc guide, and even compiled it on my own once. But thanks for the direction, and the note to the PR. I'll do my best :wink:
Change:
<ins> error[E0308]: mismatched types --> $DIR/arbitrary-self-from-method-substs.rs:14:5 | LL |     foo.get::<&Foo>(); |     ^^^ expected `&Foo`, found `Foo` error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </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
label +F-arbitraryselftypes
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. fn foo<T>() -> T { loop {} } fn test() { let ref mut a: &mut FnMut((i8,), i16) = foo(); a((0,), 0); } fn main() { let _ = test; } </ins>

Discussion:
This code compiles fine on stable/beta, but ICEs on nightly: cc happened last night, maybe recent trans changes?
That's weird...
Change:
<ins> #[diagnostic::on_unimplemented(message = "{{Test } thing")] //~^WARN unmatched `}` found //~|WARN unmatched `}` found trait ImportantTrait1 {} #[diagnostic::on_unimplemented(message = "Test {}")] //~^WARN positional format arguments are not allowed here //~|WARN positional format arguments are not allowed here trait ImportantTrait2 {} #[diagnostic::on_unimplemented(message = "Test {1:}")] //~^WARN positional format arguments are not allowed here //~|WARN positional format arguments are not allowed here trait ImportantTrait3 {} #[diagnostic::on_unimplemented(message = "Test {Self:123}")] //~^WARN invalid format specifier //~|WARN invalid format specifier trait ImportantTrait4 {} #[diagnostic::on_unimplemented(message = "Test {Self:!}")] //~^WARN expected `'}'`, found `'!'` //~|WARN expected `'}'`, found `'!'` //~|WARN unmatched `}` found //~|WARN unmatched `}` found trait ImportantTrait5 {} fn check_1(_: impl ImportantTrait1) {} fn check_2(_: impl ImportantTrait2) {} fn check_3(_: impl ImportantTrait3) {} fn check_4(_: impl ImportantTrait4) {} fn check_5(_: impl ImportantTrait5) {} fn main() { check_1(()); //~^ERROR {{Test } thing check_2(()); //~^ERROR Test {} check_3(()); //~^ERROR Test {1} check_4(()); //~^ERROR Test () check_5(()); //~^ERROR Test {Self:!} } </ins>

Discussion:
The following are some unexpected behaviors I see with the formatting strings in the attribute. I'm not sure that the attribute should actually be using std's format parsing, but if it is, the following seem like issues with the current implementation. Anything after the is ignored, and not included in the message output. Expectation: There should be a warning that the string is malformed. or These generate an error. However, my understanding of the attribute is that it tries to only generate warnings for things it doesn't understand. I would expect this to also generate a warning. This does not generate a warning or error. I would expect it to generate a warning that anything after the is ignored. This includes width, precision, debug formatting, etc. The error message generated with this is the type followed by a . I would expect this to generate a warning that the format arguments are not valid (similar to how works). : cc
I filled to hopefully address this.
Good catch! This should probably support a strict subset of formatting (only named arguments and no format options), and warn whenever the string is either not valid for or not in the supported subset. When it shows a warning, not sure what the behavior of the string should be -- maybe just take it as a literal without any interpolation?
Change:
// ignore-msvc everything is the system allocator on msvc // ignore-musl no dylibs on musl right now <ins> // ignore-bitrig no jemalloc on bitrig </ins> // aux-build:allocator-dylib2.rs // error-pattern: cannot link together two allocators

Discussion:
After the new snapshots landed, test failures showed up.
failures: [run-pass] run-pass/allocator- [run-pass] run-pass/allocator-
it looks like the outstanding jemalloc issues are finally biting us.
Change:
//! //! See comments in `src/bootstrap/rustc.rs` for more information. <del> // NO-RUSTC-WRAPPER #![deny(warnings, rust_2018_idioms, unused_lifetimes)] </del> use std::env; use std::process::Command; use std::path::PathBuf;

Discussion:
When using 1.38 beta to bootstrap itself, I get:
This is expected and not a supported bootstrapping configuration; if you want to not see these errors you'll want to either bootstrap with N-1 compiler (so, in this case, 1.37) or I believe remove from bootstrap and some other libraries, as well as set deny-warnings in to false. Note that only the 1.37 bootstrap method is officially supported as "guaranteed to work", the deny warnings fix is more of a hack. Closing as won't fix.
Huh? In the past this was always fixed as it's a very common practice for distribution packaging (I don't know of a single packager not doing that). See e.g. or (in which you sort of acknowledged that yourself) deny-warnings is already set to false in , so I guess it somehow doesn't apply to building bootstrap itself.
I hope is an acceptable compromise wrt this. Thanks for pointing out the deny-warnings option which I forgot (since it has been set to false forever for us and never had any effect on the build of bootstrap itself)
Yeah is great; in this case the unsafe block is needed for 1.37 but not on 1.38; if there was an easy way to support both use cases then I'd be happy to accept a PR targeting beta but I'm not personally aware of one -- it looks like we don't seem to have an or similar? We try to support distros and such where possible in this configuration, it's just that this specific case I'm not sure how much we can do. deny-warnings=false is always my recommendation when using a different bootstrap compiler, or manual patches to the code.
Change:
} } } <ins> /// Run a callback in a scenario which must not unwind (such as a `extern "C" /// fn` declared in a user crate). If the callback unwinds anyway, then /// `rtabort` with a message about thread local panicking on drop. #[inline] pub fn abort_on_dtor_unwind(f: impl FnOnce()) { // Using a guard like this is lower cost. let guard = DtorUnwindGuard; f(); core::mem::forget(guard); struct DtorUnwindGuard; impl Drop for DtorUnwindGuard { #[inline] fn drop(&mut self) { // This is not terribly descriptive, but it doesn't need to be as we'll // already have printed a panic message at this point. rtabort!("thread local panicked on drop"); } } } </ins>

Discussion:
Miri detects UB when running the following program: With and With
I see the bug. We have (which means fns in std automatically trap aborts) but that doesn't apply to functions which are present in the macro expansion (some of which can't really be moved outside the macro). Ill fix in like an hour or two. We just need to guard panics in a couple places. In practice I think this should not call problems and we'd just hit an abort guard in an defined in a few frames up, although perhaps that's not true in 100% of cases (I can update on this once I implement the fix).
The is that the fix to this may need to be backported thus I am tagging this with P-high.
the fix was merged and a backport was rejected:
Change:
|                    ^^^^^^^^^^^^^^^^^^ the trait `Copy` is not implemented for `Header<'_>` | = note: the `Copy` trait is required because this value will be copied for each element of the array <ins> = help: consider using `core::array::from_fn` to initialize the array = help: see https://doc.rust-lang.org/stable/std/array/fn.from_fn.html# for more information </ins> help: consider annotating `Header<'_>` with `#[derive(Copy)]` | LL + #[derive(Copy)]

Discussion:
For this snippet (): rustc gives: Since , for const-able values, rustc suggests the creation of a constant binding. Here this is not possible because is not const fn. However, we can suggest instead.
Personally, I prefer over a separate binding. Even in the case, the generated code will call the initialization function many times. Maybe in the case where bindings are possible, we can suggest both? Where they are not possible, we don't suggest anything right now, so at the least we should suggest there. what do you think?
Once is stable we can suggest that :3. But until then sounds reasonable.
Agreed, good point about . It seems to have a stabilization PR open with an FCP, which is blocked: . Maybe there might be progress on it this month: . Even if we stabilize inline const, it might make sense to wait with suggesting it for a while so that we don't make code depend on the latest MSRV immediately. So therefore, I think that it might still make sense to implement this in the meantime.
I think this should (in the future) suggest  instead, since the function would only be called once if were , whereas calls it for every element.
Change:
<del> // edition:2018 use std::sync::Arc; use std::task::{ Waker, RawWaker, RawWakerVTable, }; macro_rules! waker_vtable { ($ty:ident) => { &RawWakerVTable::new( clone_arc_raw::<$ty>, wake_arc_raw::<$ty>, wake_by_ref_arc_raw::<$ty>, drop_arc_raw::<$ty>, ) }; } pub trait ArcWake { fn wake(self: Arc<Self>); fn wake_by_ref(arc_self: &Arc<Self>) { arc_self.clone().wake() } fn into_waker(wake: Arc<Self>) -> Waker where Self: Sized { let ptr = Arc::into_raw(wake) as *const (); unsafe { Waker::from_raw(RawWaker::new(ptr, waker_vtable!(Self))) } } } unsafe fn increase_refcount<T: ArcWake>(data: *const ()) { // Retain Arc by creating a copy let arc: Arc<T> = Arc::from_raw(data as *const T); let arc_clone = arc.clone(); // Forget the Arcs again, so that the refcount isn't decrased let _ = Arc::into_raw(arc); let _ = Arc::into_raw(arc_clone); } unsafe fn clone_arc_raw<T: ArcWake>(data: *const ()) -> RawWaker { increase_refcount::<T>(data); RawWaker::new(data, waker_vtable!(T)) } unsafe fn drop_arc_raw<T: ArcWake>(data: *const ()) { // Drop Arc let _: Arc<T> = Arc::from_raw(data as *const T); } unsafe fn wake_arc_raw<T: ArcWake>(data: *const ()) { let arc: Arc<T> = Arc::from_raw(data as *const T); ArcWake::wake(arc); } unsafe fn wake_by_ref_arc_raw<T: ArcWake>(data: *const ()) { let arc: Arc<T> = Arc::from_raw(data as *const T); ArcWake::wake_by_ref(&arc); let _ = Arc::into_raw(arc); } </del>

Discussion:
E.g. in and cc
I'd like to work on this :smile:
You've got it :)
Change:
<ins> // This tests that the error generated when a character literal has multiple // characters in it contains a note about non-printing characters. fn main() { let _hair_space_around = ' x​'; //~^ ERROR: character literal may only contain one codepoint //~| NOTE: there are non-printing characters, the full sequence is `u{200a}xu{200b}` //~| HELP: consider removing the non-printing characters //~| SUGGESTION: x } </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: <!-- Please provide a link to -- (which has a zero width space between the and its ending ) The current output is: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --If there are any non-printing characters, show where they are (debug unicode representation on the whole string, maybe?), and if there's only one printing character, make a suggestion to remove everything but the printing character. <!-- If dramatically different output is caused by small changes, consider also adding them here. 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 output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
} _ => lt.clean(cx).map(GenericArg::Lifetime), }, <del> GenericArgKind::Type(_) if skip_self => { skip_self = false; </del> <ins> GenericArgKind::Type(_) if skip_first => { skip_first = false; </ins> None } <del> GenericArgKind::Type(ty) => { ty_kind = Some(ty.kind()); Some(GenericArg::Type(ty.clean(cx))) } </del> <ins> GenericArgKind::Type(ty) => Some(GenericArg::Type(ty.clean(cx))), </ins> GenericArgKind::Const(ct) => Some(GenericArg::Const(Box::new(ct.clean(cx)))), }) <del> .collect(); </del> <ins> .collect() } fn external_generic_args( cx: &mut DocContext<'_>, did: DefId, has_self: bool, bindings: Vec<TypeBinding>, substs: SubstsRef<'_>, ) -> GenericArgs { let args = substs_to_args(cx, &substs, has_self); </ins> if cx.tcx.fn_trait_kind_from_lang_item(did).is_some() { <del> let inputs = match ty_kind.unwrap() { ty::Tuple(tys) => tys.iter().map(|t| t.clean(cx)).collect(), _ => return GenericArgs::AngleBracketed { args, bindings: bindings.into() }, }; </del> <ins> let inputs = // The trait's first substitution is the one after self, if there is one. match substs.iter().nth(if has_self { 1 } else { 0 }).unwrap().expect_ty().kind() { ty::Tuple(tys) => tys.iter().map(|t| t.clean(cx)).collect(), _ => return GenericArgs::AngleBracketed { args, bindings: bindings.into() }, }; </ins> let output = None; // FIXME(#20299) return type comes from a projection now // match types[1].kind {

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. --Minimized example: Command: <!-- 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. --Platform: See backtrace <!-- 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 --<!-- TRIAGEBOT_END --
I'll look into it! claim
Minimized this to a local-crate-only test, and working on a solution currently: