jiebi/CodeConvo huggingface dataset:
Change:
use rustc_hir::def::DefKind; use rustc_hir::def_id::DefId; use rustc_macros::HashStable; <del> use rustc_span::Span; </del> <ins> use rustc_span::{Span, DUMMY_SP}; </ins> use rustc_target::abi::{Integer, Size, TargetDataLayout}; use smallvec::SmallVec; use std::{cmp, fmt};

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. --I tried this code: Running does not terminate after a long time. After running for 4 minutes, the process is using 99.2% CPU and about 80 MB memory. <!-- 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 following also hangs, though a diagnostic is first emitted:
The hang seems to happen in
I have modified to detect simple cycles like these to obtain a backtrace: <details</details
More minimal example: This one demonstrates that it's a regression, it errors out immediately on 1.35 but hangs on 1.36.
searched toolchains nightly-2019-04-09 through nightly-2019-05-22 Regression in nightly-2019-04-24 found 9 bors merge commits in the specified range commit[0] 2019-04-22UTC: Auto merge of - varkor:tidy-leading-newline, r=alexcrichton commit[1] 2019-04-22UTC: Auto merge of - estebank:continue-eval, r=oli-obk commit[2] 2019-04-23UTC: Auto merge of - euclio:pulldown-cmark, r=GuillaumeGomez commit[3] 2019-04-23UTC: Auto merge of - davazp:fix-sync-all-macos, r=KodrAus commit[4] 2019-04-23UTC: Auto merge of - varkor:tidy-double-trailing-newline, r=kennytm commit[5] 2019-04-23UTC: Auto merge of - estebank:continue-evaluating, r=oli-obk commit[6] 2019-04-23UTC: Auto merge of - stepnivlk:visit_subpats-removal, r=varkor commit[7] 2019-04-23UTC: Auto merge of - davidtwco:issue-, r=oli-obk commit[8] 2019-04-23UTC: Auto merge of - Centril:rollup-akw4r85, r=Centril Probably ? I guess the compiler used to abort early after the recursive type error but now doesn't and hangs because later code assumes structs aren't recursive. label regression-from-stable-to-stable
cc - maybe something similar is necessary here?
What did was stop doing that (aborting early if there's an error) for .

Seems a bit drastic to revert that (making the compiler unable to report other, later errors until the recursive type is fixed) for this - I think we can do something more targeted.
Perhaps the recursive field could be replaced by a ?
Assigning and removing as .20leads.20to.20infinite.20loop) in the prioritization working group.
This issue have been also reported in .
Change:
<ins> // https://github.com/rust-lang/rust/issues/82329 // compile-flags: -Zunpretty=hir,typed // check-pass pub fn main() { if true { } else if let Some(a) = Some(3) { } } </ins>

