Question: env, ffi::{OsStr, OsString}, fs::{self, File}, <del> io::{BufRead, BufReader, ErrorKind}, </del> <ins> io::{self, BufRead, BufReader, ErrorKind}, </ins> path::{Path, PathBuf}, process::{Command, Stdio}, };

broke the rust-analyzer config we suggest in the dev-guide: https://rustc-dev- since now rustfmt is in instead of . Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Hi! Just to clarify, the idea is to change to code to match the docs?
I think the idea is changing the docs to match the new behavior.
For reference:
I'd prefer to change the code so that we don't force all contributors to update their config.
I don't think we can put the binary back, or at least, that feels iffy - we'd be trying to overlap two different sysroots. rustfmt used to be statically linked to libstd and librustc_driver, but that's no longer the case.
I suppose we could try to create a symlink from the old path to the new one? That might work, not sure.
Maybe add a proxy? On Linux it might just be
A symlink seems like a good solution to me.
Does the symlink still finds the correct so?
try it and see
I'll experiment adding a symlink.
On Windows, creating a symlink does not find the needed DLLs. Trying to execute the symlink pops two msgbox saying that it doesn't find the and DLLs. You would need to symlink also the DLLs. On Linux, it does find the correct SOs.
Symlinking also works on macOS.
Ok, this is pretty messy. How about doing both: Add the symlink, which will work with both the old and new config on Mac and Linux Update the recommended config in the dev-guide, which will help contributors fix the error message on Windows and from there we can work long-term to using the same toolchain for rustfmt and other tools, without having a time pressure.
cc ,
May I get some guidance and the creation of the symlink? Do I use rust to create the symlink in after the rustfmt_path line or do I use a bash command? If I do use a bash command, is there a file I should be adding it to? Thank you!
use
And just to confirm, I use that symlink function here?


Question: env, ffi::{OsStr, OsString}, fs::{self, File}, <del> io::{BufRead, BufReader, ErrorKind}, </del> <ins> io::{self, BufRead, BufReader, ErrorKind}, </ins> path::{Path, PathBuf}, process::{Command, Stdio}, };

yes
I think it would be possible to move rustfmt back to the same sysroot as the bootstrap compiler by only taking , and from the nightly rustc component and not copying any other files like the rustc binary. and both contain a hash in their name unique for each rustc version. should contain the rustc version, so that shouldn't conflict either.
Doing the same with the DLLs on Windows could also work.
related (different error with rustfmt, but caused by the same change):
Hi any progress on the symlink? happy to help out if you're running into trouble :)
Hey ! Thanks for reaching out! I'll be starting tomorrow and will reach out to you if/when I need help! Apologies for the delay!


Question: // We have a valid span in almost all cases, but we don't have one when linting a crate // name provided via the command line. if !ident.span.is_dummy() { <ins> let sc_ident = Ident::from_str_and_span(&sc, ident.span); let (message, suggestion) = if sc_ident.is_reserved() { // We shouldn't suggest a reserved identifier to fix non-snake-case identifiers. // Instead, recommend renaming the identifier entirely or, if permitted, // escaping it to create a raw identifier. if sc_ident.name.can_be_raw() { ("rename the identifier or convert it to a snake case raw identifier", sc_ident.to_string()) } else { err.note(&format!("`{}` cannot be used as a raw identifier", sc)); ("rename the identifier", String::new()) } } else { ("convert the identifier to snake case", sc) }; </ins> err.span_suggestion( ident.span, <del> "convert the identifier to snake case", sc, </del> <ins> message, suggestion, </ins> Applicability::MaybeIncorrect, ); } else {

When you write a mod with a capital name of a keyword, we suggest changing it to the lowercase version of the keyword, which is, well, a keyword and not going to work. We should suggest converting the identifier to snake case and making it a raw identifier, or maybe suggest switching to an altogether separate name? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Hey you might want to comment here to claim this issue :)
claim


Question: // be added explicitly if necessary, see the error in `fn link_rlib`) compiled // as an executable due to `--test`. Use whole-archive implicitly, like before // the introduction of native lib modifiers. <del> || (bundle != Some(false) && sess.opts.test) </del> <ins> || (whole_archive == None && bundle != Some(false) && sess.opts.test) </ins> { cmd.link_whole_staticlib( name,

