Question: <ins> error[E0308]: mismatched types --> $DIR/issue-46112.rs:19:21 | 19 | fn main() { test(Ok(())); } |                     ^^ |                     | |                     expected enum `std::option::Option`, found () |                     help: try using a variant of the expected type: `Some(())` | = note: expected type `std::option::Option<()>` found type `()` error: aborting due to previous error </ins>

On nightly rustc (cargo) I get misleading expected type errors. If a crate has the same(?) type it is displayed instead of the std type. I tried this code: I expected to see this happen: (stable rust) Instead, this happened: (nightly) :
Confirming - broken on nightly (1.23), good on beta.
bisected across nightlys: bug was injected between and
Skimming output from , there are a number of different potential culprits. Rather than guess and "point fingers" right now, I'll just continue bisecting within that commit range.
This is recent enough that we should be able to run bisect-rust on it (cc
it is cc .
I'm a little surprised that this would be caused by that PR. I can push a revert but would like to first test locally to make sure that revert that PR will fix this.
I have misread 's statement. Your PR is not at fault, sorry. I'm doing another search further back to find the causing PR.
I tried it locally in the meantime and I can confirm it is not :)
Okay so the bug dates as far back as from September 2nd which is as close to the limit as I dare to go. So to the people in control, please, prolong the limit :).
suggests that the bug was introduced much more recently (11-08 to 11-09). Maybe the bisection script was wrong?
I should probably have read the original issue more closely :). sorry for pinging you! It seems to be cc
In particular, I have bisected it down to the commit: I have been trying to further dissect that commit to figure out why it causes the change we observe here. My current hypothesis (that I have not yet managed to confirm) is that it has to do with how we seed the hashmap's hashers with randomized state. (This commit changes our behavior in certain scenarios.) If this hypothesis is actually true, though, then I would think that this represents either a bug in hashmap itself, or a bug in how the compiler is using the hashmap...
Hmm. Its something more subtle than a hashmap-related bug.


Question: <ins> error[E0308]: mismatched types --> $DIR/issue-46112.rs:19:21 | 19 | fn main() { test(Ok(())); } |                     ^^ |                     | |                     expected enum `std::option::Option`, found () |                     help: try using a variant of the expected type: `Some(())` | = note: expected type `std::option::Option<()>` found type `()` error: aborting due to previous error </ins>

In particular, I can reproduce the old behavior on master by just linking in the old crate into (in addtion to linking in the one from ; doing this requires changing the name of the old ), without making any actual calls into the old crate. That, to me, seems very strange. I'm now trying to reduce down the size of the crate that I am linking in (while still causing this delta in behavior).
triage: P-high
I still get a non std types in erros when the path has the same length. That would be okay if it is somehow deterministic, but I get different type errors within the same file for the same types.
is that a regression from the stable channel? While I absolutely agree that a deterministic result would be better (and better stilll, a deterministic result that favored minimal-length paths rooted at ), I want to triage this appropriately.
Hmm I guess since is the person who filed the original ticket then it is reasonable to infer that they are indeed seeing the described regression compared to the stable channel.
gives me: seems to work now: Maybe this was some sort of partial compile cache issue? I haven't found a way to reproduce these mixed errors yet.
This looks like a duplicate of . That issue has some repro cases that affect the 1.22.1 stable compiler but not 1.21.0.
When I bisected the nightlies by hand on I ended up with a range (...) that does not include the commit identified here. Is it possible that the nondeterministic nature of the bug is also messing with our attempts to bisect? I wonder whether merely linking affects in the same way as it affected this issue.
Any evidence of this problem existing with the newest nightly?
All the cases I tried seem to have been fixed by and . Nicely done! I reported one follow-up in .


Question: options: TargetOptions { // Info about features at https://wiki.debian.org/ArmHardFloatPort <del> features: "+v7,+vfp3,+d16,+thumb2".to_string(), </del> <ins> features: "+v7,+vfp3,+d16,+thumb2,-neon".to_string(), </ins> cpu: "generic".to_string(), max_atomic_width: 64, .. base

I was just investigating a that Fedora's rust binaries for armv7hl use NEON, but they should not per , supposedly fixed in . (Fedora's build is 1.11, but I applied that patch.) I can see the exact same issue in the latest official , whose version file says . In particular, they flagged that as a problem. I'm no ARM expert, but from it appears the registers are NEON-only. I believe those instructions using are also a problem, because with VFP3-D16 we should only have to .
Hm looks like it's definitely still there:
( TIL of ! :open_mouth: )
Just to confirm: No . This doesn't explicitly mention vs. though. I ran on all binaries in . I see no mention of NEON registers. I see uses of -, but no higher, so I think is OK too. I'll know better if someone with a limited armv7 actually tries to run this, but LGTM!
Thanks for the confirmation


Question: OverloadedOperator, ClosureInvocation, ForLoop, <ins> MatchDiscriminant </ins> } #[deriving(PartialEq,Show)]

Sorry for not providing smaller case but I hope this is better than nothing: Both versions works (compile and start), but runtime behavior changes. The code that follows the above part: will match no matter what really is, if the value is partially moved (so mouse events are updating my game). If I use the version with , the code works as intended and game is updated only on keyboard presses.
Minimal: This shouldn't compile at all.
Nominating.
Looks like a regression. 0.10 rejects this code.


Question: key!(limit_rdylib_exports, bool); key!(override_export_symbols, opt_list); key!(merge_functions, MergeFunctions)?; <del> key!(mcount = "target_mcount"); </del> <ins> key!(mcount = "target-mcount"); </ins> key!(llvm_abiname); key!(relax_elf_relocations, bool); key!(llvm_args, list);

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: id: fld.new_id(a.id), } } //used in noop_fold_expr, and possibly elsewhere in the future fn fold_mac_(m: &mac, fld: @ast_fold) -> mac { spanned { <del> node: match m.node { mac_invoc_tt(*) => copy m.node }, span: fld.new_span(m.span), </del> <ins> node: match m.node { mac_invoc_tt(p,ref tts) => mac_invoc_tt(fld.fold_path(p), fold_tts(*tts,fld)) }, span: fld.new_span(m.span) } } fn fold_tts(tts : &[token_tree], fld: @ast_fold) -> ~[token_tree] { do tts.map |tt| { match *tt { tt_tok(span, ref tok) => tt_tok(span,maybe_fold_ident(tok,fld)), tt_delim(ref tts) => tt_delim(fold_tts(*tts,fld)), tt_seq(span, ref pattern, ref sep, is_optional) => tt_seq(span, fold_tts(*pattern,fld), sep.map(|tok|maybe_fold_ident(tok,fld)), is_optional), tt_nonterminal(sp,ref ident) => tt_nonterminal(sp,fld.fold_ident(*ident)) } } } // apply ident folder if it's an ident, otherwise leave it alone fn maybe_fold_ident(t : &token::Token, fld: @ast_fold) -> token::Token { match *t { token::IDENT(id,followed_by_colons) => token::IDENT(fld.fold_ident(id),followed_by_colons), _ => copy *t </ins> } }

See the case in .
Not critical for 0.6; de-milestoning
-- does it make sense for the AST fold to visit macros? Or is the current code correct?
From my perspective: yes, definitely. In particular, I'm going to want ident-folds to hit the idents inside of macro invocations. Could it break code to add this traversal? Well, the only place you're going to see unexpanded macro invocations is prior to expansion, and the only thing inside of macro invocations is tokens, so it seems very unlikely. To summarize: yes, this fold should visit macro invocations.
In that case, nominating for milestone 5, production-ready
accepted for production-ready milestone
I've implemented this in a local branch, I expect to push it soon (next two days)
done, now. FIXME removed downstream.


