jiebi/CodeConvo huggingface dataset:
Change:
<ins> // check-pass // aux-build:issue-79242.rs // Regression test for issue #79242 // Tests that compilation time doesn't blow up for a proc-macro // invocation with deeply nested nonterminals #![allow(unused)] extern crate issue_79242; macro_rules! declare_nats { ($prev:ty) => {}; ($prev:ty, $n:literal$(, $tail:literal)*) => { issue_79242::dummy! { $prev } declare_nats!(Option<$prev>$(, $tail)*); }; (0, $($n:literal),+) => { pub struct N0; declare_nats!(N0, $($n),+); }; } declare_nats! { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28 } fn main() {} </ins>

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --We have a library that compiles fine on 1.47.0 but after uggrading to 1.48.0 the compilation hangs. This code-snippet above is reduced from the original code as much as I can. I'm having problems understanding exactly where the problem is coming from and any further modifications to reduce it haven't worked. It uses the "paste" crate, and I've tried a few different versions including the latest one but it doesn't make a difference . I've been building it with at 1.47.0 and 1.48.0 to reproduce the issue which I got just by running doesn't work on works on </p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --
Some quick notes as I find them: This reproduces on just a cargo check, so has nothing to do with codegen (unsurprising) Compilation time scales by a little more than 2x for each additional number (going from 0 to 20 took 11 seconds, 21 took 26, 22 took 1 min 5) Given that I don't think this is a hard hang per se, just a really really long running compilation Definitely something in macro expansion, compiling the post- code is instant Reproduces on current nightly. -Zself-profile shows all the time is spent in . Unfortunately I don't have a debug build of rustc handy, but I imagine slapping a profiler on one should make the issue fairly obvious. I'd recommend cutting the provided example down from 64 to 20 though.

searched nightlies: from nightly-2020-08-24 to nightly-2020-10-03 regressed nightly: nightly-2020-10-02 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsLooks like
If it helps, this crate was exploring some ideas related to the crate
Assigning and removing as in the prioritization working group.
This is caused by some of the extra logic I in to ensure that we don't throw out the captured unnecessarily. I'm looking into improving the performance. In the longer term, this will be solved by getting rid of the pretty-print/retokenize hack entirely.
Change:
let operand = Operand::Copy(promoted_place(ty, span)); mem::replace(&mut args[index], operand) } <ins> // We expected a `TerminatorKind::Call` for which we'd like to promote an // argument. `qualify_consts` saw a `TerminatorKind::Call` here, but // we are seeing a `Goto`. That means that the `promote_temps` method // already promoted this call away entirely. This case occurs when calling // a function requiring a constant argument and as that constant value // providing a value whose computation contains another call to a function // requiring a constant argument. TerminatorKind::Goto { .. } => return, </ins> _ => bug!() } }