I am attempting to use the () syntax to control how my test binary is compiled. I have created a repro at In , I tell to link 2 static libraries, one with (+whole-archive) and one without (-whole-archive). I add a nonsense link argument so I can inspect the produced link line. I expect to see linked without whole archive. Instead, I see both and libraries linked with --whole-archive: This may be related to the default documented . When I use nightly and specify it works as expected: However, I cannot use the nightly toolchain, so I cannot use , and seems inappropriate for a final binary crate types like cdylib, staticlib, and executables anyway. Tested with 1.62.1 stable and 1.64 nightly. Possibly related issues: ,
This is a bug introduced in The backward compatibility condition should look like and not .
Could you submit a PR with this fix? (We can backport it to beta if it's done in time.)
Sure, I'll create a PR. I'm not sure what tests to include, however. I had been looking at that exact code and almost submitted a PR earlier, but I wasn't sure about the whole context of that code and all the compatibility needs.
You can try adding a test case with to . One with and , and another with and without any (the compatibility case).


Question: /// /// [`to_ascii_uppercase`]: Self::to_ascii_uppercase #[stable(feature = "ascii_methods_on_intrinsics", since = "1.23.0")] <del> #[rustc_const_unstable(feature = "const_make_ascii", issue = "130698")] </del> <ins> #[rustc_const_stable(feature = "const_make_ascii", since = "CURRENT_RUSTC_VERSION")] </ins> #[inline] <ins> #[cfg_attr(bootstrap, rustc_allow_const_fn_unstable(const_mut_refs))] </ins> pub const fn make_ascii_uppercase(&mut self) { *self = self.to_ascii_uppercase(); }

Feature gate: This is a tracking issue for marking the and methods in , , , and as "const." [x] Implementation for : [x] Implementation for : [x] Implementation for and : [x] Final comment period (FCP) [x] Stabilization PRNone yet.
fcp merge / have been stable in const since 1.52. / are unblocked now by the stabilization of
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [ ] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
Can the methods be included in this? Similarly const stable / since 1.52.
Yes, that sounds like a good idea. I'll try adding another PR later.
:bell: This is now entering its final comment period, as per the . :bell:
stabilises this.
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon.


Question: } self.cx.borrowck_context.constraints.outlives_constraints.push(constraint) } <del> for live_region in liveness_constraints.rows() { self.cx .borrowck_context .constraints .liveness_constraints .add_element(live_region, location); </del> <ins> for region in liveness_constraints.rows() { // If the region is live at at least one location in the promoted MIR, // then add a liveness constraint to the main MIR for this region // at the location provided as an argument to this method if let Some(_) = liveness_constraints.get_elements(region).next() { self.cx .borrowck_context .constraints .liveness_constraints .add_element(region, location); } </ins> } if !closure_bounds.is_empty() {

<!-- 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. --code from glacier <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This one also crashes beta and stable release channel.
Huh, why was this not detected earlier if it was tracked in glacier as fixed?
If you add a annotation to the trait bound on , then it no longer ICEs. Here's the code: Output: And if you add the two feature attributes the above messages ask you to enable, it still does not ICE, but correctly errors with "evaluation of constant value failed." Based on some debugging which I , I think this ICE has to do with the lifetime in the bound , although I'm not exactly sure how. I am new to the Rust compiler, and I just chose this issue because it seemed like a good first issue to work on, so I will read the (thanks to for sharing this) and try to further debug this.
If you plan to work on this issue, I recommend claiming it so other people know that and don't start working on it too. You can claim the issue by commenting with . More details about how to use rustbot are . You may also want to read the of the guide.
claim


Question: param_env: ty::ParamEnv<'tcx>, cause: &ObligationCause<'tcx>, ) -> Option<ty::PolyExistentialTraitRef<'tcx>> { <ins> // Don't drop any candidates in intercrate mode, as it's incomplete. // (Not that it matters, since `Unsize` is not a stable trait.) if self.infcx.intercrate { return None; } </ins> let tcx = self.tcx(); if tcx.features().trait_upcasting { return None;

<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed: !self.intercrate'', 'thread 'rustc' panicked at 'assertion failed: !self.intercrate'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [specializationgraphof] building specialization graph of trait [coherent_trait] coherence checking all impls of trait -- label +F-Unsize +F-unsize
The bisection looks incorrect? is from 1.77, and this looks to be from 1.72 to me.
Too lazy to look at its PRs :
Due to . This assertion is correct, and we probably shouldn't drop candidates in intercrate mode, since this is incomplete. I would say this fix is low-pri because of the fact that is not expected to be referenced.


Question: #[stable(feature = "rust1", since = "1.0.0")] pub fn is_dir(&self) -> bool { self.file_type().is_dir() } <del> /// Returns whether this metadata is for a regular file. </del> <ins> /// Returns whether this metadata is for a regular file. The /// result is mutually exclusive to the result of /// [`is_dir`], and will be false for symlink metadata /// obtained from [`symlink_metadata`]. /// /// [`is_dir`]: struct.Metadata.html#method.is_dir /// [`symlink_metadata`]: fn.symlink_metadata.html </ins> /// /// # Examples ///

should document that , , and are all mutually exclusive. (and that it may also be the case that none of them are true) Why? Because returns true for both files and symlinks to files, and this tends to make me paranoid that a will share similar characteristics and perhaps claim that both and . The only way to convince myself that FileType's behavior is indeed sane is to write a little test program---again. Surely I can't be alone in this.
is calling not (and equivalent on Windows), so if the path is a symlink, then it returns the results based on what the symlink points to, not the symlink itself. So respects the same mutual exclusivity rules as . But yes, this ought to be documented, especially given that the mutually exclusive behavior may be surprising to Windows developers.
Similar goes for , which should document that these are always false for a obtained by calling on a symlink.
Well you can always call on something that is not a symlink, in which case or could be true.


Question: <ins> // edition:2018 // aux-build:external_macro.rs // Ensure that CONST_ERR lint errors // are not silenced in external macros. // https://github.com/rust-lang/rust/issues/65300 extern crate external_macro; use external_macro::static_assert; fn main() { static_assert!(2 + 2 == 5); //~ ERROR } </ins>

The following does not error locally / on the playground If I copy paste the macro into the same file, it errors as expected Checking other macros, error as expected.
This feels like it's related to a similar issue () I created a while back.
cc
This is probably because the "error" is just a lint. And we appear to silence it in external macros. We shouldn't do that. IIRC this is just a flag that needs to be set for the lint macro
Yes, we need to set reportinexternal_macro param on the lint I believe
Ah, that makes sense! Building locally with the parameter set to confirm. it does ^^ will check the samples in there too.


Question: ignore_unresolved_invocations: bool, record_used: Option<Span>) -> Result<&'a NameBinding<'a>, Determinacy> { <del> let ident = ident.unhygienize(); </del> self.populate_module_if_necessary(module); let resolution = self.resolution(module, ident, ns)

Test case: Compiles successfully on , causes an ICE on . Diff contains only , CC Found while trying to minimize , but filed separately since the error message is different and this one has a small test case.
Do you have a backtrace?
Yes of course. Sorry I forgot to include it: rust error: internal compiler error: attempted .defid() on invalid def: Err note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: run with for a backtrace thread 'rustc' panicked at 'Box<Any',


Question: ignore_unresolved_invocations: bool, record_used: Option<Span>) -> Result<&'a NameBinding<'a>, Determinacy> { <del> let ident = ident.unhygienize(); </del> self.populate_module_if_necessary(module); let resolution = self.resolution(module, ident, ns)

stack backtrace: 1: 0x7fc35e73fdf3 - std::sys::imp::backtrace::tracing::imp::write::hdfa3e34b856f69a3 2: 0x7fc35e74e5dd - std::panicking::defaulthook::{{closure}}::h20f8c1082e0ce86e 3: 0x7fc35e74e17b - std::panicking::defaulthook::hd31552ac08c2a241 4: 0x7fc35e74ea68 - std::panicking::rustpanicwithhook::h73969d230a072c1a 5: 0x7fc357eda667 - std::panicking::beginpanic::hb89a2261f4776ce3 6: 0x7fc357eef99f - rustcerrors::Handler::bug::h13b3b29154320abd 7: 0x7fc35bab053a - rustc::session::optspanbugfmt::{{closure}}::hfea18dd68f59976d 8: 0x7fc35baafff7 - rustc::session::optspanbugfmt::h7d370a0810dbdbbd 9: 0x7fc35baafce2 - rustc::session::bugfmt::hcde5f50c54004a4f 10: 0x7fc35b984552 - rustc::hir::def::Def::defid::h728c22aafbe84efc 11: 0x7fc35c6ddb3a - rustcprivacy::ObsoleteVisiblePrivateTypesVisitor::pathisprivatetype::h24756a49a68d1da9 12: 0x7fc35c6d53db - rustc::hir::intravisit::walkty::h64b13c0c45b7a09a 13: 0x7fc35c6d49ba - rustc::hir::intravisit::Visitor::visitfn::ha8ad665c42b1d643 14: 0x7fc35c6de7cf - <rustcprivacy::ObsoleteVisiblePrivateTypesVisitor<'a,


Question: ignore_unresolved_invocations: bool, record_used: Option<Span>) -> Result<&'a NameBinding<'a>, Determinacy> { <del> let ident = ident.unhygienize(); </del> self.populate_module_if_necessary(module); let resolution = self.resolution(module, ident, ns)

'tcxas rustc::hir::intravisit::Visitor<'tcx::visititem::hae9f32c7942ccca1 15: 0x7fc35c6deab5 - <rustcprivacy::ObsoleteVisiblePrivateTypesVisitor<'a, 'tcxas rustc::hir::intravisit::Visitor<'tcx::visititem::hae9f32c7942ccca1 16: 0x7fc35c6e1b7a - rustcprivacy::checkcrate::h5ba75e3c4ebe0690 17: 0x7fc35eaef747 - rustcdriver::driver::phase3runanalysispasses::{{closure}}::h388b9236cf305089 18: 0x7fc35ead66d6 - rustcdriver::driver::phase3runanalysispasses::h080c1a734c4f2909 19: 0x7fc35eac5425 - rustcdriver::driver::compileinput::hab55539b85c4ceed 20: 0x7fc35eb0ea51 - rustcdriver::runcompiler::h128b89b79f649304 21: 0x7fc35ea236fb - std::panicking::try::docall::h15bca94dda232804 22: 0x7fc35e757b06 - rustmaybecatchpanic 23: 0x7fc35ea44d01 - <F as alloc::boxed::FnBox<A::callbox::h8832766c4bda585b 24: 0x7fc35e74d470 - std::sys::imp::thread::Thread::new::threadstart::h7d03d727f96da002 25: 0x7fc357684453 - startthread 26: 0x7fc35e4147de - GI__clone 27: 0x0 - <unknown
triage: P-high Seems bad. Assigning to based on bisection.
Fixed in .


Question: ignore_unresolved_invocations: bool, record_used: Option<Span>) -> Result<&'a NameBinding<'a>, Determinacy> { <del> let ident = ident.unhygienize(); </del> self.populate_module_if_necessary(module); let resolution = self.resolution(module, ident, ns)

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


Question: ignore_unresolved_invocations: bool, record_used: Option<Span>) -> Result<&'a NameBinding<'a>, Determinacy> { <del> let ident = ident.unhygienize(); </del> self.populate_module_if_necessary(module); let resolution = self.resolution(module, ident, ns)

Found a smaller test case for the inference issue: rust fn main() {} pub mod a { pub struct FontFamily; impl FontFamily { pub fn tocss(&self) -::std::fmt::Result { Ok(()) } } } macrorules! reexport { () ={ mod b { pub use a; } } } reexport!(); pub mod c { use b::a::FontFamily; struct FontFace { family: FontFamily } impl FontFace { pub fn tocss(&self) -::std::fmt::Result { try!(()); Ok(()) } } }
That "other ICE" is actually a direct observation of the bug, whereas this inference issue is some weird side-effect of the way we handle errors that don't stop compilation.
never mind, apparently it fails locally
triage: P-high Seems bad. Assigning to based on bisection.
Does this affect beta ()?
At the moment the latest successful nightly build is 3 days old. I don’t know how often playpen’s nigthly is updated. merged 2 days ago. (This is the rollup PR that merged , which introduced this issue if I did my manual bisecting correctly.) As far as I can tell no, is not reachable from and so beta is not affected.
Fixed in .


Question: #[inline] fn next(&mut self) -> Option<$elem> { // could be implemented with slices, but this avoids bounds checks <del> if self.ptr == self.end { None } else { unsafe { if mem::size_of::<T>() != 0 { ::intrinsics::assume(!self.ptr.is_null()); ::intrinsics::assume(!self.end.is_null()); } </del> <ins> unsafe { if mem::size_of::<T>() != 0 { assume(!self.ptr.is_null()); assume(!self.end.is_null()); } if self.ptr == self.end { None } else { </ins> let old = self.ptr; self.ptr = slice_offset!(self.ptr, 1); Some(slice_ref!(old))

time: 58.110 LLVM passes vs time: 785.935 LLVM passes running on hyper Full output at
cc (There's a slight suspicion that this may be caused by , since that's touching trans/codegen.)
ran with , got
cc
Could you provide files for before and after? Hopefully should work now.
Looks like this is caused by -- the assume intrinsics no longer get simplified into nonnull metadata on load instructions and cause massive slowdowns.


Question: C([Box<A>]), } <del> fn c(c:char) -> A { B(c) //~ ERROR cannot move a value of type A: the size of A cannot be statically determined </del> <ins> fn c(c:char) { B(c); //~^ ERROR cannot move a value of type A: the size of A cannot be statically determined </ins> } pub fn main() {}

The following code causes an ICE: Removing the parameter or changing it to be a value instead of a reference stops the crash with an error saying I need to specify a lifetime, which makes me think this is a problem related to inferred lifetimes.
It isn't, you just have to specify a lifetime: ICE-s as well. Returning an unsized type should be a typeck error.
happens to work because it implies , i.e. would also work.


Question: let mut is_valid = true; if let Some(mi) = attr.meta() && let Some(list) = mi.meta_item_list() { <del> for (meta_index, meta) in list.into_iter().enumerate() { </del> <ins> for meta in list { </ins> if let Some(i_meta) = meta.meta_item() { match i_meta.name_or_empty() { sym::alias

The warning by claims that on an impl item is ignored by rustdoc, but it isn't necessarily. The warning says: which is not true in the following repro: This warning is a false positive. Rustdoc does pay attention to this attribute. For the code above, the rendered documentation of and looks like: <table<tr<td<img src="https://user-" height="185"</td<td<img src="https://user-" height="300"</td</tr</tableAfter removing the supposedly unused attribute and rendering again, the "nasty uninteresting type" that we wanted not shown is going to get rendered on both pages: <table<tr<td<img src="https://user-" height="185"</td<td<img src="https://user-" height="300"</td</tr</table( :


Question: let mut is_valid = true; if let Some(mi) = attr.meta() && let Some(list) = mi.meta_item_list() { <del> for (meta_index, meta) in list.into_iter().enumerate() { </del> <ins> for meta in list { </ins> if let Some(i_meta) = meta.meta_item() { match i_meta.name_or_empty() { sym::alias

Just wanted to add that this is also affecting , but in a different way: <img width="500" src="https://user-"The isn't there at all without the : <img width="500" src="https://user-"Based on the above, this isn't correct: it actually hides the entire thing, at least for associated constants.
In your case, it's inherent associated items being accidentally flagged which is which was meaning the most recent nightly should not have your issue anymore. Sorry for the inconvenience. The longer I look this lint, the less I like it.


Question: <ins> #![crate_type = "lib"] struct Apple((Apple, Option(Banana ? Citron))); //~^ ERROR invalid `?` in type //~| ERROR expected one of `)` or `,`, found `Citron` //~| ERROR cannot find type `Citron` in this scope [E0412] //~| ERROR parenthesized type parameters may only be used with a `Fn` trait [E0214] //~| ERROR recursive type `Apple` has infinite size [E0072] </ins>

<details<summary<strongFull output including backtrace</strong</summary<p</p</detailsRegression from () <details<summaryBisection details</summarybisected with <a href=''cargo-bisect-rustc</av0.6.4 searched nightlies: from nightly-2022-10-06 to nightly-2022-10-28 regressed nightly: nightly-2022-10-09 searched commit range: regressed commit: Host triple: x8664-apple-darwin </details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
this function call crash for the assertion fail, from the log, is with count = 1, and is also 1 when crashing. Do you have any clue? is implemented at here, I'm still not quite familar with the query part:
It looks like the parens are parsed as generic parameters for a type that doesn't have generic parameters? The simple fix is just check .
I think a reasonable fix is modifying the API for , It reasonable to add assertion for , but it's better to return false for outside of expected range?
Have a test on C++'s , which also has this assertion: emm, it's better to keep it for .
claim
I'd be curious to know if we can maintain an invariant in the HIR that it does not contain generics that do not align with . That was what I assumed when writing that code, but that may be too optimistic.
I considered removing the assert too, but I think it's better to have it since it exposes invalid assumptions as in this case.
We should (replacing the assertion) -- that's probably fine as long as it's understood why the does not line up here, and it's understood why we can't fix it somewhere upstream (e.g. in parsing or lowering instead)
I have a general question for , why we just exit when we find a fatal error in parsing (which can not recover by simply autofix).


Question: <ins> #![crate_type = "lib"] struct Apple((Apple, Option(Banana ? Citron))); //~^ ERROR invalid `?` in type //~| ERROR expected one of `)` or `,`, found `Citron` //~| ERROR cannot find type `Citron` in this scope [E0412] //~| ERROR parenthesized type parameters may only be used with a `Fn` trait [E0214] //~| ERROR recursive type `Apple` has infinite size [E0072] </ins>

I have a real Dev experience when working on , I was editing an file with 3k+ lines of code, and I forgetted remove an extra '{', then the compiler give about 20+ errors, the first two are from parsing: But there are many many other errors from later phases... I need to scroll up several pages to the beginning of error to find the rootcause.
If we can not get valid AST in parsing, later phases such as analysising will report out extra (mostly unhelpful) errors?
The assertion is inside of the data structure. I generally expect data structures to simply assert on pre-conditions. We could put a delay-bug before the call, but that also seems like overkill since that is already on the error-reporting path. I agree there are cases where rustc should quit sooner. But in general I think we have to err on the side of recover-and-continue if there is some possibility that more helpful errors may be emitted.
This can happen. The parser should be more realistic on what it recovers and avoid errors from later passes that do not make sense. A few years back we would stop as soon as any error occurred in a given pass and avoid trying any further evaluation, and that was also a usability issue, because people would get a false sense of "how much work is left to fix". We shouldn't have a blanket evaluation stop, but maybe be more aggressive about pruning the AST when multiple parse errors have occurred.
do you want to take over this issue? I currently don't have any clue about the rootcause. Or we give it an simple fix now.
I can take a look.


Question: declare_lint! { pub CONST_ERR, Deny, <del> "constant evaluation detected erroneous expression" </del> <ins> "constant evaluation detected erroneous expression", report_in_external_macro: true </ins> } declare_lint! {


Question: // ignore-sgx no libc // ignore-emscripten no processes // ignore-sgx no processes <del> // ignore-android: FIXME(#85261) </del> // ignore-fuchsia no fork #![feature(rustc_private)]

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I am trying to fix it so that Rust's stdlib prevents unwinding, or allocating, in the child, after a fork on Unix (including in ). That is . (Allocation after fork of a multithreaded program is UB in several libcs.) I a new test case, Unfortunately this test fails, but just on Android: I have few good theories as to why. I wrote some speculations: I think this probably needs attention from an Android expert to try to repro and fix this issue. I suspect it's a problem with the library rather than the tests. The worst case is that it might be a general UB bug in Android Rust programs using or . I'm filing this issue here to try to ask for help again, since writing in doesn't seem like a particularly good way of getting the attention of Android folks. If we can't get a resolution, reluctantly, I guess I will disable that test on Android so that my MR can go through. The current situation is quite a hazard (see eg "panic! in Command child forked from non-main thread results in exit status 0") I will try to explain what the test does and what the symptoms seem to mean: The test file has a custom global allocator, whose purpose is to spot allocations in the child after fork. That global allocator has an atomic variable which is supposed to contain either zero (initially, meaning it's not engaged yet) or the process's pid. Whenever an allocator method is called, we read the atomic and, if it is not zero, we check it against . If it doesn't match we <strike</strike. The test enters , and engages the stunt allocator, recording the program's pid. Each call to (which is called from and therefore from ) produces output from . We see only one of these, so this must be the first test, . The test uses to fork. In the child, it calls (my new function to disable panic unwinding). It then panics (using the provided closure). This ought to result in the program dying with (or maybe or ). The parent collects the child's exit status. For the first test case, we run .


Question: // ignore-sgx no libc // ignore-emscripten no processes // ignore-sgx no processes <del> // ignore-android: FIXME(#85261) </del> // ignore-fuchsia no fork #![feature(rustc_private)]

This extracts the signal number from it and checks that it is as expected. On other systems this works. In the failing test, this test fails. The assertion on fails. Meaning, the child did die of a signal but the signal number wasn't the one expected. The previous debug print shows that the raw wait status (confusingly described by Rust stdlib as an "exit status") is <strike</strike. Usually, a bare number like that in a wait status is a signal number, and indeed that seems to be the case here since is . On Linux (and most Unices), is and 10 is . Ie, it seems that the child tried to allocate memory, despite my efforts to make sure that panicking does not involve allocation. Weirdly, a more-portable test case which uses and does not insist on specific signal numbers passes. It's definitely my stunt allocator which is tripping here, because when I changed it to use instead of , the failing test case signal number changed too.
modify labels +O-android +T-libs-impl
<strike provided an explanation here I still think there is a bug here but it is not Android-specific. I have a WIP branch to try to address it, so I think it's probably best if I close this issue and submit that as an MR when it's ready.</strike
My first guesses were right. In where I changed the stunt allocator to use , we see this:
I found a memory allocation with a patched Miri: With this code:
Apparently, the thread locals aren't working as expected. I think the child after fork is being treated as a new thread, and then the thread local storage has to be re-created. I think the surviving thread in the fork should inherit all the thread-locals from the forking thread in the parent.
But I just tested the code after , so there's no "new thread" or "parent" here...
Oh! Yes. You are right. Evidently the first use of this thread-local allocates. Presumably that would happen on a new thread as well as on the initial thread. Having panic rely on thread-locals, and thread-locals rely on the allocator, seems unfortunate. Having panic allocate is not good, especially when actually it's just trying to abort precisely to avoid this.


Question: // ignore-sgx no libc // ignore-emscripten no processes // ignore-sgx no processes <del> // ignore-android: FIXME(#85261) </del> // ignore-fuchsia no fork #![feature(rustc_private)]

Since is stored in which is not a thread-local, maybe the program could abort before using any thread-local.
It can't do that and also print the payload, because printing the payload might itself panic, and the recursive panic needs to be detected.
Maybe instead there should be a which can return None to mean "this thread-local variable has not been initialised".
I think it might be possible to use a to avoid the allocation.
Do thread-local always avoid the allocation? I think they fall back to regular thread-locals on platforms where avoiding allocations is not (easily) possible.
The version of looks basically same as the non- version when using , which will likely allocate here: Maybe the panic count could be stored directly in rather than on the heap. But is itself safe after ? If it tries to hold a lock or something it's possible to deadlock.
Should this only occur on Android? It happened on QNX as well (not yet upstreamed, work in progress so I don't trust it yet), but I can also reproduce it on with a simple patch (disables thread local storage): Would this be a target spec where we would expect to succeed?
Interesting. To be honest, I'm not sure. I do know that modern libc doctrine is that allocation after fork is UB. The test case is checking that we can safely panic after fork, and abort, without UB. This ought to work due to . I think that every failure of this test case is a real bug. Solving those bugs is not so easy because the machinery inside panic uses thread-local state which apparently is really super hard to make work without allocating or taking locks.
Yes, allocating memory is UB, same as working with mutexes. In case our setups are okay (i.e. having and using fork etc.), I also see this is a bug. Maybe we don't need to fix the issue with the thread-local state (if at all possible): calls to get the number recursive panics and if we . : determines using --works determines number recursive panics using TLS --allocates after --UB first: If it is true, it will always call -- the process will be killed very very soon by the OS In case of a recursion, a hardcoded-string is printed; otherwise additionally Do we really need to correctly determine a recursion, or can we allow "false positives"?


Question: // ignore-sgx no libc // ignore-emscripten no processes // ignore-sgx no processes <del> // ignore-android: FIXME(#85261) </del> // ignore-fuchsia no fork #![feature(rustc_private)]

Instead of having UB, I think it would be fine to only check the number of overall current panics calls (as stored in ignoring ). If it is higher than 2, assume we have a recursion (results in false positives in case two or more threads panic at the same time). ==In case we have two panics going on in parallel by two threads there is the chance that we don't output , but it prevents UB. Also, when one thread calls it will often happen that the second thread will be killed soon and outputs nothing at all. In other cases (only one thread panics), there should be no difference. A change could look like that (high probability I've missed something!): This change passes all tests of for targets and QNX on AArch64.
Would you please try to test the fix above to check if it solves the issue on Android as well?
On most Unix it's UB to touch TLS after fork. Even if we have static TLS, accessing it might cause [^1] to be be called, and that function has paths where it allocates memory, takes locks, etc. That is, this is probably not a specific issue with QNX/Android. [^1]: At least on ELF, although I believe this is broadly true for Mach-O as well.


Question: <ins> // Regression test for issue 123710. // Tests that the we do not ICE in KnownPanicsLint // when a union contains an enum with an repr(packed), // which is a repr not supported for enums #[repr(packed)] //~^ ERROR attribute should be applied to a struct or union #[repr(u32)] enum E { A, B, C, } fn main() { union InvalidTag { int: u32, e: E, //~^ ERROR field must implement `Copy` or be wrapped in `ManuallyDrop<...>` to be used in a union } let _invalid_tag = InvalidTag { int: 4 }; } </ins>

<!-- 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. --(reduced) <details<summary<strongOriginal Code</strong</summary<p</p</details- Above original code is mutated from I guess at the top causes 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details- ICE occurred at
label regression-from-stable-to-beta
searched nightlies: from nightly-2024-02-01 to nightly-2024-04-10 regressed nightly: nightly-2024-02-09 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: aarch64-unknown-linux-gnu Reproduce with: </detailscc
WG-prioritization assigning priority (). label -I-prioritize +P-medium


Question: (self.generics.clean(cx), (&self.decl, self.body).clean(cx)) }); <ins> let did = cx.tcx.hir().local_def_id(self.id); let constness = if cx.tcx.is_min_const_fn(did) { hir::Constness::Const } else { hir::Constness::NotConst }; </ins> Item { name: Some(self.name.clean(cx)), attrs: self.attrs.clean(cx),

Regression from 1.26.0 to 1.27.0 and later. See for example See also and


Question: /// /// **Example:** /// ```rust <del> /// // Bad </del> /// println!(""); <del> /// /// // Good /// println!(); </del> /// ``` pub PRINTLN_EMPTY_STRING, style,

The following sample crashed rustc: Removing the , or unwrapping the (leaving only ), or replacing the predicate (leaving ), solves the crash. Reproduced on Windows 64-bit, Fedora 32-bit, Ubuntu 64-bit. Full crash log (thanks to ) @ Short crash message:
Fixed pending
Fixed in


Question: /// /// **Example:** /// ```rust <del> /// // Bad </del> /// println!(""); <del> /// /// // Good /// println!(); </del> /// ``` pub PRINTLN_EMPTY_STRING, style,

While I was playing with the new rustc 0.6, I encountered an internal compiler error The source code is here: Compiler version is 0.6, built with gcc, on OS X 10.7.5
If you run rustc under gdb and break on , could you paste the backtrace here?
OK. Here is the backtrace:
Looks like stack exhaustion to me. What happens if you remove ?
The code compiles with no problem when I wrap the rest of the code with mod block. Like:
This yields a proper error message now; closing.


Question: /// /// **Example:** /// ```rust <del> /// // Bad </del> /// println!(""); <del> /// /// // Good /// println!(); </del> /// ``` pub PRINTLN_EMPTY_STRING, style,

When you download the 0.6 tarball and execute ./configure && make, a download occurs. and a wget info dump appears. It would be really awesome if this piece was integrated with the tarball. Not all environments are friendly to downloading arbitrary code off the net. E.g., I might be in a SCIF[1] and experimenting with Rust on a machine disconnected from the public net. Or I might be on a laptop working in a no-wifi area. :-/ (I know this is probably a real low priority issue, but it IS a (usually minor) hassle) [1]
Please note that you can avoid that if you already have a (compatible) locally installed rust compiler. Check the --local-rust and --local-rust-root parameters for ./configure. Also, I'm against bundling binaries in source tarballs. They are target-dependent and bundling all of them will make the released archive quite large. Downloading an external bootstrapper is a minor issue for downstream packagers too, though. See
far-future
Yeah, you can also just populate the directory in your builddir with an appropriate snapshot tarball. There's not much else we can do here. Putting binaries in a source tarball feels even worse, to me. Closing as I don't expect we're going to much change the requirements here and have several workable workarounds.


Question: /// /// **Example:** /// ```rust <del> /// // Bad </del> /// println!(""); <del> /// /// // Good /// println!(); </del> /// ``` pub PRINTLN_EMPTY_STRING, style,

As seen in , LLVM has lots of places where it will insert calls to libm directly, not switching stacks. One of places that I recall seeing this before is the translation of the instruction. Rust has floating point modulus and presumably it is doing it in the red zone.
We can solve this with an lang item.
Is this an issue with calls to compiler-rt too? Or are they compiled in some special way to avoid the issue?
Nominating for milestone 5, production-ready
, , and are also all generated. As far as I can tell, we can't prevent it from generating these by altering the IR we output.
We can possibly be selective about when we emit memcpy/memmov, second guessing LLVM (like, never for big things)
accepted for production-ready milestone
Closing due to segmented stacks being gone (stack switches no longer a thing)


Question: <ins> // compile-flags:--test /// ``` /// assert!(true) /// ``` pub fn f() {} pub fn f() {} </ins>

I have a no_std crate that imports std when testing: However, I get this error during testing: Allocating on the heap during testing does appear to work, so I'm assuming this is just a case of the warning still being emitted.
I have the same issue. Any update?
builds the crate both as a library (for doctests) and as a test executable. You only pull in std for the test executable, so the error message could be coming from building as a library.
I have the same issue, error message seems to be spurious
Yeah, the error message is emitted when building the library. Funnily enough, it does not cause the build to fail. That is, still continues running and then exits with success (0). Sadly, there is currently no way to link in a default allocator (or for that matter) for doctests. There is the unstable feature that provides , but I don't see how to achieve something similar without relying on unstable features. I simply use until this is fixed.
Related:
modify labels: +T-rustdoc
Error: Parsing label command in failed: labels +T-rustdo... Please let know if you're having trouble with this bot.
If you don't put inside the doctest it will be linked against even when testing a crate, you can think of each doctest as a separate crate. If you do want a different allocator you can add a static like in a normal binary. Even though this error message is printed the doc tests should still be running.
Also see the error is basically spurious.


Question: <ins> // compile-flags:--test /// ``` /// assert!(true) /// ``` pub fn f() {} pub fn f() {} </ins>

I noticed this in the output running locally: and that didn't make tests fail. Cc:
Same with panic_unwind:
This error message is printed when running , but before running any test. The code printing it is in . It looks like rustdoc is using that code in order to load the crate and find doctests in it. But since it’s not actually compiling this crate, not having an allocator is not a problem. So I think there are two issues: rustdoc keeps doing its thing even though there are errors. It probably should call something like on its instance at some point. This error should not occur in the first place. One way to inhibit it would be to tell that we’re "compiling" an rlib () rather than some other crate type. rlibs do not need (yet) to have an allocator defined. This is possibly this line: The first issue could in some other situation hide a real problem, but in this case it makes the second one mostly harmless. The only bad consequence is some noise in the output of a test run.
Related:
modify labels: +T-rustdoc
Error: Parsing label command in failed: labels +T-rustdo... Please let know if you're having trouble with this bot.


Question: <ins> error[E0433]: failed to resolve: there are too many leading `super` keywords --> $DIR/issue-82156.rs:2:5 | LL |     super(); |     ^^^^^ there are too many leading `super` keywords error: aborting due to previous error For more information about this error, try `rustc --explain E0433`. </ins>

<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --I tried to call default trait implementation from overriden method. Googling was not so useful as wanted so I started playing with "super" keyword and found this bug. Bug appears both on stable and nightly <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Bisected:
Relevant code: In case it helps, the merges in nightly-2020-06-05 were , , , , , and . Playground:
Error from just before the regression was introduced (run with ):
Assigning and removing as ) in the prioritization working group.
claim


Question: // Record, lower it to `$binding_mode $ident @ _`, and stop here. PatKind::Ident(ref bm, ident, Some(ref sub)) if sub.is_rest() => { prev_rest_span = Some(sub.span); <del> let lower_sub = |this: &mut Self| Some(this.pat_wild_with_node_id_of(sub)); let node = self.lower_pat_ident(pat, bm, ident, lower_sub); slice = Some(self.pat_with_node_id_of(pat, node)); </del> <ins> slice = Some(lower_rest_sub(self, pat, bm, ident, sub)); </ins> break; } // It was not a subslice pattern so lower it normally.

The ICE only occurs when is used. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Nominating due to impending stabilization, even though stable doesn't ICE yet
Simplified:


Question: <ins> error: unnecessary parentheses around assigned value --> $DIR/unused-parens-for-stmt-expr-attributes-issue-129833.rs:9:13 | LL |     let _ = (#[inline] #[allow(dead_code)] || println!("Hello!")); |             ^                                                   ^ | note: the lint level is defined here --> $DIR/unused-parens-for-stmt-expr-attributes-issue-129833.rs:6:9 | LL | #![deny(unused_parens)] |         ^^^^^^^^^^^^^ help: remove these parentheses | LL -     let _ = (#[inline] #[allow(dead_code)] || println!("Hello!")); LL +     let _ = #[inline] #[allow(dead_code)] || println!("Hello!"); | error: unnecessary parentheses around block return value --> $DIR/unused-parens-for-stmt-expr-attributes-issue-129833.rs:10:5 | LL |     (#[inline] #[allow(dead_code)] || println!("Hello!")) |     ^                                                   ^ | help: remove these parentheses | LL -     (#[inline] #[allow(dead_code)] || println!("Hello!")) LL +     #[inline] #[allow(dead_code)] || println!("Hello!") | error: aborting due to 2 previous errors </ins>

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: The warning fires on all three lines of , and the suggestions should only suggest removing the parentheses, not the attribute also. Instead, this happened: The fires on the first and last lines of , and the suggestion also removes the . No warning fires on the second line (but this is probably a separate issue, unrelated to attributes; it happens even when the attribute is removed; maybe overrides it or something). <!-- 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. --: Requires use of , otherwise the is not legal in that position (though note that the warning and suggestion is the same on stable, there's just an first). The issue is not specific to closures and , but that was the simplest example of a reasonable attribute-on-expression I thought of. label +A-diagnostics +requires-nightly <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
claim


Question: LL |     let _: Wow<{ A.0 }>; |                +     + <ins> error: expected type, found `]` --> $DIR/bad-const-generic-exprs.rs:16:17 | LL |     let _: Wow<[]>; |                 ^ expected type | help: expressions must be enclosed in braces to be used as const generic arguments | LL |     let _: Wow<{ [] }>; |                +    + </ins> error: expected type, found `12` --> $DIR/bad-const-generic-exprs.rs:19:17 | LL |     let _: Wow<[12]>; |                 ^^ expected type <del> error[E0747]: type provided when a constant was expected </del> <ins> error: invalid const generic expression </ins> --> $DIR/bad-const-generic-exprs.rs:19:16 | LL |     let _: Wow<[12]>; |                ^^^^ <ins> | help: expressions must be enclosed in braces to be used as const generic arguments | LL |     let _: Wow<{ [12] }>; |                +      + error: expected type, found `0` --> $DIR/bad-const-generic-exprs.rs:23:17 | LL |     let _: Wow<[0, 1, 3]>; |                 ^ expected type | help: expressions must be enclosed in braces to be used as const generic arguments | LL |     let _: Wow<{ [0, 1, 3] }>; |                +           + error: expected type, found `0xff` --> $DIR/bad-const-generic-exprs.rs:26:17 | LL |     let _: Wow<[0xff; 8]>; |                 ^^^^ expected type error: invalid const generic expression --> $DIR/bad-const-generic-exprs.rs:26:16 | LL |     let _: Wow<[0xff; 8]>; |                ^^^^^^^^^ | help: expressions must be enclosed in braces to be used as const generic arguments | LL |     let _: Wow<{ [0xff; 8] }>; |                +           + error: expected type, found `1` --> $DIR/bad-const-generic-exprs.rs:30:17 | LL |     let _: Wow<[1, 2]>; // Regression test for issue #81698. |                 ^ expected type | help: expressions must be enclosed in braces to be used as const generic arguments | LL |     let _: Wow<{ [1, 2] }>; // Regression test for issue #81698. |                +        + error: expected type, found `0` --> $DIR/bad-const-generic-exprs.rs:33:17 | LL |     let _: Wow<&0>; |                 ^ expected type | help: expressions must be enclosed in braces to be used as const generic arguments | LL |     let _: Wow<{ &0 }>; |                +    + error: expected type, found `""` --> $DIR/bad-const-generic-exprs.rs:36:17 | LL |     let _: Wow<("", 0)>; |                 ^^ expected type | help: expressions must be enclosed in braces to be used as const generic arguments | LL |     let _: Wow<{ ("", 0) }>; |                +         + error: expected type, found `1` --> $DIR/bad-const-generic-exprs.rs:39:17 | LL |     let _: Wow<(1 + 2) * 3>; |                 ^ expected type | help: expressions must be enclosed in braces to be used as const generic arguments | LL |     let _: Wow<{ (1 + 2) * 3 }>; |                +             + error: expected one of `,` or `>`, found `0` --> $DIR/bad-const-generic-exprs.rs:43:17 | LL |     let _: Wow<!0>; |         -       ^ expected one of `,` or `>` |         | |         while parsing the type for `_` | help: you might have meant to end the type parameters here | LL |     let _: Wow<!>0>; |                 + </ins> <del> error: aborting due to 6 previous errors </del> <ins> error: aborting due to 15 previous errors </ins> <del> For more information about this error, try `rustc --explain E0747`. </del>

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --This is a much abbreviated version of the code from my experiments with adding a shuffle API to the stdsimd repo, it probably needs further reduction but I wanted to file this before I forgot: I expected to see this happen: it works, provides a useful error, or even just ICEs. Instead, this happened: I got a request to input a type instead! And no, that doesn't work either if you put it in, because instead you get: : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The fix is Due to parsing ambiguities generic arguments currently need to be put into braces, unless they are really simple (like or ), is not simple enough.
Oh, cool! That does compile! I knew about that but wasn't sure if that was the problem because I thought that was just for expressions? I guess that's technically an array expression? That is none of the errors I was presented with, though, which makes this a diagnostics problem I suppose?
I believe diagnostic for const generic (example taken from ) needs to be improved too before release, at least I thought that can be used instead, if one didn't know about then they need to search it up.
Arrays as const parameters still have bad error messages. same with tuples
claim


Question: | NonMutatingUse(NonMutatingUseContext::Move) | NonMutatingUse(NonMutatingUseContext::Inspect) | NonMutatingUse(NonMutatingUseContext::Projection) <ins> | NonMutatingUse(NonMutatingUseContext::PlaceMention) </ins> | NonUse(_) => {} // These could be propagated with a smarter analysis or just some careful thinking about

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: You need edition 2015 or 2018 to reproduce this. `
Looks to me like the problem is that doesn't realize that a makes the place not dead.
The bug is . is a nonuse, but should get the same treatment as a . I feel obligated to mention that I have repeatedly warned that these bugs are going to happen. We should really stop using in optimizations. It was written for borrowck. (To be clear: I am as much at fault for this as anyone, I originally wrote this code).
I was wondering why always has strangely unhelpful information for optimizations...
Why is this not just a bug in PlaceContext assignment?
See my comment in the PR - in general, my understanding is that the definition of placecontext is what it is because that's what makes sense in some other part of the compiler. If we start changing placecontext now to have the information that's useful to optimizations, I worry we'll just end up making those parts of the compiler buggy


Question: } } <del> // FIXME(eddyb) do we need "not promotable" in anything // other than `Mode::Fn` by any chance? false </del> <ins> Self::in_operand(cx, callee) || args.iter().any(|arg| Self::in_operand(cx, arg)) </ins> } }

While attempting to build the current bobbin-sdk under Ubuntu 18.04 using rust 1.34.0-nightly ( 2019-02-26) I get a panic in rustc.
cc
Minimal repro: you need both the , a method call , and a method call on the result of that in order to trigger promotion. It seems like is promoted to make a for the call to
Ok, so promotion is indeed screwing up. The MIR is promoting the argument.
triage: P-high. Looks under control.
Just to confirm, this has not made it out to the nightly, correct? As of today I am still seeing the same error when attempting to build bobbin-hz as part of bobbin-sdk.
No, is still open, I'll bump its priority


Question: } } <del> // FIXME(eddyb) do we need "not promotable" in anything // other than `Mode::Fn` by any chance? false </del> <ins> Self::in_operand(cx, callee) || args.iter().any(|arg| Self::in_operand(cx, arg)) </ins> } }

ICE when compiling bash parity-ethereum git:(master) cargo build Compiling ethcore-miner v1.12.0 () thread 'rustc' panicked at 'index out of bounds: the len is 2 but the index is 3', stack backtrace: 0: std::sys::unix::backtrace::tracing::imp::unwindbacktrace at 1: std::syscommon::backtrace::print at 2: std::panicking::defaulthook::{{closure}} at at 3: std::panicking::defaulthook at 4: rustc::util::common::panichook 5: std::panicking::rustpanicwithhook at 6: std::panicking::continuepanicfmt at 7: rustbeginunwind at 8: core::panicking::panicfmt at 9: core::panicking::panicboundscheck at 10: <rustctarget::abi::TyLayout<'a, Ty::field 11: rustcmir::interpret::operand::<impl rustcmir::interpret::evalcontext::EvalContext<'a, 'mir, 'tcx, M::operandfield 12: rustcmir::interpret::operand::<impl rustcmir::interpret::evalcontext::EvalContext<'a, 'mir, 'tcx, M::evalplacetoop 13: rustcmir::interpret::step::<impl rustcmir::interpret::evalcontext::EvalContext<'a, 'mir, 'tcx, M::run 14: rustcmir::consteval::evalbodyusingecx 15: rustcmir::consteval::constevalrawprovider 16: rustc::ty::query::querycompute::constevalraw 17: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcxfor rustc::ty::query::queries::constevalraw<'tcx::compute 18: rustc::depgraph::graph::DepGraph::withtaskimpl 19: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx,


Question: } } <del> // FIXME(eddyb) do we need "not promotable" in anything // other than `Mode::Fn` by any chance? false </del> <ins> Self::in_operand(cx, callee) || args.iter().any(|arg| Self::in_operand(cx, arg)) </ins> } }

'tcx::getquery 20: rustcmir::consteval::constevalprovider 21: rustc::ty::query::querycompute::consteval 22: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcxfor rustc::ty::query::queries::consteval<'tcx::compute 23: rustc::depgraph::graph::DepGraph::withtaskimpl 24: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx::getquery 25: rustcmir::consteval::constevalprovider 26: rustc::ty::query::querycompute::consteval 27: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcxfor rustc::ty::query::queries::consteval<'tcx::compute 28: rustc::depgraph::graph::DepGraph::withtaskimpl 29: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx::getquery 30: rustcmir::monomorphize::collector::collectitemsrec 31: rustcmir::monomorphize::collector::collectcratemonoitems::{{closure}} 32: rustc::util::common::time 33: rustcmir::monomorphize::collector::collectcratemonoitems 34: rustc::util::common::time 35: rustcmir::monomorphize::partitioning::collectandpartitionmonoitems 36: rustc::ty::query::querycompute::collectandpartitionmonoitems 37: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcxfor rustc::ty::query::queries::collectandpartitionmonoitems<'tcx::compute 38: rustc::depgraph::graph::DepGraph::withtaskimpl 39: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx,


Question: } } <del> // FIXME(eddyb) do we need "not promotable" in anything // other than `Mode::Fn` by any chance? false </del> <ins> Self::in_operand(cx, callee) || args.iter().any(|arg| Self::in_operand(cx, arg)) </ins> } }

'tcx::getquery 40: rustccodegenssa::back::symbolexport::exportedsymbolsproviderlocal 41: rustc::ty::query::querycompute::exportedsymbols 42: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcxfor rustc::ty::query::queries::exportedsymbols<'tcx::compute 43: rustc::depgraph::graph::DepGraph::withtaskimpl 44: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx,


Question: } } <del> // FIXME(eddyb) do we need "not promotable" in anything // other than `Mode::Fn` by any chance? false </del> <ins> Self::in_operand(cx, callee) || args.iter().any(|arg| Self::in_operand(cx, arg)) </ins> } }

'tcx::getquery 45: rustcmetadata::encoder::encodemetadata 46: rustcmetadata::cstoreimpl::<impl rustc::middle::cstore::CrateStore for rustcmetadata::cstore::CStore::encodemetadata 47: rustc::ty::context::TyCtxt::encodemetadata 48: rustccodegenllvm::base::writemetadata 49: rustc::util::common::time 50: rustccodegenssa::base::codegencrate 51: <rustccodegenllvm::LlvmCodegenBackend as rustccodegenutils::codegenbackend::CodegenBackend::codegencrate 52: rustc::util::common::time 53: rustcdriver::driver::phase4codegen 54: rustcdriver::driver::compileinput::{{closure}} 55: <std::thread::local::LocalKey<T::with 56: rustc::ty::context::TyCtxt::createandenter 57: rustcdriver::driver::compileinput 58: rustcdriver::runcompilerwithpool 59: <scopedtls::ScopedKey<T::set 60: rustcdriver::runcompiler 61: syntax::withglobals 62: rustmaybecatchpanic at 63: <F as alloc::boxed::FnBox<A::callbox 64: std::sys::unix::thread::Thread::new::threadstart at at at 65: startthread 66: _clone query stack during panic: [constevalraw] const-evaluating [consteval] const-evaluating + checking [consteval] const-evaluating + checking [collectandpartitionmonoitems] collectandpartitionmonoitems [exportedsymbols] exportedsymbols end of query stack error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: rustc 1.34.0-nightly ( 2019-02-21) running on x8664-unknown-linux-gnu note: compiler flags: -C debuginfo=2 -C incremental --crate-type lib note: some of the compiler flags provided by cargo are hidden error: Could not compile . warning: build failed, waiting for other jobs to finish... error: build failed
cc
Is this a regression?


Question: } } <del> // FIXME(eddyb) do we need "not promotable" in anything // other than `Mode::Fn` by any chance? false </del> <ins> Self::in_operand(cx, callee) || args.iter().any(|arg| Self::in_operand(cx, arg)) </ins> } }

Did it work with a previous nightly? I'm currently looking through function (the ICE is during the evaluation of a promoted inside that function), but I can't find any promoteds :confused:
I can't debug this right now, because a debugging compiler fails even earlier:
So apparently still causes the ICE, but only inside the crate. If I try to create an MCVE everything compiles just fine... Very confusing.
triage: P-high. Looks to be in good hands.
Thanks, I can verify that it is fixed in


Question: args: vec![Operand::Consume(data.value.clone())], destination: Some((unit_temp, target)), cleanup: None <del> }); block </del> <ins> } </ins> }

This generates the following (broken) MIR: As you can see, is dropped but never written to (AFAIK this should be OK because of zeroing) but the boxes are never freed.
cc
EDIT: I wasn’t looking closely enough, it is indeed broken.
This is a problem on latest master ()


Question: <ins> // Copyright 2015 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. pub fn main() { let f = || || 0; std::thread::spawn(f()); } </ins>

I can confirm this is still an issue with the latest 1.0 beta:
I get the same error with both stable and nightly with:
These examples compile on Playpen Nightly.
I'll go ahead and add regression tests for this


Question: } } <ins> fn get_rustfmt_version(build: &Builder<'_>) -> Option<(String, PathBuf)> { let stamp_file = build.out.join("rustfmt.stamp"); let mut cmd = Command::new(match build.initial_rustfmt() { Some(p) => p, None => return None, }); cmd.arg("--version"); let output = match cmd.output() { Ok(status) => status, Err(_) => return None, }; if !output.status.success() { return None; } Some((String::from_utf8(output.stdout).unwrap(), stamp_file)) } /// Return whether the format cache can be reused. fn verify_rustfmt_version(build: &Builder<'_>) -> bool { let Some((version, stamp_file)) = get_rustfmt_version(build) else {return false;}; !program_out_of_date(&stamp_file, &version) } /// Updates the last rustfmt version used fn update_rustfmt_version(build: &Builder<'_>) { let Some((version, stamp_file)) = get_rustfmt_version(build) else {return;}; t!(std::fs::write(stamp_file, version)) } /// Returns the files modified between the `merge-base` of HEAD and /// rust-lang/master and what is now on the disk. /// /// Returns `None` if all files should be formatted. fn get_modified_files(build: &Builder<'_>) -> Option<Vec<String>> { let Ok(remote) = get_rust_lang_rust_remote() else {return None;}; if !verify_rustfmt_version(build) { return None; } Some( output( build .config .git() .arg("diff-index") .arg("--name-only") .arg("--merge-base") .arg(&format!("{remote}/master")), ) .lines() .map(|s| s.trim().to_owned()) .collect(), ) } /// Finds the remote for rust-lang/rust. /// For example for these remotes it will return `upstream`. /// ```text /// origin  https://github.com/Nilstrieb/rust.git (fetch) /// origin  https://github.com/Nilstrieb/rust.git (push) /// upstream        https://github.com/rust-lang/rust (fetch) /// upstream        https://github.com/rust-lang/rust (push) /// ``` fn get_rust_lang_rust_remote() -> Result<String, String> { let mut git = Command::new("git"); git.args(["config", "--local", "--get-regex", "remote..*.url"]); let output = git.output().map_err(|err| format!("{err:?}"))?; if !output.status.success() { return Err("failed to execute git config command".to_owned()); } let stdout = String::from_utf8(output.stdout).map_err(|err| format!("{err:?}"))?; let rust_lang_remote = stdout .lines() .find(|remote| remote.contains("rust-lang")) .ok_or_else(|| "rust-lang/rust remote not found".to_owned())?; let remote_name = rust_lang_remote.split('.').nth(1).ok_or_else(|| "remote name not found".to_owned())?; Ok(remote_name.into()) } </ins> #[derive(serde::Deserialize)] struct RustfmtConfig { ignore: Vec<String>,

Since rustfmt is deterministic and idempotent, running it twice on the same file should always have the same output (if it's not both of those things, it's a bug). So we can avoid running it unless the file has changed, which should make without arguments much faster. Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This will need to be careful to still rerun rustfmt when we bump its version (which happens about every 6 weeks). Maybe we can generate a file and format everything if it doesn't yet exist or has the wrong version.
Hello, I want to work on that. How would the detection of modified files work ?
you can use to see modified files. Make sure to fall back to formatting all files if that command fails for some reason, we support building from source tarballs without git installed.
This means that already-commited files that were not formatted when committed would not be formatted, right ?
Ah, good point. You can use to find where the two diverged and compare all files since then. And should still look at all files unconditionally.
Thanks, I will start working on this ! claim
That assumes that the rust-lang remote is labeled as origin. I call that upstream and my fork origin. Using the local master may also not work if one does on branch.
Yes, has a more general solution.
PR is up at


Question: <ins> // error-pattern: this file contains an unclosed delimiter // error-pattern: this file contains an unclosed delimiter // error-pattern: expected pattern, found `=` // error-pattern: expected one of `)`, `,`, `->`, `where`, or `{`, found `]` // error-pattern: expected item, found `]` fn main() {} fn p([=(} </ins>

<!-- 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. --Another case from : The md5 of is: <!-- 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. --It is test with nightly, beta, and stable versions. : The output is from nightly. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Because we already emit some correct errors a potential fix would be to just remove the problematic and return an empty function body. However there's another problem; call in generates non-existing tokens outside of the file to close all unmatched brackets. That's why we see column 11 in the error message even though column of the last token is 9 in the source file. called by (called by to recover from the invlid argument when seeing which is invalid in pattern context) first generates at column 9 (which is actually the location of ), which I guess (didn't check) shifts to column 10, which is somehow skipped and some other function inserts (couldn't figure out which function) at column 11. As a result we get this error that points to outside of the file
Is there an expected buffer overrun here or is it guarded?
Assigning as discussed as part of the and removing .
I ran  and some finer-grained manual bisection. The regression happened in cc
I'm guessing is because of this code branch: I haven't checked to see how it could even get to it, as looking at the code it should be unreachable.
Actually, this is caused by a different problem (), because if you try the same code without a trailing newline, this behavior doesn't occur (the error message then points to column 10, which is correct, as it is the location of the EOF token). The spurious ]` is an unrelated issue, which I have filed separately ().
Fixed by but there's no regression test for this case, marking as E-needs-test.


Question: #[derive(Copy, Clone, Debug)] pub struct Discr<'tcx> { <ins> /// bit representation of the discriminant, so `-128i8` is `0xFF_u128` </ins> pub val: u128, pub ty: Ty<'tcx> } impl<'tcx> fmt::Display for Discr<'tcx> { fn fmt(&self, fmt: &mut fmt::Formatter) -> fmt::Result { <del> if self.ty.is_signed() { write!(fmt, "{}", self.val as i128) } else { write!(fmt, "{}", self.val) </del> <ins> match self.ty.sty { ty::TyInt(ity) => { let bits = ty::tls::with(|tcx| { Integer::from_attr(tcx, SignedInt(ity)).size().bits() }); let x = self.val as i128; // sign extend the raw representation to be an i128 let x = (x << (128 - bits)) >> (128 - bits); write!(fmt, "{}", x) }, _ => write!(fmt, "{}", self.val), </ins> } } }

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


Question: } enum XYZ { <del> X, //~ ERROR variant is never used Y { //~ ERROR variant is never used </del> <ins> X, //~ ERROR variant is never constructed Y { //~ ERROR variant is never constructed </ins> a: String, b: i32, c: i32,

I was changing some code from integer constants to a proper enum and was greeted by the following warning: The warning sounded weird to me because I was pattern-matching on that damn variant in various places of the code; but I was pointed out to the fact that I wasn't actually creating that value. Maybe the warning should be rewritten to explicitly mention value creation? Cc
cc that looks like your thing
duplicate of
Yup! Closing in favor of that.


Question: <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>

<!-- 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).


Question: <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>

Gives:
cc ICE-ing instead of user error on misuse seems somewhat okay given that it's an internal attribute, IMO.
agreed. We don't protect against mis-use of rustc internal attributes beyond making sure that you can't trivially create buggy code. I don't think we should put any effort into making this nicer to use and instead create the const-generic based replacement.


Question: <ins> error[E0277]: the trait bound `[T; _]: From<()>` is not satisfied --> $DIR/hash-tyvid-regression-1.rs:9:5 | LL |     <[T; N.get()]>::try_from(()) |     ^^^^^^^^^^^^^^^^^^^^^^^^ the trait `From<()>` is not implemented for `[T; _]` | = note: required because of the requirements on the impl of `Into<[T; _]>` for `()` = note: required because of the requirements on the impl of `TryFrom<()>` for `[T; _]` note: required by `try_from` --> $SRC_DIR/core/src/convert/mod.rs:LL:COL | LL |     fn try_from(value: T) -> Result<Self, Self::Error>; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error[E0308]: mismatched types --> $DIR/hash-tyvid-regression-1.rs:9:5 | LL |     <[T; N.get()]>::try_from(()) |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `()`, found enum `Result` | = note: expected unit type `()` found enum `Result<[T; _], Infallible>` help: consider using a semicolon here | LL |     <[T; N.get()]>::try_from(()); |                                 + help: try adding a return type | LL | -> Result<[T; _], Infallible> where | +++++++++++++++++++++++++++++ error: aborting due to 2 previous errors Some errors have detailed explanations: E0277, E0308. For more information about an error, try `rustc --explain E0277`. </ins>

<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --I'm creating this issue mainly because it seems to be a different one than the ones listed in <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
What command are you running? I tried this code , but I encountered an error that doesn't have a method.
how strange, for me just causes the ice and it doesn't even come to notice that the function is missing. I just ran , and with the newest rustc () I still get the same error as above (in a new cargo project with the code copied from the playground link above).
Just ran again today and still get an ICE. Made the example a bit smaller: Output of (build also fails with the same message): Considering the rustc versions it should be the same that is currently on the playground, however there it does not cause an ICE. Maybe someone could try to reproduce this in a local environment?
can reproduce this locally, not sure why it doesn't ICE on the playground
cc -- it ICEs locally, but not on the playground
Try with ?
That indeed removes the ICE, let me just check which one of the options it is. Adding to the (or profile.release in release mode) section causes the ice to disappear.
That's even weirder. Seems like this is partly an incr-comp bug then.
Note that the ICE occurs in the incr-comp hasher (ICH): So this seems to be an incr-comp bug.
Reposting : So I removed .


Question: <ins> error[E0277]: the trait bound `[T; _]: From<()>` is not satisfied --> $DIR/hash-tyvid-regression-1.rs:9:5 | LL |     <[T; N.get()]>::try_from(()) |     ^^^^^^^^^^^^^^^^^^^^^^^^ the trait `From<()>` is not implemented for `[T; _]` | = note: required because of the requirements on the impl of `Into<[T; _]>` for `()` = note: required because of the requirements on the impl of `TryFrom<()>` for `[T; _]` note: required by `try_from` --> $SRC_DIR/core/src/convert/mod.rs:LL:COL | LL |     fn try_from(value: T) -> Result<Self, Self::Error>; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error[E0308]: mismatched types --> $DIR/hash-tyvid-regression-1.rs:9:5 | LL |     <[T; N.get()]>::try_from(()) |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `()`, found enum `Result` | = note: expected unit type `()` found enum `Result<[T; _], Infallible>` help: consider using a semicolon here | LL |     <[T; N.get()]>::try_from(()); |                                 + help: try adding a return type | LL | -> Result<[T; _], Infallible> where | +++++++++++++++++++++++++++++ error: aborting due to 2 previous errors Some errors have detailed explanations: E0277, E0308. For more information about an error, try `rustc --explain E0277`. </ins>

<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<details<summary<strongQuery Stack</strong</summary<p</p</details
modify labels to +requires-nightly
The following snippet gives the same ICE. The types are intentionally wrong. <details<summary<strongBacktrace</strong</summary<p</p</details<details<summary<strongQuery Stack</strong</summary<p</p</details
Triage: This is now fixed on the recent nightly, marking as E-needs-test.


Question: But it *does not* match `Result<Vec, u8>` or `Result<u8<Vec>>`. <del> ### Changing displayed theme You can change the displayed theme by opening the settings menu (the gear icon in the upper right) and then pick a new one from there. </del> ### Shortcuts Pressing `S` while focused elsewhere on the page will move focus to the

Rustdoc has accumulated a handful of settings that users can toggle as they read docs, but we don't document them anywhere. It would be ideal if we had some documentation about these options in the Rustdoc Book that described their functionality better than the short descriptions shown on the settings page itself. !
I don't mind picking this up, unless you want to do this yourself! I do however have some questions!: The Rustdoc book you mean is right? Do you suggest adding a new section to this book or would you include it in an already existing section? What do you believe is not clear / elaborated enough in the short descriptions? I do not know the specific details of each switch are there any side-effects that are not in the short description?
Triage: no changes. The rustdoc book is that one, ! I am not a rustdoc maintainer these days (cc ) but I would probably make a new section. While the short description is good, I think it would make sense to show the options in slightly more detail, for example, maybe a before/after.
Bit of a late reply :) Do you have something to add to this? Otherwise I will follow what Steve said!


Question: nested: Vec<Ty<'tcx>>) -> VtableBuiltinData<PredicateObligation<'tcx>> { <del> let derived_cause = self.derived_cause(obligation, BuiltinDerivedObligation); let obligations = nested.iter().map(|&bound_ty| { // the obligation might be higher-ranked, e.g. for<'a> &'a // int : Copy. In that case, we will wind up with // late-bound regions in the `nested` vector. So for each // one we instantiate to a skolemized region, do our work // to produce something like `&'0 int : Copy`, and then // re-bind it. This is a bit of busy-work but preserves // the invariant that we only manipulate free regions, not // bound ones. self.infcx.try(|snapshot| { let (skol_ty, skol_map) = self.infcx().skolemize_late_bound_regions(&ty::Binder(bound_ty), snapshot); let skol_predicate = util::predicate_for_builtin_bound( self.tcx(), derived_cause.clone(), bound, obligation.recursion_depth + 1, skol_ty); match skol_predicate { Ok(skol_predicate) => Ok(self.infcx().plug_leaks(skol_map, snapshot, &skol_predicate)), Err(ErrorReported) => Err(ErrorReported) } }) }).collect::<Result<_, _>>(); let obligations = match obligations { Ok(o) => o, Err(ErrorReported) => Vec::new(), </del> <ins> let trait_def = match self.tcx().lang_items.from_builtin_kind(bound) { Ok(def_id) => def_id, Err(_) => { self.tcx().sess.bug("builtin trait definition not found"); } </ins> }; <ins> let obligations = self.collect_predicates_for_types(obligation, trait_def, nested); </ins> let obligations = VecPerParamSpace::new(obligations, Vec::new(), Vec::new()); debug!("vtable_builtin_data: obligations={}",

For example, this code does not compile: cc
I think this may be another instance of
Trusting analysis, closing in favor of but adding test case there as well.
(it of course would be good to confirm that this actually is an instance of -- my initial reaction when I saw it was "they might be related ... but wait, wasn't part of the opt-in-builtin-bounds work to be able to move the special case handling of / out into library code...?"; I've only done some rough skimming that makes me think the hypothesis remains plausible.)
Ah either way is fine by me, I personally like fewer issues :). We can reopen once is addressed one way or another if necessary (or if you'd like to reopen now that's also fine by me!)
oh that was really just a note to myself as much as anything else, not a comment on your choice to close this ticket. :)
I don't think this code uses type-contents. If it does, that is itself a bug! Either way, we should keep this open for the time being.
cc


Question: nested: Vec<Ty<'tcx>>) -> VtableBuiltinData<PredicateObligation<'tcx>> { <del> let derived_cause = self.derived_cause(obligation, BuiltinDerivedObligation); let obligations = nested.iter().map(|&bound_ty| { // the obligation might be higher-ranked, e.g. for<'a> &'a // int : Copy. In that case, we will wind up with // late-bound regions in the `nested` vector. So for each // one we instantiate to a skolemized region, do our work // to produce something like `&'0 int : Copy`, and then // re-bind it. This is a bit of busy-work but preserves // the invariant that we only manipulate free regions, not // bound ones. self.infcx.try(|snapshot| { let (skol_ty, skol_map) = self.infcx().skolemize_late_bound_regions(&ty::Binder(bound_ty), snapshot); let skol_predicate = util::predicate_for_builtin_bound( self.tcx(), derived_cause.clone(), bound, obligation.recursion_depth + 1, skol_ty); match skol_predicate { Ok(skol_predicate) => Ok(self.infcx().plug_leaks(skol_map, snapshot, &skol_predicate)), Err(ErrorReported) => Err(ErrorReported) } }) }).collect::<Result<_, _>>(); let obligations = match obligations { Ok(o) => o, Err(ErrorReported) => Vec::new(), </del> <ins> let trait_def = match self.tcx().lang_items.from_builtin_kind(bound) { Ok(def_id) => def_id, Err(_) => { self.tcx().sess.bug("builtin trait definition not found"); } </ins> }; <ins> let obligations = self.collect_predicates_for_types(obligation, trait_def, nested); </ins> let obligations = VecPerParamSpace::new(obligations, Vec::new(), Vec::new()); debug!("vtable_builtin_data: obligations={}",

The following doesn't compile, but I believe it should: Error: Even though , and . In fact, this compiles:
should be , because the old definition that didn't use assoc types was . Probably the code that detects builtin bounds wasn't updated to handle associated types. cc
This breaks us in hyper. For now, I'll have to manually , knowing that it's safe.,,


Question: target_option_val!(exe_suffix); target_option_val!(staticlib_prefix); target_option_val!(staticlib_suffix); <del> target_option_val!(os_family, "target_family"); </del> <ins> target_option_val!(os_family, "target-family"); </ins> target_option_val!(abi_return_struct_as_int); target_option_val!(is_like_osx); target_option_val!(is_like_solaris);

Hello everyone, this is my first Issue on the Rust project, let me know if I'm doing anthing wrong ! I am in the process of building a library/runtime for the Wii fully written in Rust. To acheive this goal, I need to cross-compile my library to a custom target I named . The json file contains and along other lines to define the architecture. Normally, the build completes without an issue. On the latest nighlty, the compiler fails and return: Of course, is set to in the file, so this shouldn't happen. It most recently worked on: : It fails on this nightly, currently latest at the time of writing: : I can provide any file or other precision if necessary ! Thanks for reading my report !
I was also having the some issue and tracked it to this: That commit broke the equivalence between "target_endian" and "target-endian" by adding a case to the macro without the replace line for it.
cc
I'll fix this today.
Fixed in
I hope this gets merged asap :-)
(Reopening because isn't merged yet.)


Question: <ins> warning: the feature `const_generics` is incomplete and may cause the compiler to crash --> $DIR/cannot-infer-type-for-const-param.rs:1:12 | LL | #![feature(const_generics)] |            ^^^^^^^^^^^^^^ error[E0282]: type annotations needed --> $DIR/cannot-infer-type-for-const-param.rs:10:19 | LL |     let _ = Foo::<3>([1, 2, 3]); |                   ^ cannot infer type for `{integer}` error: aborting due to previous error For more information about this error, try `rustc --explain E0282`. </ins>

Following code sample causes a compiler panic. should be .
Also happens on nightly. Likely due to const generics changes (cc
Minimal reproduction:
Another case:


Question: /// # Examples /// /// ``` <del> /// # #![feature(duration_as_u128)] </del> /// use std::time::Duration; /// /// let duration = Duration::new(5, 730023852); /// assert_eq!(duration.as_micros(), 5730023); /// ``` <del> #[unstable(feature = "duration_as_u128", issue = "50202")] </del> <ins> #[stable(feature = "duration_as_u128", since = "1.33.0")] </ins> #[inline] pub const fn as_micros(&self) -> u128 { self.secs as u128 * MICROS_PER_SEC as u128 + (self.nanos / NANOS_PER_MICRO) as u128

Duration has historically lacked a way to get the actual number of nanoseconds it contained as a normal Rust type because u64 was of insufficient range, and f64 of insufficient precision. The u128 type solves both issues, so I propose adding an as_nanos function to expose the capability. CC:
I still don't understand why Duration is not allowed to be negative. It bugs me that the SystemTime difference returns a Result<Duration,Errorand returns and error if the time from is after the time to. To me, it should just return a negative Duration (Yes, the System Clock can go backwards). I find it odd that Duration does not support a negative amount.
I think it's about the way you think of . If it's a span of time (like described in the documentation) or an interval, then it must be positive. If it's the distance between two time points, it's negative. You're probably thinking of a distance instead of an interval. That's not necessarily a bad thing, but it's different from what the type is today, and it will never change due to compatibility concerns.
Here is what I take issue with: And....DING! DING! DING! know what, now that I've typed out that code, I can't think of any justifiable reason I would actually want that, so, once again, the thoughtfulness of Rust shows itself. You and the designers of Duration were correct. Negative Duration doesn't make sense (even though it feels like it should).
You can use if you want to measure a duration.
Yes, I'm aware. I guess I think there should be another thing called ClockTimeDifference (that can be neg/pos) and there should be methods on SystemTime that don't return Result<Duration,Error, but, instead return ClockTimeDifference. It could be as simple as:
It can, but the return type of will never change, so it's up to you (or a crate) to implement that.
This is the tracking issue for a feature that adds several specific methods to Duration, not a place to debate general concerns about the Duration type. Your discussion is probably better suited for the site.
Why can't as_millis return an i64?
large durations won't fit into that type.
Pardon my ignorance, but why is this unstable?


Question: /// # Examples /// /// ``` <del> /// # #![feature(duration_as_u128)] </del> /// use std::time::Duration; /// /// let duration = Duration::new(5, 730023852); /// assert_eq!(duration.as_micros(), 5730023); /// ``` <del> #[unstable(feature = "duration_as_u128", issue = "50202")] </del> <ins> #[stable(feature = "duration_as_u128", since = "1.33.0")] </ins> #[inline] pub const fn as_micros(&self) -> u128 { self.secs as u128 * MICROS_PER_SEC as u128 + (self.nanos / NANOS_PER_MICRO) as u128

For my usecase, I probably don't need more than a , and I really only need millis (though the code I'm porting happens to use microseconds). I'd rather have a , but I'm just not sure what to do here for my code which I'm trying to keep as close to fully stable as possible (I want it to be as portable and safe as I can make it). I know (I think?) I can use , but I'd rather not lose the precision and I think I can always use for all my platforms.
is there any reason not to move forward with stabilization on this? correctly observes that it has been unstable for quite a while
The stability of u128 was the blocker previously, but that's now no longer a problem. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
I couldn’t find all the details in this issue, grepping through the code shows that this tracking issue is for:
This may be a stupid question, but is available on all platforms that Rust supports?
:bell: This is now entering its final comment period, as per the . :bell:
Yep, it should be available on all platforms.
The final comment period, with a disposition to merge, as per the , is now complete.
Now that final comment period has ended, can these methods be stabilized?
Yes, the next step is a stabilization PR.
Awesome! I've made a PR for stabilization here: Please let me know if it needs any adjustments. I can't wait for this to land! :tada:


Question: use m::*; <del> // The variant `Same` introduced by this import is not considered when resolving the prefix // `Same::` during import validation (issue #62767). use Same::Same; </del> <ins> // The variant `Same` introduced by this import is also considered when resolving the prefix // `Same::` during import validation to avoid effects similar to time travel (#74556). use Same::Same; //~ ERROR unresolved import `Same` // Case from #74556. mod foo { pub mod bar { pub mod bar { pub fn foobar() {} } } } use foo::*; use bar::bar; //~ ERROR unresolved import `bar::bar` //~| ERROR inconsistent resolution for an import use bar::foobar; </ins> fn main() {}

I tried this code: I expected to see this happen: Compilation error. This shadows one (glob-imported) with another . As far as I know, this should be forbidden. Instead, this happened: this code successfully compiled. : c.c. c.c.
Shadowing a glob import with a specific item is allowed and will unambiguously resolve to the specific one. This is also how the prelude works. The following compiles fine as well: .
To clarify, the problem is not shadowing, but time travel. We shadow identifier which have been already used to resolve another import, so we end up with meaning two things at the same time in the same scope.
This is a change from Rust 1.44, in Rust 1.43 this is an ICE "inconsistent resolution for an import". Possibly a consequence of
I'm not sure this is a bug. When resolving we are looking at all names in scope except for the names introduced by itself. Otherwise we'd have cycles even in trivial cases like where is a name from extern prelude. If you take this detail into consideration, then all paths seem to be resolved correctly.
cc (somewhat related)
I think, the difference with is that doesn't replace one resolution with another. We already have a name in the scope that is resolved to a particular extern crate. In my example, uses name from the scope, and then rebinds this name to another item. I can complicate my example a bit. What this program prints, "111" or "222"? It'd say, it depends on imports resolution order, but looks like it always prints "111".
It'd say, it depends on imports resolution order The intent for the resolution results is to never depend on internal resolution order. (cc , order-dependence can probably happen in practice due to the current not very principled implementation, but hopefully still can be eliminated in backward-compatible-in-practice way by rewriting the main resolution/expansion loop more carefully.) but looks like it always prints "111" That's what I'd expect. resolves to in resolves to (because non-globs shadow globs) first in resolves to (which the only in scope after excluding itself)
I'd still be ok with replacing the former ICE with an error though, since that's a more conservative choice.


Question: use m::*; <del> // The variant `Same` introduced by this import is not considered when resolving the prefix // `Same::` during import validation (issue #62767). use Same::Same; </del> <ins> // The variant `Same` introduced by this import is also considered when resolving the prefix // `Same::` during import validation to avoid effects similar to time travel (#74556). use Same::Same; //~ ERROR unresolved import `Same` // Case from #74556. mod foo { pub mod bar { pub mod bar { pub fn foobar() {} } } } use foo::*; use bar::bar; //~ ERROR unresolved import `bar::bar` //~| ERROR inconsistent resolution for an import use bar::foobar; </ins> fn main() {}

Actually enabling the property "name resolve to the same thing whether some items were excluded during its resolution to avoid cycles or not" may be useful for using something like "inference variables" for unresolved imports and making import resolution more like unification in type inference. That's an idea I had for quite some, but I hadn't realized that merging went against it.
Sigh, the issue already affects three stable releases - from 1.44 to 1.46. I'll try to prioritize it.
Addressed in
Assigning so this isn't lost. See the .
The fix caused some regressions -
The code in the issue produce no errors using Rust 1.67.1. Should we re-open the issue or is it not considered a bug now?
The fix was reverted due to breakage () and the current behavior is considered by design since then.
(Also it's not exactly a time travel - )