jiebi/CodeConvo huggingface dataset:
Code change:
<ins> error[E0599]: no method named `some_function` found for struct `SmallVec` in the current scope --> $DIR/hash-tyvid-regression-3.rs:17:19 | LL |         node.keys.some_function(); |                   ^^^^^^^^^^^^^ method not found in `SmallVec<{ D * 2 }>` ... LL | struct SmallVec<const D: usize> {} | ------------------------------- method `some_function` not found for this error: aborting due to previous error For more information about this error, try `rustc --explain E0599`. </ins>

Related discussion:
text: <!-- 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'm creating this issue mainly because it seems to be a different one than the ones listed in <!-- 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
What command are you running? I tried this code , but I encountered an error that doesn't have a method.
how strange, for me just causes the ice and it doesn't even come to notice that the function is missing. I just ran , and with the newest rustc () I still get the same error as above (in a new cargo project with the code copied from the playground link above).
Just ran again today and still get an ICE. Made the example a bit smaller: Output of (build also fails with the same message): Considering the rustc versions it should be the same that is currently on the playground, however there it does not cause an ICE. Maybe someone could try to reproduce this in a local environment?
can reproduce this locally, not sure why it doesn't ICE on the playground
cc -- it ICEs locally, but not on the playground
Try with ?
That indeed removes the ICE, let me just check which one of the options it is. Adding to the (or profile.release in release mode) section causes the ice to disappear.
That's even weirder. Seems like this is partly an incr-comp bug then.
Note that the ICE occurs in the incr-comp hasher (ICH): So this seems to be an incr-comp bug.
Reposting : So I removed .
Code change:
<ins> error[E0599]: no method named `some_function` found for struct `SmallVec` in the current scope --> $DIR/hash-tyvid-regression-3.rs:17:19 | LL |         node.keys.some_function(); |                   ^^^^^^^^^^^^^ method not found in `SmallVec<{ D * 2 }>` ... LL | struct SmallVec<const D: usize> {} | ------------------------------- method `some_function` not found for this error: aborting due to previous error For more information about this error, try `rustc --explain E0599`. </ins>

Related discussion:
text: <!-- 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<details<summary<strongQuery Stack</strong</summary<p</p</details
modify labels to +requires-nightly
The following snippet gives the same ICE. The types are intentionally wrong. <details<summary<strongBacktrace</strong</summary<p</p</details<details<summary<strongQuery Stack</strong</summary<p</p</details
Triage: This is now fixed on the recent nightly, marking as E-needs-test.
Code change:
<ins> warning: unnecessary parentheses around function argument --> $DIR/try-block-unused-delims.rs:10:13 | LL |     consume((try {})); |             ^^^^^^^^ help: remove these parentheses | note: the lint level is defined here --> $DIR/try-block-unused-delims.rs:5:9 | LL | #![warn(unused_parens, unused_braces)] |         ^^^^^^^^^^^^^ warning: unnecessary braces around function argument --> $DIR/try-block-unused-delims.rs:13:13 | LL |     consume({ try {} }); |             ^^^^^^^^^^ help: remove these braces | note: the lint level is defined here --> $DIR/try-block-unused-delims.rs:5:24 | LL | #![warn(unused_parens, unused_braces)] |                        ^^^^^^^^^^^^^ warning: unnecessary parentheses around `match` scrutinee expression --> $DIR/try-block-unused-delims.rs:16:11 | LL |     match (try {}) { |           ^^^^^^^^ help: remove these parentheses warning: unnecessary parentheses around `let` scrutinee expression --> $DIR/try-block-unused-delims.rs:21:22 | LL |     if let Err(()) = (try {}) {} |                      ^^^^^^^^ help: remove these parentheses warning: unnecessary parentheses around `match` scrutinee expression --> $DIR/try-block-unused-delims.rs:24:11 | LL |     match (try {}) { |           ^^^^^^^^ help: remove these parentheses warning: 5 warnings emitted </ins>

