jiebi/CodeConvo huggingface dataset:
Change:
<ins> // Regression test for the ICE described in #79546. // compile-flags: --cap-lints=allow -Zfuel=issue79546=0 // check-pass #![crate_name="issue79546"] struct S; fn main() {} </ins>

Discussion:
Building with leads 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. --: From bisecting previous nightlies, this is a regression between 2020-09-03 and 2020-09-04 . Within ..., it looks like is related. Cc <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
is a workaround.
Minimal reproduction without Cargo: <details<summaryFull output</summary</details
I am also seeing this panic, though perhaps unrelated because I don't have those flags. I don't have a minimal example yet. Here's my trace. Let me know if I should make another bug.
I found a minimal example and opened a new issue, . Same error message, very different example. Seems unrelated.
Change:
<ins> // Copyright 2016 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. use std::fmt; // @has issue_29503/trait.MyTrait.html pub trait MyTrait { fn my_string(&self) -> String; } // @has - "//ul[@id='implementors-list']/li" "impl<T> MyTrait for T where T: Debug" impl<T> MyTrait for T where T: fmt::Debug { fn my_string(&self) -> String { format!("{:?}", self) } } pub fn main() { } </ins>

Discussion:
has the implementation which is It is however , so rustdoc does the correct thing after doc inlining. This bug with blanket impls shows up in user's crates, ; for example the trait in itertools does not have its blanket impl visible in the docs.
It regressed on nightly, it also disappeard from the libstd page.
The regression is not due to specialization, see e.g. vs which does not use specialization. Regression is also visible on beta btw.
hmm, is this bug affecting me? , corresponding
Yes, it's the same bug.
thanks. a bit confusing, since that impl is the whole point of my crate :smile:
The regression was already fixed in
Change:
<ins> Available lint options: -W <foo>           Warn about <foo> -A <foo>           Allow <foo> -D <foo>           Deny <foo> -F <foo>           Forbid <foo> (deny <foo> and all attempts to override) Lint checks provided by rustc: $NAMES  $LEVELS  $MEANINGS Lint groups provided by rustc: $NAMES  $SUB_LINTS Lint checks provided by plugins loaded by this crate: $NAMES  $LEVELS  $MEANINGS Lint groups provided by plugins loaded by this crate: rustdoc::all  $GROUPS </ins>