Question: self.fields.infcx.tcx } <ins> fn relate_item_args( &mut self, item_def_id: rustc_hir::def_id::DefId, a_arg: ty::GenericArgsRef<'tcx>, b_arg: ty::GenericArgsRef<'tcx>, ) -> RelateResult<'tcx, ty::GenericArgsRef<'tcx>> { if self.ambient_variance == ty::Variance::Invariant { // Avoid fetching the variance if we are in an invariant // context; no need, and it can induce dependency cycles // (e.g., #41849). relate_args_invariantly(self, a_arg, b_arg) } else { let tcx = self.tcx(); let opt_variances = tcx.variances_of(item_def_id); relate_args_with_variances(self, item_def_id, opt_variances, a_arg, b_arg, false) } } </ins> fn relate_with_variance<T: Relate<'tcx>>( &mut self, variance: ty::Variance,

<!-- 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
related. label F-inherentassociatedtypes
It caused by a cycle query:
There's a related bug to this (I believe by involving some traits with associated types) that I would like to report, though I was able to raise mine on Stable (1.70.0) without using the feature flag. Should I make a separate bug report or attach it here?


Question: self.fields.infcx.tcx } <ins> fn relate_item_args( &mut self, item_def_id: rustc_hir::def_id::DefId, a_arg: ty::GenericArgsRef<'tcx>, b_arg: ty::GenericArgsRef<'tcx>, ) -> RelateResult<'tcx, ty::GenericArgsRef<'tcx>> { if self.ambient_variance == ty::Variance::Invariant { // Avoid fetching the variance if we are in an invariant // context; no need, and it can induce dependency cycles // (e.g., #41849). relate_args_invariantly(self, a_arg, b_arg) } else { let tcx = self.tcx(); let opt_variances = tcx.variances_of(item_def_id); relate_args_with_variances(self, item_def_id, opt_variances, a_arg, b_arg, false) } } </ins> fn relate_with_variance<T: Relate<'tcx>>( &mut self, variance: ty::Variance,

Regression in nightly-2023-02-21 found 9 bors merge commits in the specified range commit[0] 2023-02-19: Auto merge of - cjgillot:codegen-overflow-check, r=tmiasko commit[1] 2023-02-19: Auto merge of - clubby789:builtin-derived-attr, r=jackh726 commit[2] 2023-02-20: Auto merge of - fmease:iat-type-directed-probing, r=jackh726 commit[3] 2023-02-20: Auto merge of - tmiasko:read-buf, r=the8472 commit[4] 2023-02-20: Auto merge of - camelid:rustdoc-all-only-stable, r=GuillaumeGomez commit[5] 2023-02-20: Auto merge of - b-naber:proj-relate-variance, r=lcnr commit[6] 2023-02-20: Auto merge of - megakorre:issue_105700, r=petrochenkov commit[7] 2023-02-20: Auto merge of - matthiaskrgr:rollup-4tdvnx6, r=matthiaskrgr commit[8] 2023-02-20: Auto merge of - lnicola:rust-analyzer-2023-02-20, r=lnicola ERROR: no CI builds available between and within last 167 days I guess ?
Seems this has been fixed on the latest nightly, marked as E-needs-test. labels: +E-needs-test
this regressed again in


Question: .map(|did| tcx.provided_trait_methods(did).map(|meth| meth.name).collect()) .unwrap_or_default() } <ins> pub(crate) fn is_negative_trait_impl(&self) -> bool { matches!(self.polarity, ty::ImplPolarity::Negative) } </ins> } #[derive(Clone, Debug)]

<p align="center"<img width="400" src=""</pI would prefer if only the negative impl signature were rendered here (and any doc comment on the negative impl). Not even a collapsed-by-default accordion to show the trait's contents. The reader can click the trait's name to see what is in it if they need. Having associated items of a negative impl rendered is inconvenient because something like <kbdCTRL+F</kbdfor "fn position" will land the reader deep in the middle of the big impl showing them APIs that their type does not have. Example of this occurring in standard library documentation:  Mentioning tracking issue.


Question: use rustc_errors::{Applicability, DiagnosticBuilder}; <ins> use rustc_infer::infer::TyCtxtInferExt; </ins> use rustc_middle::mir::*; use rustc_middle::ty; use rustc_span::source_map::DesugaringKind;

<!-- 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. --Haven't minimized the code yet, but the exact code is up here: It's a kind of search algorithm. I think the problematic code is the function in . Will report back if I figure out anything more. <!-- 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</detailsI just switched to the stable toolchain, and the compilar gave me two errors: Apparently these were not caught by the nightly compiler.
This is probably a duplicate of You're using the nightly compiler though, so working as intended
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium


Question: use rustc_errors::{Applicability, DiagnosticBuilder}; <ins> use rustc_infer::infer::TyCtxtInferExt; </ins> use rustc_middle::mir::*; use rustc_middle::ty; use rustc_span::source_map::DesugaringKind;

<!-- 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. --Compiles with replaced for <!-- 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 --
I got the same issue on the latest nightly and on , without using rustc-private The commented out block was used originally and triggers the ICE as well.
searched nightlies: from nightly-2021-07-29 to nightly-2021-08-02 regressed nightly: nightly-2021-07-31 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x8664-pc-windows-msvc Reproduce with: </detailsI think this might have been introduced by , in particular this piece of code:
If that's indeed caused by then we should let its author know:
Just checked and thankfully .
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high


Question: #[test] fn wtf8buf_show() { <del> let mut string = Wtf8Buf::from_str("aé 💩"); </del> <ins> let mut string = Wtf8Buf::from_str("até 💩r"); </ins> string.push(CodePoint::from_u32(0xD800).unwrap()); <del> assert_eq!(format!("{:?}", string), r#""aé 💩u{D800}""#); </del> <ins> assert_eq!(format!("{:?}", string), r#""atu{e9} u{1f4a9}ru{D800}""#); </ins> } #[test]

Formatting a string containing special characters with usually prints them escaped i.e.. This snippet runs as expected in the . However on Windows, using both and , the is printed unescaped : From what I can gather,  only concerns itself with faulty surrogates and completely ignores special characters.


Question: getSearchInput().focus(); } <del> // Removes the focus from the search bar </del> <ins> // Removes the focus from the search bar. </ins> function defocusSearchBar() { getSearchInput().blur(); }

mdbook v4.6+ has a feature that pressing ESC removes query components from URLs (for example ). The feature was implemented in rust-lang/mdBook. It would be nice if rustdoc offers the same kind of that feature. This is, for example, an URL that contains query components in rustdoc: When users share URLs to an API, they don't have to remove the query manually.
could you share some thoughts about this feature request? If possible, could you mentor contributors how to implement this ?
I think it's a good idea. Gonna take a look at how to do it.
Can we reopen this issue ? I think only removes the query component when we remove keywords in search bar. This issue is about adding a keyboard shortcut.
Oh I see, my bad. Reopening!


Question: self.warn_dead_code(impl_item.id, impl_item.span, impl_item.name, <del> "associated const"); </del> <ins> "associated const", "used"); </ins> } self.visit_nested_body(body_id) } hir::ImplItemKind::Method(_, body_id) => { if !self.symbol_is_live(impl_item.id, None) { let span = self.tcx.sess.codemap().def_span(impl_item.span); <del> self.warn_dead_code(impl_item.id, span, impl_item.name, "method"); </del> <ins> self.warn_dead_code(impl_item.id, span, impl_item.name, "method", "used"); </ins> } self.visit_nested_body(body_id) }

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> // This test asserts that `index` is not polluted with unrelated items. // See https://github.com/rust-lang/rust/issues/114039 //@ count "$.index[*]" 1 fn main() {} </ins>

Generated rustdoc JSON for every one of dozens of crates I've looked at seems to contain unexpected inlined items that look like an block and its contents. I expected to see this happen: rustdoc JSON file contains only the items defined or re-exported by the corresponding crate. Instead, this happened: the rustdoc JSON file contains items like this: In this example, is and here are the names of the items contained in that impl (also part of the rustdoc JSON): Similarly, you can find items from : Invocation for generating rustdoc JSON: : You can find a variety of pre-generated rustdoc JSON files with this issue here: Briefly discussed in Zulip: https://rust- I'll have to work around this behavior to shield , which uses the same codebase as the playground link above. I can hold off on updating the playground for, say, another week, but at some point I'll need to upgrade it to include my workaround which means those items will cease being shown. label +T-rustdoc +A-rustdoc-json
Possibly duplicate of
Might be! Definitely at least some overlap, not entirely sure if duplicate. Do you mind if I ship the workaround for this in cargo-semver-checks and the playground, which will hide these items from our lints and from queries in the playground?
Yeah, it's easy enough to reproduce in raw json, I'm not worried about the repro breaking.


Question: expected, found, block_or_return_id, <del> parent_id, </del> <ins> fcx.body_id, </ins> ); }

<!-- ICE: Rustc '' 'error: internal compiler error: node HirId(DefId(0:7 ~ ice[9097]::readfield2).4) (type ) cannot be placed in TypeckResults with hirowner DefId(0:8 ~ ice[9097]::readfield2::FIELD2)', 'error: internal compiler error: node HirId(DefId(0:7 ~ ice[9097]::readfield2).4) (type ) cannot be placed in TypeckResults with hirowner DefId(0:8 ~ ice[9097]::readfield2::FIELD2)' 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: [typeck] type-checking [checkwellformed] checking that is well-formed --
fyi