Related discussion:
text: This produces a lint: But removing the parentheses produces an error. This bug was already mentioned in , but that issue is lost in feature-request purgatory since it asks for the version without parentheses to be allowed. I'm opening this issue to track the incorrect lint specifically. (Edit: Fixed the example.) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim Will wait for to get merged before this is fixed though.
Code change:
<ins> warning: unnecessary parentheses around function argument --> $DIR/try-block-unused-delims.rs:10:13 | LL |     consume((try {})); |             ^^^^^^^^ help: remove these parentheses | note: the lint level is defined here --> $DIR/try-block-unused-delims.rs:5:9 | LL | #![warn(unused_parens, unused_braces)] |         ^^^^^^^^^^^^^ warning: unnecessary braces around function argument --> $DIR/try-block-unused-delims.rs:13:13 | LL |     consume({ try {} }); |             ^^^^^^^^^^ help: remove these braces | note: the lint level is defined here --> $DIR/try-block-unused-delims.rs:5:24 | LL | #![warn(unused_parens, unused_braces)] |                        ^^^^^^^^^^^^^ warning: unnecessary parentheses around `match` scrutinee expression --> $DIR/try-block-unused-delims.rs:16:11 | LL |     match (try {}) { |           ^^^^^^^^ help: remove these parentheses warning: unnecessary parentheses around `let` scrutinee expression --> $DIR/try-block-unused-delims.rs:21:22 | LL |     if let Err(()) = (try {}) {} |                      ^^^^^^^^ help: remove these parentheses warning: unnecessary parentheses around `match` scrutinee expression --> $DIR/try-block-unused-delims.rs:24:11 | LL |     match (try {}) { |           ^^^^^^^^ help: remove these parentheses warning: 5 warnings emitted </ins>

Related discussion:
text: The following code fails to compile (): The compiler error is: Adding parentheses or braces, it will compile fine: The same issue happens with other constructs such as:
cc
I believe the error is expected here, the same as with : Which also needs to be to compile. That said, the warning to remove the necessary parens is definitely wrong. EDIT: Hmm, I might be wrong, actually. The following compiles, which surprised me: as does this: So maybe the parser restriction is only for struct literals, not for keyword-introduced expressions.
Yeah I think is the better comparison here so it's probably a bug.
This is exactly what a thought. I didn't know that this:
For , hmmm... well, I can't come up with a truly devastating example, but eliminating the parentheses could hurt diagnostics.
Code change:
} // Visit everything except for private impl items. hir::ItemKind::Impl(ref impl_) => { <del> for impl_item_ref in impl_.items { if impl_.of_trait.is_some() || self.tcx.visibility(impl_item_ref.id.def_id) == ty::Visibility::Public { self.update(impl_item_ref.id.def_id, item_level); } } </del> if item_level.is_some() { self.reach(item.def_id, item_level).generics().predicates().ty().trait_ref();

Related discussion:
text: EDIT (ehuss) Reproduction: Clone <!-- 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 --
We are seeing this too on rustc 1.60.0-nightly ( 2022-01-10) running on aarch64-apple-darwin
label +I-prioritize
cc This seems to have regressed starting with .
I'm taking a look
I can reproduce and I did find some differences in the access level table. seems to be missing when it's supposed to be Reachable in the good version. I'll investigate further Updates: Actually, the whole Impl seems to be missing. It should be marked as Reachable but is not even there. claim
Marking as , as .
Same on Mac, on x86_64-apple-darwin as well, same toolchain version (rustc 1.60.0-nightly ( 2022-01-10))
As an update for those watching: currently, the best workaround is to use an older nightly. The good news is that a fix PR is open (), with people working on getting it in shape to be merged.
Code change:
pub(crate) no_emit_shared: bool, /// If `true`, HTML source code pages won't be generated. pub(crate) html_no_source: bool, <del> /// Whether `-Zforce-unstable-if-unmarked` unstable option is set pub(crate) force_unstable_if_unmarked: bool, </del> } #[derive(Copy, Clone, Debug, PartialEq, Eq)]