Discussion:
: produces cc
Not that this fixes the issue, but and aren't necessarily guaranteed to have the same representation without or on both and .
minified: is this a victim of the backwards algorithm for promotion? Just a hunch, but it might have promoted away the call to and then end up trying to promote the , but it's not in the place where it was expected, because it now lives inside the promoted. So it ends up trying to promote an argument in a basic block that was already promoted away
thanks , I'll update the PR that triggered this - for context
As a workaround until we fix this ICE, you can introduce an intermediate explicit constant for the argument to . Or is this part of a user-exposed API?
This is part of a user-exposed API, but that workaround should allow me to at least get the const tests running.
It won't remove the definition if there's more than one use (unless this is fallout from your changes?)
There's only one use. I don't see how my changes could have caused this, but it seems possible. I'll do a bisection
Oh, I see, is and that's missing a check like:
Fix instructions: Add a which, like the variable, is used to mark blocks whose terminator has been promoted out. skip promoting all such terminators when encountering said block id in a ()
You can use a , although I'm not even sure it's necessary. A promoted call ends up as a , so you could just skip it based on that?
Change:
<ins> error[E0308]: mismatched types --> $DIR/issue-100605.rs:4:18 | LL |     takes_option(&None); |     ------------ ^^^^^ expected enum `Option`, found `&Option<_>` |     | |     arguments to this function are incorrect | = note:   expected enum `Option<&String>` found reference `&Option<_>` note: function defined here --> $DIR/issue-100605.rs:1:4 | LL | fn takes_option(_arg: Option<&String>) {} |    ^^^^^^^^^^^^ --------------------- help: you can convert from `&Option<T>` to `Option<&T>` using `.as_ref()` | LL |     takes_option(None.as_ref()); |                  ~~~~~~~~~~~~~ help: consider removing the borrow | LL -     takes_option(&None); LL +     takes_option(None); | error[E0308]: mismatched types --> $DIR/issue-100605.rs:8:18 | LL |     takes_option(&res); |     ------------ ^^^^ |     |            | |     |            expected enum `Option`, found `&Option<String>` |     |            help: you can convert from `&Option<T>` to `Option<&T>` using `.as_ref()`: `res.as_ref()` |     arguments to this function are incorrect | = note:   expected enum `Option<&String>` found reference `&Option<String>` note: function defined here --> $DIR/issue-100605.rs:1:4 | LL | fn takes_option(_arg: Option<&String>) {} |    ^^^^^^^^^^^^ --------------------- error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0308`. </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 --The current output is: The error is correct, but I think the diagnostic is wrong. The second recommendation to call is sound, but the first one () seems like bad advice. This reproduces on 1.61 (on my workstation), as well as 1.63 (stable channel in playground), 1.64 (beta channel in playground), and 1.65 (nightly channel in playground). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Intresting.. This code also make wrong help, The current output is: Using is a bad advice.
claim
Change:
fn a_test() {} #[rustc_main] #[coverage(off)] <del> #[allow(missing_docs)] </del> <ins> #[doc(hidden)] </ins> pub fn main() -> () { extern crate test; test::test_main_static(&[&a_test, &m_test, &z_test])

Discussion:
I tried this code: I expected to see this happen: no errors Instead, this happened: : Very likely to be related
Looks like allowed missing docs on the generated function, but didn't test having any actual s. cc
Attempt fix in
Change:
<ins> fn main() { type Predicate = fn<'a>(&'a str) -> bool; //~^ ERROR function pointer types may not have generic parameters type Identity = fn<T>(T) -> T; //~^ ERROR function pointer types may not have generic parameters //~| ERROR cannot find type `T` in this scope //~| ERROR cannot find type `T` in this scope let _: fn<const N: usize, 'e, Q, 'f>(); //~^ ERROR function pointer types may not have generic parameters let _: for<'outer> fn<'inner>(); //~^ ERROR function pointer types may not have generic parameters let _: for<> fn<'r>(); //~^ ERROR function pointer types may not have generic parameters type Hmm = fn<>(); //~^ ERROR function pointer types may not have generic parameters let _: extern fn<'a: 'static>(); //~^ ERROR function pointer types may not have generic parameters //~| ERROR lifetime bounds cannot be used in this context let _: for<'any> extern "C" fn<'u>(); //~^ ERROR function pointer types may not have generic parameters type QuiteBroken = fn<const>(); //~^ ERROR expected identifier, found `>` } </ins>

Discussion:
Newcomers might attempt to write a “generic” function pointer like . In such case, the compiler should provide a better error message. Inspired by a recent Reddit thread I sadly cannot find anymore. Given the following code: The compiler should mention that function pointers may not be generic or […] may not have generic parameters, suggest to move the lifetime(s) to a parameter list (this should be machine-applicable in my judgement) and be able to recover: For later reference, the current output is: Given the following code: The compiler should mention that function pointers may not be generic or […] may not have generic parameters and be able to recover emitting two diagnostics, one for each line. The compiler could also suggest moving the generic parameter list further up to the owning function, struct, etc. if available. Note that this might not be what the user intended (since there is a semantic difference between hypothetical higher-ranked generics and normal ones) and therefore shouldn't be machine-applicable. For later reference, the current output is: label A-parser A-suggestion-diagnostics D-newcomer-roadblock <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
} } <ins> #[cfg(target_has_atomic = "ptr")] </ins> #[stable(feature = "atomic_from", since = "1.23.0")] impl<T> From<*mut T> for AtomicPtr<T> { #[inline]

Discussion:
Here is the verbose output:
cc All the needs to have .
If is busy I can try it.
(Note: affects msp430 as well)
I saw no open PR to fix this so I opened . (I hope no one minds)
Change:
<ins> // compile-flags: -Zunstable-options pub fn issue_111280() { struct_span_err(msg).emit(); //~ ERROR cannot find value `msg` //~^ ERROR cannot find function `struct_span_err` } fn main() {} </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- 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 --
I've seen this on a few ICE reports, but I'd recommend putting the first ICE in the title instead of any other subsequent ICE messages, since this: really is the root cause of this issue, and the second one (mentioning ) is just a side-effect of panicking during certain queries :smilecat:
searched toolchains nightly-2023-04-21 through nightly-2023-05-06 Regression in nightly-2023-04-27 Regression in Regression in cc
Oops claim
Change:
if self.eat(&token::ModSep) { self.parse_use_tree_glob_or_nested()? } else { <ins> // Recover from using a colon as path separator. while self.eat_noexpect(&token::Colon) { self.struct_span_err(self.prev_token.span, "expected `::`, found `:`") .span_suggestion_short( self.prev_token.span, "use double colon", "::", Applicability::MachineApplicable, ) .note_once("import paths are delimited using `::`") .emit(); // We parse the rest of the path and append it to the original prefix. self.parse_path_segments(&mut prefix.segments, PathStyle::Mod, None)?; prefix.span = lo.to(self.prev_token.span); } </ins> UseTreeKind::Simple(self.parse_rename()?, DUMMY_NODE_ID, DUMMY_NODE_ID) } };

Discussion:
I tried this code: I expected to see this happen: I expected to see two diagnostic messages, telling me about the distinct parse errors on lines 1 and 2. Instead, this happened: The first error was treated as non-recoverable, yielding this output (): I'm assuming recovering in the face of this parse error would be a relatively simple task, given that there is already the present that should be a strong hint that someone meant to type . So I'm tagging this with labels indicating that its a good opportunity for someone who wants to acquaint themselves with the code base. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
(This needs a mentor. I am thinking that if someone doesn't pick it up by Friday, then I will see about using it as the basis for one or more instructional videos.)
I can mentor whoever wants to work on this. See for the general area where changes need to be made, and ping me if someone needs help on Zulip.
May I work on this?
You can , and I recommend checking out the to find out what the contribution process looks like.
i would like to work on this with your help.
claim
release-assignment
This is mostly about adding checks around such that it recovers when encountering . However, we would also need the ability to recover to be configurable as arguments to , as we would want to recover from as well. PS: don't take this as is.. I am not that familiar with ast and recovery, but I think this is the main idea
I will take a quick look into this. claim
Change:
use rustc_middle::query::on_disk_cache::AbsoluteBytePos; use rustc_middle::query::on_disk_cache::{CacheDecoder, CacheEncoder, EncodedDepNodeIndex}; use rustc_middle::query::Key; <ins> use rustc_middle::ty::print::with_reduced_queries; </ins> use rustc_middle::ty::tls::{self, ImplicitCtxt}; use rustc_middle::ty::{self, TyCtxt}; use rustc_query_system::dep_graph::{DepNodeParams, HasDepContext};

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. --from Rustc will crash "normally" (expected as the bug is not fixed) but when trying to print the query stack, rustc will eat up all available memory which is BAD. <!-- 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
Its very likely hat this was caused by cc
This looks like again. It was fixed in , but the doesn't actually test what it's supposed to, because it doesn't check for the "end of query stack" line. (This also means that we currently have an UI that will fill up your entire RAM and then get killed.) The / calls are needed to fix this, not sure why they got removed.
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Change:
<del> Subproject commit 644e2a76a87a129f597dc40b47593fc8f72539cb </del> <ins> Subproject commit 3bf51f591f7ffdd45f51cd1d42a4002482af2bd5 </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.
triage: P-medium, removing nomination label.
Change:
enter_impl_trait(cx, || (self.generics.clean(cx), (self.decl, self.body).clean(cx))); let did = cx.tcx.hir().local_def_id(self.id); <del> let constness = if is_min_const_fn(cx.tcx, did.to_def_id()) { </del> <ins> let constness = if is_const_fn(cx.tcx, did.to_def_id()) && !is_unstable_const_fn(cx.tcx, did.to_def_id()).is_some() { </ins> hir::Constness::Const } else { hir::Constness::NotConst

Discussion:
This is a follow-up on I opened earlier, with the requested minimal reproduction in the form of a simple .
Looks like this is either or cc - do you know what those are doing/why they exist?
It's because of the feature. As long as it's not stable, they don't want the keyword to be displayed, even if the function description is describing a const fn. This is a bit strange.
Yeah, that makes no sense to me at all. I have a crate that is very much nightly-only containing a rather large number of s, and at the moment literally none of them are displayed as such in my documentation because of this, despite the fact that they've never not been and will never not be in the future. I of course cannot disable the flag either as then the crate won't compile, as much of what I'm doing does not fit into the stabilized set of functionality. At the very least, surely there must be some way to make it possible to specifically tell rustdoc to "please always document s as exactly what they are no matter what" without changing this default behaviour if that's not desired?
I think the metric should be 'does this have , not 'is this a function'.
I wonder if this isn't an artifact of the switch when adding support... But in any case, it should be a check over , you're absolutely right.
I wonder if this ever worked ... do you mind trying this with an old version of rustdoc? Preferably before was implemented: cc
I'll try that on my crate later today.
After testing both the example I gave here and my own crate with various nightlies from before was implemented, I can confirm that this problem definitely pre-dates it. There's no difference in how rustdoc behaved.
(apologies to lcnr for the ping)
If this helps at all, whichever version of rustdoc was using on August 1st did document my crate properly, it seems. Only the very latest version, uploaded on September 5th, was documented with the keyword missing. So it's a fairly recent bug, overall.
Ok, so I think I was reading the dates on the PRs a bit wrong when I tested yesterday as far as the timeframe for when was merged.

I just did a whole bunch more one-by-one testing of nightlies from August, and in fact the problem doesn't quite predate which was merged on August 7th. Specifically, the very last nightly to have a rustdoc that documents correctly is . Switching directly from that to from the next day makes the problem appear.
consider using instead which will do it automatically
Well, I already know it's a commit from between the 10th and 11th of August now, at least. Also, doesn't really seem to be designed for scenarios where identifying the problem specifically requires running on a crate and then visually inspecting the generated HTML files...
Change:
<ins> pub struct Foo<T>(pub core::ptr::NonNull<T>); </ins>

Discussion:
Some build environments (e.g. Chromium (), Bazel) may generate crate names based on names of build targets. While this results in globally-unique () crate names, it results in long and quite unwieldy crate names. Both Chromium and Blaze provide a macro to help working with such crate names: The macro usage above expands to something like: Unfortunately, it seems that some diagnostics keep referring to the long and unwieldy name. () see () globally-unique crate names = within a given build tree No response More detailed repro can be found below:
Is this something worth fixing? Is the original crate name worth preferring over the aliased name in some scenarios?
BTW: I also want to note/highlight that I am not able to repro the problem without using . For example (same files):
/cc
Change:
/// // The heap should now be empty. /// assert!(heap.is_empty()) /// ``` <ins> /// /// ## Min-heap /// /// Either `std::cmp::Reverse` or a custom `Ord` implementation can be used to /// make `BinaryHeap` a min-heap. This makes `heap.pop()` return the smallest /// value instead of the greatest one. /// /// ``` /// use std::collections::BinaryHeap; /// use std::cmp::Reverse; /// /// let mut heap = BinaryHeap::new(); /// /// // Wrap values in `Reverse` /// heap.push(Reverse(1)); /// heap.push(Reverse(5)); /// heap.push(Reverse(2)); /// /// // If we pop these scores now, they should come back in the reverse order. /// assert_eq!(heap.pop(), Some(Reverse(1))); /// assert_eq!(heap.pop(), Some(Reverse(2))); /// assert_eq!(heap.pop(), Some(Reverse(5))); /// assert_eq!(heap.pop(), None); /// ``` </ins> #[stable(feature = "rust1", since = "1.0.0")] pub struct BinaryHeap<T> { data: Vec<T>,

