Question:
See below:
Reduced to only use the task proc-macro: It seems important, that Foo isn't defined, if I define a , the ICE goes away.
searched nightlies: from nightly-2020-06-01 to nightly-2021-01-01 regressed nightly: nightly-2020-10-27 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: </detailsI'm pretty sure that isn't at fault here, but instead it just uncovers the problem.
MCVE:
Panic location:

<ins> error[E0425]: cannot find value `Foo` in this scope --> $DIR/layout-error.rs:21:17 | LL |         let a = Foo; |                 ^^^ not found in this scope error: aborting due to previous error For more information about this error, try `rustc --explain E0425`. </ins>


Question:
Just encountered the following output: It would be nice if we could peek at the fields of and provide an appropriate structured suggestion: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim

debug!("exp_found {:?} terr {:?}", exp_found, terr); if let Some(exp_found) = exp_found { self.suggest_as_ref_where_appropriate(span, &exp_found, diag); <ins> self.suggest_accessing_field_where_appropriate(cause, &exp_found, diag); </ins> self.suggest_await_on_expect_found(cause, span, &exp_found, diag); }


Question:
Just encountered the following output: It would be nice if we could peek at the fields of and provide an appropriate structured suggestion: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim

} } <ins> fn suggest_accessing_field_where_appropriate( &self, cause: &ObligationCause<'tcx>, exp_found: &ty::error::ExpectedFound<Ty<'tcx>>, diag: &mut DiagnosticBuilder<'tcx>, ) { debug!( "suggest_accessing_field_where_appropriate(cause={:?}, exp_found={:?})", cause, exp_found ); if let ty::Adt(expected_def, expected_substs) = exp_found.expected.kind() { if expected_def.is_enum() { return; } if let Some((name, ty)) = expected_def .non_enum_variant() .fields .iter() .filter(|field| field.vis.is_accessible_from(field.did, self.tcx)) .map(|field| (field.ident.name, field.ty(self.tcx, expected_substs))) .find(|(_, ty)| ty::TyS::same_type(ty, exp_found.found)) { if let ObligationCauseCode::Pattern { span: Some(span), .. } = cause.code { if let Ok(snippet) = self.tcx.sess.source_map().span_to_snippet(span) { let suggestion = if expected_def.is_struct() { format!("{}.{}", snippet, name) } else if expected_def.is_union() { format!("unsafe {{ {}.{} }}", snippet, name) } else { return; }; diag.span_suggestion( span, &format!( "you might have meant to use field `{}` of type `{}`", name, ty ), suggestion, Applicability::MaybeIncorrect, ); } } } } } </ins> /// When encountering a case where `.as_ref()` on a `Result` or `Option` would be appropriate, /// suggests it. fn suggest_as_ref_where_appropriate(


Question:
Just encountered the following output: It would be nice if we could peek at the fields of and provide an appropriate structured suggestion: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim

<ins> // run-rustfix #![allow(dead_code)] struct A { b: B, } enum B { Fst, Snd, } union Foo { bar: u32, qux: f32, } fn main() { let a = A { b: B::Fst }; if let B::Fst = a.b {}; //~ ERROR mismatched types [E0308] //~^ HELP you might have meant to use field `b` of type `B` match a.b { //~^ HELP you might have meant to use field `b` of type `B` //~| HELP you might have meant to use field `b` of type `B` B::Fst => (), //~ ERROR mismatched types [E0308] B::Snd => (), //~ ERROR mismatched types [E0308] } let foo = Foo { bar: 42 }; match unsafe { foo.bar } { //~^ HELP you might have meant to use field `bar` of type `u32` 1u32 => (), //~ ERROR mismatched types [E0308] _ => (), } } </ins>


Question:
Just encountered the following output: It would be nice if we could peek at the fields of and provide an appropriate structured suggestion: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim

<ins> // run-rustfix #![allow(dead_code)] struct A { b: B, } enum B { Fst, Snd, } union Foo { bar: u32, qux: f32, } fn main() { let a = A { b: B::Fst }; if let B::Fst = a {}; //~ ERROR mismatched types [E0308] //~^ HELP you might have meant to use field `b` of type `B` match a { //~^ HELP you might have meant to use field `b` of type `B` //~| HELP you might have meant to use field `b` of type `B` B::Fst => (), //~ ERROR mismatched types [E0308] B::Snd => (), //~ ERROR mismatched types [E0308] } let foo = Foo { bar: 42 }; match foo { //~^ HELP you might have meant to use field `bar` of type `u32` 1u32 => (), //~ ERROR mismatched types [E0308] _ => (), } } </ins>


Question:
Just encountered the following output: It would be nice if we could peek at the fields of and provide an appropriate structured suggestion: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim

<ins> error[E0308]: mismatched types --> $DIR/field-access.rs:20:12 | LL |     Fst, |     --- unit variant defined here ... LL |     if let B::Fst = a {}; |            ^^^^^^   - this expression has type `A` |            | |            expected struct `A`, found enum `B` | help: you might have meant to use field `b` of type `B` | LL |     if let B::Fst = a.b {}; |                     ^^^ error[E0308]: mismatched types --> $DIR/field-access.rs:25:9 | LL |     Fst, |     --- unit variant defined here ... LL |     match a { |           - this expression has type `A` ... LL |         B::Fst => (), |         ^^^^^^ expected struct `A`, found enum `B` | help: you might have meant to use field `b` of type `B` | LL |     match a.b { |           ^^^ error[E0308]: mismatched types --> $DIR/field-access.rs:26:9 | LL |     Snd, |     --- unit variant defined here ... LL |     match a { |           - this expression has type `A` ... LL |         B::Snd => (), |         ^^^^^^ expected struct `A`, found enum `B` | help: you might have meant to use field `b` of type `B` | LL |     match a.b { |           ^^^ error[E0308]: mismatched types --> $DIR/field-access.rs:32:9 | LL |     match foo { |           --- this expression has type `Foo` LL | LL |         1u32 => (), |         ^^^^ expected union `Foo`, found `u32` | help: you might have meant to use field `bar` of type `u32` | LL |     match unsafe { foo.bar } { |           ^^^^^^^^^^^^^^^^^^ error: aborting due to 4 previous errors For more information about this error, try `rustc --explain E0308`. </ins>


Question:
Given a situation where an iterator is : We should suggest using in these cases. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Or flatten/flat_map?
I want for us to detect cases of trying to operate on iterators of iterators because the only option then is to allocate or completely rework the logic. The former will help newcomers, experts will know enough to try the later.
claim
Couldn't we still recommend both? Recommending bad practices seems suboptimal.

FakeReadCause, Local, LocalDecl, LocalInfo, LocalKind, Location, Operand, Place, PlaceRef, ProjectionElem, Rvalue, Statement, StatementKind, Terminator, TerminatorKind, VarBindingForm, }; <del> use rustc_middle::ty::{self, suggest_constraining_type_param, Instance, Ty}; use rustc_span::{source_map::DesugaringKind, symbol::sym, Span}; </del> <ins> use rustc_middle::ty::{self, suggest_constraining_type_param, Ty, TypeFoldable}; use rustc_span::source_map::DesugaringKind; use rustc_span::symbol::sym; use rustc_span::Span; </ins> use crate::dataflow::drop_flag_effects; use crate::dataflow::indexes::{MoveOutIndex, MovePathIndex}; use crate::util::borrowck_errors; use crate::borrow_check::{ <del> borrow_set::BorrowData, prefixes::IsPrefixOf, InitializationRequiringAction, MirBorrowckCtxt, PrefixSet, WriteKind, </del> <ins> borrow_set::BorrowData, diagnostics::Instance, prefixes::IsPrefixOf, InitializationRequiringAction, MirBorrowckCtxt, PrefixSet, WriteKind, </ins> }; use super::{


Question:
Given a situation where an iterator is : We should suggest using in these cases. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Or flatten/flat_map?
I want for us to detect cases of trying to operate on iterators of iterators because the only option then is to allocate or completely rework the logic. The former will help newcomers, experts will know enough to try the later.
claim
Couldn't we still recommend both? Recommending bad practices seems suboptimal.

if return_span != borrow_span { err.span_label(borrow_span, note); <ins> let tcx = self.infcx.tcx; let ty_params = ty::List::empty(); let return_ty = self.regioncx.universal_regions().unnormalized_output_ty; let return_ty = tcx.erase_regions(return_ty); // to avoid panics if !return_ty.has_infer_types() { if let Some(iter_trait) = tcx.get_diagnostic_item(sym::Iterator) { if tcx.type_implements_trait((iter_trait, return_ty, ty_params, self.param_env)) { if let Ok(snippet) = tcx.sess.source_map().span_to_snippet(return_span) { err.span_suggestion_hidden( return_span, "use `.collect()` to allocate the iterator", format!("{}{}", snippet, ".collect::<Vec<_>>()"), Applicability::MaybeIncorrect, ); } } } } </ins> } Some(err)


Question:
Given a situation where an iterator is : We should suggest using in these cases. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Or flatten/flat_map?
I want for us to detect cases of trying to operate on iterators of iterators because the only option then is to allocate or completely rework the logic. The former will help newcomers, experts will know enough to try the later.
claim
Couldn't we still recommend both? Recommending bad practices seems suboptimal.

message = "`{Self}` is not an iterator" )] #[doc(spotlight)] <ins> #[rustc_diagnostic_item = "Iterator"] </ins> #[must_use = "iterators are lazy and do nothing unless consumed"] pub trait Iterator { /// The type of the elements being iterated over.


Question:
Given a situation where an iterator is : We should suggest using in these cases. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Or flatten/flat_map?
I want for us to detect cases of trying to operate on iterators of iterators because the only option then is to allocate or completely rework the logic. The former will help newcomers, experts will know enough to try the later.
claim
Couldn't we still recommend both? Recommending bad practices seems suboptimal.

<ins> // run-rustfix fn main() { let _ = vec![vec![0, 1], vec![2]] .into_iter() .map(|y| y.iter().map(|x| x + 1).collect::<Vec<_>>()) //~^ ERROR cannot return value referencing function parameter `y` .collect::<Vec<_>>(); } </ins>


Question:
Given a situation where an iterator is : We should suggest using in these cases. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Or flatten/flat_map?
I want for us to detect cases of trying to operate on iterators of iterators because the only option then is to allocate or completely rework the logic. The former will help newcomers, experts will know enough to try the later.
claim
Couldn't we still recommend both? Recommending bad practices seems suboptimal.

<ins> // run-rustfix fn main() { let _ = vec![vec![0, 1], vec![2]] .into_iter() .map(|y| y.iter().map(|x| x + 1)) //~^ ERROR cannot return value referencing function parameter `y` .collect::<Vec<_>>(); } </ins>


Question:
Given a situation where an iterator is : We should suggest using in these cases. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Or flatten/flat_map?
I want for us to detect cases of trying to operate on iterators of iterators because the only option then is to allocate or completely rework the logic. The former will help newcomers, experts will know enough to try the later.
claim
Couldn't we still recommend both? Recommending bad practices seems suboptimal.

<ins> error[E0515]: cannot return value referencing function parameter `y` --> $DIR/issue-81584.rs:5:22 | LL |             .map(|y| y.iter().map(|x| x + 1)) |                      -^^^^^^^^^^^^^^^^^^^^^^ |                      | |                      returns a value referencing data owned by the current function |                      `y` is borrowed here | = help: use `.collect()` to allocate the iterator error: aborting due to previous error For more information about this error, try `rustc --explain E0515`. </ins>


Question:
Given a situation where an iterator is : We should suggest using in these cases. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Or flatten/flat_map?
I want for us to detect cases of trying to operate on iterators of iterators because the only option then is to allocate or completely rework the logic. The former will help newcomers, experts will know enough to try the later.
claim
Couldn't we still recommend both? Recommending bad practices seems suboptimal.

| |                   ------------------------------ temporary value created here LL | |     } | |_____^ returns a value referencing data owned by the current function <ins> | = help: use `.collect()` to allocate the iterator </ins> error: aborting due to 4 previous errors


Question:
The LLDB provider for hash maps has been broken since . Repro: Run this, notice that it doesn't print any values for the hash map: Using an older version works (1.49 or earler): I don't understand the motivation for , as you can see the older versions are able to display the type. can you clarify what is going on? I did some debugging, and the and values are invalid. Another way to check this is to run the  test. Due to it hasn't been running on CI. It has a check for the following output: But the actual output is:
I checked the issue with two different LLDB: shipped with LLDB built from LLVM 10.0.1 sources with Rust patches by adding the following code to the method: So it seems like the problem only occurs with . Probably this is due to the lack of Rust patches in . AFAIU the Rust patches still have not been to (I remember this related issue ). To fix this problem, the following code should be used insted: I've opened a PR with these changes: However, I believe that should use Rust patches not only to avoid this specific problem but to provide a much better debugging experience, with proper type rendering (e.g. instead of ), some expression evaluation support, and so forth. It is really unfortunate that Rust debugging support is not maintained enough except for some independent forks, for example, and CLion's LLDB.
I may be misunderstanding you, but is just a that runs the system lldb. Building lldb with patches was removed a long time ago (), and I suspect is not coming back in the foreseeable future.
Oh, that's even worse since macOS LLDB has very poor Rust support. I believe that debugging support is crucial for any compiled programming language, surely including Rust. So it would be really great to consider shipping rust-enabled LLDB and, more importantly, to maintain and improve Rust support in both GDB and LLDB.

ctrl = table.GetChildMemberWithName("ctrl").GetChildAtIndex(0) self.size = table.GetChildMemberWithName("items").GetValueAsUnsigned() <del> self.pair_type = table.type.template_args[0].GetTypedefedType() </del> <ins> self.pair_type = table.type.template_args[0] if self.pair_type.IsTypedefType(): self.pair_type = self.pair_type.GetTypedefedType() </ins> self.pair_type_size = self.pair_type.GetByteSize() self.new_layout = not table.GetChildMemberWithName("data").IsValid()


Question:
Hi, When running doc-tests with the latest Nightly on my crate, I get an ICE after the first doc-test is executed twice in a row. The issue does not occur on Stable. The issue seems to be caused when multiple threads are used for doc-tests. The ICE is caused by in . The issue occured on the and targets. Curiously, there are multiple targets on which it does not occur (according to Travic CI builds). The Travis CI build status is available here : . the repo for the ; commit ; either or . The actual number of threads does not seem to matter as long as there is more than one. In my case, specifying was not necessary, since I think the number of threads is determined automatically in this case. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
This is now a regression from stable to beta.
Bisection says the regression happened in . label -E-needs-bisection
cc do you have time to take a look?
It seems like the underlying problem is that it’s possible for different tests to collide to the same when macros are involved. Minimal example: /// asserteq!(1, 1); /// /// asserteq!(1, 1); /// Before , this produced and now it panics. We should fix the underlying problem, but a simple band-aid for beta would be to turn the into an . The only side effect would be that we don’t get the benefits of in the presence of these collisions.
I’ve submitted that workaround as .

} let mut completed_test = res.unwrap(); <del> let running_test = running_tests.remove(&completed_test.desc).unwrap(); if let Some(join_handle) = running_test.join_handle { if let Err(_) = join_handle.join() { if let TrOk = completed_test.result { completed_test.result = TrFailedMsg("panicked after reporting success".to_string()); </del> <ins> if let Some(running_test) = running_tests.remove(&completed_test.desc) { if let Some(join_handle) = running_test.join_handle { if let Err(_) = join_handle.join() { if let TrOk = completed_test.result { completed_test.result = TrFailedMsg("panicked after reporting success".to_string()); } </ins> } } }


Question:
The following is an attempted minimum reproducible sample that causes ICE. From a few minutes of experimentation, I wasn't able to further minimize the example, but I feel as if it should be possible (perhaps an example can be formed with just an async boundary and a mutex?). <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: Also saw the ICE on nightly, but I can't seem to get my instance of cargo to recognize the 1.52 toolchain. Testing on shows this still is present: The following outputs are the result of building on nightly playgound: <details<summary<strongBacktrace</strong</summary<p</p</details
Smaller:
Relevant code: So I think that just needs to be a .
I've actually been looking to contribute to Rust—would this be a good first issue to tackle?
This would definitely be a good first issue!

| GenericArgKind::Const(_), _, ) => { <del> // I *think* that HIR lowering should ensure this // doesn't happen, even in erroneous // programs. Else we should use delay-span-bug. span_bug!( </del> <ins> // HIR lowering sometimes doesn't catch this in erroneous // programs, so we need to use delay_span_bug here. See #82126. self.infcx.tcx.sess.delay_span_bug( </ins> hir_arg.span(), <del> "unmatched subst and hir arg: found {:?} vs {:?}", kind, hir_arg, </del> <ins> &format!("unmatched subst and hir arg: found {:?} vs {:?}", kind, hir_arg), </ins> ); } }


Question:
The following is an attempted minimum reproducible sample that causes ICE. From a few minutes of experimentation, I wasn't able to further minimize the example, but I feel as if it should be possible (perhaps an example can be formed with just an async boundary and a mutex?). <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: Also saw the ICE on nightly, but I can't seem to get my instance of cargo to recognize the 1.52 toolchain. Testing on shows this still is present: The following outputs are the result of building on nightly playgound: <details<summary<strongBacktrace</strong</summary<p</p</details
Smaller:
Relevant code: So I think that just needs to be a .
I've actually been looking to contribute to Rust—would this be a good first issue to tackle?
This would definitely be a good first issue!

<ins> // Regression test for #82126. Checks that mismatched lifetimes and types are // properly handled. // edition:2018 use std::sync::Mutex; struct MarketMultiplier {} impl MarketMultiplier { fn buy(&mut self) -> &mut usize { todo!() } } async fn buy_lock(generator: &Mutex<MarketMultiplier>) -> LockedMarket<'_> { //~^ ERROR this struct takes 0 lifetime arguments but 1 lifetime argument was supplied //~^^ ERROR this struct takes 1 type argument but 0 type arguments were supplied LockedMarket(generator.lock().unwrap().buy()) //~^ ERROR cannot return value referencing temporary value } struct LockedMarket<T>(T); fn main() {} </ins>


Question:
The following is an attempted minimum reproducible sample that causes ICE. From a few minutes of experimentation, I wasn't able to further minimize the example, but I feel as if it should be possible (perhaps an example can be formed with just an async boundary and a mutex?). <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: Also saw the ICE on nightly, but I can't seem to get my instance of cargo to recognize the 1.52 toolchain. Testing on shows this still is present: The following outputs are the result of building on nightly playgound: <details<summary<strongBacktrace</strong</summary<p</p</details
Smaller:
Relevant code: So I think that just needs to be a .
I've actually been looking to contribute to Rust—would this be a good first issue to tackle?
This would definitely be a good first issue!

<ins> error[E0107]: this struct takes 0 lifetime arguments but 1 lifetime argument was supplied --> $DIR/issue-82126-mismatched-subst-and-hir.rs:16:59 | LL | async fn buy_lock(generator: &Mutex<MarketMultiplier>) -> LockedMarket<'_> { |                                                           ^^^^^^^^^^^^---- help: remove these generics |                                                           | |                                                           expected 0 lifetime arguments | note: struct defined here, with 0 lifetime parameters --> $DIR/issue-82126-mismatched-subst-and-hir.rs:23:8 | LL | struct LockedMarket<T>(T); |        ^^^^^^^^^^^^ error[E0107]: this struct takes 1 type argument but 0 type arguments were supplied --> $DIR/issue-82126-mismatched-subst-and-hir.rs:16:59 | LL | async fn buy_lock(generator: &Mutex<MarketMultiplier>) -> LockedMarket<'_> { |                                                           ^^^^^^^^^^^^ expected 1 type argument | note: struct defined here, with 1 type parameter: `T` --> $DIR/issue-82126-mismatched-subst-and-hir.rs:23:8 | LL | struct LockedMarket<T>(T); |        ^^^^^^^^^^^^ - help: add missing type argument | LL | async fn buy_lock(generator: &Mutex<MarketMultiplier>) -> LockedMarket<'_, T> { |                                                                          ^^^ error[E0515]: cannot return value referencing temporary value --> $DIR/issue-82126-mismatched-subst-and-hir.rs:19:5 | LL |     LockedMarket(generator.lock().unwrap().buy()) |     ^^^^^^^^^^^^^-------------------------^^^^^^^ |     |            | |     |            temporary value created here |     returns a value referencing data owned by the current function error: aborting due to 3 previous errors Some errors have detailed explanations: E0107, E0515. For more information about an error, try `rustc --explain E0107`. </ins>


Question:
After I see this spam in output: As I understand wants to run some third-party tool called (with ), but it actually runs the rustbuild's which doesn't support such command line use. (Also this expensive probing happens unconditionally when running any test, even it is not related to rustdoc.) Originally posted by in
I can't replicate this (specifically, confusing for ) on Linux. is on Windows and I think is too. Can you post what your PATH environment variable is?
Semicolons replaced with newlines for clarity: Interestingly a turns up nothing and attempting to run gives a not found as well. Is this something in the environment created by x.py?
This is indeed Windows only. This is the culprit: On windows, is : so PATH is expanded to include and . The strange thing is tidy isn't in either of those directories :confused: it's in (without ). Hopefully I can change this so that only commands that compiletest runs get this variable set, not compiletest itself. If not, maybe I could just rename the binary.
I think I figured it out. The tidy that's being run is in buildx86_64-pc-windows-msvcstage0-tools-bin, which is the same location as That's how it's finding a tidy without one being anywhere in PATH.

fn run(self, builder: &Builder<'_>) -> Option<PathBuf> { let compiler = self.compiler; let target = self.target; <del> let tool = self.tool; </del> <ins> let mut tool = self.tool; </ins> let path = self.path; let is_optional_tool = self.is_optional_tool;


Question:
After I see this spam in output: As I understand wants to run some third-party tool called (with ), but it actually runs the rustbuild's which doesn't support such command line use. (Also this expensive probing happens unconditionally when running any test, even it is not related to rustdoc.) Originally posted by in
I can't replicate this (specifically, confusing for ) on Linux. is on Windows and I think is too. Can you post what your PATH environment variable is?
Semicolons replaced with newlines for clarity: Interestingly a turns up nothing and attempting to run gives a not found as well. Is this something in the environment created by x.py?
This is indeed Windows only. This is the culprit: On windows, is : so PATH is expanded to include and . The strange thing is tidy isn't in either of those directories :confused: it's in (without ). Hopefully I can change this so that only commands that compiletest runs get this variable set, not compiletest itself. If not, maybe I could just rename the binary.
I think I figured it out. The tidy that's being run is in buildx86_64-pc-windows-msvcstage0-tools-bin, which is the same location as That's how it's finding a tidy without one being anywhere in PATH.

None } } else { <ins> // HACK(#82501): on Windows, the tools directory gets added to PATH when running tests, and // compiletest confuses HTML tidy with the in-tree tidy. Name the in-tree tidy something // different so the problem doesn't come up. if tool == "tidy" { tool = "rust-tidy"; } </ins> let cargo_out = builder.cargo_out(compiler, self.mode, target).join(exe(tool, compiler.host)); let bin = builder.tools_dir(compiler).join(exe(tool, compiler.host));


Question:
After I see this spam in output: As I understand wants to run some third-party tool called (with ), but it actually runs the rustbuild's which doesn't support such command line use. (Also this expensive probing happens unconditionally when running any test, even it is not related to rustdoc.) Originally posted by in
I can't replicate this (specifically, confusing for ) on Linux. is on Windows and I think is too. Can you post what your PATH environment variable is?
Semicolons replaced with newlines for clarity: Interestingly a turns up nothing and attempting to run gives a not found as well. Is this something in the environment created by x.py?
This is indeed Windows only. This is the culprit: On windows, is : so PATH is expanded to include and . The strange thing is tidy isn't in either of those directories :confused: it's in (without ). Hopefully I can change this so that only commands that compiletest runs get this variable set, not compiletest itself. If not, maybe I could just rename the binary.
I think I figured it out. The tidy that's being run is in buildx86_64-pc-windows-msvcstage0-tools-bin, which is the same location as That's how it's finding a tidy without one being anywhere in PATH.

version = "0.1.0" authors = ["Alex Crichton <alex@alexcrichton.com>"] edition = "2018" <ins> autobins = false </ins> [dependencies] cargo_metadata = "0.11" regex = "1" lazy_static = "1" walkdir = "2" <ins> [[bin]] name = "rust-tidy" path = "src/main.rs" </ins>


Question:
I visited nightly-generated docs, e.g. With the dark and ayu themes, some texts appear black although they shouldn't. This includes: tab buttons in searches ("in names", "in parameters", "in return types") theme selection buttons, including those in the settings page IIRC this wasn't the case yesterday, so this must have regressed in today's nightly (2021-02-26)
I think this might be due to ? cc


Question:
While writing a SparseArray impl, I forgot a return on . This should_ be an error, but I got an ice instead. This fails with the expected on stable. playground: (Note that switching to stable resolves the ICE) <!-- 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. --:
label regression-from-stable-to-nightly
Bisection result searched nightlies: from nightly-2021-02-22 to nightly-2021-02-28 regressed nightly: nightly-2021-02-24 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: </details
Caused by :

use rustc_hir::{ExprKind, ItemKind, Node}; use rustc_infer::infer; use rustc_middle::lint::in_external_macro; <del> use rustc_middle::ty::{self, Ty}; </del> <ins> use rustc_middle::ty::{self, Binder, Ty}; </ins> use rustc_span::symbol::kw; use std::iter;


Question:
While writing a SparseArray impl, I forgot a return on . This should_ be an error, but I got an ice instead. This fails with the expected on stable. playground: (Note that switching to stable resolves the ICE) <!-- 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. --:
label regression-from-stable-to-nightly
Bisection result searched nightlies: from nightly-2021-02-22 to nightly-2021-02-28 regressed nightly: nightly-2021-02-24 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: </details
Caused by :

let found = self.resolve_vars_with_obligations(found); if let hir::FnRetTy::Return(ty) = fn_decl.output { let ty = AstConv::ast_ty_to_ty(self, ty); <ins> let ty = self.tcx.erase_late_bound_regions(Binder::bind(ty)); </ins> let ty = self.normalize_associated_types_in(expr.span, ty); if self.can_coerce(found, ty) { err.multipart_suggestion(


Question:
While writing a SparseArray impl, I forgot a return on . This should_ be an error, but I got an ice instead. This fails with the expected on stable. playground: (Note that switching to stable resolves the ICE) <!-- 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. --:
label regression-from-stable-to-nightly
Bisection result searched nightlies: from nightly-2021-02-22 to nightly-2021-02-28 regressed nightly: nightly-2021-02-24 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: </details
Caused by :

<ins> // Regression test for #82612. use std::marker::PhantomData; pub trait SparseSetIndex { fn sparse_set_index(&self) -> usize; } pub struct SparseArray<I, V = I> { values: Vec<Option<V>>, marker: PhantomData<I>, } impl<I: SparseSetIndex, V> SparseArray<I, V> { pub fn get_or_insert_with(&mut self, index: I, func: impl FnOnce() -> V) -> &mut V { let index = index.sparse_set_index(); if index < self.values.len() { let value = unsafe { self.values.get_unchecked_mut(index) }; value.get_or_insert_with(func) //~ ERROR mismatched types } unsafe { self.values.get_unchecked_mut(index).as_mut().unwrap() } } } fn main() {} </ins>


Question:
While writing a SparseArray impl, I forgot a return on . This should_ be an error, but I got an ice instead. This fails with the expected on stable. playground: (Note that switching to stable resolves the ICE) <!-- 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. --:
label regression-from-stable-to-nightly
Bisection result searched nightlies: from nightly-2021-02-22 to nightly-2021-02-28 regressed nightly: nightly-2021-02-24 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: </details
Caused by :

<ins> error[E0308]: mismatched types --> $DIR/issue-82612-return-mutable-reference.rs:18:13 | LL | /         if index < self.values.len() { LL | |             let value = unsafe { self.values.get_unchecked_mut(index) }; LL | |             value.get_or_insert_with(func) | |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `()`, found `&mut V` LL | |         } | |_________- expected this to be `()` | = note:      expected unit type `()` found mutable reference `&mut V` help: consider using a semicolon here | LL |             value.get_or_insert_with(func); |                                           ^ help: consider using a semicolon here | LL |         }; |          ^ help: you might have meant to return this value | LL |             return value.get_or_insert_with(func); |             ^^^^^^                               ^ error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>


Question:
From So not sure which way seems better? What do you think ?
Yeah I think we should document the new stuff and remove the docs for the deprecated stuff (perhaps mention that these deprecated features exist, but not document them in depth)
I've felt confused about this before: Why do we even let people customize which passes are run? That seems like unnecessary entanglement with rustdoc internals.
Also, there doesn't seem to be a flag. Are you thinking of ? If so, rustdoc says that's deprecated. Edit: It looks like is deprecated as well.
What is "the new stuff"? Do you mean things like ? Other than my confusion about that, I agree with Manish here. I think we should mention the deprecated features, but not document them extensively since they shouldn't be used anyway. If we extensively document deprecated features, we are wasting our time and our readers' time.
Yes. I do think the pass infra should stay mostly internal, with specific options being exposed via specific attributes. How we construct it internally should not be something the user should ever have to care about.

- [Documentation tests](documentation-tests.md) - [Linking to items by name](linking-to-items-by-name.md) - [Lints](lints.md) <del> - [Passes](passes.md) </del> - [Advanced features](advanced-features.md) - [Unstable features](unstable-features.md) <ins> - [Passes](passes.md) </ins> - [References](references.md)


Question:
From So not sure which way seems better? What do you think ?
Yeah I think we should document the new stuff and remove the docs for the deprecated stuff (perhaps mention that these deprecated features exist, but not document them in depth)
I've felt confused about this before: Why do we even let people customize which passes are run? That seems like unnecessary entanglement with rustdoc internals.
Also, there doesn't seem to be a flag. Are you thinking of ? If so, rustdoc says that's deprecated. Edit: It looks like is deprecated as well.
What is "the new stuff"? Do you mean things like ? Other than my confusion about that, I agree with Manish here. I think we should mention the deprecated features, but not document them extensively since they shouldn't be used anyway. If we extensively document deprecated features, we are wasting our time and our readers' time.
Yes. I do think the pass infra should stay mostly internal, with specific options being exposed via specific attributes. How we construct it internally should not be something the user should ever have to care about.

LLVM version: 3.9 ``` <del> ## `-r`/`--input-format`: input format This flag is currently ignored; the idea is that `rustdoc` would support various input formats, and you could specify them via this flag. Rustdoc only supports Rust source code and Markdown input formats. If the file ends in `.md` or `.markdown`, `rustdoc` treats it as a Markdown file. Otherwise, it assumes that the input file is Rust. ## `-w`/`--output-format`: output format This flag is currently ignored; the idea is that `rustdoc` would support various output formats, and you could specify them via this flag. Rustdoc only supports HTML output, and so this flag is redundant today. </del> ## `-o`/`--output`: output path Using this flag looks like this:


Question:
From So not sure which way seems better? What do you think ?
Yeah I think we should document the new stuff and remove the docs for the deprecated stuff (perhaps mention that these deprecated features exist, but not document them in depth)
I've felt confused about this before: Why do we even let people customize which passes are run? That seems like unnecessary entanglement with rustdoc internals.
Also, there doesn't seem to be a flag. Are you thinking of ? If so, rustdoc says that's deprecated. Edit: It looks like is deprecated as well.
What is "the new stuff"? Do you mean things like ? Other than my confusion about that, I agree with Manish here. I think we should mention the deprecated features, but not document them extensively since they shouldn't be used anyway. If we extensively document deprecated features, we are wasting our time and our readers' time.
Yes. I do think the pass infra should stay mostly internal, with specific options being exposed via specific attributes. How we construct it internally should not be something the user should ever have to care about.

as the `.rs` file. `--crate-name` lets you override this assumption with whatever name you choose. <ins> ## `--document-private-items`: Show items that are not public Using this flag looks like this: ```bash $ rustdoc src/lib.rs --document-private-items ``` By default, `rustdoc` only documents items that are publicly reachable. ```rust pub fn public() {} // this item is public and will documented mod private { // this item is private and will not be documented pub fn unreachable() {} // this item is public, but unreachable, so it will not be documented } ``` `--document-private-items` documents all items, even if they're not public. </ins> ## `-L`/`--library-path`: where to look for dependencies Using this flag looks like this:


Question:
From So not sure which way seems better? What do you think ?
Yeah I think we should document the new stuff and remove the docs for the deprecated stuff (perhaps mention that these deprecated features exist, but not document them in depth)
I've felt confused about this before: Why do we even let people customize which passes are run? That seems like unnecessary entanglement with rustdoc internals.
Also, there doesn't seem to be a flag. Are you thinking of ? If so, rustdoc says that's deprecated. Edit: It looks like is deprecated as well.
What is "the new stuff"? Do you mean things like ? Other than my confusion about that, I agree with Manish here. I think we should mention the deprecated features, but not document them extensively since they shouldn't be used anyway. If we extensively document deprecated features, we are wasting our time and our readers' time.
Yes. I do think the pass infra should stay mostly internal, with specific options being exposed via specific attributes. How we construct it internally should not be something the user should ever have to care about.

The arguments to this flag are the same as those for the `-C` flag on rustc. Run `rustc -C help` to get the full list. <del> ## `--passes`: add more rustdoc passes Using this flag looks like this: ```bash $ rustdoc --passes list $ rustdoc src/lib.rs --passes strip-priv-imports ``` An argument of "list" will print a list of possible "rustdoc passes", and other arguments will be the name of which passes to run in addition to the defaults. For more details on passes, see [the chapter on them](passes.md). See also `--no-defaults`. ## `--no-defaults`: don't run default passes Using this flag looks like this: ```bash $ rustdoc src/lib.rs --no-defaults ``` By default, `rustdoc` will run several passes over your code. This removes those defaults, allowing you to use `--passes` to specify exactly which passes you want. For more details on passes, see [the chapter on them](passes.md). See also `--passes`. </del> ## `--test`: run code examples as tests Using this flag looks like this:


Question:
From So not sure which way seems better? What do you think ?
Yeah I think we should document the new stuff and remove the docs for the deprecated stuff (perhaps mention that these deprecated features exist, but not document them in depth)
I've felt confused about this before: Why do we even let people customize which passes are run? That seems like unnecessary entanglement with rustdoc internals.
Also, there doesn't seem to be a flag. Are you thinking of ? If so, rustdoc says that's deprecated. Edit: It looks like is deprecated as well.
What is "the new stuff"? Do you mean things like ? Other than my confusion about that, I agree with Manish here. I think we should mention the deprecated features, but not document them extensively since they shouldn't be used anyway. If we extensively document deprecated features, we are wasting our time and our readers' time.
Yes. I do think the pass infra should stay mostly internal, with specific options being exposed via specific attributes. How we construct it internally should not be something the user should ever have to care about.

command line options from it. These options are one per line; a blank line indicates an empty option. The file can use Unix or Windows style line endings, and must be encoded as UTF-8. <ins> ## `--passes`: add more rustdoc passes This flag is **deprecated**. For more details on passes, see [the chapter on them](passes.md). ## `--no-defaults`: don't run default passes This flag is **deprecated**. For more details on passes, see [the chapter on them](passes.md). ## `-r`/`--input-format`: input format This flag is **deprecated** and **has no effect**. Rustdoc only supports Rust source code and Markdown input formats. If the file ends in `.md` or `.markdown`, `rustdoc` treats it as a Markdown file. Otherwise, it assumes that the input file is Rust. </ins>


Question:
From So not sure which way seems better? What do you think ?
Yeah I think we should document the new stuff and remove the docs for the deprecated stuff (perhaps mention that these deprecated features exist, but not document them in depth)
I've felt confused about this before: Why do we even let people customize which passes are run? That seems like unnecessary entanglement with rustdoc internals.
Also, there doesn't seem to be a flag. Are you thinking of ? If so, rustdoc says that's deprecated. Edit: It looks like is deprecated as well.
What is "the new stuff"? Do you mean things like ? Other than my confusion about that, I agree with Manish here. I think we should mention the deprecated features, but not document them extensively since they shouldn't be used anyway. If we extensively document deprecated features, we are wasting our time and our readers' time.
Yes. I do think the pass infra should stay mostly internal, with specific options being exposed via specific attributes. How we construct it internally should not be something the user should ever have to care about.

Rustdoc has a concept called "passes". These are transformations that `rustdoc` runs on your documentation before producing its final output. <del> In addition to the passes below, check out the docs for these flags: </del> <ins> Customizing passes is **deprecated**. The available passes are not considered stable and may change in any release. </ins> <del> * [`--passes`](command-line-arguments.md#--passes-add-more-rustdoc-passes) * [`--no-defaults`](command-line-arguments.md#--no-defaults-dont-run-default-passes) ## Default passes By default, rustdoc will run some passes, namely: * `strip-hidden` * `strip-private` * `collapse-docs` * `unindent-comments` However, `strip-private` implies `strip-priv-imports`, and so effectively, all passes are run by default. ## `strip-hidden` This pass implements the `#[doc(hidden)]` attribute. When this pass runs, it checks each item, and if it is annotated with this attribute, it removes it from `rustdoc`'s output. Without this pass, these items will remain in the output. ## `unindent-comments` When you write a doc comment like this: ```rust,no_run /// This is a documentation comment. # fn f() {} ``` There's a space between the `///` and that `T`. That spacing isn't intended to be a part of the output; it's there for humans, to help separate the doc comment syntax from the text of the comment. This pass is what removes that space. The exact rules are left under-specified so that we can fix issues that we find. Without this pass, the exact number of spaces is preserved. ## `collapse-docs` With this pass, multiple `#[doc]` attributes are converted into one single documentation string. For example: ```rust,no_run #[doc = "This is the first line."] #[doc = "This is the second line."] # fn f() {} ``` Gets collapsed into a single doc string of ```text This is the first line. This is the second line. ``` ## `strip-private` This removes documentation for any non-public items, so for example: ```rust,no_run /// These are private docs. struct Private; /// These are public docs. pub struct Public; ``` This pass removes the docs for `Private`, since they're not public. This pass implies `strip-priv-imports`. ## `strip-priv-imports` This is the same as `strip-private`, but for `extern crate` and `use` statements instead of items. </del> <ins> In the past the most common use case for customizing passes was to omit the `strip-private` pass. You can do this more easily, and without risk of the pass being changed, by passing [`--document-private-items`](./unstable-features.md#--document-private-items). </ins>


Question:
From So not sure which way seems better? What do you think ?
Yeah I think we should document the new stuff and remove the docs for the deprecated stuff (perhaps mention that these deprecated features exist, but not document them in depth)
I've felt confused about this before: Why do we even let people customize which passes are run? That seems like unnecessary entanglement with rustdoc internals.
Also, there doesn't seem to be a flag. Are you thinking of ? If so, rustdoc says that's deprecated. Edit: It looks like is deprecated as well.
What is "the new stuff"? Do you mean things like ? Other than my confusion about that, I agree with Manish here. I think we should mention the deprecated features, but not document them extensively since they shouldn't be used anyway. If we extensively document deprecated features, we are wasting our time and our readers' time.
Yes. I do think the pass infra should stay mostly internal, with specific options being exposed via specific attributes. How we construct it internally should not be something the user should ever have to care about.

Public items that are not documented can be seen with the built-in `missing_docs` lint. Private items that are not documented can be seen with Clippy's `missing_docs_in_private_items` lint. <ins> ## `-w`/`--output-format`: output format When using [`--show-coverage`](https://doc.rust-lang.org/nightly/rustdoc/unstable-features.html#--show-coverage-get-statistics-about-code-documentation-coverage), passing `--output-format json` will display the coverage information in JSON format. For example, here is the JSON for a file with one documented item and one undocumented item: ```rust /// This item has documentation pub fn foo() {} pub fn no_documentation() {} ``` ```json {"no_std.rs":{"total":3,"with_docs":1,"total_examples":3,"with_examples":0}} ``` Note that the third item is the crate root, which in this case is undocumented. When not using `--show-coverage`, `--output-format json` emits documentation in the experimental [JSON format](https://github.com/rust-lang/rfcs/pull/2963). `--output-format html` has no effect, and is also accepted on stable toolchains. </ins> ### `--enable-per-target-ignores`: allow `ignore-foo` style filters for doctests Using this flag looks like this:


Question:
<!-- 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
This isn't really a bug, it's just that it has bad diagnostics because it uses , which is a perma-unstable attribute. I would recommend against reporting bugs that need attributes unless they cause unsoundness.
MCVE:
Should I exclude all test programs that have a line starting with ? Thanks.
I don't personally feel comfortable setting a policy that we'll never fix ICEs with attributes, but they are definitely less likely to be bugs than other ICEs. Note that this isn't sufficient to catch programs that have an attribute, you can have arbitrary macros that play with conditional compilation, like . Catching and will probably hit the common cases, though (you may want to also include inner attributes).

} impl Attribute { <ins> #[inline] </ins> pub fn has_name(&self, name: Symbol) -> bool { match self.kind { AttrKind::Normal(ref item, _) => item.path == name,


Question:
<!-- 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
This isn't really a bug, it's just that it has bad diagnostics because it uses , which is a perma-unstable attribute. I would recommend against reporting bugs that need attributes unless they cause unsoundness.
MCVE:
Should I exclude all test programs that have a line starting with ? Thanks.
I don't personally feel comfortable setting a policy that we'll never fix ICEs with attributes, but they are definitely less likely to be bugs than other ICEs. Note that this isn't sufficient to catch programs that have an attribute, you can have arbitrary macros that play with conditional compilation, like . Catching and will probably hit the common cases, though (you may want to also include inner attributes).

use rustc_middle::ty::query::Providers; use rustc_middle::ty::TyCtxt; <del> use rustc_ast::{Attribute, LitKind, NestedMetaItem}; </del> <ins> use rustc_ast::{Attribute, Lit, LitKind, NestedMetaItem}; </ins> use rustc_errors::{pluralize, struct_span_err}; use rustc_hir as hir; use rustc_hir::def_id::LocalDefId;


Question:
<!-- 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
This isn't really a bug, it's just that it has bad diagnostics because it uses , which is a perma-unstable attribute. I would recommend against reporting bugs that need attributes unless they cause unsoundness.
MCVE:
Should I exclude all test programs that have a line starting with ? Thanks.
I don't personally feel comfortable setting a policy that we'll never fix ICEs with attributes, but they are definitely less likely to be bugs than other ICEs. Note that this isn't sufficient to catch programs that have an attribute, you can have arbitrary macros that play with conditional compilation, like . Catching and will probably hit the common cases, though (you may want to also include inner attributes).

self.check_export_name(hir_id, &attr, span, target) } else if self.tcx.sess.check_name(attr, sym::rustc_args_required_const) { self.check_rustc_args_required_const(&attr, span, target, item) <ins> } else if self.tcx.sess.check_name(attr, sym::rustc_layout_scalar_valid_range_start) { self.check_rustc_layout_scalar_valid_range(&attr, span, target) } else if self.tcx.sess.check_name(attr, sym::rustc_layout_scalar_valid_range_end) { self.check_rustc_layout_scalar_valid_range(&attr, span, target) </ins> } else if self.tcx.sess.check_name(attr, sym::allow_internal_unstable) { self.check_allow_internal_unstable(hir_id, &attr, span, target, &attrs) } else if self.tcx.sess.check_name(attr, sym::rustc_allow_const_fn_unstable) {


Question:
<!-- 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
This isn't really a bug, it's just that it has bad diagnostics because it uses , which is a perma-unstable attribute. I would recommend against reporting bugs that need attributes unless they cause unsoundness.
MCVE:
Should I exclude all test programs that have a line starting with ? Thanks.
I don't personally feel comfortable setting a policy that we'll never fix ICEs with attributes, but they are definitely less likely to be bugs than other ICEs. Note that this isn't sufficient to catch programs that have an attribute, you can have arbitrary macros that play with conditional compilation, like . Catching and will probably hit the common cases, though (you may want to also include inner attributes).

} } <ins> fn check_rustc_layout_scalar_valid_range( &self, attr: &Attribute, span: &Span, target: Target, ) -> bool { if target != Target::Struct { self.tcx .sess .struct_span_err(attr.span, "attribute should be applied to a struct") .span_label(*span, "not a struct") .emit(); return false; } let list = match attr.meta_item_list() { None => return false, Some(it) => it, }; if matches!(&list[..], &[NestedMetaItem::Literal(Lit { kind: LitKind::Int(..), .. })]) { true } else { self.tcx .sess .struct_span_err(attr.span, "expected exactly one integer literal argument") .emit(); false } } </ins> /// Checks if `#[rustc_legacy_const_generics]` is applied to a function and has a valid argument. fn check_rustc_legacy_const_generics( &self,


Question:
<!-- 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
This isn't really a bug, it's just that it has bad diagnostics because it uses , which is a perma-unstable attribute. I would recommend against reporting bugs that need attributes unless they cause unsoundness.
MCVE:
Should I exclude all test programs that have a line starting with ? Thanks.
I don't personally feel comfortable setting a policy that we'll never fix ICEs with attributes, but they are definitely less likely to be bugs than other ICEs. Note that this isn't sufficient to catch programs that have an attribute, you can have arbitrary macros that play with conditional compilation, like . Catching and will probably hit the common cases, though (you may want to also include inner attributes).

<ins> #![feature(rustc_attrs)] #[rustc_layout_scalar_valid_range_start(u32::MAX)] //~ ERROR pub struct A(u32); #[rustc_layout_scalar_valid_range_end(1, 2)] //~ ERROR pub struct B(u8); #[rustc_layout_scalar_valid_range_end(a = "a")] //~ ERROR pub struct C(i32); #[rustc_layout_scalar_valid_range_end(1)] //~ ERROR enum E { X = 1, Y = 14, } fn main() { let _ = A(0); let _ = B(0); let _ = C(0); let _ = E::X; } </ins>


Question:
<!-- 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
This isn't really a bug, it's just that it has bad diagnostics because it uses , which is a perma-unstable attribute. I would recommend against reporting bugs that need attributes unless they cause unsoundness.
MCVE:
Should I exclude all test programs that have a line starting with ? Thanks.
I don't personally feel comfortable setting a policy that we'll never fix ICEs with attributes, but they are definitely less likely to be bugs than other ICEs. Note that this isn't sufficient to catch programs that have an attribute, you can have arbitrary macros that play with conditional compilation, like . Catching and will probably hit the common cases, though (you may want to also include inner attributes).

<ins> error: expected exactly one integer literal argument --> $DIR/invalid_rustc_layout_scalar_valid_range.rs:3:1 | LL | #[rustc_layout_scalar_valid_range_start(u32::MAX)] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: expected exactly one integer literal argument --> $DIR/invalid_rustc_layout_scalar_valid_range.rs:6:1 | LL | #[rustc_layout_scalar_valid_range_end(1, 2)] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: expected exactly one integer literal argument --> $DIR/invalid_rustc_layout_scalar_valid_range.rs:9:1 | LL | #[rustc_layout_scalar_valid_range_end(a = "a")] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: attribute should be applied to a struct --> $DIR/invalid_rustc_layout_scalar_valid_range.rs:12:1 | LL |   #[rustc_layout_scalar_valid_range_end(1)] |   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ LL | / enum E { LL | |     X = 1, LL | |     Y = 14, LL | | } | |_- not a struct error: aborting due to 4 previous errors </ins>


Question:
Interesingly, and shockingly If you remove and , this doesn't panic. <details<summaryWhats up with the diff? </summaryThe assetion format is differnt to usual as I've patch rustc with to make it readable, but this can also be repoduced with the latest nightly </details modify labels: +A-rustdoc-json +T-rustdoc
MCVE: One has while the other has - I bet one is going through HIR and the other is going through metadata, that could explain why the generic parameter matters.
I have a similar MCVE generated from , but the only item that differs in the assertion is the visibility: The left has a visibility of , and the right has a visibility of . A similar MCVE, with as a parameter, has as an input for the right side, but not for the left (and the / visibility issue):

cx.generated_synthetics.insert((ty, trait_def_id)); <ins> let hir_imp = impl_def_id.as_local() .map(|local| cx.tcx.hir().expect_item(local)) .and_then(|item| if let hir::ItemKind::Impl(i) = &item.kind { Some(i) } else { None }); let items = match hir_imp { Some(imp) => imp .items .iter() .map(|ii| cx.tcx.hir().impl_item(ii.id).clean(cx)) .collect::<Vec<_>>(), None => cx.tcx .associated_items(impl_def_id) .in_definition_order() .map(|x| x.clean(cx)) .collect::<Vec<_>>(), }; </ins> impls.push(Item { name: None, attrs: Default::default(),


Question:
Interesingly, and shockingly If you remove and , this doesn't panic. <details<summaryWhats up with the diff? </summaryThe assetion format is differnt to usual as I've patch rustc with to make it readable, but this can also be repoduced with the latest nightly </details modify labels: +A-rustdoc-json +T-rustdoc
MCVE: One has while the other has - I bet one is going through HIR and the other is going through metadata, that could explain why the generic parameter matters.
I have a similar MCVE generated from , but the only item that differs in the assertion is the visibility: The left has a visibility of , and the right has a visibility of . A similar MCVE, with as a parameter, has as an input for the right side, but not for the left (and the / visibility issue):

// the post-inference `trait_ref`, as it's more accurate. trait_: Some(trait_ref.clean(cx)), for_: ty.clean(cx), <del> items: cx .tcx .associated_items(impl_def_id) .in_definition_order() .map(|x| x.clean(cx)) .collect::<Vec<_>>(), </del> <ins> items, </ins> polarity: ty::ImplPolarity::Positive, kind: ImplKind::Blanket(box trait_ref.self_ty().clean(cx)), }),


Question:
Interesingly, and shockingly If you remove and , this doesn't panic. <details<summaryWhats up with the diff? </summaryThe assetion format is differnt to usual as I've patch rustc with to make it readable, but this can also be repoduced with the latest nightly </details modify labels: +A-rustdoc-json +T-rustdoc
MCVE: One has while the other has - I bet one is going through HIR and the other is going through metadata, that could explain why the generic parameter matters.
I have a similar MCVE generated from , but the only item that differs in the assertion is the visibility: The left has a visibility of , and the right has a visibility of . A similar MCVE, with as a parameter, has as an input for the right side, but not for the left (and the / visibility issue):

/// the hashmap because certain items (traits and types) need to have their mappings for trait /// implementations filled out before they're inserted. fn item(&mut self, item: clean::Item) -> Result<(), Error> { <del> let local_blanket_impl = match item.def_id { clean::ItemId::Blanket { impl_id, .. } => impl_id.is_local(), clean::ItemId::Auto { .. } | clean::ItemId::DefId(_) | clean::ItemId::Primitive(_, _) => false, }; </del> // Flatten items that recursively store other items <del> // FIXME(CraftSpider): We skip children of local blanket implementations, as we'll have //     already seen the actual generic impl, and the generated ones don't need documenting. //     This is necessary due to the visibility, return type, and self arg of the generated //     impls not quite matching, and will no longer be necessary when the mismatch is fixed. if !local_blanket_impl { item.kind.inner_items().for_each(|i| self.item(i.clone()).unwrap()); } </del> <ins> item.kind.inner_items().for_each(|i| self.item(i.clone()).unwrap()); </ins> let id = item.def_id; if let Some(mut new_item) = self.convert_item(item) {


Question:
Interesingly, and shockingly If you remove and , this doesn't panic. <details<summaryWhats up with the diff? </summaryThe assetion format is differnt to usual as I've patch rustc with to make it readable, but this can also be repoduced with the latest nightly </details modify labels: +A-rustdoc-json +T-rustdoc
MCVE: One has while the other has - I bet one is going through HIR and the other is going through metadata, that could explain why the generic parameter matters.
I have a similar MCVE generated from , but the only item that differs in the assertion is the visibility: The left has a visibility of , and the right has a visibility of . A similar MCVE, with as a parameter, has as an input for the right side, but not for the left (and the / visibility issue):

// @has blanket_with_local.json "$.index[*][?(@.name=='Load')]" pub trait Load { <ins> // @has - "$.index[*][?(@.name=='load')]" </ins> fn load() {} <ins> // @has - "$.index[*][?(@.name=='write')]" fn write(self) {} </ins> } impl<P> Load for P { fn load() {} <ins> fn write(self) {} </ins> } // @has - "$.index[*][?(@.name=='Wrapper')]"


Question:
Most of the types in are implicitly copyable. This results in some confusing situations and is also incorrect since it's doing non-atomic copies.
I don't think an "atomic copy" is a thing? Since all the atomic operations essentially just work on the pointer, copying an atomic type results in an entire new value, in a new memory location. I'm pretty sure that an "atomic copy" is impossible since it requires a read and then store to 2 separate memory locations. The only thing I can think of is the lack of an atomic load. I'm also not sure that being implicitly copyable is an issue, other the above point, and would prefer to keep this way to be honest. There is no semantic difference between using the types and the methods on them and using the atomic intrinsics directly pointers to the values you want to manipulate. The only real advantage of the atomic types is a nicer API. The way it currently is means that the atomic types are identical (except for ) to their non-atomic counterparts.
It's doing a copy of the value at a memory location that is only accessed through atomics without doing an atomic load. It's not true that they are identical to non-atomic types. They encapsulate a memory location to which they only allow access via atomics - except for this non-atomic load.
would make sense, I think.
Nominating

use option::{Option,Some,None}; use libc::c_void; use ops::Drop; <ins> use util::NonCopyable; </ins> /** * A simple atomic flag, that can be set and cleared. The most basic atomic type. */ pub struct AtomicFlag { <del> priv v: int </del> <ins> priv v: int, priv nocopy: NonCopyable </ins> } /** * An atomic boolean type. */ pub struct AtomicBool { <del> priv v: uint </del> <ins> priv v: uint, priv nocopy: NonCopyable </ins> } /** * A signed atomic integer type, supporting basic atomic arithmetic operations */ pub struct AtomicInt { <del> priv v: int </del> <ins> priv v: int, priv nocopy: NonCopyable </ins> } /** * An unsigned atomic integer type, supporting basic atomic arithmetic operations */ pub struct AtomicUint { <del> priv v: uint </del> <ins> priv v: uint, priv nocopy: NonCopyable </ins> } /** * An unsafe atomic pointer. Only supports basic atomic operations */ pub struct AtomicPtr<T> { <del> priv p: *mut T </del> <ins> priv p: *mut T, priv nocopy: NonCopyable </ins> } /**


Question:
Most of the types in are implicitly copyable. This results in some confusing situations and is also incorrect since it's doing non-atomic copies.
I don't think an "atomic copy" is a thing? Since all the atomic operations essentially just work on the pointer, copying an atomic type results in an entire new value, in a new memory location. I'm pretty sure that an "atomic copy" is impossible since it requires a read and then store to 2 separate memory locations. The only thing I can think of is the lack of an atomic load. I'm also not sure that being implicitly copyable is an issue, other the above point, and would prefer to keep this way to be honest. There is no semantic difference between using the types and the methods on them and using the atomic intrinsics directly pointers to the values you want to manipulate. The only real advantage of the atomic types is a nicer API. The way it currently is means that the atomic types are identical (except for ) to their non-atomic counterparts.
It's doing a copy of the value at a memory location that is only accessed through atomics without doing an atomic load. It's not true that they are identical to non-atomic types. They encapsulate a memory location to which they only allow access via atomics - except for this non-atomic load.
would make sense, I think.
Nominating

SeqCst } <del> pub static INIT_ATOMIC_FLAG : AtomicFlag = AtomicFlag { v: 0 }; pub static INIT_ATOMIC_BOOL : AtomicBool = AtomicBool { v: 0 }; pub static INIT_ATOMIC_INT  : AtomicInt  = AtomicInt  { v: 0 }; pub static INIT_ATOMIC_UINT : AtomicUint = AtomicUint { v: 0 }; </del> <ins> pub static INIT_ATOMIC_FLAG : AtomicFlag = AtomicFlag { v: 0, nocopy: NonCopyable }; pub static INIT_ATOMIC_BOOL : AtomicBool = AtomicBool { v: 0, nocopy: NonCopyable }; pub static INIT_ATOMIC_INT  : AtomicInt  = AtomicInt  { v: 0, nocopy: NonCopyable }; pub static INIT_ATOMIC_UINT : AtomicUint = AtomicUint { v: 0, nocopy: NonCopyable }; </ins> impl AtomicFlag { pub fn new() -> AtomicFlag { <del> AtomicFlag { v: 0 } </del> <ins> AtomicFlag { v: 0, nocopy: NonCopyable } </ins> } /**


Question:
Most of the types in are implicitly copyable. This results in some confusing situations and is also incorrect since it's doing non-atomic copies.
I don't think an "atomic copy" is a thing? Since all the atomic operations essentially just work on the pointer, copying an atomic type results in an entire new value, in a new memory location. I'm pretty sure that an "atomic copy" is impossible since it requires a read and then store to 2 separate memory locations. The only thing I can think of is the lack of an atomic load. I'm also not sure that being implicitly copyable is an issue, other the above point, and would prefer to keep this way to be honest. There is no semantic difference between using the types and the methods on them and using the atomic intrinsics directly pointers to the values you want to manipulate. The only real advantage of the atomic types is a nicer API. The way it currently is means that the atomic types are identical (except for ) to their non-atomic counterparts.
It's doing a copy of the value at a memory location that is only accessed through atomics without doing an atomic load. It's not true that they are identical to non-atomic types. They encapsulate a memory location to which they only allow access via atomics - except for this non-atomic load.
would make sense, I think.
Nominating

impl AtomicBool { pub fn new(v: bool) -> AtomicBool { <del> AtomicBool { v: if v { 1 } else { 0 } } </del> <ins> AtomicBool { v: if v { 1 } else { 0 }, nocopy: NonCopyable } </ins> } #[inline]


Question:
Most of the types in are implicitly copyable. This results in some confusing situations and is also incorrect since it's doing non-atomic copies.
I don't think an "atomic copy" is a thing? Since all the atomic operations essentially just work on the pointer, copying an atomic type results in an entire new value, in a new memory location. I'm pretty sure that an "atomic copy" is impossible since it requires a read and then store to 2 separate memory locations. The only thing I can think of is the lack of an atomic load. I'm also not sure that being implicitly copyable is an issue, other the above point, and would prefer to keep this way to be honest. There is no semantic difference between using the types and the methods on them and using the atomic intrinsics directly pointers to the values you want to manipulate. The only real advantage of the atomic types is a nicer API. The way it currently is means that the atomic types are identical (except for ) to their non-atomic counterparts.
It's doing a copy of the value at a memory location that is only accessed through atomics without doing an atomic load. It's not true that they are identical to non-atomic types. They encapsulate a memory location to which they only allow access via atomics - except for this non-atomic load.
would make sense, I think.
Nominating

impl AtomicInt { pub fn new(v: int) -> AtomicInt { <del> AtomicInt { v:v } </del> <ins> AtomicInt { v:v, nocopy: NonCopyable } </ins> } #[inline]


Question:
Most of the types in are implicitly copyable. This results in some confusing situations and is also incorrect since it's doing non-atomic copies.
I don't think an "atomic copy" is a thing? Since all the atomic operations essentially just work on the pointer, copying an atomic type results in an entire new value, in a new memory location. I'm pretty sure that an "atomic copy" is impossible since it requires a read and then store to 2 separate memory locations. The only thing I can think of is the lack of an atomic load. I'm also not sure that being implicitly copyable is an issue, other the above point, and would prefer to keep this way to be honest. There is no semantic difference between using the types and the methods on them and using the atomic intrinsics directly pointers to the values you want to manipulate. The only real advantage of the atomic types is a nicer API. The way it currently is means that the atomic types are identical (except for ) to their non-atomic counterparts.
It's doing a copy of the value at a memory location that is only accessed through atomics without doing an atomic load. It's not true that they are identical to non-atomic types. They encapsulate a memory location to which they only allow access via atomics - except for this non-atomic load.
would make sense, I think.
Nominating

impl AtomicUint { pub fn new(v: uint) -> AtomicUint { <del> AtomicUint { v:v } </del> <ins> AtomicUint { v:v, nocopy: NonCopyable } </ins> } #[inline]


Question:
Most of the types in are implicitly copyable. This results in some confusing situations and is also incorrect since it's doing non-atomic copies.
I don't think an "atomic copy" is a thing? Since all the atomic operations essentially just work on the pointer, copying an atomic type results in an entire new value, in a new memory location. I'm pretty sure that an "atomic copy" is impossible since it requires a read and then store to 2 separate memory locations. The only thing I can think of is the lack of an atomic load. I'm also not sure that being implicitly copyable is an issue, other the above point, and would prefer to keep this way to be honest. There is no semantic difference between using the types and the methods on them and using the atomic intrinsics directly pointers to the values you want to manipulate. The only real advantage of the atomic types is a nicer API. The way it currently is means that the atomic types are identical (except for ) to their non-atomic counterparts.
It's doing a copy of the value at a memory location that is only accessed through atomics without doing an atomic load. It's not true that they are identical to non-atomic types. They encapsulate a memory location to which they only allow access via atomics - except for this non-atomic load.
would make sense, I think.
Nominating

impl<T> AtomicPtr<T> { pub fn new(p: *mut T) -> AtomicPtr<T> { <del> AtomicPtr { p:p } </del> <ins> AtomicPtr { p:p, nocopy: NonCopyable } </ins> } #[inline]


Question:
Most of the types in are implicitly copyable. This results in some confusing situations and is also incorrect since it's doing non-atomic copies.
I don't think an "atomic copy" is a thing? Since all the atomic operations essentially just work on the pointer, copying an atomic type results in an entire new value, in a new memory location. I'm pretty sure that an "atomic copy" is impossible since it requires a read and then store to 2 separate memory locations. The only thing I can think of is the lack of an atomic load. I'm also not sure that being implicitly copyable is an issue, other the above point, and would prefer to keep this way to be honest. There is no semantic difference between using the types and the methods on them and using the atomic intrinsics directly pointers to the values you want to manipulate. The only real advantage of the atomic types is a nicer API. The way it currently is means that the atomic types are identical (except for ) to their non-atomic counterparts.
It's doing a copy of the value at a memory location that is only accessed through atomics without doing an atomic load. It's not true that they are identical to non-atomic types. They encapsulate a memory location to which they only allow access via atomics - except for this non-atomic load.
would make sense, I think.
Nominating

<ins> // Copyright 2012 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. // Issue #8380 #[feature(globs)]; use std::unstable::atomics::*; use std::ptr; fn main() { let x = INIT_ATOMIC_FLAG; let x = *&x; //~ ERROR: cannot move out of dereference let x = INIT_ATOMIC_BOOL; let x = *&x; //~ ERROR: cannot move out of dereference let x = INIT_ATOMIC_INT; let x = *&x; //~ ERROR: cannot move out of dereference let x = INIT_ATOMIC_UINT; let x = *&x; //~ ERROR: cannot move out of dereference let x: AtomicPtr<uint> = AtomicPtr::new(ptr::mut_null()); let x = *&x; //~ ERROR: cannot move out of dereference let x: AtomicOption<uint> = AtomicOption::empty(); let x = *&x; //~ ERROR: cannot move out of dereference } </ins>


Question:
You can also see a somewhat similar compilation error on Rust Playground . I tried this code: And I get this compilation error: It most recently worked on: rustc 1.53.0-nightly ( 2021-03-26) : modify labels: +regression-from-stable-to-nightly -regression-untriaged
Bisected: searched nightlies: from nightly-2021-03-01 to nightly-2021-04-28 regressed nightly: nightly-2021-03-28 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: </detailsI believe the cause is either or . cc
Assigning priority as discussed as part of the and removing . label -I-prioritize +P-medium +requires-nightly -regression-from-stable-to-nightly
With removed: Note that removing the feature gate makes it compile and run without a problem.
looks like we aren't normalizing here. That shouldn't happen. is what introduced this but i would expect us to fix this by adding a call to normalize somewhere before creating symbols.
see , should still be fixed :laughing:

debug!("QueryNormalizer: result = {:#?}", result); debug!("QueryNormalizer: obligations = {:#?}", obligations); self.obligations.extend(obligations); <del> Ok(result.normalized_ty) </del> <ins> let res = result.normalized_ty; // `tcx.normalize_projection_ty` may normalize to a type that still has // unevaluated consts, so keep normalizing here if that's the case. if res != ty && res.has_type_flags(ty::TypeFlags::HAS_CT_PROJECTION) { Ok(res.try_super_fold_with(self)?) } else { Ok(res) } </ins> } ty::Projection(data) => {


Question:
You can also see a somewhat similar compilation error on Rust Playground . I tried this code: And I get this compilation error: It most recently worked on: rustc 1.53.0-nightly ( 2021-03-26) : modify labels: +regression-from-stable-to-nightly -regression-untriaged
Bisected: searched nightlies: from nightly-2021-03-01 to nightly-2021-04-28 regressed nightly: nightly-2021-03-28 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: </detailsI believe the cause is either or . cc
Assigning priority as discussed as part of the and removing . label -I-prioritize +P-medium +requires-nightly -regression-from-stable-to-nightly
With removed: Note that removing the feature gate makes it compile and run without a problem.
looks like we aren't normalizing here. That shouldn't happen. is what introduced this but i would expect us to fix this by adding a call to normalize somewhere before creating symbols.
see , should still be fixed :laughing:

debug!("QueryNormalizer: result = {:#?}", result); debug!("QueryNormalizer: obligations = {:#?}", obligations); self.obligations.extend(obligations); <del> Ok(crate::traits::project::PlaceholderReplacer::replace_placeholders( </del> <ins> let res = crate::traits::project::PlaceholderReplacer::replace_placeholders( </ins> infcx, mapped_regions, mapped_types, mapped_consts, &self.universes, result.normalized_ty, <del> )) </del> <ins> ); // `tcx.normalize_projection_ty` may normalize to a type that still has // unevaluated consts, so keep normalizing here if that's the case. if res != ty && res.has_type_flags(ty::TypeFlags::HAS_CT_PROJECTION) { Ok(res.try_super_fold_with(self)?) } else { Ok(res) } </ins> } _ => ty.try_super_fold_with(self), })()?; self.cache.insert(ty, res); Ok(res) }


Question:
You can also see a somewhat similar compilation error on Rust Playground . I tried this code: And I get this compilation error: It most recently worked on: rustc 1.53.0-nightly ( 2021-03-26) : modify labels: +regression-from-stable-to-nightly -regression-untriaged
Bisected: searched nightlies: from nightly-2021-03-01 to nightly-2021-04-28 regressed nightly: nightly-2021-03-28 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: </detailsI believe the cause is either or . cc
Assigning priority as discussed as part of the and removing . label -I-prioritize +P-medium +requires-nightly -regression-from-stable-to-nightly
With removed: Note that removing the feature gate makes it compile and run without a problem.
looks like we aren't normalizing here. That shouldn't happen. is what introduced this but i would expect us to fix this by adding a call to normalize somewhere before creating symbols.
see , should still be fixed :laughing:

<ins> // build-pass #![allow(incomplete_features)] #![feature(generic_const_exprs)] trait TraitOne { const MY_NUM: usize; type MyErr: std::fmt::Debug; fn do_one_stuff(arr: [u8; Self::MY_NUM]) -> Result<(), Self::MyErr>; } trait TraitTwo { fn do_two_stuff(); } impl<O: TraitOne> TraitTwo for O where [(); Self::MY_NUM]:, { fn do_two_stuff() { O::do_one_stuff([5; Self::MY_NUM]).unwrap() } } struct Blargotron; #[derive(Debug)] struct ErrTy<const N: usize>([(); N]); impl TraitOne for Blargotron { const MY_NUM: usize = 3; type MyErr = ErrTy<{ Self::MY_NUM }>; fn do_one_stuff(_arr: [u8; Self::MY_NUM]) -> Result<(), Self::MyErr> { Ok(()) } } fn main() { Blargotron::do_two_stuff(); } </ins>


Question:
You can also see a somewhat similar compilation error on Rust Playground . I tried this code: And I get this compilation error: It most recently worked on: rustc 1.53.0-nightly ( 2021-03-26) : modify labels: +regression-from-stable-to-nightly -regression-untriaged
Bisected: searched nightlies: from nightly-2021-03-01 to nightly-2021-04-28 regressed nightly: nightly-2021-03-28 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: </detailsI believe the cause is either or . cc
Assigning priority as discussed as part of the and removing . label -I-prioritize +P-medium +requires-nightly -regression-from-stable-to-nightly
With removed: Note that removing the feature gate makes it compile and run without a problem.
looks like we aren't normalizing here. That shouldn't happen. is what introduced this but i would expect us to fix this by adding a call to normalize somewhere before creating symbols.
see , should still be fixed :laughing:

<ins> // build-pass #![allow(incomplete_features)] #![feature(generic_const_exprs)] use std::convert::AsMut; use std::default::Default; trait Foo: Sized { type Baz: Default + AsMut<[u8]>; fn bar() { Self::Baz::default().as_mut(); } } impl Foo for () { type Baz = [u8; 1 * 1]; //type Baz = [u8; 1]; } fn main() { <() as Foo>::bar(); } </ins>


Question:
You can also see a somewhat similar compilation error on Rust Playground . I tried this code: And I get this compilation error: It most recently worked on: rustc 1.53.0-nightly ( 2021-03-26) : modify labels: +regression-from-stable-to-nightly -regression-untriaged
Bisected: searched nightlies: from nightly-2021-03-01 to nightly-2021-04-28 regressed nightly: nightly-2021-03-28 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: </detailsI believe the cause is either or . cc
Assigning priority as discussed as part of the and removing . label -I-prioritize +P-medium +requires-nightly -regression-from-stable-to-nightly
With removed: Note that removing the feature gate makes it compile and run without a problem.
looks like we aren't normalizing here. That shouldn't happen. is what introduced this but i would expect us to fix this by adding a call to normalize somewhere before creating symbols.
see , should still be fixed :laughing:

<ins> // build-pass #![allow(incomplete_features)] #![feature(generic_const_exprs)] trait Collate<Op> { type Pass; type Fail; fn collate(self) -> (Self::Pass, Self::Fail); } impl<Op> Collate<Op> for () { type Pass = (); type Fail = (); fn collate(self) -> ((), ()) { ((), ()) } } trait CollateStep<X, Prev> { type Pass; type Fail; fn collate_step(x: X, prev: Prev) -> (Self::Pass, Self::Fail); } impl<X, P, F> CollateStep<X, (P, F)> for () { type Pass = (X, P); type Fail = F; fn collate_step(x: X, (p, f): (P, F)) -> ((X, P), F) { ((x, p), f) } } struct CollateOpImpl<const MASK: u32>; trait CollateOpStep { type NextOp; type Apply; } impl<const MASK: u32> CollateOpStep for CollateOpImpl<MASK> where CollateOpImpl<{ MASK >> 1 }>: Sized, { type NextOp = CollateOpImpl<{ MASK >> 1 }>; type Apply = (); } impl<H, T, Op: CollateOpStep> Collate<Op> for (H, T) where T: Collate<Op::NextOp>, Op::Apply: CollateStep<H, (T::Pass, T::Fail)>, { type Pass = <Op::Apply as CollateStep<H, (T::Pass, T::Fail)>>::Pass; type Fail = <Op::Apply as CollateStep<H, (T::Pass, T::Fail)>>::Fail; fn collate(self) -> (Self::Pass, Self::Fail) { <Op::Apply as CollateStep<H, (T::Pass, T::Fail)>>::collate_step(self.0, self.1.collate()) } } fn collate<X, const MASK: u32>(x: X) -> (X::Pass, X::Fail) where X: Collate<CollateOpImpl<MASK>>, { x.collate() } fn main() { dbg!(collate::<_, 5>(("Hello", (42, ('!', ()))))); } </ins>


Question:
You can also see a somewhat similar compilation error on Rust Playground . I tried this code: And I get this compilation error: It most recently worked on: rustc 1.53.0-nightly ( 2021-03-26) : modify labels: +regression-from-stable-to-nightly -regression-untriaged
Bisected: searched nightlies: from nightly-2021-03-01 to nightly-2021-04-28 regressed nightly: nightly-2021-03-28 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: </detailsI believe the cause is either or . cc
Assigning priority as discussed as part of the and removing . label -I-prioritize +P-medium +requires-nightly -regression-from-stable-to-nightly
With removed: Note that removing the feature gate makes it compile and run without a problem.
looks like we aren't normalizing here. That shouldn't happen. is what introduced this but i would expect us to fix this by adding a call to normalize somewhere before creating symbols.
see , should still be fixed :laughing:

<ins> // build-pass #![allow(incomplete_features)] #![feature(generic_const_exprs)] pub trait Foo { fn foo(&self); } pub struct FooImpl<const N: usize>; impl<const N: usize> Foo for FooImpl<N> { fn foo(&self) {} } pub trait Bar: 'static { type Foo: Foo; fn get() -> &'static Self::Foo; } struct BarImpl; impl Bar for BarImpl { type Foo = FooImpl< { { 4 } }, >; fn get() -> &'static Self::Foo { &FooImpl } } pub fn boom<B: Bar>() { B::get().foo(); } fn main() { boom::<BarImpl>(); } </ins>


Question:
You can also see a somewhat similar compilation error on Rust Playground . I tried this code: And I get this compilation error: It most recently worked on: rustc 1.53.0-nightly ( 2021-03-26) : modify labels: +regression-from-stable-to-nightly -regression-untriaged
Bisected: searched nightlies: from nightly-2021-03-01 to nightly-2021-04-28 regressed nightly: nightly-2021-03-28 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: </detailsI believe the cause is either or . cc
Assigning priority as discussed as part of the and removing . label -I-prioritize +P-medium +requires-nightly -regression-from-stable-to-nightly
With removed: Note that removing the feature gate makes it compile and run without a problem.
looks like we aren't normalizing here. That shouldn't happen. is what introduced this but i would expect us to fix this by adding a call to normalize somewhere before creating symbols.
see , should still be fixed :laughing:

<ins> // build-pass #![feature(generic_const_exprs)] #![allow(incomplete_features)] trait Foo { type Output; fn foo() -> Self::Output; } impl Foo for [u8; 3] { type Output = [u8; 1 + 2]; fn foo() -> [u8; 3] { [1u8; 3] } } fn bug<const N: usize>() where [u8; N]: Foo, <[u8; N] as Foo>::Output: AsRef<[u8]>, { <[u8; N]>::foo().as_ref(); } fn main() { bug::<3>(); } </ins>


Question:
You can also see a somewhat similar compilation error on Rust Playground . I tried this code: And I get this compilation error: It most recently worked on: rustc 1.53.0-nightly ( 2021-03-26) : modify labels: +regression-from-stable-to-nightly -regression-untriaged
Bisected: searched nightlies: from nightly-2021-03-01 to nightly-2021-04-28 regressed nightly: nightly-2021-03-28 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: </detailsI believe the cause is either or . cc
Assigning priority as discussed as part of the and removing . label -I-prioritize +P-medium +requires-nightly -regression-from-stable-to-nightly
With removed: Note that removing the feature gate makes it compile and run without a problem.
looks like we aren't normalizing here. That shouldn't happen. is what introduced this but i would expect us to fix this by adding a call to normalize somewhere before creating symbols.
see , should still be fixed :laughing:

<ins> // build-pass #![allow(incomplete_features)] #![feature(generic_const_exprs)] use std::marker::PhantomData; fn main() { let x = FooImpl::<BarImpl<1>> { phantom: PhantomData }; let _ = x.foo::<BarImpl<1>>(); } trait Foo<T> where T: Bar, { fn foo<U>(&self) where T: Operation<U>, <T as Operation<U>>::Output: Bar; } struct FooImpl<T> where T: Bar, { phantom: PhantomData<T>, } impl<T> Foo<T> for FooImpl<T> where T: Bar, { fn foo<U>(&self) where T: Operation<U>, <T as Operation<U>>::Output: Bar, { <<T as Operation<U>>::Output as Bar>::error_occurs_here(); } } trait Bar { fn error_occurs_here(); } struct BarImpl<const N: usize>; impl<const N: usize> Bar for BarImpl<N> { fn error_occurs_here() {} } trait Operation<Rhs> { type Output; } //// Part-A: This causes error. impl<const M: usize, const N: usize> Operation<BarImpl<M>> for BarImpl<N> where BarImpl<{ N + M }>: Sized, { type Output = BarImpl<{ N + M }>; } //// Part-B: This doesn't cause error. // impl<const M: usize, const N: usize> Operation<BarImpl<M>> for BarImpl<N> { //     type Output = BarImpl<M>; // } //// Part-C: This also doesn't cause error. // impl<const M: usize, const N: usize> Operation<BarImpl<M>> for BarImpl<N> { //     type Output = BarImpl<{ M }>; // } </ins>


Question:
Crashes when running . <!-- 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
Regression in nightly-2020-10-28 between ... Does occur since 1.49 modify labels: A-meta regression-from-stable-to-stable
This is an error-ICE case, with a nice error as well. <details<summaryfull build output</summary</details
modify labels -I-prioritize +P-medium As discussed in the prioritization working group
Minimized
Interesting thing… my minimized example only regresses at ( to ), however I can confirm the regression at ( to ) for the original example. AFAICT possibly .
Ah, that makes sense… the later regression is due to . Using takes it back to .
Edit: Probably not the underlying problem, see comments below.
label -A-meta +A-frontend
Nevermind, further minimization to puts the regression point earlier than .
The (error -error+ICE) regression of the example happens at . cc <details<summaryCompiler output/backtrace</summaryon on (with backtrace)
As a reminder: Please add [both][0] code [snippets][1] as testcases in the final PR. They seem to be triggered differently, therefore it shouldn't hurt to add them both. [0]: [1]:

Res::Def(DefKind::Ctor(..), def_id) => { tcx.generics_of(tcx.parent(def_id).unwrap()) } <del> Res::Def(_, def_id) => tcx.generics_of(def_id), </del> <ins> // Other `DefKind`s don't have generics and would ICE when calling // `generics_of`. Res::Def( DefKind::Struct | DefKind::Union | DefKind::Enum | DefKind::Variant | DefKind::Trait | DefKind::OpaqueTy | DefKind::TyAlias | DefKind::ForeignTy | DefKind::TraitAlias | DefKind::AssocTy | DefKind::Fn | DefKind::AssocFn | DefKind::AssocConst | DefKind::Impl, def_id, ) => tcx.generics_of(def_id), </ins> Res::Err => { tcx.sess.delay_span_bug(tcx.def_span(def_id), "anon const with Res::Err"); return None;


Question:
Crashes when running . <!-- 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
Regression in nightly-2020-10-28 between ... Does occur since 1.49 modify labels: A-meta regression-from-stable-to-stable
This is an error-ICE case, with a nice error as well. <details<summaryfull build output</summary</details
modify labels -I-prioritize +P-medium As discussed in the prioritization working group
Minimized
Interesting thing… my minimized example only regresses at ( to ), however I can confirm the regression at ( to ) for the original example. AFAICT possibly .
Ah, that makes sense… the later regression is due to . Using takes it back to .
Edit: Probably not the underlying problem, see comments below.
label -A-meta +A-frontend
Nevermind, further minimization to puts the regression point earlier than .
The (error -error+ICE) regression of the example happens at . cc <details<summaryCompiler output/backtrace</summaryon on (with backtrace)
As a reminder: Please add [both][0] code [snippets][1] as testcases in the final PR. They seem to be triggered differently, therefore it shouldn't hurt to add them both. [0]: [1]:

<ins> fn f() { std::<0>; //~ ERROR expected value } fn j() { std::<_ as _>; //~ ERROR expected value //~^ ERROR expected one of `,` or `>`, found keyword `as` } fn main () {} </ins>


Question:
Crashes when running . <!-- 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
Regression in nightly-2020-10-28 between ... Does occur since 1.49 modify labels: A-meta regression-from-stable-to-stable
This is an error-ICE case, with a nice error as well. <details<summaryfull build output</summary</details
modify labels -I-prioritize +P-medium As discussed in the prioritization working group
Minimized
Interesting thing… my minimized example only regresses at ( to ), however I can confirm the regression at ( to ) for the original example. AFAICT possibly .
Ah, that makes sense… the later regression is due to . Using takes it back to .
Edit: Probably not the underlying problem, see comments below.
label -A-meta +A-frontend
Nevermind, further minimization to puts the regression point earlier than .
The (error -error+ICE) regression of the example happens at . cc <details<summaryCompiler output/backtrace</summaryon on (with backtrace)
As a reminder: Please add [both][0] code [snippets][1] as testcases in the final PR. They seem to be triggered differently, therefore it shouldn't hurt to add them both. [0]: [1]:

<ins> error: expected one of `,` or `>`, found keyword `as` --> $DIR/issue-84831.rs:5:13 | LL |     std::<_ as _>; |             ^^ expected one of `,` or `>` | help: expressions must be enclosed in braces to be used as const generic arguments | LL |     std::<{ _ as _ }>; |           ^        ^ error[E0423]: expected value, found crate `std` --> $DIR/issue-84831.rs:2:5 | LL |     std::<0>; |     ^^^^^^^^ not a value error[E0423]: expected value, found crate `std` --> $DIR/issue-84831.rs:5:5 | LL |     std::<_ as _>; |     ^^^^^^^^^^^^^ not a value error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0423`. </ins>


Question:
Given the following code (): The current output is: This is rather confusing. It's not immediately clear what the difference between and this working code is (): Since is accepted, the user might be confused why would be considered a nominal type when isn't. The real reason why is an error is because it is an block for . Ideally the output should look like:
It seems like this only happens with auto traits. Regular traits already emit E0116 in this case (): Note that this still happens with auto traits in the same crate, but in this case wouldn't be applicable (): The diagnostic is still confusing in this case and could be rewritten to explicitly point out that is not allowed. modify labels: +D-confusing +F-auto_traits

E0782: include_str!("./error_codes/E0782.md"), E0783: include_str!("./error_codes/E0783.md"), E0784: include_str!("./error_codes/E0784.md"), <ins> E0785: include_str!("./error_codes/E0785.md"), </ins> ; //  E0006, // merged with E0005 //  E0008, // cannot bind by-move into a pattern guard