jiebi/CodeConvo huggingface dataset:
Change:
.. }) => (m, span, hir_id), Node::Crate => (&self.forest.krate.module, self.forest.krate.span, hir_id), <del> _ => panic!("not a module") </del> <ins> node => panic!("not a module: {:?}", node), </ins> } }

Discussion:
Seems to be something to do with Rocket. Having a on the internal function is causing the compiler to blow up. Version: Stack trace:
I think this issue might be better-suited for the Rocket repository.
Ah OK. The output told me to file an issue here so I thought it might be a compiler problem rather than something specific to Rocket. Can we leave it open for a bit just until it's confirmed as Rocket-specific?
Hm, this bug probably originates with interesting codegen in Rocket, but is likely a bug in rustc in the end. I would keep it here, though letting Rocket know about it might not be a bad idea.
I'm going to label this as P-high for now since it affects Rocket. cc re. macros & privacy.
Without looking too deeply I would wager that we're getting a here, although it could be any other which would be worrisome:
Would be great to have a reproducer that did not depend on Rocket and codegen, if it is possible.
Trying to get a simple reproducible example and am unable to :( It got a little time-consuming and I really need to get work done so have worked around it for now. I could possibly publish everything in a repo, but it would still be rocket + codegen and not a very simple example!
Latest nightly (2019-08-11) still panics, but with different error message:
Also as a sidenote: Rocket master does not ICE anymore. The ICE "was fixed" by so it may be a problem with decl_macro ?
I would still wan't not to ICE on the face of malformed input.
For future reference, when panicking or using for not finding what you expect it is a good idea to include in the message what the found value was. :)
I think you got me wrong. I haven't said, that this should be closed because upstream code has changed, but I said, that upstream does not ICE anymore, so I looked into it, what caused it to not ICE anymore.

I try to go that ;) Confirmed, that it is related to decl maros modify labels: +A-macros-2.0
I need your help with the tags here please ^^
<details<summaryBacktraces</summary<details<summary60960a260</summary</details<details<summarydddb7fca0</summary</details</details modify labels: -E-needs-mcve
What is the appropriate visibility scope for ? is failing because we get the following instead: In my mind the expected semantics of this could would be to scope to inside , but currently with a macro by example it would be scoped to the current module. I can implement either semantic. Edit: I'm talking out of my ass, matches my intuition. Don't know why I thought otherwise.
Change:
| GenericArgKind::Const(_), _, ) => { <del> // I *think* that HIR lowering should ensure this // doesn't happen, even in erroneous // programs. Else we should use delay-span-bug. span_bug!( </del> <ins> // HIR lowering sometimes doesn't catch this in erroneous // programs, so we need to use delay_span_bug here. See #82126. self.infcx.tcx.sess.delay_span_bug( </ins> hir_arg.span(), <del> "unmatched subst and hir arg: found {:?} vs {:?}", kind, hir_arg, </del> <ins> &format!("unmatched subst and hir arg: found {:?} vs {:?}", kind, hir_arg), </ins> ); } }

Discussion:
The following is an attempted minimum reproducible sample that causes ICE. From a few minutes of experimentation, I wasn't able to further minimize the example, but I feel as if it should be possible (perhaps an example can be formed with just an async boundary and a mutex?). <!-- 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. --: Also saw the ICE on nightly, but I can't seem to get my instance of cargo to recognize the 1.52 toolchain. Testing on shows this still is present: The following outputs are the result of building on nightly playgound: <details<summary<strongBacktrace</strong</summary<p</p</details
Smaller:
Relevant code: So I think that just needs to be a .
I've actually been looking to contribute to Rust—would this be a good first issue to tackle?
This would definitely be a good first issue!
Change:
border-bottom-left-radius: 5px; } <del> .rustdoc:not(.source) .example-wrap > pre.rust { </del> <ins> .rustdoc:not(.source) .example-wrap > pre:not(.line-number) { </ins> width: 100%; overflow-x: auto; }

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. --Repro: text /// aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa /// rust /// bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb /// Rustdoc output: ! It seems that only code block with language are affected. cc
A quick test showed that the bug was introduced in (i.e.: works fine)
label +regression-from-stable-to-nightly
Thanks, I'll fix it in the next hours.
In case you want to take a look to the fix, it's .
Change:
drop(Box::from_raw(block)); } } head &= !MARK_BIT; <del> self.head.block.store(ptr::null_mut(), Ordering::Release); </del> self.head.index.store(head, Ordering::Release); }

