jiebi/CodeConvo huggingface dataset:
Change:
<ins> // compile-flags: --crate-type=lib // check-pass // issue #55482 #![no_std] macro_rules! foo { ($e:expr) => { $crate::core::assert!($e); $crate::core::assert_eq!($e, true); }; } pub fn foo() { foo!(true); } </ins>

Discussion:
Compiling the above code generates this error message: However, this compiles: Note that for the invokation both versions and just works. Is this intended behaviour or a bug? Try it yourself at .
This may be related to the issue where macros (it seems limited to built-in ones) don't work when called qualified with their path.
is not defined in the library, it's a built-in macro defined by the language. in its turn is indeed defined in , so it can be used as . It should be possible to make a proxy macro in calling built-in , it may require some care about what rusdoc shows for that macro though.
This is a bug. I understand that there is nuance around built-in macros but it's clear to me that should be accepted.
Triage: the docs of libcore should probably be updated.
Is the request for to be accepted or for rustdoc to stop documenting ? If the former, this should be tagged or , not .
you've said contradicting things: said should be accepted as-is and said the docs shouldn't show as valid. Which is it? Does it need an RFC?
needs to work. It does not require an RFC. According to OP, already works. It's possible there was a rustdoc issue also. According to , rustdoc was showing in core even though it was not exposed by core in a way that was callable.
Heh, after all that it turns out this compiles as-is (maybe assert was moved to core recently?). I'll add a test for it.
Change:
<ins> error[E0277]: `main` has invalid return type `impl std::marker::Copy` --> $DIR/termination-trait-impl-trait.rs:12:14 | LL | fn main() -> impl Copy { } |              ^^^^^^^^^ `main` can only return types that implement `std::process::Termination` | = help: consider using `()`, or a `Result` error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>

Discussion:
we’re stabilizing the combination of features that allows you to put in the return type of main as in . Amusing but unintended so it’s better to forbid this for now.
It's a bit late to change this. Does it cause any problem? AFAICT it just gives you a weird way to declare , but no new capability.
It doesn't give any new capability, I guess would even make sense in the return type of main. This bug could be considered a feature.
cc
Why this is an issue? returns and implements .
does not implement , which is required for the return type of .
Yea, it seems you can use any trait: Works on beta and nightly. So it'll probably work on this weeks stable You can't do anything stupid with this feature. The checks see right through the impl Trait to the real type (). I'd say adding a regression test that ensures that this corner case essentially ignores the anonymization of impl Trait is fine. We can add a deny by default lint that tells you that while this works, it's not pretty.
This seems fine to me and unless we care enough to stop the stable release we're not going to change this. cc though.
Hmm, I feel like we should just fix this. I doubt there are a lot of people taking advantage of it. I can put up some mentoring instructions. We can do a warning period if needed.
Fwiw I tried fixing by doing and got ICEs and stack oveflows which I couldn't debug so I gave up.
Hmm, I don't understand the stack overflows, but I think I would expect that patch to have no effect. The cause of the bug is that we are "instantiating" the impl Trait, here: In the process, we shadow the "original" with a new variable . This new will contain an inference variable used to find the "hidden" type underneath the . Later on, when we add the obligation that (where is the return type), we use this new variable: If we used the original (currently shadowed) , I think it would permit you to use but not other impl traits. (That said, it wouldn't be the end of the world if we just let this go, I suppose.)
As far as I understand we don't want to block 1.26 stable on this, right?