Question: <ins> // force-host // no-prefer-dynamic #![crate_type = "proc-macro"] extern crate proc_macro; use proc_macro::{Group, Spacing, Punct, TokenTree, TokenStream}; // This macro exists as part of a reproduction of #61963 but without using quote/syn/proc_macro2. #[proc_macro_attribute] pub fn dom_struct(_: TokenStream, input: TokenStream) -> TokenStream { // Construct the expected output tokens - the input but with a `#[derive(DomObject)]` applied. let attributes: TokenStream = "#[derive(DomObject)]".to_string().parse().unwrap(); let output: TokenStream = attributes.into_iter() .chain(input.into_iter()).collect(); let mut tokens: Vec<_> = output.into_iter().collect(); // Adjust the spacing of `>` tokens to match what `quote` would produce. for token in tokens.iter_mut() { if let TokenTree::Group(group) = token { let mut tokens: Vec<_> = group.stream().into_iter().collect(); for token in tokens.iter_mut() { if let TokenTree::Punct(p) = token { if p.as_char() == '>' { *p = Punct::new('>', Spacing::Alone); } } } let mut stream = TokenStream::new(); stream.extend(tokens); *group = Group::new(group.delimiter(), stream); } } let mut output = TokenStream::new(); output.extend(tokens); output } </ins>

One of the many new (or newly enabled by default) warnings in Servo in today’s Nightly: The suggestion is wrong, which means also fails and therefore does not apply fixes for (the many) other warnings where the suggestion is correct.
Triage: Preliminarily assigning P-high before Felix reviews this.
Also cc since iirc you did some macro related work here.
Possible solution: when a warning’s span is exactly a macro invocation, don’t emit a “suggested fix” that is likely wrong. (But still emit a warning.)
We have that check for most suggestions, but it might be missing for . Was this in latest nightly? I know a couple of these have been fixed in the past few weeks.
This is in rustc 1.37.0-nightly ( 2019-06-18). works around this and allows ’ing the rest of the warnings (namely old syntax for inclusive ranges) or warnings in other crates.
Oh. I just noticed the suggestion. I’d missed it in that blob of text.
Apologies for the time this has taken - I've struggled to find time to dig in to this. So far, I've managed to make a smaller example (it still depends on , and ) that reproduces the issue, you can find it in (run in the directory).
Thanks to some help from I've now got a minimal test case w/out any dependencies that outputs the same tokens that the reduced example from servo did (you can see it in ). When inspecting the span that the lint is emitted for, it isn't marked as coming from a macro expansion, and it appears that it was created that way during the macro expansion. I'd appreciate any opinions on what the correct fix is here - is it a bug in / that they output what appears to be incorrect spans? Should rustc be able to handle this case? If so, where should I be looking to mark the span or what check should I be performing to identify it as a result of macro expansion?
cc
I believe this is a compiler bug, not something that needs a fix in syn or quote. is a call_site span. It is the span of tokens in macro output that are not attributable to any particular input token. Usually that will be most of the tokens in any macro output; diagnostics need to take this into account.