Discussion:
Running this test: with many different seeds in Miri eventually shows: This indicates that the allocation made here does not get freed properly: Specifically when running this with Miri , seed 139 causes the issue. I don't think there is any way for this to be a false positive. Cc
I think this is not recent, it's just hard to trigger. I'll try reproducing on some older versions of rustc+Miri: (Jan 24th): seed 1870 (Nov 22nd, 2023): seed 1020 We can't go back much further since it seems we're not keeping the artifacts long enough for that? So probably this existed ever since landed.
Reproduced this with crossbeam-channel 0.5.11 and miri `.
Change:
<ins> // edition:2021 #![allow(unused_macros)] macro_rules! foo { ($x:pat | $y:pat) => {} } //~ ERROR `$x:pat` is followed by `|`, which is not allowed for `pat` fragments macro_rules! bar { ($($x:pat)+ | $($y:pat)+) => {} } //~ ERROR `$x:pat` is followed by `|`, which is not allowed for `pat` fragments macro_rules! qux { ($x:pat, $y:pat) => {} } // should be ok macro_rules! match_any { ( $expr:expr , $( $( $pat:pat )|+ => $expr_arm:expr ),+ ) => { //~ ERROR `$pat:pat` may be followed by `|`, which is not allowed for `pat` fragments match $expr { $( $( $pat => $expr_arm, )+ )+ } }; } fn main() { let result: Result<i64, i32> = Err(42); let int: i64 = match_any!(result, Ok(i) | Err(i) => i.into()); assert_eq!(int, 42); } </ins>

Discussion:
In Edition 2021, the following should error: for the same reason that the following already errors: cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I was wondering if you were interested in fixing this as a follow-up to -- I don't think you included it in that PR, right?
claim
I think the problem is here: , but if we allow , then will also be allowed. This does not seem right. But in the current function we can't yet tell what token comes next in . Do you have any suggestions?
Actually, the code may already be correct? It appears that is not allowed for , which is the goal: Maybe we just need a test -- or maybe there already is one!
Yes this part of the logic I have , but my question is about . I will add an additional test for pat2021.
I expect to be an error -- it is, right?
Yes. I see what you mean. I misunderstood your description in the issue.
Change:
<ins> error: arbitrary expressions aren't allowed in patterns --> $DIR/issue-92074-macro-ice.rs:18:25 | LL |     () => { force_expr!(Vec::new()) } |                         ^^^^^^^^^^ ... LL |     assert!(matches!(x, En::A(make_vec!()))); |                               ----------- in this macro invocation | = note: this error originates in the macro `make_vec` (in Nightly builds, run with -Z macro-backtrace for more info) error: arbitrary expressions aren't allowed in patterns --> $DIR/issue-92074-macro-ice.rs:22:24 | LL |     () => { force_pat!(get_usize(), get_usize()) } |                        ^^^^^^^^^^^ ... LL |     assert!(matches!(5, make_pat!())); |                         ----------- in this macro invocation | = note: this error originates in the macro `make_pat` (in Nightly builds, run with -Z macro-backtrace for more info) error: arbitrary expressions aren't allowed in patterns --> $DIR/issue-92074-macro-ice.rs:22:37 | LL |     () => { force_pat!(get_usize(), get_usize()) } |                                     ^^^^^^^^^^^ ... LL |     assert!(matches!(5, make_pat!())); |                         ----------- in this macro invocation | = note: this error originates in the macro `make_pat` (in Nightly builds, run with -Z macro-backtrace for more info) error: aborting due to 3 previous errors </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. --Note: this only occurs when the type of the code block is a result. Removing the line and swapping for does not yield the ICE. //! use rustice::sub; //! //! let x = sub::makestruct()?; //! //! assert!(matches!(x, sub::En::A(sub::B { inner: vec![], .. }))); //! Ok::<(), &'static str(()) //! <!-- 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. --: and after a rustup, (still getting the same ICE): <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Here's a reproduction without rustdoc involved:
Minimized:
Change:
/// Fixed frame used to clean the backtrace with `RUST_BACKTRACE=1`. #[inline(never)] fn __rust_begin_short_backtrace<F: FnOnce()>(f: F) { <del> f() </del> <ins> f(); // prevent this frame from being tail-call optimised away black_box(()); </ins> } fn run_test_in_process(

Discussion:
v.s. is less verbose, but I remember it also filtering out some stack frames in some previous compiler versions. (Only frame # 6 is really useful to me here.) Indeed, contains some code that looks for a symbol on the stack to find out what to filter. It looks like some functionality has regressed. Stepping through the program in gdb it looks like the function is called, but despite there’s apparently no stack frame (anymore?) for it. CC and for , , and .
contains a fix for this
Now being worked on in instead afaict?
It is.
This issue hasn't been active in almost two years, and so have the issues linked here. Is there any intention of resuming work on this? It's mostly a small papercut because currently when crashing, programs suggest: run with environment variable to display a backtrace. and after setting that, also claim that: Some details are omitted, run with for a verbose backtrace. even though no details were omitted at all (which is the issue of course)
A simple fix would be to just look for "std::rt::lang_start::{{closure}}" instead until the real solution to the disappearing function is found..
This single fix is likely to have the biggest positive effect on my use of Rust since async/await. Thank you so much!
Awesome! I'm happy to see this finally fixed :D Thanks to everyone who had a part in this fix :)
Change:
<ins> #![warn(unused_imports)] </ins> mod a { fn foo() {} mod foo {} mod a { pub use super::foo; //~ ERROR cannot be re-exported <del> pub use super::*; //~ ERROR must import something with the glob's visibility </del> <ins> pub use super::*; //~^ WARNING glob import doesn't reexport anything because no candidate is public enough </ins> } } mod b { pub fn foo() {} <del> mod foo { pub struct S; } </del> <ins> mod foo { pub struct S; } </ins> pub mod a { pub use super::foo; // This is OK since the value `foo` is visible enough.

Discussion:
Consider the following three examples: A and C are accepted and B has a compilation error. However, the message reported in B looks more like a lint than a compilation error. A consequence of this error is that adding a non-public function to a module (e.g. the in B) may break code that imports from that module. This causes surprises when refactoring. Shouldn't "A non-empty glob must import something with the glob's visibility" be a lint? The original discussion is here:
The error was introduced in as a part of import modularization, and discussed in one of the related issues, but I can't find where exactly. The error was introduced by analogy with errors for single imports (and just to be conservative): The error is not technically necessary, and we should be able to report it as a lint for glob imports while keeping it an error for single imports.
Would this be a "good first issue" or is it complex to fix?
No, not complex. Find where "non-empty glob must import something" is reported. Replace with .
I want to do this issue but the problem I have is with a test (ui/imports/reexports) that checks for this error, I don't know the compiler structure so I don't know when compiling this file the lint will not be reported because of the other errors or not. Else I changed the to
Change:
<ins> error: mismatched closing delimiter: `}` --> $DIR/issue-108242-semicolon-recovery.rs:4:8 | LL | fn main() { |           - closing delimiter possibly meant for this LL |     foo(; LL |     foo(; |        ^ unclosed delimiter LL | } | ^ mismatched closing delimiter error: aborting due to previous error </ins>

Discussion:
master at with debug assertions <details<summary<strongBacktrace</strong</summary<p</p Related to , but not fixed by label requires-debug-assertions S-bug-has-mcve
Interestingly, while doesn't fix this, the error is instead:
good
Change:
println!("Could not find usable git. Skipping git-aware format checks"); } <del> let ignore_fmt = ignore_fmt.build().unwrap(); </del> <ins> let fmt_override = fmt_override.build().unwrap(); </ins> let rustfmt_path = build.initial_rustfmt().unwrap_or_else(|| { eprintln!("./x.py fmt is not supported on this channel");

Discussion:
The skipped files are files in the repo that are not tracked by git. It looks like they might still get to the "formatted modified file" counter? I have no other changed files in the repo, so I wonder what rustfmt is saying to have formatted here :sweat_smile:
It detects X files modified, but the fact that they are not tracked means that their rustfmt invocation will be skipped.
It's better to give different counts for skipped and formatted files?
Maybe soemthing like "formatted x files, skipped y untracked files" would make more sense.
The number is actually right, but it's the number of the files that have been modified in the current branch compared to the master branch: you have 86 untracked path in this case. Anywa, we can make it more explicit here.
Change:
tcx.sess.delay_span_bug(tcx.def_span(def_id), "anon const with Res::Err"); return None; } <del> _ => span_bug!( DUMMY_SP, "unexpected anon const res {:?} in path: {:?}", res, path, ), </del> <ins> _ => { // If the user tries to specify generics on a type that does not take them, // e.g. `usize<T>`, we may hit this branch, in which case we treat it as if // no arguments have been passed. An error should already have been emitted. tcx.sess.delay_span_bug( tcx.def_span(def_id), &format!("unexpected anon const res {:?} in path: {:?}", res, path), ); return None; } </ins> }; generics

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 --
Reduced:
This doesn't ICE on 1.46. modify labels: +regression-from-stable-to-stable
We decided to label this as it's unlikely to be hit, it used to be an error in a previous release. Also, it's very esoteric code.
Line triggered the ICE: Regressed in , cc fyi Note that the snippet doesn't have to contain : <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Will look into this in a few weeks so I am claiming this for now so I don't forget. claim If anyone else wants to work on this before that feel free to do so, don't have much time rn
The solution might be as simple as merging the linked match arm with the previous error one, making this a delayspanbug and ignoring it.
I just saw this issue and thought the same thing. I'm testing the fix now.
Change:
t("Hard-break  nsummary", "Hard-break summary"); t("hello [Rust] :)nn[Rust]: https://www.rust-lang.org", "hello Rust :)"); t("hello [Rust](https://www.rust-lang.org "Rust") :)", "hello Rust :)"); <del> t("code `let x = i32;` ...", "code `let x = i32;` ..."); t("type `Type<'static>` ...", "type `Type<'static>` ..."); </del> <ins> t("code `let x = i32;` ...", "code `let x = i32;` …"); t("type `Type<'static>` ...", "type `Type<'static>` …"); </ins> t("# top header", "top header"); t("## header", "header"); t("first paragraphnnsecond paragraph", "first paragraph");

Discussion:
Split off from . modify labels: T-rustdoc C-enhancement <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Uh, it looks like rustbot is editing my message and adding weird comments:
Cc
It looks like smart punctuation doesn't work in headers: ! wasn't able to reproduce this in pulldown itself; I'm guessing rustdoc is doing something special with headers. Cc
Triagebot does that as a way of easily storing data per-issue (we could do it in the database now, we didn't have one back then). But it's expected and shouldn't really be a problem.
Is this a good thing? Wouldn't keeping things as it is is better?
I think if you want to argue against doing this, giving reasons would be helpful. I personally think given that we already use emoji and otherwise non-ASCII characters readily, it should be reasonable for us to generate smart quotes as well.
I do think emoji and other non-ASCII characters if specified would be good except for smart quote. It's like saying to use greek question mark which is the same as semi-colon when a semi-colon was seen in documentation to make it look a bit cooler. One thing is copying, when others are copying the text, it will copy the utf-8 version of smart quotes which when displayed in terminals which in turn will make it look ugly and hard for text processing. Auto changing text to emoji I am okay with that. But not automatically changing single quotes, double quotes and semi-colons. Personally I don't see much benefit to that, usually if users want it they would specifically type it out but otherwise it would be similar. In my humble opinion, looks wise the smart quotes are more ugly, but easier to distinguish opening and closing quotes, but still when copied and pasted it may not look so good.
Change:
/// ``` #[inline] #[must_use] <del> #[unstable(feature = "cmp_min_max_by", issue = "64460")] </del> <ins> #[stable(feature = "cmp_min_max_by", since = "1.53.0")] </ins> pub fn max_by<T, F: FnOnce(&T, &T) -> Ordering>(v1: T, v2: T, compare: F) -> T { match compare(&v1, &v2) { Ordering::Less | Ordering::Equal => v2,