Discussion:
std::collections::BinaryHeap is a max-heap. A very common use case for users will be to make a min-heap. The basic example should include a min-heap.
Do you think you would be able to make a PR based on e.g. ?
Added an example in
Change:
use rustc_hir::def::DefKind; use rustc_hir::def_id::DefIdSet; use rustc_llvm::RustString; <ins> use rustc_middle::bug; </ins> use rustc_middle::middle::codegen_fn_attrs::CodegenFnAttrFlags; use rustc_middle::mir::coverage::CodeRegion; use rustc_middle::ty::TyCtxt;

Discussion:
Between nightly versions 2022-01-14 and 2022-01-15, 0.8.2 lost track of 82% of the coverage of when using the LLVM coverage option (). Other projects of mine continue to have code coverage correctly measured. I'm not where to start narrowing this down, as I'm not getting any errors or warnings printed. Here are the steps to get good code coverage reports out of 2022-01-14: If you look at the report in the coverage folder, the html report will show 80% coverage. Now, test with the next nightly: If you look at the report again, the html report now shows < 1% coverage. The quantity of profraw files are the same, and the sizes of the files are more or less equivalent. I'm not quite sure where to start narrowing this down since it's a unique issue to this project of mine -- but the only unique part I'm aware of is its size :sweat_smile:. For now I'll pin our CI to the last working nightly. Thank you in advance for any suggestions or help!
We noticed the same when upgrading rustc in our project from (December) to . Code coverage measured with and inexplicably dropped . Some crates that are clearly running don't show up at all in the reports. suggests that this is probably caused by
^ says is also affected.
cc label +requires-nightly +A-code-coverage
Thanks for the report! I've tried reproducing locally and I'm able to see the same behavior. Running the LLVM tools directly, I see this when trying to process coverage data for the various binaries: which seems to be the same issue as was reported in a comment on . I'm continuing to investigate ...
The minimal repro seems to be I think I'll have a fix for this within the next few days.