Question: self.assign(local, DefLocation::Body(location)); } <del> PlaceContext::NonUse(_) | PlaceContext::MutatingUse(MutatingUseContext::Retag) => {} </del> <ins> PlaceContext::NonUse(_) | PlaceContext::NonMutatingUse(NonMutatingUseContext::PlaceMention) | PlaceContext::MutatingUse(MutatingUseContext::Retag) => {} </ins> PlaceContext::NonMutatingUse( NonMutatingUseContext::Copy | NonMutatingUseContext::Move,

<!-- 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: <ins> // compile-flags: -Zvalidate-mir fn _test() { let x = || 45; missing(); //~^ ERROR cannot find function `missing` in this scope } fn main() {} </ins>

<!-- ICE: Rustc '-Zvalidate-mir -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: unexpected body ty: {type error} phase Runtime(PostCleanup)', 'error: internal compiler error: unexpected body ty: {type error} phase Runtime(PostCleanup)' 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: [mirdropselaboratedandconstchecked] elaborating drops for [analysis] running analysis passes on this crate --
cc :D (note you'll need which was merged 10 minutes ago ^^ )


Question: <ins> // compile-flags: -Zvalidate-mir fn _test() { let x = || 45; missing(); //~^ ERROR cannot find function `missing` in this scope } fn main() {} </ins>

<!-- ICE: Rustc '--edition=2021 -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: impossible case reached', 'error: internal compiler error: impossible case reached' File: --auto-reduced (treereduce-rust): <details<summary<strongoriginal code</strong</summary<poriginal: </p</detailsVersion 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: [mirconst] preparing for borrow checking [mirpromoted] promoting constants in MIR for [mir_borrowck] borrow-checking [analysis] running analysis passes on this crate --
cc


Question: | ------- similarly named trait `I` defined here LL | type K = dyn I; LL | impl K for isize {} <del> |      ^ |      | |      type aliases cannot be used as traits |      help: a trait with a similar name exists: `I` </del> <ins> |      ^ type aliases cannot be used as traits </ins> | help: you might have meant to use `#![feature(trait_alias)]` instead of a `type` alias <del> --> $DIR/issue-5035.rs:2:1 </del> | <del> LL | type K = dyn I; | ^^^^^^^^^^^^^^^ </del> <ins> LL | trait K = dyn I; | help: a trait with a similar name exists | LL | impl I for isize {} |      ^ </ins> error: aborting due to 2 previous errors

I managed to reproduce the problem with this snippet: The compiler yells E0404 at me, but fair enough I always ask it to a bit more about it :) However this time, it only says this: This is confusing because the snippet above doesn't involve the keyword so I didn't understand initially what I was doing wrong, then I read the error message again: I first tried this, and it worked, but having to repeat the whole syntax everywhere wasn't too compelling, hence the alias: The compiler error message makes it very clear that I can't alias a trait, but the E0404 explanation doesn't mention it at all. I hope the description could also include this use case as I've seen sometimes EXXXX explanations go over several facets of the same problem. That won't help me, but maybe others that may trip on the same problem. I would have submitted a pull request for the docs myself, but I have no idea why you can't use type aliases for traits so I can't it ;) I'm using stable Rust 1.19.0 (on Fedora).
One more thing, even though the compiler lets me create an alias for a trait, I don't know when I can use such an alias. Maybe this should be explained too.
Current output (in nightly):
Current output: No structured suggestion for the nightly feature (should be and the feature flag).


Question: <ins> #[deprecated = b"test"] //~ ERROR attribute must be of the form fn foo() {} fn main() {} </ins>

Look for example to It is deprecated, and in source code there is hint what should be used instead: but in generated html documentation there is no hint about
isn't the correct syntax for the attribute. It should be . You can see it work: . This isn't a rustdoc issue. It's an issue with rustc that it doesn't reject .


Question: F: FnOnce(&T) -> R { unsafe { <del> let ptr = self.inner.get(); </del> <ins> let ptr = (self.inner)().get(); </ins> assert!(!ptr.is_null(), "cannot access a scoped thread local  variable without calling `set` first"); cb(&*ptr)

There is an  in the scoped TLS module, which allows for sharing of data that wasn't meant to be shared. An unqualified should only_ be used when provides some sort of threadsafe locking mechanism. and do not. This lets us, for example, clone an or between threads, in safe code: Here, we have clones from different threads being interleaved, which can cause unsafety if there's a race on the refcount. We could also cause unsafety with a , or any other non-Sync type. basically lets us share across threads even if . I put the sleeps in there because somehow without them the routines are run serially. Note that this is not a problem with the API. I'm using here because to exploit one needs to be able to share across threads, and has an additional bound which doesn't satisfy. Any usable API will probably have to make the assumption that . Nor is this a problem with , since it can be done with , too. Solution: Make it ... I think. I'm not familiar with this API, and I'm not sure why it's even in the first place.
cc
cc This seems concerning: this is designed to be thread-local, so that e.g. storing a works (which would be safe, if it were guaranteed to stay on one thread). However currently requires unconditionally, hence this overly-accepting impl.
Qualifying the impl with breaks scoped TLS for (see the associated PR); because becomes no longer and thus can't be stuffed inside a static.
I believe the only way statics can be safe is by requiring the absence of Sync. That may sound odd, but consider the following: - sending thread-local references across threads is memory unsafe even with no interior mutability a static with no interior mutability is almost entirely useless, certainly not a common case non- containers offering interior mutabilities are cheaper and preferred to ones, where they can be used The main issue is actually within the libstd TLS implementation: is a wrapper for getters so it's unaffected by it, but may live in a static or a global one, depending on whether the platform natively supports TLS or not. -ing a across threads is actually safe on the architectures which do not have native TLS support. However, allowing it on some architectures and not on others is undesirable. Should use an accessor model like ?


Question: F: FnOnce(&T) -> R { unsafe { <del> let ptr = self.inner.get(); </del> <ins> let ptr = (self.inner)().get(); </ins> assert!(!ptr.is_null(), "cannot access a scoped thread local  variable without calling `set` first"); cb(&*ptr)

Then the actual borrow of a static is an implementation detail and happens on the thread where the key is used, not where it was itself borrowed.
"I believe the only way #[threadlocal] statics can be safe is by requiring the absence of ." This is wrong, I think. For example, one might use thread local data for intrusive linked lists of hazard pointers. They would be thread local but might still be (one can guarantee existence with scoped threads or in certain circumstances where threads are bound to cores). That said you can obviously come up with other representations. In any case, I've mostly come around to believing that we need a separate lifetime (not just for this, but for things like ensuring that can't catch an error in a thread that changes thread local data, violating exception safety).
Based on what wrote, it seems like the TLS interface requires a that only allows non- data and is still accessible like one. One idea I had of how to enable this in todays Rust is to make generate a unit like struct instead of a . That struct would be and have a impl: According to this could also help with , but I'm not familiar enough with the TLS API in general to really reason about this.
I was expecting the impl to target an intermediary type, not the contents themselves. and have their own APIs to deal with. You would still be about to use the TLS API provided by libstd with thread-safe data, it's just the low-level which would have the requirement. Ideas of thread-local lifetimes predate the removal of from , and I'm not sure how relevant they are anymore. I'm also conflating thread-safe data access and thread lifetime... but how long does a thread live? What would unify with? Actually, there's an... easy solution for this. Somehow we were blinded by language semantics, but their details are fluid. It is trivial to make borrows of behave like borrows of an arbitrary rvalue, allowing the resulting reference to be passed down, but not returned. That would ensure that the the thread is just as alive for such borrows as it is for stack ones. would still require a like has, because it may not be when native TLS is supported. But both their APIs are compatible with such a change.
Wouldn't that limit the usability of thread locals in some cases, though?


Question: F: FnOnce(&T) -> R { unsafe { <del> let ptr = self.inner.get(); </del> <ins> let ptr = (self.inner)().get(); </ins> assert!(!ptr.is_null(), "cannot access a scoped thread local  variable without calling `set` first"); cb(&*ptr)

e.g., wouldn't that make it difficult to have a thread local point to another thread local? Maybe I just have to think about it. (BTW, I'm aware we're just talking about the low-level API :)).
in a , borrows are , I didn't even think of that. First off, a global static shouldn't be allowed to borrow a static. And in general, having borrows in a is going to be difficult to support, except for non- data, because they would be right now. We could disallow borrows or we could give some kind of scope to those borrows. Which makes me think, as a compromise between a lifetime and , there could be a pseudo-(rvalue)-scope. Combined with the ability to leave out in globals' type (or not having a type at all), the scope should bubble up into users of those statics. They would behave as if they were borrowed before everything else in the function where they're used, but still not (and they can't be returned from functions).
There's a few intertwined issues here at play, so I just want to quickly summarize the way I see things: This does not affect as it which has an , which while sound should be fixed, allowing removal of the block for . A borrow of a static should not yield something with the lifetime, as that is clearly not sound. I'm not sure I follow why we might require the types in a are not , I haven't quite followed that. Due the cross-platform requirements of std, however, I believe the best solution here is to use the same strategy as with an indirect accessor to ensure the semantics are the same across platforms that have and those that don't (where a normal is used).
triage: P-medium This is an unstable API so it's not super-high priority to fix, but we should defnitely fix!
requiring that a is not is an easy way to ensure that a borrow of it, while , cannot escape the current thread. I've changed my mind and prefer an rvalue borrow semantic for , but it still is the case that and use non- statics (ignoring the workarounds for ). If was supported everywhere, having rvalue borrow semantics wouldn't hurt the std TLS API (aside from stability issues with ), as the access patterns are already through anonymous lifetimes (references passed to closures).


Question: F: FnOnce(&T) -> R { unsafe { <del> let ptr = self.inner.get(); </del> <ins> let ptr = (self.inner)().get(); </ins> assert!(!ptr.is_null(), "cannot access a scoped thread local  variable without calling `set` first"); cb(&*ptr)

Maybe a combined strategy, where borrows of statics are iff the data is not (and rvalue-like otherwise), might work better and would require fewer changes to the std TLS implementation.
Right, but returning a borrow with a lifetime for a global is unsafe for other reasons (the lifetime of the thread is not ).
how can it be abused without sending it to a different thread?
The actual values themselves do not have a lifetime, so it can be a source of unsafety to advertise otherwise. For example you could stick a into a TLS value with a destructor, but when the destructor runs that pointer could be invalid.


Question: strings.insert("setab".to_string(), b"x1B[4%p1%dm".to_vec()); let mut numbers = HashMap::new(); <del> numbers.insert("colors".to_string(), 8u16); </del> <ins> numbers.insert("colors".to_string(), 8); </ins> TermInfo { names: vec!["cygwin".to_string()], // msys is a fork of an older cygwin version

does not emit color output when running under a tmux session with set correctly to (supported by the latest versions of ncurses) even with when is set to . On the machine in question (macOS) the term file for is installed and returns the following: Per cargo should be invoking rustc with the flag, and indeed, returns 'Option color given more than once. Executing also does not produce color output, but does.
I have a similar bug on Archlinux. I used to get colored output on this system, but that recently stopped working for rustc. (Cargo is still fine for me.) If I add in and run in , I get Result::unwrap()Err/lib/terminfo/x/xterm-256colorncursesNEWS file does mention a new (incompatible) file format with a different magic number: Could rustc switch to whatever Cargo uses for colored terminal output?
A work-around for my machine was temporarily downgrading the packages, and copying the old file to .
Yes rustc should be able to switch at any time
Thanks for the workaround!
Changing from to also seems to work as a temporary workaround. (note: this may affect other terminal applications)
Another work-around if you're using sh: This sets to a possibly incorrect value, but limits its impact to only the output of a command.
That worked for me as well. I had no colour with . I downgraded to , which was what I had in , and now I have colour again.
I have a similar issue: In my regular terminal emulator (not tmux), there are no colors from rustc (as executed with ), colors from cargo itself are working fine. The default setting for there is: . The problem is fixed by setting to . Inside tmux however, colors work just fine, there seems to be by default.
Colors are fixed in the latest nightly (thanks to o/)
This is fixed for me in today’s nigthly, presumably by
With the current nightly I still have no colors with and have to use as a work around. What might still be broken?
Terminal colors are still broken with . however, does use colors, so there's clearly still a discrepancy between how and use termcolor
It works fine for me with ncurses 6.1, even rustup has colors again since the last version .


Question: strings.insert("setab".to_string(), b"x1B[4%p1%dm".to_vec()); let mut numbers = HashMap::new(); <del> numbers.insert("colors".to_string(), 8u16); </del> <ins> numbers.insert("colors".to_string(), 8); </ins> TermInfo { names: vec!["cygwin".to_string()], // msys is a fork of an older cygwin version

I’d like to note though that things like destroy this for some reason (even if is set). It took me some time to figure that out
I'm using ncurses 6.1 on Fedora 28 and everything appears to be working fine except for test colors. In mentioned that a bit tricky due to how the build works, but we can always tackle that later. What is the barrier to migrating libtest from to ? For now, it's leaving my test output looking like this. !
I have an in-progress patch for libtest but I ran into I'm guessing that's the build issue that is referring to. I don't know how linking libtest works, but I'm happy to try to fix the build if someone can point me in the right direction.


Question: <ins> // force-host // no-prefer-dynamic #![crate_type="lib"] // Issue 111888: this crate (1.) is imported by a proc-macro crate and (2.) // exports a no_mangle function; that combination of acts was broken for some // period of time. See further discussion in the test file that imports this // crate. #[no_mangle] pub fn some_no_mangle_function() { } </ins>

<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. ---rs has been updated with a workaround, so the reproduction described below will need adapting (e.g. check out that repo from around or earlier, since that will not include the workaround in ) problem exhibits itself only with certain numbers of codegen-units. The default setting for codegen-units is host dependent (the default is chosen, in part, as a function of the number of cores the host has available, in order to parallelize the code-generation performed by LLVM). In my own experiments, the problem is masked (does not arise) for codegen-units={1,2,4,8}, and the problem does arise for codegen-units={16,32,64,128,256}. You are best off passing explicit when investigating this, just to ward against that being an invisible factor in the experiments. (bug report follows below) I tried this code: I expected to see this happen: succeeds in debug mode. Instead, this happened: fails in debug mode. *isn't immediately obvious why would cause the problem searched nightlies: from nightly-2023-03-27 to nightly-2023-04-02 regressed nightly: nightly-2023-04-01 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-nightly-to-nightly -regression-untriaged --
I forked and minimized the reproducible example down to simply having a type (but not a value) with in a crate (and then adding that proc macro crate as a dependency of another crate). You can find it here: (just run in ) Here is a workaround for the crate:
WG-prioritization assigning priority ().


Question: <ins> // force-host // no-prefer-dynamic #![crate_type="lib"] // Issue 111888: this crate (1.) is imported by a proc-macro crate and (2.) // exports a no_mangle function; that combination of acts was broken for some // period of time. See further discussion in the test file that imports this // crate. #[no_mangle] pub fn some_no_mangle_function() { } </ins>

label -I-prioritize +P-high +T-compiler
TBH it's not clear to me how alignment checks would end up causing linker errors, but since this seems bisected to , let's at the very least notify the PR's author
I already looked over this and was also mystified. I suppose I could take another look? I know almost completely nothing about wasm so I'm not hopeful.
Builds fine: Same linker error: As a mitigation for the linker error, users may put this in their (for the workspace!) That only helps with the alignment checks, is still not going to work.
I can build the reproducer, unmodified, if I use LLD. Or suggests this might be a link order issue. That would explain why LLD is fine with the link, but GNU's linker isn't. Actually, that doesn't make much sense because our standard library is already at the end of the link. I'm out of ideas :shrug: I think this is somehow dependent on linker details that I don't know and I'm struggling to educate myself on.
reported this same linker error from . It can be reproduced by creating an empty Cargo project, then running then . I have not managed to minimize this reproducer. The errant symbol is which is defined as: This has the same sort of shape as the non-unwinding panics from the alignment checks and from the standard library UB-detecting assertions. searched nightlies: from nightly-2023-01-01 to nightly-2023-06-09 regressed nightly: nightly-2023-03-12 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </detailsSo this bisects to a rollup then can't find the unrolled perf builds. Manual trials identifies as the source of the regression.
A tiny update: it seems like this problem goes away if you use  (and for me, it also didn't reproduce for many other values for number-of-codegen-units; I won't bother enumerating those here). This was somewhat of a surprise. I need to investigate more to figure out what relevance the codegen unit partitioning has to do with this issue.


Question: <ins> // force-host // no-prefer-dynamic #![crate_type="lib"] // Issue 111888: this crate (1.) is imported by a proc-macro crate and (2.) // exports a no_mangle function; that combination of acts was broken for some // period of time. See further discussion in the test file that imports this // crate. #[no_mangle] pub fn some_no_mangle_function() { } </ins>

If nothing else, it is a halfway decent fallback measure while we continue to investigate the problem.
Wanted to add, that I also ran into this issue. For me, it also occurred while compiling a macro crate. I originally thought it was an issue with , as it happened after I ran a , and the issue was fixed by pinning to a slightly older version: There was a bunch of weird behavior I encountered when trying to uncover the issue. The issue was one. When I made other library upgrade changes, it would cause or fix the breakage. I didn't dive too deeply, but it seems like I was still encountering this issue even when I set the compiler to 1.67. (See this Github Actions build and associated commit: ) So it's possible that going to an old version simply hid the issue, but didn't actually pinpoint where the issue was introduced. Let me know if there's any other information I can provide to help isolate the issue. I've seemingly been able to work around the issue by using , as described earlier: I didn't try the other solution about codegen-units.
One MCVE for the stylist-macros build issue looks like this: Just a stylist-macros crate, with this and : So now I'm switching gears to see if I reduce wasm_bindgen to something smaller, so that we can have a small set of crates to talk about on their own here.
Okay got a pretty impressively tiny MCVE for wasm-bindgen too: In case its not clear, this seems like a pretty simple example that should easily work out of the box. (The use of from the mcve-stylist part of the story seems like an important part of the reproduction.) Still looking. Update: Wow, is it somehow of all things that is causing the problem here? That is ... bizarre, to say the least.
may be relevant. That issue is about not mentioning symbols in the version script such that they don't get exported. Also when applying to the rlib containing the symbols the linker error is fixed, so it seems like the linker doesn't pull in archive members even when the version script mentions it. Edit: For regular dylibs we mention all these symbols in , but for proc macros we only list a couple of internal symbols.


Question: <ins> // force-host // no-prefer-dynamic #![crate_type="lib"] // Issue 111888: this crate (1.) is imported by a proc-macro crate and (2.) // exports a no_mangle function; that combination of acts was broken for some // period of time. See further discussion in the test file that imports this // crate. #[no_mangle] pub fn some_no_mangle_function() { } </ins>

Edit2: There is a special case for proc macros with the handling to not mention any symbols beyond those required to handle circular dependencies. Fixing should fix this issue too by making the version script a subset of again (apart from a couple of symbols defined outside of archives).
: As an addendum to this: (which was in a rollup, as mentioned) the future-proofing safe-guard of adding to the linker invocation. We can add that same link-arg ourselves as part of further bisection that acts prior to PR . In my own MCVE, when I add that link-arg, I find that the code did compile circa 1.63 even with that flag. The flag stopped working sometime between nightly-2022-08-01 and nightly-2022-08-02. (I have not yet tracked down further than that, since its too old to have per-commit prebuilds archived.) Update: oh, of course, it is almost certainly PR that injected the change in behavior mentioned in the previous paragraph.
See related discussion in https://rust- (I have a branch with a commit that seems to fix this here: ; I hope to have a PR up today, once I get a regression test into place.)


Question: use std::collections::HashMap; use std::collections::hashmap::{Occupied, Vacant}; use std::slice; <del> use std::{i8, i16, i32, i64, u8, u16, u32, u64, f32, f64}; </del> <ins> use std::{int, i8, i16, i32, i64, uint, u8, u16, u32, u64, f32, f64}; </ins> use syntax::abi; use syntax::ast_map; <ins> use syntax::ast_util::is_shift_binop; </ins> use syntax::attr::AttrMetaMethods; use syntax::attr; use syntax::codemap::Span; use syntax::parse::token; use syntax::{ast, ast_util, visit}; <ins> use syntax::ast::{TyI, TyU, TyI8, TyU8, TyI16, TyU16, TyI32, TyU32, TyI64, TyU64}; </ins> use syntax::ptr::P; use syntax::visit::Visitor;

Currently overlong bit shifts are undefined behavior because that's how llvm rolls--. But even when they aren't, we should warn on something like where happens to be , since it's a useless operation that couldn't possibly return anything interesting. There's a and I imagine it'd be a common gotcha since other languages tend to read unadorned integral literals as 32bit s and then promote the in before doing the actual shift.
I think this can be closed, resolved in
Hooray!


Question: <ins> error: this file contains an unclosed delimiter --> $DIR/issue-81804.rs:9:11 | LL | fn p([=(} |     --    ^ |     || |     |unclosed delimiter |     unclosed delimiter error: this file contains an unclosed delimiter --> $DIR/issue-81804.rs:9:11 | LL | fn p([=(} |     --    ^ |     || |     |unclosed delimiter |     unclosed delimiter error: expected pattern, found `=` --> $DIR/issue-81804.rs:9:7 | LL | fn p([=(} |       ^ expected pattern error: expected one of `)`, `,`, `->`, `where`, or `{`, found `]` --> $DIR/issue-81804.rs:9:8 | LL | fn p([=(} |        ^ -^ |        | | |        | help: `)` may belong here |        unclosed delimiter error: expected item, found `]` --> $DIR/issue-81804.rs:9:11 | LL | fn p([=(} |           ^ expected item error: aborting due to 5 previous errors </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: <ins> #![feature(optin_builtin_traits)] // Test for issue #56934 - that it is impossible to redundantly // implement an auto-trait for a trait object type that contains it. // Positive impl variant. auto trait Marker1 {} auto trait Marker2 {} trait Object: Marker1 {} // A supertrait marker is illegal... impl Marker1 for dyn Object + Marker2 { }   //~ ERROR E0371 // ...and also a direct component. impl Marker2 for dyn Object + Marker2 { }   //~ ERROR E0371 // But implementing a marker if it is not present is OK. impl Marker2 for dyn Object {} // OK // A non-principal trait-object type is orphan even in its crate. unsafe impl Send for dyn Marker2 {} //~ ERROR E0117 // And impl'ing a remote marker for a local trait object is forbidden // by one of these special orphan-like rules. unsafe impl Send for dyn Object {} //~ ERROR E0321 unsafe impl Send for dyn Object + Marker2 {} //~ ERROR E0321 fn main() { } </ins>

Code gives the same error as , giving (dyn Xyz + Abc + 'static)XyzCode passes coherence, but wfcheck fails because of the confusion:


Question: let mut rbml_w = Encoder::new(wr); <ins> encode_rustc_version(&mut rbml_w); </ins> encode_crate_name(&mut rbml_w, &ecx.link_meta.crate_name); encode_crate_triple(&mut rbml_w, &tcx.sess.opts.target_triple); encode_hash(&mut rbml_w, &ecx.link_meta.crate_hash);

When trying to update uutils/coreutils to HEAD, I got this ICE: Version: code:
apparently, this happens as a side effect of the build process. i had built with stable, then tried to build with nightly, giving incorrect metadata


Question: <ins> //@ run-rustfix // Check the `unused_parens` suggestion for paren_expr with attributes. // The suggestion should retain attributes in the front. #![feature(stmt_expr_attributes)] #![deny(unused_parens)] pub fn foo() -> impl Fn() { let _ = #[inline] #[allow(dead_code)] || println!("Hello!"); //~ERROR unnecessary parentheses #[inline] #[allow(dead_code)] || println!("Hello!") //~ERROR unnecessary parentheses } fn main() { let _ = foo(); } </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: } fn lower_expr_yield(&mut self, span: Span, opt_expr: Option<&Expr>) -> hir::ExprKind<'hir> { <ins> let yielded = opt_expr.as_ref().map(|x| self.lower_expr(x)).unwrap_or_else(|| self.expr_unit(span)); </ins> let is_async_gen = match self.coroutine_kind { Some(hir::CoroutineKind::Desugared(hir::CoroutineDesugaring::Gen, _)) => false, Some(hir::CoroutineKind::Desugared(hir::CoroutineDesugaring::AsyncGen, _)) => true, Some(hir::CoroutineKind::Desugared(hir::CoroutineDesugaring::Async, _)) => { <del> return hir::ExprKind::Err( self.dcx().emit_err(AsyncCoroutinesNotSupported { span }), </del> <ins> // Lower to a block `{ EXPR; <error> }` so that the awaited expr // is not accidentally orphaned. let stmt_id = self.next_id(); let expr_err = self.expr( yielded.span, hir::ExprKind::Err(self.dcx().emit_err(AsyncCoroutinesNotSupported { span })), ); return hir::ExprKind::Block( self.block_all( yielded.span, arena_vec![self; hir::Stmt { hir_id: stmt_id, kind: hir::StmtKind::Semi(yielded), span: yielded.span, }], Some(self.arena.alloc(expr_err)), ), None, </ins> ); } Some(hir::CoroutineKind::Coroutine(_)) => {

<!-- ICE: Rustc '--edition=2021 -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'no entry found for key'', 'thread 'rustc' panicked at 'no entry found for key'' 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: [hirownerparent] getting HIR parent of [checkunused_traits] checking unused trait imports in crate [analysis] running analysis passes on this crate --
cc
Minimal:


Question: <ins> // unit-test: DeadStoreElimination // compile-flags: -Zmir-keep-place-mention // EMIT_MIR place_mention.main.DeadStoreElimination.diff fn main() { // Verify that we account for the `PlaceMention` statement as a use of the tuple, // and don't remove it as a dead store. let (_, _) = ("Hello", "World"); } </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: 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: expr: &'tcx hir::Expr<'tcx>, ty: &str, ) -> bool { <ins> // Look past casts to support cases like `0..256 as u8` let (expr, lit_span) = if let Node::Expr(par_expr) = cx.tcx.hir().get(cx.tcx.hir().parent_id(expr.hir_id)) && let ExprKind::Cast(_, _) = par_expr.kind { (par_expr, expr.span) } else { (expr, expr.span) }; </ins> // We only want to handle exclusive (`..`) ranges, // which are represented as `ExprKind::Struct`. let par_id = cx.tcx.hir().parent_id(expr.hir_id);

<!-- 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: printing all numbers from 0 to 255 (inclusive) Instead, this happened: : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The error is correct, 256 is indeed out of range for u8. You need to use .
You can run that code if you want, by allowing the lint: if you do you'll see that it will print nothing because the overflows and becomes , so it's which is empty. Examples like this where allowing the literal overflow would do something you don't want are exactly why this lint is deny-by-default
I've renamed this issue because the lint is correct. If there's anything to be done here, it would be to add a range-specific suggestion for this situation to help guide towards the correct code.
claim


Question: let mut confirm_cx = ConfirmContext::new(self, span, self_expr, call_expr); confirm_cx.confirm(unadjusted_self_ty, pick, segment) } <ins> pub fn confirm_method_for_diagnostic( &self, span: Span, self_expr: &'tcx hir::Expr<'tcx>, call_expr: &'tcx hir::Expr<'tcx>, unadjusted_self_ty: Ty<'tcx>, pick: &probe::Pick<'tcx>, segment: &hir::PathSegment<'_>, ) -> ConfirmResult<'tcx> { let mut confirm_cx = ConfirmContext::new(self, span, self_expr, call_expr); confirm_cx.skip_record_for_diagnostics = true; confirm_cx.confirm(unadjusted_self_ty, pick, segment) } </ins> } impl<'a, 'tcx> ConfirmContext<'a, 'tcx> {

<!-- 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. --No user code, just trying to compile my project. The 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. --:
Do you mind checking if this still ICEs on the most recent nightly?
I just did that now, and it looks like the issue is fixed on the latest nightly. (sorry should have tried that in first place!)
That's weird, because I can repro it (cross-compiling for from linux if it matters).
on the latest nightly?
yep: Also the version of winit from the report () is not the latest . I'm working on bisecting and reducing now
Wait, this actually ICEs on stable too and I didn't notice because rustc emitted a bunch of errors after the ICE (?!)
I've reduced it down to this (which is no longer macOS or aarch64 dependent): (The assignment to was of course something more reasonable in the original code, but now I can't seem to replace it without making the ICE go away) This failed to compile without ICE on 1.69: Regression in () searched nightlies: from nightly-2023-03-06 to nightly-2023-04-19 regressed nightly: nightly-2023-04-15 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details label regression-from-stable-to-stable
Whoops, I seemed to have caused it I'll look into it!
WG-prioritization assigning priority (). label -I-prioritize +P-medium


Question: pub fn get_z(x: S) -> u64; pub fn get_c_many_params(_: *const (), _: *const (), _: *const (), _: *const (), f: Quad) -> u64; <ins> pub fn get_c_exhaust_sysv64_ints( _: *const (), _: *const (), _: *const (), _: *const (), _: *const (), _: *const (), _: *const (), h: QuadFloats, ) -> f32; </ins> pub fn rust_dbg_abi_1(q: Quad) -> Quad; pub fn rust_dbg_abi_2(f: Floats) -> Floats; }

We encountered this with WebRender, where we exposed a method in Rust to the Gecko, and the last parameters supplied appeared random on the Rust side. I made a reduced test case adapted from it that you can grab at: It is a very simple test case where the C++ program puts all the parameters on the stack, prints the expected values of some of them, and calls the Rust method. The Rust method prints the values it received. We have enough parameters to fill up the registers used in the calling convention, and once we get to pushing things on the stack, it goes wrong. You can see from the output that they mismatch. ./build- && ./run- outputs c++ expect width=7 height=8 c++ expect slice=9 10 11 12 c++ expect outset=13. 13. 13. 13. c++ expect repeat h=0 v=0 got rust image 6 width 7 height 8 got rust slice SideOffsets { top: 9, right: 10, bottom: 11, left: 12 } got rust outset LayoutGeometry { top: 0.0, left: 0.0, width: 0.0, height: 0.0 } got rust repeat h=26 v=58 Note that the earlier parameters are correct, but the last 3 (outset, repeat h and repeat v) are all incorrect.
Is there an upstream issue in WebRender you can link? What platform is this happening on?
The Gecko side integrating with WebRender was disabled, and I have been working to re-enable this in You can find the code in question at: I intend to just work around this using structs for the moment as part of the aforementioned bug.
We're seeing this on all of our x64 platforms (win, mac, linux; all using clang). It looks like a pretty clear bug in our sysv callee ABI for x64 when there are lots of arguments.
<details<summaryrustc callee llvm-ir </summary</details<details<summaryclang caller llvm-ir </summary</detailsJust the signatures:
Note to self: can go negative from scalar integer arguments after the 6 integer registers have been exhausted and then is always true. Will try to fix soon (also I wonder if this is a stable-to-stable regression from years ago?).


Question: pub fn get_z(x: S) -> u64; pub fn get_c_many_params(_: *const (), _: *const (), _: *const (), _: *const (), f: Quad) -> u64; <ins> pub fn get_c_exhaust_sysv64_ints( _: *const (), _: *const (), _: *const (), _: *const (), _: *const (), _: *const (), _: *const (), h: QuadFloats, ) -> f32; </ins> pub fn rust_dbg_abi_1(q: Quad) -> Quad; pub fn rust_dbg_abi_2(f: Floats) -> Floats; }

Looks like this was working circa 1.0, but has been broken at least since 1.12. Oof.
Do you need this fixed on beta as well, btw?
it would certainly be great if you uplifted this, but we have to work around it for the next few weeks anyway


Question: // Refers to temporaries which cannot be promoted as // promote_consts decided they weren't simple enough. <ins> // FIXME(oli-obk,eddyb): Remove this flag entirely and // solely process this information via `IsNotConst`. </ins> struct IsNotPromotable; impl Qualif for IsNotPromotable {

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: // Refers to temporaries which cannot be promoted as // promote_consts decided they weren't simple enough. <ins> // FIXME(oli-obk,eddyb): Remove this flag entirely and // solely process this information via `IsNotConst`. </ins> struct IsNotPromotable; impl Qualif for IsNotPromotable {

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: // Refers to temporaries which cannot be promoted as // promote_consts decided they weren't simple enough. <ins> // FIXME(oli-obk,eddyb): Remove this flag entirely and // solely process this information via `IsNotConst`. </ins> struct IsNotPromotable; impl Qualif for IsNotPromotable {

'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: // Refers to temporaries which cannot be promoted as // promote_consts decided they weren't simple enough. <ins> // FIXME(oli-obk,eddyb): Remove this flag entirely and // solely process this information via `IsNotConst`. </ins> struct IsNotPromotable; impl Qualif for IsNotPromotable {

'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: // Refers to temporaries which cannot be promoted as // promote_consts decided they weren't simple enough. <ins> // FIXME(oli-obk,eddyb): Remove this flag entirely and // solely process this information via `IsNotConst`. </ins> struct IsNotPromotable; impl Qualif for IsNotPromotable {

'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: // Refers to temporaries which cannot be promoted as // promote_consts decided they weren't simple enough. <ins> // FIXME(oli-obk,eddyb): Remove this flag entirely and // solely process this information via `IsNotConst`. </ins> struct IsNotPromotable; impl Qualif for IsNotPromotable {

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: COMPILE_FLAGS=-Copt-level=3 -Clto=fat -Cprofile-generate="$(TMPDIR)" <del> # LLVM doesn't yet support instrumenting binaries that use unwinding on MSVC: # https://github.com/rust-lang/rust/issues/61002 # # Things work fine with -Cpanic=abort though. ifdef IS_MSVC COMPILE_FLAGS+= -Cpanic=abort endif </del> all: $(RUSTC) $(COMPILE_FLAGS) test.rs $(call RUN,test) || exit 1

LLVM's "IR-level" instrumentation, which is used by to generate PGO instrumented binaries, does not yet work with exception handling on Windows MSVC. The problem has been reported to LLVM for C++ here: This also affects Rust programs built with for Windows MSVC. As long as LLVM does not support exception handling there, it is a known limitation that PGO can only be used with on this platform.
PGO does not yet work on for other reasons (see ). Once it does, we should check if this problem is specific to MSVC.
I have working x86_64 windows-gnu (64 bit builds use SEH) build with PGO I'll open PR once is merged. I can do testing in meantime. FWIW simple hello world example works fine after going through PGO.
if you test, be sure to compile your LLVM with assertions: Thanks for looking into it!
I'll recompile it with assertions today later. Should the test case be using any specific code like ?
The following test case runs into the problem with MSVC: See for how the file is compiled.
It does not reproduce with gnu toolchain with Rust and LLVM assertions enabled, I'll try to remember about fixing along with gnu profiler.
Cool!
I just confirmed that (for me locally) PGO seems to work on Windows GNU. That is, I built with instrumentation, ran it, and rebuilt it with the profiling data collected. It worked just fine, no crashes. So I updated the original issue text to just mention MSVC instead of Windows in general.
It looks like is a bit too aggressive with its error reporting. For example when invoking rustc, but not compiling in our Firefox build we can the following : I'm not sure the best solution while mw is away; perhaps we should revert for now.
Maybe we can just convert the error to a warning?
Not the best long-term solution but seems ok
It looks like the was marked fixed a year ago. What's the status of this issue in rustc?


Question: let mut impl_items = Buffer::empty_from(w); let mut default_impl_items = Buffer::empty_from(w); <ins> let impl_ = i.inner_impl(); </ins> <del> for trait_item in &i.inner_impl().items { doc_impl_item( &mut default_impl_items, &mut impl_items, cx, trait_item, if trait_.is_some() { &i.impl_item } else { parent }, link, render_mode, false, trait_, rendering_params, ); </del> <ins> if !impl_.is_negative_trait_impl() { for trait_item in &impl_.items { doc_impl_item( &mut default_impl_items, &mut impl_items, cx, trait_item, if trait_.is_some() { &i.impl_item } else { parent }, link, render_mode, false, trait_, rendering_params, ); } </ins> } fn render_default_items(

<p align="center"<img width="400" src=""</pI would prefer if only the negative impl signature were rendered here (and any doc comment on the negative impl). Not even a collapsed-by-default accordion to show the trait's contents. The reader can click the trait's name to see what is in it if they need. Having associated items of a negative impl rendered is inconvenient because something like <kbdCTRL+F</kbdfor "fn position" will land the reader deep in the middle of the big impl showing them APIs that their type does not have. Example of this occurring in standard library documentation:  Mentioning tracking issue.


Question: assert_eq!(cnum, LOCAL_CRATE); let mut visible_parent_map: DefIdMap<DefId> = DefIdMap(); <ins> // Issue 46112: We want the map to prefer the shortest // paths when reporting the path to an item. Therefore we // build up the map via a breadth-first search (BFS), // which naturally yields minimal-length paths. // // Note that it needs to be a BFS over the whole forest of // crates, not just each individual crate; otherwise you // only get paths that are locally minimal with respect to // whatever crate we happened to encounter first in this // traversal, but not globally minimal across all crates. let bfs_queue = &mut VecDeque::new(); </ins> for &cnum in tcx.crates().iter() { // Ignore crates without a corresponding local `extern crate` item. if tcx.missing_extern_crate_item(cnum) { continue } <del> let bfs_queue = &mut VecDeque::new(); </del> <ins> bfs_queue.push_back(DefId { krate: cnum, index: CRATE_DEF_INDEX }); } // (restrict scope of mutable-borrow of `visible_parent_map`) { </ins> let visible_parent_map = &mut visible_parent_map; let mut add_child = |bfs_queue: &mut VecDeque<_>, child: &def::Export,

On nightly rustc (cargo) I get misleading expected type errors. If a crate has the same(?) type it is displayed instead of the std type. I tried this code: I expected to see this happen: (stable rust) Instead, this happened: (nightly) :
Confirming - broken on nightly (1.23), good on beta.
bisected across nightlys: bug was injected between and
Skimming output from , there are a number of different potential culprits. Rather than guess and "point fingers" right now, I'll just continue bisecting within that commit range.
This is recent enough that we should be able to run bisect-rust on it (cc
it is cc .
I'm a little surprised that this would be caused by that PR. I can push a revert but would like to first test locally to make sure that revert that PR will fix this.
I have misread 's statement. Your PR is not at fault, sorry. I'm doing another search further back to find the causing PR.
I tried it locally in the meantime and I can confirm it is not :)
Okay so the bug dates as far back as from September 2nd which is as close to the limit as I dare to go. So to the people in control, please, prolong the limit :).
suggests that the bug was introduced much more recently (11-08 to 11-09). Maybe the bisection script was wrong?
I should probably have read the original issue more closely :). sorry for pinging you! It seems to be cc
In particular, I have bisected it down to the commit: I have been trying to further dissect that commit to figure out why it causes the change we observe here. My current hypothesis (that I have not yet managed to confirm) is that it has to do with how we seed the hashmap's hashers with randomized state. (This commit changes our behavior in certain scenarios.) If this hypothesis is actually true, though, then I would think that this represents either a bug in hashmap itself, or a bug in how the compiler is using the hashmap...
Hmm. Its something more subtle than a hashmap-related bug.


Question: assert_eq!(cnum, LOCAL_CRATE); let mut visible_parent_map: DefIdMap<DefId> = DefIdMap(); <ins> // Issue 46112: We want the map to prefer the shortest // paths when reporting the path to an item. Therefore we // build up the map via a breadth-first search (BFS), // which naturally yields minimal-length paths. // // Note that it needs to be a BFS over the whole forest of // crates, not just each individual crate; otherwise you // only get paths that are locally minimal with respect to // whatever crate we happened to encounter first in this // traversal, but not globally minimal across all crates. let bfs_queue = &mut VecDeque::new(); </ins> for &cnum in tcx.crates().iter() { // Ignore crates without a corresponding local `extern crate` item. if tcx.missing_extern_crate_item(cnum) { continue } <del> let bfs_queue = &mut VecDeque::new(); </del> <ins> bfs_queue.push_back(DefId { krate: cnum, index: CRATE_DEF_INDEX }); } // (restrict scope of mutable-borrow of `visible_parent_map`) { </ins> let visible_parent_map = &mut visible_parent_map; let mut add_child = |bfs_queue: &mut VecDeque<_>, child: &def::Export,

In particular, I can reproduce the old behavior on master by just linking in the old crate into (in addtion to linking in the one from ; doing this requires changing the name of the old ), without making any actual calls into the old crate. That, to me, seems very strange. I'm now trying to reduce down the size of the crate that I am linking in (while still causing this delta in behavior).
triage: P-high
I still get a non std types in erros when the path has the same length. That would be okay if it is somehow deterministic, but I get different type errors within the same file for the same types.
is that a regression from the stable channel? While I absolutely agree that a deterministic result would be better (and better stilll, a deterministic result that favored minimal-length paths rooted at ), I want to triage this appropriately.
Hmm I guess since is the person who filed the original ticket then it is reasonable to infer that they are indeed seeing the described regression compared to the stable channel.
gives me: seems to work now: Maybe this was some sort of partial compile cache issue? I haven't found a way to reproduce these mixed errors yet.
This looks like a duplicate of . That issue has some repro cases that affect the 1.22.1 stable compiler but not 1.21.0.
When I bisected the nightlies by hand on I ended up with a range (...) that does not include the commit identified here. Is it possible that the nondeterministic nature of the bug is also messing with our attempts to bisect? I wonder whether merely linking affects in the same way as it affected this issue.
Any evidence of this problem existing with the newest nightly?
All the cases I tried seem to have been fixed by and . Nicely done! I reported one follow-up in .


Question: <ins> // This test ensures that negative impls don't have items listed inside them. #![feature(negative_impls)] #![crate_name = "foo"] pub struct Thing; //@ has 'foo/struct.Thing.html' // We check the full path to ensure there is no `<details>` element. //@ has - '//div[@id="trait-implementations-list"]/section[@id="impl-Iterator-for-Thing"]/h3'  // 'impl !Iterator for Thing' impl !Iterator for Thing {} // This struct will allow us to compare both paths. pub struct Witness; //@ has 'foo/struct.Witness.html' //@ has - '//div[@id="trait-implementations-list"]/details//section[@id="impl-Iterator-for-Witness"]/h3'  // 'impl Iterator for Witness' impl Iterator for Witness { type Item = u8; fn next(&mut self) -> Option<Self::Item> { None } } </ins>


Question: <ins> // Confusing diagnostic when using variable as a type: // // Previous warnings indicate Foo is not used, when in fact it is // used improperly as a variable or constant. New warning points // out user may be trying to use variable as a type. Test demonstrates // cases for both local variable and const. fn main() { let Baz: &str = ""; println!("{}", Baz::Bar); //~ ERROR: failed to resolve: use of undeclared type `Baz` } #[allow(non_upper_case_globals)] pub const Foo: &str = ""; mod submod { use super::Foo; fn function() { println!("{}", Foo::Bar); //~ ERROR: failed to resolve: use of undeclared type `Foo` } } </ins>

The following code... the following error and warning: The warning says that is not used but it clearly is, just not properly. This error is normally easier to spot when using the proper casing for constants, but that might not always be the case. Perhaps in this instance, we should look for other items with the exact same name and point out that the user is trying to use a constant as a type. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Every single one of these errors should point at similarly named things of the wrong namespace.
Do you know where in the code this is coming from?
running the following will tell you where the error is being emitted: From there the place you might want to start looking at is , which is a bit hard to follow at the moment (I'm doing a slight clean up of that method at the moment), but should be reasonably straight forward to add another check for this case to that pile :)
claim
Can I take this issue?
Yes feel free to take it, I removed my assignment.
I’m going to be tied up until May, feel free to take this issue:pray:
Hey I'm looking to get to know the Rust codebase better and contribute to the project - would love to take a crack at this issue!
claim


Question: <ins> fn main() {} trait T { fn qux() -> Option<usize> { let _ = if true { }); //~^ ERROR expected one of `async`, `const`, `extern`, `fn`, `type`, `unsafe`, or `}`, found `;` //~^^ ERROR expected one of `.`, `;`, `?`, `else`, or an operator, found `}` //~^^^ ERROR 6:11: 6:12: expected identifier, found `;` //~^^^^ ERROR missing `fn`, `type`, or `const` for trait-item declaration Some(4) } </ins>

I got an internal compiler error while compiling some code with a syntax error. The error is in the final line of the match statement in the function parse. () Errors:
triage: P-high. (Unnominating since there doesn't seem to be much else to discuss)
Assigning myself to look into and fix.
:
this ICE only happens for already broken code, I don't believe this is P-high.


Question: // Make this module private for now since external users should not call these directly. mod rustc_smir; <ins> #[macro_use] extern crate scoped_tls; </ins>

is left set to a dangling pointer if unwinds. This is unsound because a later call to will use that dangling pointer. There is a similar issue with and unwinding. since you're on the Stable MIR cc list: cc
if you can add it as a dependency, using would probably be better than rolling your own version.
Yea, that makes sense. I think we should look into using it for the module, too, which is how we get a within the compiler itself


Question: throw_ub_custom!(fluent::const_eval_copy_nonoverlapping_overlapping); } } <ins> } </ins> <del> for i in 0..num_copies { ptr::copy( src_bytes, dest_bytes.add((size * i).bytes_usize()), // `Size` multiplication size.bytes_usize(), ); </del> <ins> let size_in_bytes = size.bytes_usize(); // For particularly large arrays (where this is perf-sensitive) it's common that // we're writing a single byte repeatedly. So, optimize that case to a memset. if size_in_bytes == 1 && num_copies >= 1 { // SAFETY: `src_bytes` would be read from anyway by copies below (num_copies >= 1). // Since size_in_bytes = 1, then the `init.no_bytes_init()` check above guarantees // that this read at type `u8` is OK -- it must be an initialized byte. let value = *src_bytes; dest_bytes.write_bytes(value, (size * num_copies).bytes_usize()); } else if src_alloc_id == dest_alloc_id { let mut dest_ptr = dest_bytes; for _ in 0..num_copies { ptr::copy(src_bytes, dest_ptr, size_in_bytes); dest_ptr = dest_ptr.add(size_in_bytes); </ins> } } else { <del> for i in 0..num_copies { ptr::copy_nonoverlapping( src_bytes, dest_bytes.add((size * i).bytes_usize()), // `Size` multiplication size.bytes_usize(), ); </del> <ins> let mut dest_ptr = dest_bytes; for _ in 0..num_copies { ptr::copy_nonoverlapping(src_bytes, dest_ptr, size_in_bytes); dest_ptr = dest_ptr.add(size_in_bytes); </ins> } } }

This program takes an inordinate amount of time and memory to compile (it's worse if the array is actually used, but this is a minimal test case): const SIZE: usize = 1 << 30; static SLICE: [u8; SIZE] = [0u8; SIZE]; fn main() {} I was hoping this would be a viable way to get a big chunk of so I don't have to depend on an crate to get a lot of static zeroes, but the effect on compile time makes that impractical. If I run , the big offender is: Although the time (and memory) is reportedly spent checking lints, setting doesn't make any difference. I'm guessing the "lint checking" pass includes some things that need to be checked even if lints are suppressed? If not, it seems like a separate issue is that a lot of work could be saved with cap-lints set (e.g. when compiling dependencies). Here are the top results from , for : So it looks like miri is actually creating the array and folding over it. I know it's not going to find any problems, because I have ECC memory :laughing:. There are already some bugs relating to slow compilation of large arrays, with the most relevant I could find being , . I think this is separate from those cases because: the input in this case is a [0; _] array, whereas the others initialize arrays from sequences of elements those cases seem to refer to superlinear runtime; this issue appears roughly linear in time and space and only becomes noticeable for much larger arrays the bottleneck in this case occurs during lint checking, which I didn't see in any other array performance bugs
Have you seen any improvement after ?
I've wondered before whether we should special-case constants whose bits are all defined and zero. I'll open a discussion in the const-eval zulip channel.
I also ran into this problem. has that discussion happened?
Kind of. We will have special treatment for constants that consist solely of undef bytes (see ). This scheme can likely be extended to support all bytes being zero withour requiring time or space overhead.
I opened for this.
was closed, are there still plans to implement this?
Not right now... there are other more important construction sites in const eval.


Question: sysinfo = { version = "0.26.0", optional = true } clap = { version = "4.2.4", default-features = false, features = ["std", "usage", "help", "derive", "error-context"] } clap_complete = "4.2.2" <ins> semver = "1.0.17" </ins> # Solaris doesn't support flock() and thus fd-lock is not option now [target.'cfg(not(target_os = "solaris"))'.dependencies]

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


Question: sysinfo = { version = "0.26.0", optional = true } clap = { version = "4.2.4", default-features = false, features = ["std", "usage", "help", "derive", "error-context"] } clap_complete = "4.2.2" <ins> semver = "1.0.17" </ins> # Solaris doesn't support flock() and thus fd-lock is not option now [target.'cfg(not(target_os = "solaris"))'.dependencies]

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