In that case I think we should go with a lint instead of an hard error, since both of the features will be stabilized now.
I probably borked the state of my clone or something. Thanks for the explanation, makes perfect sense, will make a patch.
Change:
<ins> error: expected one of `!` or `::`, found keyword `enum` --> $DIR/public-instead-of-pub-1.rs:4:8 | LL | public enum Test { |        ^^^^ expected one of `!` or `::` | help: write `pub` instead of `public` to make the item public | LL | pub enum Test { | ~~~ error: aborting due to previous error </ins>

Discussion:
When writing it will suggest and I think nothing should be suggested before it is validated. The statement to be suggested must be checked if it is true or not, if true it is suggested and if not it is not. The issue from: : The current output is: <!-- The following is not always necessary. --Ideally the output should look like: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Oh dear, I didn't think of that while making the PR. A possible solution could be checking if the current token is for initializing an item? Like, struct/enum/macro, etc.
I wrote this solution, but I don't know if I can use it in rustc, it's currently building
I can't work on the problem unfortunately, whoever will assign it to him you can solve it this way The block
release-assignment
claim
Trying to add a method in token: And add a check: Any other better idea?
could be the keyword, as well. looks alright, ideally the repeated block could be prevented using a macro? I'm afraid that might slightly overengineer it, though.
Change:
output: $output:tt) => { define_map_struct! { tcx: $tcx, <del> ready: ([pub] $attrs $name), </del> <ins> ready: ([] $attrs $name), </ins> input: ($($input)*), output: $output }

Discussion:
running yields Happening on . Did not happen on the latest nightly available through rustup on 27.04.2017.
Last working nightly: First broken nightly: .
maybe it was ? cc
could be. let me try it on my big MIR refactoring branch =)
I confirm that the error occurs at but not at So it looks to me like is indeed the culprit.
Yes. I can reproduce. Will investigate.
I see the problem. PR coming soon.
Fix at
I'm still seeing this issue, on the latest nightly and on master.
can you give more details of how you are reproducing the problem? (I a test for the precise scenario reported, so I'm reasonably sure it's not that case anymore.)
Hmm, perhaps my regression test wasn't sufficient. I see I used ; I remember that the test did fail, but I guess that it passing doesn't prove all issues are resolved. =)
The earliest commit where I can reproduce this problem is
Change:
to_bcb: BasicCoverageBlock, counter_kind: BcbCounter, ) -> BcbCounter { <del> // If the BCB has an edge counter (to be injected into a new `BasicBlock`), it can also // have an expression (to be injected into an existing `BasicBlock` represented by this // `BasicCoverageBlock`). if let Some(node_counter) = self.bcb_counter(to_bcb) && !node_counter.is_expression() { bug!( "attempt to add an incoming edge counter from {from_bcb:?}  when the target BCB already has {node_counter:?}" ); } self.bcb_has_incoming_edge_counters.insert(to_bcb); </del> if let Some(replaced) = self.bcb_edge_counters.insert((from_bcb, to_bcb), counter_kind) { bug!( "attempt to set an edge counter more than once; from_bcb: 

Discussion:
<!-- [31mICE[0m: Rustc '-Cinstrument-coverage -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'attempt to add a to a BCB target with existing incoming edge counters'', 'thread 'rustc' panicked at 'attempt to add a to a BCB target with existing incoming edge counters'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [mirpromoted] promoting constants in MIR for [mirborrowck] borrow-checking [typeofopaque] computing type of opaque [typeof] computing type of [checkwellformed] checking that is well-formed [checkmodtypewf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --
cc ^_^
Further reduced:
(Also note that even before this presumably would have still ICEd, because the only thing we did with that error was unwrap it.)
I think the assertion is just incorrect in this case. Normally a BCB will only have a physical counter if it has exactly one in-edge. If it has multiple in-edges, it will get an expression that sums up all of its in-edges, most of which will have physical counters. That's what the assertion is verifying. However, if a BCB has an out-edge back to itself (i.e. ), it gets a physical counter regardless. The assertion doesn't account for this, and fails. Perhaps the reason we haven't seen this before is that the other in-edge to the loop node usually happens to be the one chosen to get an expression, so the assertion never sees the two-counters case.
I tried to fix the assertion itself, but that ended up being pretty complicated. The information we'd need isn't readily available in the place that we need it, and there's also a related assertion in that has the same problem. Given that these assertions aren't load-bearing (the code should work fine even if it's violated), I'm inclined to just rip them out. They only exist as a holdover from the original implementation anyway.
Change:
<ins> error: unsatisfied lifetime constraints --> $DIR/issue-55394.rs:21:9 | LL |     fn new(bar: &mut Bar) -> Self { |                 -            ---- return type is Foo<'2> |                 | |                 let's call the lifetime of this reference `'1` LL |         Foo { bar } |         ^^^^^^^^^^^ returning this value requires that `'1` must outlive `'2` error: aborting due to previous error </ins>

Discussion:
Hi, I'm not sure if this has been reported or is known at all. If it has feel free to close it out. This example: causes an ICE on rustc 1.31.0-nightly ( 2018-10-25) This is the error I'm getting, backtrace included:
Okay, the good news here is that I only see this ICE with ; it does not arise with the NLL migration mode being deployed as part of the 2018 edition. See e.g. this .
The code in question is rejected by AST-borrowck. It looks like it is being rejected by NLL as well, and the problem is that we hit an error when trying to generated our diagnostic. Therefore, I'm going to tag this as NLL-sound (since this seems like a case where we want to reject the code in question) and NLL-diagnostics (since the ICE itself is stemming from diagnostics code). And I think I'm going to make it P-high, because 1. ICE's are super annoying and 2. I bet its not hard to fix. But I'm not going to tag it with the Release milestone, because its not something we need to worry about backporting to the beta channel (because it does not arise with NLL migration mode).
actually I'll remove NLL-sound; this isn't a case where NLL is incorrectly accepting the code. Its just incorrectly behaving while generating the diagnostics.
Change:
LL |     let _: ConstString<"Hello"> = ConstString::<"World">; |                                   ^^^^^^^^^^^^^^^^^^^^^^ expected `"Hello"`, found `"World"` | <del> = note: expected type `ConstString<>` found type `ConstString<>` </del> <ins> = note: expected type `ConstString<"Hello">` found type `ConstString<"World">` </ins> error[E0308]: mismatched types --> $DIR/slice-const-param-mismatch.rs:11:33

Discussion:
This code (): results in with missing const arguments in the at the bottom.
Hey guys could I take this on?
Just FYI, same problem with messages involving const generics and matches, e.g. () Also for functions: ()
Interestingly, when I use concrete types for the function example, things display properly: gives ()
you're welcome to look into fixing this! However, I'm not sure what might be causing this problem, so I don't have any suggestions for where to start looking yet.
I spent a few hours doing some digging and I can't find anything yet as well, though I'm as of yet still quite unfamiliar with the code-base. I might have more time tomorrow to look things over again, or maybe the day after.
Change:
<del> //@ known-bug: rust-lang/rust#125811 mod assert { use std::mem::{Assume, BikeshedIntrinsicFrom}; pub fn is_transmutable<Src, Dst>() where Dst: BikeshedIntrinsicFrom<Src>, { } } #[repr(C)] struct Zst; enum V0 { B(!), } enum V2 { V = 2, } enum Lopsided { Smol(Zst), Lorg(V0), } #[repr(C)] #[repr(C)] struct Dst(Lopsided, V2); fn should_pad_variants() { assert::is_transmutable::<Src, Dst>(); } </del>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed'', 'thread 'rustc' panicked at 'assertion failed'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [tagforvariant] computing variant tag for enum [evaluateobligation] evaluating trait selection obligation --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
That is the transmutability check asking for the discriminant of an uninhabited variant. I'm not sure what that code is doing with this information, but probably it makes sense to just remove the assertion and treat uninhabited variants like niched variants -- writing their discriminant is a NOP, but then the validation we do will definitely fail as the uninhabited variant cannot actually be represented in-memory. Cc
claim
Change:
#[stable(feature = "rust1", since = "1.0.0")] #[macro_export] #[cfg(dox)] <del> macro_rules! format_args { ($fmt:expr, $($args:tt)*) => ({ /* compiler built-in */ }) } </del> <ins> macro_rules! format_args { ($fmt:expr) => ({ /* compiler built-in */ }); ($fmt:expr, $($args:tt)*) => ({ /* compiler built-in */ }); } </ins> /// Inspect an environment variable at compile time. ///

Discussion:
Example: The macro is when in reality, the following call is legal (): I believe this is because . and (edit: also ) are in a similar boat (they also support trailing commas in places where the documented pattern suggests they would not). In all fairness this is not a big deal, and even has the conceivable benefit that the documentation is cleaner without such laser precision. I just thought it was worth making an issue for.
it's all good! These should be correct. Happy to take PRs.
closing since fix was merged
Change:
`"mips"`, `"powerpc"`, `"arm"`, or `"aarch64"`. * `target_endian = "..."`. Endianness of the target CPU, either `"little"` or `"big"`. <ins> * `target_env = ".."` - an option provided by the compiler by default describing the runtime environment of the target platform. Some examples of this are `musl` for builds targeting the MUSL libc implementation, `msvc` for Windows builds targeting MSVC, and `gnu` frequently the rest of the time. This option may also be blank on some platforms. </ins> * `target_family = "..."`. Operating system family of the target, e. g. `"unix"` or `"windows"`. The value of this configuration option is defined as a configuration itself, like `unix` or `windows`.

Discussion:
Title says it all. cc
This was recently for MUSL/MSVC, and for sake the docs would probably look something like: - a cfg option provided by the compiler by default describing the runtime environment of the target platform. Some examples of this are "musl" for builds targeting the MUSL libc implementation, "msvc" for Windows builds targeting MSVC, and "gnu" frequently the rest of the time. This option may also be blank on some platforms.
Change:
<ins> // Copyright 2015 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. // Test that we generate obsolete syntax errors around usages of closure kinds: `|:|`, `|&:|` and // `|&mut:|`. fn main() { let a = |:| {};  //~ ERROR obsolete syntax: `:`, `&mut:`, or `&:` let a = |&:| {};  //~ ERROR obsolete syntax: `:`, `&mut:`, or `&:` let a = |&mut:| {};  //~ ERROR obsolete syntax: `:`, `&mut:`, or `&:` } </ins>

Discussion:
and are obsolete, but is not.
I think I spotted the problem, testing...
Fix in
Change:
| RegionNameSource::AnonRegionFromUpvar(..) | RegionNameSource::AnonRegionFromOutput(..) | RegionNameSource::AnonRegionFromYieldTy(..) <del> | RegionNameSource::AnonRegionFromAsyncFn(..) => { </del> <ins> | RegionNameSource::AnonRegionFromAsyncFn(..) | RegionNameSource::AnonRegionFromImplSignature(..) => { </ins> debug!("Region {:?} is NOT suggestable", name); false }

Discussion:
<details<summary<strongBacktrace</strong</summary<p</p</details
Changing Self{field} to MyStruct{field} makes it build btw.
I haven't done a search for the exact commit, but on the playground this regressed between beta and nightly. label +regression-from-stable-to-nightly
This is due to the NLL stabilization PR , since it manifests with on 1.61 (with to allow feature flags). I'll be looking at it in a few hours when I get home!
Change:
fn get_label_res(&self, id: NodeId) -> Option<NodeId>; fn get_lifetime_res(&self, id: NodeId) -> Option<LifetimeRes>; fn take_extra_lifetime_params(&mut self, id: NodeId) -> Vec<(Ident, NodeId, LifetimeRes)>; <ins> fn remap_extra_lifetime_params(&mut self, from: NodeId, to: NodeId); </ins> fn decl_macro_kind(&self, def_id: LocalDefId) -> MacroKind; }

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
Regression in nightly-2023-08-29 Regression in cc
Change:
map[&hash] }; <del> let data = self.root.expn_data.get(self, index).unwrap().decode(self); </del> <ins> let data = self.root.expn_data.get(self, index).unwrap().decode((self, sess)); </ins> rustc_span::hygiene::register_expn_id(self.cnum, index, data, hash) }

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. --Assuming that you copied to . <!-- 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
I reproduced this ICE locally. On my end I did it by copying the git checkout of into , because I wasn't able to figure out the right invocation to get it setup with files in (Oh, whoops, I think I was accidentally passing instead of . Of course that wasn't going to work.) well, not 100%, my query stack was a little different: but it seemed like a similar bug, nonetheless.
modify labels: +I-prioritize
Assigning as discussed as part of the and removing .
Now happens for when retrying the repro. (with replaced with as it was changed in rustc) <details<summarybacktrace</summary</detailsIt also gives an unstable fingerprint ICE for when compiling : <details<summarybacktrace</summary</details
The compilation now fails when accessing session in : It looks that decodes which in turn decodes which in turn requires access to a session, but by the time of call, the session in no longer threaded through. cc
I can confirm it works now. Pushed to re-enable incremental compilation for compiling the sysroot.
Change:
<ins> error[E0308]: mismatched types --> $DIR/issue-30904.rs:20:45 | LL |     let _: for<'a> fn(&'a str) -> Str<'a> = Str; |                                             ^^^ expected concrete lifetime, found bound lifetime parameter 'a | = note: expected type `for<'a> fn(&'a str) -> Str<'a>` found type `fn(&str) -> Str<'_> {Str::<'_>}` error[E0631]: type mismatch in function arguments --> $DIR/issue-30904.rs:26:10 | LL | fn test<F: for<'x> FnOnce<(&'x str,)>>(_: F) {} |    ----    -------------------------- required by this bound in `test` ... LL | struct Str<'a>(&'a str); | ------------------------ found signature of `fn(&str) -> _` ... LL |     test(Str); |          ^^^ expected signature of `for<'x> fn(&'x str) -> _` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0308`. </ins>

Discussion:
This issue might be related to , which has been fixed in playground link: Backtrace:
removing the argument inside the closure gives a different ICE. Interestingly stable refuses to compile this, but beta and nightly ICE's playground: Backtrace:
UPDATE: now also ICE's in stable.
Now no longer ICE's since 1.32.
The ICE doesn't appear on the latest nightly via the above playground link, marked as E-needstest
Change:
<ins> error[E0308]: mismatched types --> $DIR/issue-30904.rs:20:45 | LL |     let _: for<'a> fn(&'a str) -> Str<'a> = Str; |                                             ^^^ expected concrete lifetime, found bound lifetime parameter 'a | = note: expected type `for<'a> fn(&'a str) -> Str<'a>` found type `fn(&str) -> Str<'_> {Str::<'_>}` error[E0631]: type mismatch in function arguments --> $DIR/issue-30904.rs:26:10 | LL | fn test<F: for<'x> FnOnce<(&'x str,)>>(_: F) {} |    ----    -------------------------- required by this bound in `test` ... LL | struct Str<'a>(&'a str); | ------------------------ found signature of `fn(&str) -> _` ... LL |     test(Str); |          ^^^ expected signature of `for<'x> fn(&'x str) -> _` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0308`. </ins>

Discussion:
While minimizing I stumbled upon another ICE () Errors:
modify labels: I-ICE A-closures A-impl-trait C-bug F-typealiasimpl_trait T-compiler
The ICE doesn't appear on the latest nightly
Change:
<ins> // run-pass // compile-flags: -C opt-level=0 #![feature(dyn_star)] #![allow(incomplete_features)] use std::fmt::Display; fn make_dyn_star() -> dyn* Display { Box::new(42) as dyn* Display } fn main() { let x = make_dyn_star(); println!("{x}"); } </ins>

Discussion:
Example: This fails in LLVM:
label +C-bug +A-LLVM +requires-nightly