Discussion:
I got this error on my code even though it did not have any in it. Also, it seems to only happen on crates. Just a is enough to reproduce it. rust playground: The bug also happens on and versions of the compiler. : <!-- 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 --
Oh, I think it's worth noting that if the code is refatored as: The bug ceases to happen.
I think duplicated of ?
this one doesn't need nightly to trigger
The code in works for me
right, because it's a different problem and only triggers with .
The issue seems to be that the gets desugared to a , which is currently unexpected in an branch. claim
Change:
match m.primitive_locations.get(&prim) { Some(&def_id) if def_id.is_local() => { let len = cx.current.len(); <del> let len = if len == 0 { 0 } else { len - 1 }; </del> <ins> let path = if len == 0 { let cname_sym = ExternalCrate { crate_num: def_id.krate }.name(cx.tcx()); format!("{cname_sym}/") } else { "../".repeat(len - 1) }; </ins> write!( f, "<a class="primitive" href="{}primitive.{}.html{fragment}">", <del> "../".repeat(len), </del> <ins> path, </ins> prim.as_sym() )?; needs_termination = true;

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. --to on the usize return parameter link goes here: This happens with other parameters. . Nor is it broken on the portable simd docs. There are other things broken, such as slices on the SIMD page as well. It is also on other SIMD types' documentation pages. I don't know the exact pattern though. The link would be to this page: The link is to this page: Basically it seems to not be inserting the "std" directory in the link. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +A-docs +A-rustdoc-ui +T-rustdoc -needs-triage
claim
Regressed in one of these two commits: . Not sure which because the second one, which is the predecessor of the first one, doesn't build.
Ignore the above comment. It was a wrong bisection. The regression most likely occurred in PR . I say "most likely" because it was impossible to bisect around this part of the git log because builds kept failing with ICE's. Anyway, the cause of the bug is that in type alias docs links to primitives are being rendered relative to the target type not the alias. For example for the link is rendered as instead of because the target type is two levels deep from the root even though is just one level deep. This problem seems limited only type aliases. Internally this is how the rendering of the link works: generates the primitive path as just in the HTML fragment held in the JSONP format. in then prepends this string with the value of which seems to be relative to the target type (i.e. for our above example of ) The end result is that we get a link relative to the type not the alias.
The fix could either be in wherein we could compute the correct path to prepend depending on the path of the alias instead of just using . Or it could be in / methods whereby we could generate the path instead of for the primitive which will ensure that just prepending in front of it will work.

What are your thoughts since you where the original author? This is the first time I've ventured into rustdoc so any pointers will be helpful.
I think the second option, generating the link as , is the better choice.
Change:
<ins> #![crate_name = "foo"] // Check that default trait items that are impossible to satisfy pub trait Foo { fn needs_sized(&self) where Self: Sized, {} fn no_needs_sized(&self) {} } // @!has foo/struct.Bar.html '//*[@id="method.needs_sized"]//h4[@class="code-header"]'  // "fn needs_sized" // @has foo/struct.Bar.html '//*[@id="method.no_needs_sized"]//h4[@class="code-header"]'  // "fn no_needs_sized" pub struct Bar([u8]); impl Foo for Bar {} </ins>

Discussion:
Found in [this topic] on URLO. It shows the method on the page for . This is misleading, because you can't actually call that method, because . [this topic]: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
The same issue with and . do you know how to exclude these options from hashmap? I'm still digging with it, if hashmap has this kind of issue, other data structures maybe have similar kind of issue. I think we need to check the trait bounds when generating the doc.
I expect you want to do it while — turning the rustc IR into rustdoc's own IR — or earlier. Doing it later would mean reimplementing parts of rustc's type checker using rustdoc's IR, and nobody wants to do that.
For the record I was working on this, sorry for not claiming this... Anyways, let me know if you don't get around to this, and I'll pick it back up :smile_cat: . Seems like you've claimed a few issues in the past hours so not sure which ones you've gotten started with.
I haven't started this one, released it, please go ahead. It's funny and also helpful to learn some Rust internals, I'm starting with some trivial fixes
Thank you Sorry for the mistake, and I am excited for you to get involved more in the compiler :) claim
This is a dupe of
Uh, sorry, actually not a dupe. That's impl level, this is method level. I think there were legitimate concerns with hiding whole impls in that other issue. Reopening this, andf I'll probably solve this first.
Change:
LockstepIterSize::Constraint(r_len, _) if l_len == r_len => self, LockstepIterSize::Constraint(r_len, r_id) => { let msg = format!( <del> "inconsistent lockstep iteration:  '{}' has {} items, but '{}' has {}", </del> <ins> "meta-variable `{}` repeats {} times, but `{}` repeats {} times", </ins> l_id, l_len, r_id, r_len ); LockstepIterSize::Contradiction(msg)

Discussion:
Given this test file: stable Rust errors like this: while on 1.36.0-nightly ( 2019-05-21) running on x86_64-unknown-linux-gnu:
caused by cc
Yay, we have a test case.
Hmm... interesting... yeah, I guess we have a test case. I will open a PR to revert and add the test case. Thanks ! But this raises a bigger point that has been growing on me for a while now: there are a ton of checks that are currently only done at macro invocation time (or are not done at all) that really would make more sense to do a macro definition time. Checking that the Kleene operator used in the body is the same as that in the matcher Checking that all meta-variables used in the body are defined and in scope Checking that all meta-variables used in the body are repeating at the right depth Checking that the body of a macro is actually valid rust syntax (to the extent that we can, anyway) So far, I have been holding off on attempting to fix these because they could involve building a whole language, and it seems that at some point we want to just use macros... Thoughts?
Opened
there are a ton of checks that are currently only done at macro invocation time (or are not done at all) that really would make more sense to do a macro definition time. If the defined macro produces an error with any possible input, then we should probably report it at definition time, at least as a quality of implementation measure (perhaps as a warning for a start). I have more confidence in reporting errors related to the macro definition language itself (meta-variables, repetitions, etc.), than in errors for produced tokens (which are not necessarily supposed to be Rust code, with eager expansion they may be consumed by another macro, for example).
Ok, makes sense. I will open another issue with these items so we can track them.
Change:
} else { format!("{{ {}; {} }}", migration_string, s) }; <del> (sugg, Applicability::MachineApplicable) </del> <ins> (closure_body_span, sugg, Applicability::MachineApplicable) </ins> } <del> Err(_) => (migration_string.clone(), Applicability::HasPlaceholders), </del> <ins> Err(_) => (closure_span, migration_string.clone(), Applicability::HasPlaceholders), </ins> }; let diagnostic_msg = format!(

Discussion:
produces: It expanded the macro. This only happens when the macro invocation is the entire body of the closure.
cc
Working on a fix.
Change:
<ins> // force-host // no-prefer-dynamic #![crate_type = "proc-macro"] extern crate proc_macro; use proc_macro::TokenStream; #[proc_macro_derive(Deserialize)] pub fn deserialize_derive(input: TokenStream) -> TokenStream { "impl Build { fn deserialize() -> Option<u64> { let x: Option<u32> = Some(0); Some(x? + 1) } } " .parse() .unwrap() } </ins>

Discussion:
No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Short code to reproduce the issue.
Change:
<ins> error: cannot find attribute `main` in this scope --> $DIR/main-removed-1.rs:1:3 | LL | #[main] |   ^^^^ | = note: `main` is in scope, but it is a function, not an attribute error: aborting due to previous error </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. --I tried this code: I expected an error, because the main attribute has never been available on stable, and had apparently been removed in . Instead, the program ran without error, although the attribute has no apparent effect. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked as expected (emitting an error) on Rust 1.52.1: <!-- Provide the version you are using that has the regression. --This stopped being an error in 1.53.0 (in which a warning was still emitted), and continues to be accepted in stable through the current 1.58.1 version (in which the warning has also disappeared).
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high +T-compiler
Change:
let result_t = fcx.expr_ty(expr); demand::suptype(fcx, expr.span, result_t, lhs_t); <ins> let tcx = fcx.tcx(); if !ty::expr_is_lval(tcx, fcx.ccx.method_map, lhs) { tcx.sess.span_err(lhs.span, "illegal left-hand side expression"); } </ins> // Overwrite result of check_binop...this preserves existing behavior // but seems quite dubious with regard to user-defined methods // and so forth. - Niko

Discussion:
When compiling the following code: I get the error: Compiled with:
I also just hit this today. An even simpler test case:
Reproduced with (both cases). Interestingly, rustc warns that X0 and X1 don't need to be mutable on the first case.
Similar ICE with structs:
The simplest case I think:
It's because assumes only one of will come but it met . So seems easy to fix, but what about tuples/structs? is also not allowed, right? I initially thought it is allowed because is. But previous discussions seem that it's not: , .
My impression is that isn't supposed to be allowed. That said, it would be kinda neat if it was. Right now I'm writing the same 3 lines over and over that look like and I'd love to be able to just say
I forgot to mention about mutability; currently is obsolete, and (heard from irc) it may be because it's confusing that immutable tuples are with . I don't know any previous discussion about it. anyone? If it is true, should be disallowed in the same manner, because is immutable while and are. Anyway, I agree with it's not cool to unpack manually.
Clearly something in the compiler is not checking that the LHS of an assignment is actually an lvalue. Kind of amusing. Rather surprising that this gets through borrowck, I'll have to look at that. It's probably assuming that an earlier pass would have caught such cases. Anyway, it'd be nice to permit , certainly, but it is not currently allowed. I think that'd be a post-Rust 1.0 sort of extension. I previously thought it would introduce horrible ambiguities into parsing, but I realize now that it would not, so long as you only have two cases: , which assigns to a pattern, and which always declares new bindings, and , which always overwrites existing lvalues.
Change:
lint_supertrait_as_deref_target = `{$t}` implements `Deref` with supertrait `{$target_principal}` as target .label = target type is set here <del> lint_suspicious_double_ref_op = using `.{$call}()` on a double reference, which returns `{$ty}` instead of {$op -> *[should_not_happen] [{$op}] [deref] dereferencing [borrow] borrowing [clone] cloning } the inner type </del> <ins> lint_suspicious_double_ref_clone = using `.clone()` on a double reference, which returns `{$ty}` instead of cloning the inner type lint_suspicious_double_ref_deref = using `.deref()` on a double reference, which returns `{$ty}` instead of dereferencing the inner type </ins> lint_trivial_untranslatable_diag = diagnostic with static strings only

Discussion:
If I have a type , and a trait that is implemented for both and , is a valid way to get a reference from an object of type . But since beta 1.71, this emits a warning. I have no idea what the warning is trying to convey, what "double reference" is referring to, or what "the inner type" is. No response
cc
Ah. then I think this lint shouldn't apply to since can mean specifically to borrow . But I think this should still apply to and
(sorry)
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
}) .map(|(formatter, span)| (*span, formatter(name))) .collect(); <ins> if spans_suggs.is_empty() { // If all the spans come from macros, we cannot extract snippets and then // `formatters` only contains None and `spans_suggs` is empty. return; } </ins> err.multipart_suggestion_verbose( &format!( "consider using the `{}` lifetime",

Discussion:
<details<summary<strongBacktrace</strong</summary<p</p</details
This bisects to &mdash; regressed nightly: nightly-2021-12-03 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
There was an issue with similar ICE that has been fixed recently Does this problem still repro with latest nightly ?
Yes this one still reproduces as of that nightly, which contains .
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Change:
edition: Edition, test_id: Option<&str>, ) -> (String, usize, bool) { <del> let (crate_attrs, everything_else, crates) = partition_source(s); </del> <ins> let (crate_attrs, everything_else, crates) = partition_source(s, edition); </ins> let everything_else = everything_else.trim(); let mut line_offset = 0; let mut prog = String::new();

Discussion:
With following doctest, where the cfg attribute spans multiple lines, the final program is invalid: the wrapping method doesn't take into account the dangling line that closes the attribute. rust /// # #![cfgattr(not(dox), feature(cfgtargetfeature, targetfeature, /// # stdsimd))] /// /// fn foo() { /// let mut dst = [0]; /// addquickly(&[1], &[2], &mut dst); /// asserteq!(dst[0], 3); /// } ///
cc
cc
I don't see a message associated with the stack trace, is that missing?
The problem lies in how rustdoc parses doctests. It scans lines for crate-level attributes and statements, but it doesn't do anything more intelligent than checking the beginning of each line: We recently changed the parsing for and detection to use the libsyntax parser, but this initial scan is still a string-based search. The way to fix the test in the OP is to actually remove the part of it - rustdoc doesn't pass on any information into doctest compilation, so those features are going to be enabled regardless.
This is the associated message:
Change:
pub enum BacktraceStatus { /// Capturing a backtrace is not supported, likely because it's not /// implemented for the current platform. <ins> #[stable(feature = "backtrace", since = "1.65.0")] </ins> Unsupported, /// Capturing a backtrace has been disabled through either the /// `RUST_LIB_BACKTRACE` or `RUST_BACKTRACE` environment variables. <ins> #[stable(feature = "backtrace", since = "1.65.0")] </ins> Disabled, /// A backtrace has been captured and the `Backtrace` should print /// reasonable information when rendered. <ins> #[stable(feature = "backtrace", since = "1.65.0")] </ins> Captured, }

Discussion:
As of current nightly rustc 1.65.0-nightly ( 2022-08-10): : Mentioning erstwhile tracking issue Mentioning in connection with .
"encountered unmarked API" &mdash; maybe it's that there is no #[stable] attribute on the enum variants, like there is in other stable enums? I'd have expected that to be caught during the libstd build, so we should fix whatever was supposed to catch it, not just add the attributes.
Indeed, I didn't realize that enum variants also needed stable attributes.
Change:
impl EarlyLintPass for UnusedParens { #[inline] fn check_expr(&mut self, cx: &EarlyContext<'_>, e: &ast::Expr) { <ins> if let ExprKind::Binary(op, lhs, _rhs) = &e.kind && (op.node == ast::BinOpKind::Lt || op.node == ast::BinOpKind::Shl) && let ExprKind::Cast(_expr, ty) = &lhs.kind && let ast::TyKind::Paren(_) = &ty.kind { self.parens_in_cast_in_lt.push(ty.id); } </ins> match e.kind { ExprKind::Let(ref pat, _, _) | ExprKind::ForLoop(ref pat, ..) => { self.check_unused_parens_pat(cx, pat, false, false, (true, true));

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: But with the suggestion applied the compiler displays an error with a different suggestion: <!-- The following is not always necessary. --Ideally the compiler should not output a warning and treat and as identical. <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- 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. -- label D-incorrect A-suggestion-diagnostics <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I think it's relate with and
It would be great if it could give since parenthesizing the expression instead avoids the potential "is that a tuple?" confusion of .
Duplicate of .
Change:
a: ty::Const<'tcx>, b: ty::Const<'tcx>, ) -> RelateResult<'tcx, ty::Const<'tcx>> { <del> if a == b { return Ok(a); } relate::super_relate_consts(self, a, b) // could do something similar here for constants! </del> <ins> self.infcx.probe(|_| { if a.is_ct_infer() || b.is_ct_infer() { Ok(a) } else { relate::super_relate_consts(self, a, b) // could do something similar here for constants! } }) </ins> } fn binders<T: Relate<'tcx>>(

Discussion:
Regression from stable 1.66 / beta 1.67 -nightly 1.68 (haven't bisected). Stable/beta correctly produce an error, nightly ICEs. I've also confirmed the behavior on the latest commit to master (, at time of writing). (nightly — ICE) (beta — error as expected) (stable — error as expected) Setting produced the same output as above. I tried to dig into this, struggled to make sense of the typechecking code. I think the following is going on: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cargo-bisect-rustc seems to think this is caused by of which looks like the most plausible candidate since it touched type relation code which calls without handling infer vars :thinking: cc
Ugh i'll fix it claim
WG-prioritization assigning priority (). label -I-prioritize +P-high
This is a bit weird, but I was able to come up with an alternative reduction (after hit it on - we use a pinned nightly so this is mostly a coincidence): I'm not sure why the inference variable vs generic param makes a difference like that, but I wasn't able to combine the two reductions together. Also, the ICE query stack confirms the / split between nightly versions, even in the combined example.