Discussion:
Tracking issue for the feature, which adds the / / / functions to . PR:
Is there anything blocking this from stabilizing?
Doesn't look like it! If somebody would like to open a stabilization PR then we can start a FCP
Stabilization PR up at
Change:
<ins> error[E0425]: cannot find value `x` in this scope --> $DIR/issue-74539.rs:9:13 | LL |             x |             ^ help: a local variable with a similar name exists: `e` error: `x @` is not allowed in a tuple struct --> $DIR/issue-74539.rs:8:14 | LL |         E::A(x @ ..) => { |              ^^^^^^ this is only allowed in slice patterns | = help: remove this and bind each tuple field independently help: if you don't need to use the contents of x, discard the tuple's remaining fields | LL |         E::A(..) => { |              ^^ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0425`. </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 bug exists in the beta, nightly, and stable build channels. : The error and the backtrace provided are produced by the stable build. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
reduced: Edit: you can actually omit the enum declaration and it still crashes :thinking: `
oh, sorry, I've already got a fix. I'll post it soon. Though it may not be the best one.
Great! You should tweak not losing diags. For further reference, you could do when you work on an issue to avoid conflicts.
okay, thanks. Better late than never… claim
This is caused by , I believe. 1.44 emits errors w/o ICE'ing but 1.45 hits it. godbolt (1.44): godbolt (1.45):
Let's keep this open to track stable/beta backports.
The reference suggested this to be possible, which is how I came to suggest it to OP. We wanted to avoid naming them to not suggest any specific content.
here is another one: (assuming related)
The stable fix is reverted, and the nightly one is also but introduced another fix. I keep this open when that PR is beta-nominated, just in case.
We don't backport the fix in favor of this comment: So I'm just going to close this as fixed.