Related discussion:
text: for example lists implementations of in , which aren't visible anyway and the links are also broken.
Not present in the docs for 1.77.2, regression?
cc getting multiple reports of this:
I believe this regressed in (
This was closed but it's still happening on current stable docs, in various traits, Debug being the one that seems the worst: ! !
What page are you looking at? I do not see those implementations on
stable docs, not nightly I understand this was reported the day 1.78.0 was released and 1.79.0 isn't due for a few weeks more, but I feel it should be possible to apply the fix to the current stable docs at least as published on rust- in the meantime
The stable docs are tied to the release, so we would have to make a new release to update them. The fix for this is in 1.80, and will reach stable on July 25.
There's no way to backport it internally? That's unfortunate. I was hoping it would land for 1.79.0 at least
Closing then.
This can in fact be beta backported.
And it was in
Good to know, thank you
Code change:
.collect::<Vec<_>>() .into(), id: fld.new_id(id), <del> ident: ident, </del> <ins> ident: fld.fold_ident(ident), </ins> bounds: fld.fold_bounds(bounds), default: default.map(|x| fld.fold_ty(x)), span: span

Related discussion:
text: Test case: Compiles successfully on , causes an ICE on . Diff contains only , CC Found while trying to minimize , but filed separately since the error message is different and this one has a small test case.
Do you have a backtrace?
Yes of course. Sorry I forgot to include it: rust error: internal compiler error: attempted .defid() on invalid def: Err note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: run with for a backtrace thread 'rustc' panicked at 'Box<Any',
Code change:
.collect::<Vec<_>>() .into(), id: fld.new_id(id), <del> ident: ident, </del> <ins> ident: fld.fold_ident(ident), </ins> bounds: fld.fold_bounds(bounds), default: default.map(|x| fld.fold_ty(x)), span: span

Related discussion:
text: stack backtrace: 1: 0x7fc35e73fdf3 - std::sys::imp::backtrace::tracing::imp::write::hdfa3e34b856f69a3 2: 0x7fc35e74e5dd - std::panicking::defaulthook::{{closure}}::h20f8c1082e0ce86e 3: 0x7fc35e74e17b - std::panicking::defaulthook::hd31552ac08c2a241 4: 0x7fc35e74ea68 - std::panicking::rustpanicwithhook::h73969d230a072c1a 5: 0x7fc357eda667 - std::panicking::beginpanic::hb89a2261f4776ce3 6: 0x7fc357eef99f - rustcerrors::Handler::bug::h13b3b29154320abd 7: 0x7fc35bab053a - rustc::session::optspanbugfmt::{{closure}}::hfea18dd68f59976d 8: 0x7fc35baafff7 - rustc::session::optspanbugfmt::h7d370a0810dbdbbd 9: 0x7fc35baafce2 - rustc::session::bugfmt::hcde5f50c54004a4f 10: 0x7fc35b984552 - rustc::hir::def::Def::defid::h728c22aafbe84efc 11: 0x7fc35c6ddb3a - rustcprivacy::ObsoleteVisiblePrivateTypesVisitor::pathisprivatetype::h24756a49a68d1da9 12: 0x7fc35c6d53db - rustc::hir::intravisit::walkty::h64b13c0c45b7a09a 13: 0x7fc35c6d49ba - rustc::hir::intravisit::Visitor::visitfn::ha8ad665c42b1d643 14: 0x7fc35c6de7cf - <rustcprivacy::ObsoleteVisiblePrivateTypesVisitor<'a,
Code change:
.collect::<Vec<_>>() .into(), id: fld.new_id(id), <del> ident: ident, </del> <ins> ident: fld.fold_ident(ident), </ins> bounds: fld.fold_bounds(bounds), default: default.map(|x| fld.fold_ty(x)), span: span

Related discussion:
text: 'tcxas rustc::hir::intravisit::Visitor<'tcx::visititem::hae9f32c7942ccca1 15: 0x7fc35c6deab5 - <rustcprivacy::ObsoleteVisiblePrivateTypesVisitor<'a, 'tcxas rustc::hir::intravisit::Visitor<'tcx::visititem::hae9f32c7942ccca1 16: 0x7fc35c6e1b7a - rustcprivacy::checkcrate::h5ba75e3c4ebe0690 17: 0x7fc35eaef747 - rustcdriver::driver::phase3runanalysispasses::{{closure}}::h388b9236cf305089 18: 0x7fc35ead66d6 - rustcdriver::driver::phase3runanalysispasses::h080c1a734c4f2909 19: 0x7fc35eac5425 - rustcdriver::driver::compileinput::hab55539b85c4ceed 20: 0x7fc35eb0ea51 - rustcdriver::runcompiler::h128b89b79f649304 21: 0x7fc35ea236fb - std::panicking::try::docall::h15bca94dda232804 22: 0x7fc35e757b06 - rustmaybecatchpanic 23: 0x7fc35ea44d01 - <F as alloc::boxed::FnBox<A::callbox::h8832766c4bda585b 24: 0x7fc35e74d470 - std::sys::imp::thread::Thread::new::threadstart::h7d03d727f96da002 25: 0x7fc357684453 - startthread 26: 0x7fc35e4147de - GI__clone 27: 0x0 - <unknown
triage: P-high Seems bad. Assigning to based on bisection.
Fixed in .
Code change:
.collect::<Vec<_>>() .into(), id: fld.new_id(id), <del> ident: ident, </del> <ins> ident: fld.fold_ident(ident), </ins> bounds: fld.fold_bounds(bounds), default: default.map(|x| fld.fold_ty(x)), span: span

Related discussion:
text: Servo compiles with rustc 2016-12-18, but not with 2016-12-21. Diff: The crate fails to build with: The method being called here is: Its return type is which is . This call is in another impl of the same method of the same trait: Adding an explicit type annotation works around this error, but only to uncover another very similar one, then another. The third one was in code generated by serde’s , so I gave up that approach. So far I haven’t managed to reduce a test case smaller than "most of Servo", sorry. I’m suspicious of (which is part of ) because it’s commit message mentions inference. I’m not building a compiler to confirm.
CC
Also fails in , so is not to blame. New diff: I don’t have another guess, and doing a full bisect would take a very long time…
I can't find the cause in that range, at least nothing changed in the compiler AFAICT. Can you try (the commit before larger rollup)?
Expanding the macro: (Even simplifying it, this is not using ) gives:
Alright, that matches what I've seen from What about a couple more steps of bisecting? Or maybe compiling this crate with the "servo" feature off (which, AFAICT, turns off all the macros 1.1 - they might be responsible).
Swapping the order of the two arms: Changing the pattern to : Hacking to not use the stable version of the compiler (so effectively disabling the feature and enabling the one) also gives the same error.
New range, based on manual bisect: good, bad. Diff: , which leaves only in-between. CC Also found more clues. More context for the code where the error happens: is a module generated by a macro, that contains re-exports of other modules: If I add a similar not in a macro: or if I change the original code to use the real path without going through a , this seems to work around this issue completely. … only to uncover another one:
Found another ICE, I don’t know if it’s related: .
Code change:
.collect::<Vec<_>>() .into(), id: fld.new_id(id), <del> ident: ident, </del> <ins> ident: fld.fold_ident(ident), </ins> bounds: fld.fold_bounds(bounds), default: default.map(|x| fld.fold_ty(x)), span: span

Related discussion:
text: Found a smaller test case for the inference issue: rust fn main() {} pub mod a { pub struct FontFamily; impl FontFamily { pub fn tocss(&self) -::std::fmt::Result { Ok(()) } } } macrorules! reexport { () ={ mod b { pub use a; } } } reexport!(); pub mod c { use b::a::FontFamily; struct FontFace { family: FontFamily } impl FontFace { pub fn tocss(&self) -::std::fmt::Result { try!(()); Ok(()) } } }
That "other ICE" is actually a direct observation of the bug, whereas this inference issue is some weird side-effect of the way we handle errors that don't stop compilation.
never mind, apparently it fails locally
triage: P-high Seems bad. Assigning to based on bisection.
Does this affect beta ()?
At the moment the latest successful nightly build is 3 days old. I don’t know how often playpen’s nigthly is updated. merged 2 days ago. (This is the rollup PR that merged , which introduced this issue if I did my manual bisecting correctly.) As far as I can tell no, is not reachable from and so beta is not affected.
Fixed in .
Code change:
match tcx.const_eval(param_env.and(cid)) { Ok(&ty::Const { val: ConstVal::Value(Value::ByVal(PrimVal::Bytes(b))), <del> .. </del> <ins> ty, </ins> }) => { trace!("discriminants: {} ({:?})", b, repr_type); <del> let ty = repr_type.to_ty(tcx); if repr_type.is_signed() { let val = b as i128; // sign extend to i128 let amt = 128 - bit_size; let val = (val << amt) >> amt; Some(Discr { val: val as u128, ty, }) } else { Some(Discr { val: b, ty, }) } </del> <ins> Some(Discr { val: b, ty, }) </ins> }, Ok(&ty::Const { val: ConstVal::Value(other),

Related discussion:
text: I was trying to build which pulls in pango 0.1.3 as dependency . While building pango, rustc segfaults  meta: Crash happens in So apparently const eval produces a discriminant that doesn't match any variant's discriminant. more concretely, it happens during a match on which is the only discriminant with as its value.
weird, I am still getting the panic with todays nightly :(
Same backtrace? We do have a regression test for this exact issue
Yeah, backtrace is identical except for the rustc version string in the ICE notes. :/
Fix confirmed, thanks!
Code change:
"once_cell", "opener", "pretty_assertions", <ins> "semver", </ins> "serde", "serde_derive", "serde_json",

Related discussion:
text: I'm trying to build Rust on a Tier 3 platform (; actually it's that's listed in Tier 3, but I don't think that affects the problem). Since there are no snapshots for this platform, I installed rustc from the distro's package manager (apk) and created a file to force using the pre-installed rustc rather than downloading snapshots: And the output of : I ran ; when it got as far as building the core library, I got a series of errors that were very hard to make sense of until I realized that it's because core library code depends on unstable features and I was using a stable rustc to compile it: There were many more errors, but I think they all relate to unstable features. It took me ages to figure out that (for example) the first error is due to the feature being disabled in stable. I understand that the stable compiler won't allow using unstable features even with , but is it possible for the parser to recognize this code even so and reject it with something like "feature is not enabled" instead of the much more generic "expected identifier" error?
Huh, usually Rust gets around this by setting , and usually when we bootstrap it's with a beta compiler, which does need that set by , and that would allow all the features. I wonder if wasn't set?
It's set, but the command that's actually failing (it took some effort to figure out which executable was actually failing) is: And what's installed for me in is a stable compiler. I realized after the fact that I can't use it to bootstrap, but with a different error message I might have noticed that sooner.
Forwards compatibility in diagnostics seems extremely hard. I think a much simpler and more helpful fix is to check the output of in bootstrap and give a hard error if it's not either the current version or N-1.
Note that the problem here is that you were trying to use 1.68 to build 1.70; it's unrelated to stable vs beta, the problem is that it was two versions behind instead of only one.
Mentoring instructions: in , if is set, run that process with . Compare that output to the contents of using the crate; if the minor versions aren't either the same or 1 apart, give a hard error. Note that this should also disallow e.g.
Code change:
"once_cell", "opener", "pretty_assertions", <ins> "semver", </ins> "serde", "serde_derive", "serde_json",

Related discussion:
text: building 1.68 with 1.69; we use deny-warnings in most cases and have no guarantees that unstable features will be the same between releases. Only building 1.68 with 1.67 or 1.68 should be allowed.
btw I've noticed you running into a few different bootstrap bugs the past few days — reading through https://rustc-dev- may or may not make it easier to diagnose these issues without having to spend ages interpreting the diagnostics. I'm also happy to chat about "how should this work" sorts of things .
Yes, I've read that. Thanks!
The error message could be improved though. Maybe one could make the to put into libcore/bootstrap's
I don't think rust-version is a good way to solve this, no - that won't give a warning or error if you use a future version to compile an older version. Also it won't be able to catch local-rebuild issues where the nightly version of the bootstrap compiler is too old. See my suggestion in
Hmm, I'm afraid I might have said something unclear. I'm not asking for forward compatibility in diagnostics. The feature was in version 1.68.0, according to , and I was using rustc version 1.68.2. So it should "know" about that feature, but my understanding is that when I was invoking rustc it was with flags that prevent unstable features from being used.
hmm, in that case something strange is going on because playground gives a much more reasonable error than the one you saw:
what commit of rustc were you trying to build when you got this error? I'm going to see if I can replicate it locally.
I was trying to build .
Ah ok, it was related to the context of the closure: If you look at the same gist with beta, the error message is much better: So I think this particular diagnostic issue has already been fixed. I still want to keep this issue open to track checking the version of the bootstrap compiler, though.
Code change:
use abi::Abi; use ast::{self, Ident, Generics, Expr, BlockCheckMode, UnOp, PatKind}; use attr; <del> use syntax_pos::{Span, DUMMY_SP, Pos}; </del> <ins> use syntax_pos::{Span, DUMMY_SP}; </ins> use codemap::{dummy_spanned, respan, Spanned}; use ext::base::ExtCtxt; use ptr::P;

Related discussion:
text: cc , There are no guarantees that the two spans used to create the new one come from the same place or are even valid.