Discussion:
I tried this code: I expected to see this happen: Rustdoc prints a list of all lints, the same way rustc does. Instead, this happened: Rustdoc ignored the flag. <!-- 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. --: rustdoc 1.53.0-nightly ( 2021-04-03) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
option is parsed into , but is then ignored: It should be pretty straightforward to instead call when this flag is set. claim
Make sure you call init_lints first, or it will be missing rustdoc's own lints.
Re adding a test for this... is there any way to have check only for whether some substring appears within stderr? Else every time a lint is /removed, or its level modified, the test will need updating—which seems far too brittle to me?
I mean, personally that seems ok to me as long as you can update it with . But if you think it's a hassle you could use .
Change:
<ins> error[E0412]: cannot find type `Color` in this scope --> $DIR/trait-selection-ice-84727.rs:5:17 | LL |     foreground: Color<Fg>, |                 ^^^^^ not found in this scope error[E0412]: cannot find type `Color` in this scope --> $DIR/trait-selection-ice-84727.rs:7:17 | LL |     background: Color<Bg>, |                 ^^^^^ not found in this scope error[E0412]: cannot find type `Color` in this scope --> $DIR/trait-selection-ice-84727.rs:18:16 | LL |     Self: Over<Color<BottomBg>, Cell<NewFg>>, |                ^^^^^ not found in this scope error[E0412]: cannot find type `NewBg` in this scope --> $DIR/trait-selection-ice-84727.rs:32:27 | LL |     fn over(self) -> Cell<NewBg> { |                           ^^^^^ not found in this scope | help: you might be missing a type parameter | LL | impl<'b, TopFg, TopBg, BottomFg, BottomBg, NewBg> Over<&Cell<BottomFg, BottomBg>, ()> |                                          +++++++ error[E0308]: mismatched types --> $DIR/trait-selection-ice-84727.rs:21:22 | LL |     fn over(self) -> Cell<NewFg> { |        ----          ^^^^^^^^^^^ expected `Cell<NewFg>`, found `()` |        | |        implicitly returns `()` as its body has no tail or `return` expression LL | LL |         self.over(); |                    - help: remove this semicolon to return this value | = note: expected struct `Cell<NewFg>` found unit type `()` error: aborting due to 5 previous errors Some errors have detailed explanations: E0308, E0412. For more information about an error, try `rustc --explain E0308`. </ins>

Discussion:
: Same in 1.52.0-nightly, same in 1.51.0. : <details<summary<strongBacktrace</strong</summary<p</p</detailsGood luck! <3
This happens on top of too much code for me to take the time to minimalize this issue, sorry. Though I'll try to file the fixing patch.
Wait! I made it! This issue revolves around L.31. Comment to see the ice go away. Interestingly, comment L.40 (or the whole impl L.37-45) to see ice go away as well. Commenting L.47-56 does not make ice go away. Commenting L.13-22 should raise another error (as L.31 is supposed to go there), but doesn't. Actually, the real fix is to replace L.31 with: Have fun!
Minimized with , then a bit by hand: <details<summaryDetails</summary<pIcemelter version: v0.2.0 label +S-bug-has-mcve </p</details
fixed by . we previously used to eagerly error but did not consider them as part of the cache key. So using a cache key from an evaluation with different can result in buggy behavior
Change:
<ins> // ignore-tidy-linelength #![feature(const_generics)] #![crate_name = "foo"] use std::ops::Add; // @has foo/struct.Simd.html '//pre[@class="rust struct"]' 'pub struct Simd<T, const WIDTH: usize>' pub struct Simd<T, const WIDTH: usize> { inner: T, } // @has foo/struct.Simd.html '//div[@id="implementations-list"]/h3/code' 'impl Add<Simd<u8, 16>> for Simd<u8, 16>' impl Add for Simd<u8, 16> { type Output = Self; fn add(self, rhs: Self) -> Self::Output { Self { inner: 0 } } } </ins>

Discussion:
When playing around with const generics, I found some weird generated docs: How to reproduce: and go to the documentation on the VecSet struct (inside the vecset module), and find the auto impls.
My guess is that rustdoc just doesn't yet handle const generics properly
Support for const generics in rustdoc has not been tested very thoroughly at all (I don't think there are any tests in the test suite for it at all yet). We also have a number of issues with pretty-printing consts (). That said, I imagine this would not be too difficult to fix: we're getting the right parameter — we're just debug printing it instead of pretty-printing it.
Change:
Struct { r: r } } <del> trait Curve {} enum E {X(Curve+'static)} </del> fn main() {}

Discussion:
Backtrace: This seems to occur when using a non-struct type that contains an unsized type. This is probably because  only handles and the base unsized types. This should be extended to handle enums and tuples as well.
This is still happening. Does this mean we should avoid using DSTs for complex custom types for now?
Visiting for triage This is still an issue:
ICE also happens with a tupled trait object:
I've seen this too with: Reproducer: Version: Backtrace:
No longer reproduces but the other tests do.
cc
Is this the same as or related to ?
leads to . As mentioned inline, using the correct type works (). I'm using the Ubuntu PPA "rust-nightly", version ~~vivid.
Does not compile for other reasons that the ICE anymore. I've adjusted to the following and could not reproduce it anymore.
Another example hitting this same ICE:
Bugs similar to this one have been reported numerous times (most of the references to this issue are duplicates). Although it would be nice for reporters to search for similar issues before filing a new one, it's hard to blame them, since the ICE message from rustc tells people to file an issue. This issue itself was opened over two years ago. Separate from fixing the underlying problem, we should at least investigate displaying a real error instead of an ICE.
Change:
let rcvr = &args[0]; let rcvr_t = self.check_expr_with_needs(&rcvr, needs); // no need to check for bot/err -- callee does that <del> let rcvr_t = self.structurally_resolved_type(expr.span, rcvr_t); </del> <ins> let rcvr_t = self.structurally_resolved_type(args[0].span, rcvr_t); </ins> let method = match self.lookup_method(rcvr_t, segment,

Discussion:
E.g., the expression with unknown type is the variable use , but the error highlight covers the entire sub-expression of . I assume this is due to us doing something sub-optimal with the spans here in the HIR lowering.
is worried that similar issues are arising with other desugarings, i.e. that this might be an across-the-board regression. Worth investigating.
: gives
triage: P-medium Doesn't seem like a "stop everything" sort of problem, but would be good to figure it out. However, it does not appear to be a regression: e.g., the above test case behaves the same in 1.16.0 as well.
Change:
}; use rustc_data_structures::fx::FxIndexMap; use rustc_data_structures::unord::{ExtendUnord, UnordMap, UnordSet}; <ins> use rustc_feature::ACCEPTED_FEATURES; </ins> use rustc_hir as hir; use rustc_hir::def::{DefKind, Res}; use rustc_hir::def_id::{CRATE_DEF_ID, LOCAL_CRATE, LocalDefId, LocalModDefId};

Discussion:
This should probably not be accepted: is already stable, so having an unstable function under this feature makes no sense. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Should we also reject features that don't exist? Right now, this test would fail (because it would compile without problems)
"unstable" attributes is how library features come into existence. So yes we should accept features that do not yet exist.
Change:
include ../../run-make-fulldeps/tools.mk <ins> # FIXME https://github.com/rust-lang/rust/issues/78911 </ins> # ignore-32bit wrong/no cross compiler and sometimes we pass wrong gcc args (-m64) all: foo

Discussion:
I encountered an ICE today. Below you find the backtrace of running . I ran afterwards and the ICE vanished, so it seams to be connected to incremental compilation. If required I can attach the full project including the build directories, as I zipped it after the ICE.
If possible, we would most of all appreciate a reproducer that works on the playground (this will facilitate fixing the bug faster) but if that's not possible a link to the zip would be good also.
Sorry, I didn't had enough time for it lately. Are there any guidelines how to track down such an incremental compilation error? Unfortunately I cannot recall the steps I've done. I've minimized the code in such a way, that removing any more causes the ICE to vanish. I'll attach this Zip-archive, so somebody else might have a look. Note, that this is not yet a MCVE.
any luck so far? The code looks good, now you have to recall what you did (rename a variable, changed something from a struct to a trait? Deleted members of a struct? Added functions? Removed them?) I know it's hard to debug incremental bugs (I encountered two so far). Any chance that you can tell us, what you did between , and the second ?
Unfortunately no. I tried to recall things, that I've done at this point, but any change I made either also ICEs or compiles fine. I've tried to reproduce this by writing the same code again, but obviously I write it a little bit different now, so I cannot get it to crash. Are there any tips how to deal with those incremental compilation crashes? Trying to reproduce like I'm doing it now is poking around in the dark.
As said, it could be anything ^^ Here are some examples I've seen so far in the wild:
Okay, thanks, I'll have a look at the linked issues :smiley:
Today I encountered the same ICE with "the len is 1077 but the index is 1077". I was writing and running some integration tests; it involved a serialization format (with Serde). I changed an array constant in a test case, then the panic occurred. When I changed it again, the ICE went away, and then I couldn't reproduce it anymore, not even with the value that seems to have caused it in the first place.

We've got the same bug with the len number of 30, not on my machine but on (the CI account isn't mine). If you guys know how to do the magic to pull the build artifacts from travis - you're welcome, CI account's owner seems willing to cooperate
Maybe the commit succession can be of interest to investigate the bug.
I got this same panic, and it also went away after a clean build.
Another one here, looks like the same problem and it also went away for now after .
Change:
<ins> error: argument 3 is required to be a constant --> $DIR/const_arg_local.rs:10:5 | LL |     _mm_clmulepi64_si128(a, b, imm8) |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error </ins>

Discussion:
Expected the following code to compile But getting Repro:
Also happens on beta, not on stable
Stable says:
For reference, the function signature as defined is exactly the same.
The actual ICE occurs first in nightly-2019-03-03 (...). But interesting enough, stable (as jonas pointed out) procuces an error, saying, that the third argument must be a constant. Since nightly-2019-02-16 (...) this does not emit an error anymore, but also does not ICE.
I guess for the "does not emit an error anymore" can say something about it. should be responsible for it.
triage: P-high
Note that because of the on the definition, you can't wrap it (without matching on and having 256 separate calls). I don't think this is intentional, but I'm not sure why it would happen, maybe arguments are treated incorrectly in the qualifier. cc
So I agree that this code can't compile, that's the expected behavior; if you want to wrap it, you have to use a macro - Rust functions aren't able to abstract over this type of hardware operations yet. The ICE is a regression over the error message that was being produced before. We should definitely add an ui test for that.
triage, assigning to self to fix the stable-to-beta regression.
The behavior here varies with edition as well as channel. edition 2018 ------------------ ------------------------ stable expected error beta unexpected compile-pass nightly-2019-04-05 ICE I think the most immediate thing to address is the unexpected compile-pass that has leaked into beta.
The easiest thing might be to revert
I have an actual fix in (also easier to backport than a revert)
Okay then I'm reassigning to
Change:
<ins> #![deny(unused_mut)] fn main() { let mut x; //~ ERROR: variable does not need to be mutable x = String::new(); dbg!(x); } </ins>

Discussion:
(sorry if this is an duplicate or the wrong repo :innocent: ) () Current behavior: no warning Expected behavior: The variable clearly doesn't need to be mutable, still, nothing is detected and no warning is emitted. Rust 1.35.0 (Using the , also in ())
The warning appears again if you switch to 2015 edition. Huh. Nice catch!
I found that Stable 2015 edition produces the warning and everything else doesn't.
cc (likely caused by NLL migrate mode, which was enabled in for the 2015 edition)
Yes, looks like another nll bug. If someone wants to have a go at this, the issue is that we are treating DropAndReplace differently to Assign for the purposes of this lint.
I can try doing it I just don't know here to begin.
I don't know this code too well, but take a look at . The first thing I'd try is adding a case for to the match in that mirrors what's done for .
Makes sense thank you. I was looking at librustc_lint and couldn't find anything.
Change:
Ok(ty::Const::from_value(tcx, lit, ty)) } <del> fn parse_float<'tcx>(num: Symbol, fty: ty::FloatTy, neg: bool) -> ConstValue<'tcx> { </del> <ins> fn parse_float<'tcx>(num: Symbol, fty: ty::FloatTy, neg: bool) -> Option<ConstValue<'tcx>> { </ins> let num = num.as_str(); use rustc_apfloat::ieee::{Double, Single}; let scalar = match fty { ty::FloatTy::F32 => { <del> let rust_f = num .parse::<f32>() .unwrap_or_else(|e| panic!("f32 failed to parse `{}`: {:?}", num, e)); </del> <ins> let rust_f = match num.parse::<f32>() { Ok(f) => f, Err(_) => return None, }; </ins> let mut f = num.parse::<Single>().unwrap_or_else(|e| { panic!("apfloat::ieee::Single failed to parse `{}`: {:?}", num, e) });

Discussion:
I'm seeing an internal compiler error on the following input, found by : The ICE happens after correctly reporting a malformed float error, so low priority. Note that slight modifications of the input fix the panic. For example using instead of results in no panic. Also there is no panic if compling only the string . Affected versions: I tried nightly 2021-11-30 and stable 1.56.1 and they both show the same ICE. <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Might be related? Formatting of "1e-15" behavior seems to have changed on nightly for f64 and f32.
It may have a common cause, but you should open a separate issue because the pull request that fixes this doesn't fix your problem.
Change:
<ins> // check-pass #![feature(generic_associated_types)] pub trait Scalar: 'static { type RefType<'a>: ScalarRef<'a>; } pub trait ScalarRef<'a>: 'a {} fn cmp_eq<'a, 'b, A: Scalar, B: Scalar, O: Scalar>(a: A::RefType<'a>, b: B::RefType<'b>) -> O { todo!() } fn build_expression<A: Scalar, B: Scalar, O: Scalar>( ) -> impl Fn(A::RefType<'_>, B::RefType<'_>) -> O { cmp_eq } 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</detailsThanks for investigating into this issue! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
... I found that I forget to impl and for bool. Even if I do: The issue still exists...
claim

<!-- 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. --I was experimenting with Bevy, and suddenly found has stopped me to show errors. It turned out that paniced on this function: I a commit with exact state of my project (it's pretty small ATM) where the compiler pianics <!-- 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
Thanks for the code. Would be great if someone could take a stab at minimizing it. label +E-needs-mcve I may come back and attempt to myself
I've managed to get it to this point.
Here's a version with the bevy calls minimized as well
epic! label -E-needs-mcve glacier ""
Error: Parsing glacier command in failed: ...'cier https' ''... Please let know if you're having trouble with this bot.
Error: Parsing glacier command in failed: ...' glacier :' ''... Please let know if you're having trouble with this bot.
Oh, can the glacier command only be used by repository members?
Change:
<ins> // Test to ensure that there is no ICE when normalizing a projection. // See also <https://github.com/rust-lang/rust/pull/106938>. // issue: rust-lang/rust#107872 pub trait Identity { type Identity; } pub type Foo = u8; pub union Bar { a:  <Foo as Identity>::Identity, //~ ERROR the trait bound `u8: Identity` is not satisfied b: u8, } </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. --: Regression in <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Considering this errors with rustc, and rustdoc can only document rust code that actually compiles, I'd say this is in the same bucket as the other issues we have open about this, meaning "not a bug, just a papercut"?
this is not true
I can only document code that compiles, ignoring method bodies. This specific test has no method bodies, so does it fall under that rule?
That seems possible, but you should test to make sure. Rustdoc's logic around this is extremely janky and indirect.
What is the benefit of documenting code that does not compile?
I can't keep having this argument. Please read the documentation.
cc
Triage: No longer ICEs. Might need regression test, not sure. Current compiler output:
Change:
<ins> error: `$x:pat2021` is followed by `|`, which is not allowed for `pat2021` fragments --> $DIR/macro-pat2021-pattern-followed-by-or.rs:3:32 | LL | macro_rules! foo { ($x:pat2021 | $y:pat2021) => {} } |                                ^ not allowed after `pat2021` fragments | = note: allowed there are: `=>`, `,`, `=`, `if` or `in` error: `$x:pat2021` is followed by `|`, which is not allowed for `pat2021` fragments --> $DIR/macro-pat2021-pattern-followed-by-or.rs:6:32 | LL | macro_rules! ogg { ($x:pat2021 | $y:pat2015) => {} } |                                ^ not allowed after `pat2021` fragments | = note: allowed there are: `=>`, `,`, `=`, `if` or `in` error: `$pat:pat2021` may be followed by `|`, which is not allowed for `pat2021` fragments --> $DIR/macro-pat2021-pattern-followed-by-or.rs:8:40 | LL |     ( $expr:expr , $( $( $pat:pat2021 )|+ => $expr_arm:pat2021 ),+ ) => { |                                        ^ not allowed after `pat2021` fragments | = note: allowed there are: `=>`, `,`, `=`, `if` or `in` error: aborting due to 3 previous errors </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.