Question: /// Composite function which sets LLVM attributes for function depending on its AST (#[attribute]) /// attributes. <del> pub fn from_fn_attrs(cx: &CodegenCx<'ll, '_>, llfn: &'ll Value, id: DefId) { let codegen_fn_attrs = cx.tcx.codegen_fn_attrs(id); </del> <ins> pub fn from_fn_attrs( cx: &CodegenCx<'ll, '_>, llfn: &'ll Value, id: Option<DefId>, ) { let codegen_fn_attrs = id.map(|id| cx.tcx.codegen_fn_attrs(id)) .unwrap_or(CodegenFnAttrs::new()); </ins> inline(llfn, codegen_fn_attrs.inline); <ins> // The `uwtable` attribute according to LLVM is: // //     This attribute indicates that the ABI being targeted requires that an //     unwind table entry be produced for this function even if we can show //     that no exceptions passes by it. This is normally the case for the //     ELF x86-64 abi, but it can be disabled for some compilation units. // // Typically when we're compiling with `-C panic=abort` (which implies this // `no_landing_pads` check) we don't need `uwtable` because we can't // generate any exceptions! On Windows, however, exceptions include other // events such as illegal instructions, segfaults, etc. This means that on // Windows we end up still needing the `uwtable` attribute even if the `-C // panic=abort` flag is passed. // // You can also find more info on why Windows is whitelisted here in: //      https://bugzilla.mozilla.org/show_bug.cgi?id=1302078 if !cx.sess().no_landing_pads() || cx.sess().target.target.options.requires_uwtable { attributes::emit_uwtable(llfn, true); } </ins> set_frame_pointer_elimination(cx, llfn); set_probestack(cx, llfn);

and are both broken on s390x since Rust 1.28. When is built without debuginfo, the tests hang with their backtracing processes stuck in a loop. With debuginfo, it fails with output like: I believe the problem is this part of : where doesn't identify that is a 64-bit platform. See also alexcrichton/backtrace-rs. I plan to update that here when it's published, and make a similar fix in .
fixes the backtrace when is built with debuginfo, but I'm still getting a hang without. In GDB, it looks like the unwinder gets to the that catches panics, then loops unwinding that same PC forever. This part of the regression is older -- happens on 1.27.2 as well, but 1.26.2 is fine. Binaries from the older version don't appear to have a distinct symbol at all, but maybe that's just inlined differently. I'm bisecting for that hang now.
Bisecting pointed me at (cc which attributes to all functions. For s390x the base features actually include a removal, . But it doesn't look like the features are applied to the synthesized (), and as a result it doesn't get inlined anymore since it has more features (w/ ) than the callee. We probably should apply target-features to as well. I don't know why the non-inlined can't be unwound -- maybe we need to force ? By default GDB backtrace stops at crate , but tries to go further: Maybe Rust's could have a similar defensive check, at least.
Nice find Definitely makes sense to me, and this should be fixed up (at least the business) in
With , , and , I believe we have this fixed.


Question: <ins> error[E0785]: cannot define inherent `impl` for a dyn auto trait --> $DIR/issue-85026.rs:5:6 | LL | impl dyn AutoTrait {} |      ^^^^^^^^^^^^^ impl requires at least one non-auto trait | = note: define and implement a new trait or type instead error[E0785]: cannot define inherent `impl` for a dyn auto trait --> $DIR/issue-85026.rs:8:6 | LL | impl dyn Unpin {} |      ^^^^^^^^^ impl requires at least one non-auto trait | = note: define and implement a new trait or type instead error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0785`. </ins>

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


Question: <del> error[E0277]: the trait bound `&'static mut (): Clone` is not satisfied --> $DIR/issue-93008.rs:5:5 | LL |     &'static mut (): Clone, |     ^^^^^^^^^^^^^^^^^^^^^^ the trait `Clone` is not implemented for `&'static mut ()` | = help: see issue #48214 = help: add `#![feature(trivial_bounds)]` to the crate attributes to enable error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </del>

<!-- 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. --./src/test/ui/impl- or ./src/test/ui/impl-trait/issues/issue- <!-- 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</detailscc I believe this might be caused by
I'll look into it regardless
I was unable to reproduce same error perhaps it already fixed on stable channel try updating your rust compiler onto stable channel
the nightly that contains suspicious commit has not been released yet, there is no point in trying to reproduce this with nightly (or even stable). You'll need something that contains
This is the same issue that I identified in , but the bug identified and fixed in actually caused it to not be triggered until now. The issue here is a "trivial bound" () causing us to not select but in the MIR inliner. The caching bug actually caused the latter branch to happen everywhere, so when that bug was fixed, we started to normalize to in some places, causing this ICE. I bet I could trigger an ICE with a slight modification to this code using the inliner even with reverted. This is probably only triggered by the inliner, but the MIR inliner isn't enabled without being explicitly provided, right?


Question: <del> error[E0277]: the trait bound `&'static mut (): Clone` is not satisfied --> $DIR/issue-93008.rs:5:5 | LL |     &'static mut (): Clone, |     ^^^^^^^^^^^^^^^^^^^^^^ the trait `Clone` is not implemented for `&'static mut ()` | = help: see issue #48214 = help: add `#![feature(trivial_bounds)]` to the crate attributes to enable error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </del>

Trying to emulate trivial bounds via generics & associated types panics on stable, beta and nightly. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: Reproducible on beta and nightly <!-- 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 --
Bug is not present in 1.51 and appears in 1.52. More precisely, it appeared somewhere between and .
Seems like introduces the regression Probably is the culprit
It seems to affect only traits that are checked by . Changing to fixes the panic.
I wonder if this could be fixed by normalizing the caller-bounds when checking for trivial bounds in WF. Hmm.... might think about this issue later tonight.
I'm putting up a PR soon to fix a whole bunch of impossible-bounds related things. So I'll claim this for the time being. claim


Question: Some(f) => f, None => return DummyResult::any(sp) }; <del> let file = cx.resolve_path(file, sp); </del> <ins> let file = match cx.resolve_path(file, sp) { Ok(f) => f, Err(mut err) => { err.emit(); return DummyResult::any(sp); }, }; </ins> match cx.source_map().load_binary_file(&file) { Ok(bytes) => { base::MacEager::expr(cx.expr_lit(sp, ast::LitKind::ByteStr(Lrc::new(bytes))))

to reproduce the fault this can be used: will result in this ICE: thread 'rustc' panicked at 'cannot resolve relative path in non-file source ', note: Run with RUSTBACKTRACE=1 environment variable to display a backtrace. 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.36.0 ( 2019-07-03) running on x86_64-unknown-linux-gnu the question is what is the path that shall be used when the code is from stdin maybe some temp file name in the currrent working dir.
This ICE also occurs when using and , which makes sense as they use the same mechanism under the hood (, , meaning it also .
While poking at this I also noticed that items are silently ignored, and filed .


Question: return Success(PrefixFound(containing_module, i)); } <ins> fn resolve_crate_var(&mut self, mut crate_var_ctxt: SyntaxContext) -> Module<'a> { while crate_var_ctxt.source().0 != SyntaxContext::empty() { crate_var_ctxt = crate_var_ctxt.source().0; } let module = self.invocations[&crate_var_ctxt.source().1].module.get(); if module.is_local() { self.graph_root } else { module } } </ins> // AST resolution // // We maintain a list of value ribs and type ribs.

When on latest rust nightly , you get an ICE when compiling .
Its a pretty recent regression, it can't be reproduced with .
Okay, managed to minimize it: Looks like a regression of . cc any ideas on this?
Yeah, this was caused by an oversight in -- fixed in .


Question: <ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn main() { let a = std::sys::imp::process::process_common::StdioPipes { ..panic!() }; //~^ ERROR failed to resolve. Could not find `imp` in `sys` [E0433] //~^^ ERROR module `sys` is private [E0603] } </ins>

I was playing around with some code which can be found and is attached below. When I click on output I get the following output: I don't have a rust installation locally right now, so I cannot create the backtrace. I'll add it later today. The code which triggers this:
Stack trace: (There is no ICE with (nothing generated either due to type error). Perhaps playpen should use instead.)
You can get backtrace on playpen here: !
Looks like this has been fixed recently


Question: <ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn main() { let a = std::sys::imp::process::process_common::StdioPipes { ..panic!() }; //~^ ERROR failed to resolve. Could not find `imp` in `sys` [E0433] //~^^ ERROR module `sys` is private [E0603] } </ins>

I was in the middle of making a big changes to some code when this panic occurred. I was expecting a lot of compiler errors but got a compiler panic instead! :fearful: I ran the build with and the panic still occurred. Run to get this. Here's the full output with : Since I was in the middle of editing, there's no commit to point to, so I just attached my source code as is so you have something to debug. When you download it and run , the compiler should panic. The repo is called . I don't know how to narrow this issue down, or else I would try to find a smaller example for you. Hope this is good enough.
Some context for the change that caused this: Before this error happened, I changed the file . I split into two structs, and . I was relying on the compiler to find all the places where that change would effect things, and it seems that something went wrong in the compiler while trying to do that.
Once I fix that, everything works again. No more compiler panic. So it seems to have something to do with when I split up that struct. All the messed up pattern matches caused a panic. (Actually just fixing 2 broken pattern matches fixed the problem.)
I've just encountered this myself. I managed to reduce it down: It looks like this happens when a closure's body is a single (non-block) expression, and a tuple struct pattern is used somewhere in the expression. A simple workaround (if anyone needs one for some reason), then, is to just make the closure body a block:


Question: <ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn main() { let a = std::sys::imp::process::process_common::StdioPipes { ..panic!() }; //~^ ERROR failed to resolve. Could not find `imp` in `sys` [E0433] //~^^ ERROR module `sys` is private [E0603] } </ins>

Related code: Compiler panic: Note that everything is fine if I annotate the lifetimes: I am running , the MSVC x64 version.
I just ran into this. Managed to reduce the crash to Explicit lifetimes indeed fix it:
don't know if this helps, but I came up with minimal test case


Question: <ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn main() { let a = std::sys::imp::process::process_common::StdioPipes { ..panic!() }; //~^ ERROR failed to resolve. Could not find `imp` in `sys` [E0433] //~^^ ERROR module `sys` is private [E0603] } </ins>

Playground Output: Other example (possibly different bug): Output:
I just got the same ICE on linux with both the and builds. My case is essentially the same. You create an iterator of references to sub-elements of some thing which has been passed in by reference. The compiler should figure out that the iterator can only live as long as the original object, but ICEs instead. ()


Question: <ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn main() { let a = std::sys::imp::process::process_common::StdioPipes { ..panic!() }; //~^ ERROR failed to resolve. Could not find `imp` in `sys` [E0433] //~^^ ERROR module `sys` is private [E0603] } </ins>

Spawned off of There are still some cases where referencing an inaccessible item can cause the compiler to ICE. Here is one crafted example () but if 's module structure is revised then that example may fail to compile without ICE'ing for other reasons, so take care in understanding the issue: the change introduced by is skipping the requirement for stability attributes is slightly too narrow, in that it uses a local notion of pub/non-pub instead of overall accessibility. One simple solution to this may be to just follow the suggestion here and just remove the assertion entirely. (I did not want to adopt that solution for a PR to be backported to beta, but I think it is worth considering doing in nightly alone to resolve this low priority issue.)
Keywords: for better search


Question: Change this file to make users of the `download-ci-llvm` configuration download a new version of LLVM from CI, even if the LLVM submodule hasn’t changed. <del> Last change is for: https://github.com/rust-lang/rust/pull/109373 </del> <ins> Last change is for: https://github.com/rust-lang/rust/pull/96971 </ins>

I tried this code: I expected to see this happen: rustc prints the target spec successfully, because it knows it exists: Instead, this happened: rustc fails to load the LLVM specification: Note that this is different from the error we emit for an unrecognized target: Also, this only happens for local builds, because we don't use the LLVM in the component in rustup, only when building rustc from source. ... wtf ??? HEAD is branched from
cc do you know what could be going wrong here?
Thank you for bringing this to my attention. It is possible that the locally builds has enabled , and that prebuilt LLVM does not support LoongArch architecture. It would be great if you could provide specific steps to reproduce. Thank you.
Yes, that's exactly what's happened, I have download-ci-llvm enabled and the prebuilt LLVM differs. Here's steps to reproduce:
The RustDev component builds LLVM here: but I'm not sure how that differs from the component?
I think the difference is that the of ci-llvm does not contain LoongArch, but locally it does. Is it time to update ci-llvm?
Maybe need to bump download-ci-llvm-stamp to pick up the LoongArch enablement?
Thank you for catching that. I was mistaken to think that the cached prebuilt ci-llvm would automatically update over time.
no worries :) it updates every six weeks when we make a new release, or if the submodule is updated, but it's cached until then so it's not constantly re-uploaded on every change to bootstrap.
Is there any way CI could help prevent such problems? Like, complain if gets changed but the stamp file does not, or something like that?
we can use heuristics, but they're only heuristics and I wouldn't want to fail CI on them. That said, having rustbot leave a comment if you touch rustc_llvm or seems reasonable, so the PR author can make a judgement call but also doesn't forget about the stamp.


Question:
document(w, cx, it)?; if !e.variants.is_empty() {  write!(w, "
Variants
n")?;   write!(w, "
 Variants
n")?;  for variant in &e.variants { let id = derive_id(format!("{}.{}", ItemType::Variant,

A page like has many things that could be useful to link to. These should be possible to link to by clicking on: [x] The header [x] 's on a page. [x] at the top On it's hit or miss: [x] Examples [x] Associated Types [x] Required Methods [x] Implementors On [x] Provided Methods I don't have any big use cases but when I want to link to these for something like this bug I can't link to any specific line. I gotta say go to vec page, scroll 75% to bottom. Squint hard to see it.
Just ran into this today; I'd really like to have links from the impls in the Implementors section to the source containing the impl.
Triage: we always need more links....
Update: Headers written in docs and (most) auto-generated headers are either fully hyperlinked or have a "section marker" symbol that shows up on hover. Major auto-generated page headers have links in the top of the sidebar of the page. Impl blocks do not have hyperlinks (yet); that's
Since got merged and closed out , that was the last major request on this issue, so i'll close this out. If you think of something else that needs a hyperlinked header, feel free to open a new issue or reopen this one.


Question: } } <ins> fn replace_tabs(str: &str) -> String { str.replace('t', "    ") } </ins> fn draw_col_separator(buffer: &mut StyledBuffer, line: usize, col: usize) { buffer.puts(line, col, "| ", Style::LineNumber); }

The code that truncates long lines doesn't take (hard) tabs into account, so the lines printed are off. Example code: Gives the following error: If you use four spaces instead of each tab it works as expected: cc and cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I thought we were already accounting for tabs, but looking we rely on which considers to not have a width, which we then assume to be 1.
claim


Question: if w > 2 { val = utf8_acc_cont_byte!(val, s[i + 2]); } if w > 3 { val = utf8_acc_cont_byte!(val, s[i + 3]); } <del> return CharRange {ch: unsafe { transmute(val as u32) }, next: i + w}; </del> <ins> return CharRange {ch: unsafe { transmute(val) }, next: i + w}; </ins> } return multibyte_char_range_at(*self, i);

We need some way to interpret a as UTF-8, using the replacement character for invalid sequences instead of conditions. This would ideally be provided in the form of an .
Could we remove the current condition API in favour of this? It doesn't really seem to offer anything but failing, and we already have an API returning an .
I would be quite pleased if we could do that. Using the condition is rather awkward, and I would rather just have replacement chars myself.
This is a duplicate of , no?
And also the e-mail thread here I think is relevant:
This is an implementation of a mostly complete → UTF-8 decoder
It's only a duplicate if the intended resolution of is to use the replacement char instead of conditions, but it's unclear from the discussion if that's the plan.
I guess my thinking was that a maximally expressive condition-based solution would let one express a replacement char approach using conditions. But I don't actually favor doing that at this point. Or at least, I don't favor making that the only way to accomplish this, since I suspect a more specialized approach will be much nicer to use (both in terms of programmer convenience and in terms of efficiency). So okay, this is not a duplicate of .
Rust needs to support both fatal and replacement error handling modes, it should follow the WHATWG spec simonsapin has said (edit by is WHATWG spec.)
the fatal mode is already handled by the API
well, the current functions in str don't handle decoding buffers in chunks like the proposed encodings API. But yes, it does handle one-off decoding with 'fatal' error handling.
I think we need to improve/extend our API along the lines suggested here for 1.0. Nominating for P-backcompat-lang. (Arguably we could avoid the backwards compatibility hazard by offering a fail-only method for 1.0 and then adding an alternative entry point that provides the more flexible API supporting replacement characters in post 1.0. But I think this case is important enough that we should try to get the primary API method to provide both choices up front. That, or put dynamic fluid support in for representing the state of that choice.)
I submitted a PR for this last night, although I forgot there was an open issue too so I didn't link them. The PR is


Question: } } <del> visible_parent_map </del> <ins> drop(visible_parent_map); self.visible_parent_map.borrow() </ins> } }

I was going through some refactoring and the compiler exploded. No unsafe. The last bits of code I was playing with can be found , before I tried to refactor the example, the tests were building and passing. The macro that might be to blame is . I parked a branch with the code that made it blew up, you can find it here works, blows up. a happy compiler, worst case an unhappy one a dead compiler : Backtrace:
Minimal example:
Thanks that was a quick fix. Do you have a workaround until the fix makes it to master?
The ICE occurs when you have an item referenced in an impl signature is imported from an statement occurs within an impl. To work around the ICE, you can move the call to to a different free function.
Got it, it works , thanks!


Question: /* Code ========================================================================== */ pre, code { <del> font-family: Menlo, Monaco, Consolas, "Courier New", monospace; </del> <ins> font-family: Menlo, Monaco, Consolas, "DejaVu Sans Mono", monospace; </ins> border-radius: 4px; } pre { <del> background-color: #F5F5F5; </del> <ins> background-color: #FDFDFD; </ins> border: 1px solid #CCC; border-radius: 0.5em; white-space: pre-wrap;

It's currently very bright and distracting (IMO). (Sorry :( ) Current scheme, for future triage/comparison purposes: !
I think I should reconsider my career in graphic design.
I'm looking at this.
(The relevant file is , if you're lost. :) )
BTW I was wondering, why not just use for src line numbering? Probably more optimized/idiomatic in the browser.
Also, it's pretty much impossible to have consistency between rustdoc and the old codemirror (tutorial) since both parsers behave very differently. would it be possible to pass the standalone documentation through rustdoc?
Doesn't this mean every line is a new tag? Also, it possibly screws with copy-paste and making the formatting consistent. This bug is specifically about the colour scheme of rustdoc since it's so wild. Also, about using rustdoc for everything.
My preference for the highlighting scheme is bold for keywords, green for macros, red for strings (the current color is fine), gray for comments (would be nice if code within comments were highlighted). I'd also like to hear more suggestions before we change it.
Something I hacked up a few days ago: ! (The macro colour wasn't "optimised" at all.)
No, it would look like this: I think it would be better to use that since that's the browser native numberings. No it doesn't. The identifier of a list aren't inlined with the content. is an example.
Oh, awesome. It does seem like a good idea, if you can get that to work.
Another note: current rustdoc parsing could be improved, i.e. the "ident" class corresponds to variable names, function names, paths, parameters... could be more split if you ask me.
The highlighting is performed by just by the token types the lexer (with a little bit of extra logic for attributes, macros and $ non-terminals in macros) and so does not have that information.


Question: <del> //! Ensure that we call Windows TLS callbacks in the local crate. //@only-target-windows // Calling eprintln in the callback seems to (re-)initialize some thread-local storage // and then leak the memory allocated for that. Let's just ignore these leaks, // that's not what this test is about. //@compile-flags: -Zmiri-ignore-leaks #[link_section = ".CRT$XLB"] #[used] // Miri only considers explicitly `#[used]` statics for `lookup_link_section` pub static CALLBACK: unsafe extern "system" fn(*const (), u32, *const ()) = tls_callback; unsafe extern "system" fn tls_callback(_h: *const (), _dw_reason: u32, _pv: *const ()) { eprintln!("in tls_callback"); } fn main() {} </del>

I tried this code: I expected to see this happen: Compiles successfully. Instead, this happened: Fails with this error: nightly-2024-06-26 and earlier. nightly-2024-06-27 and later, starting with . See for a discussion of the issue. : cc
To elaborate, the difference is in symbols.o. Here's a dump of symbols.o before the change: And here's after: Spot the difference. Spoiler: is now present.
So is that right or wrong? The static is "used" so marking it exported to ensure it does not get optimized away seems to make sense? I don't understand why this is a problem only on Windows.
Well that's not a problem per se but if we want to do that then we have to do it properly. is defined as a in (on my machine). This is linked directly and not in a lib file. So it's already being included. There's no reason for to include it. The only issue is that is being emitted as a comdat, meaning the linker is still allowed to remove it. We could just not do that (or add a linker directive). But that's a pre-existing issue.
I don't understand any part of that.^^ Should my PR get reverted or is there a better way to fix this regression? If there is a better way, I am afraid I lack the knowledge to implement and test it. I don't understand symbol handling on Linux, let alone on Windows.
I don't know enough about the Rust compiler to say. My complete guess would be that was silently broken before but now it's nosily broken.
Hm, who would understand our Windows linking story? ?
After CGU partitioning, we try to internalize symbols when possible. What is surprising to me is that this process only looks at export level, ignoring used attribute (in the contrast to say the internalization during fat LTO). Consequently we have a situation where synthetic object file references a symbol that is no longer exported (on Linux that does not result in a linking error, even though reference is unresolved). Anyway, if the consequence of would be to export those symbols for no reason, that seems rather counter productive to me.


Question: <del> //! Ensure that we call Windows TLS callbacks in the local crate. //@only-target-windows // Calling eprintln in the callback seems to (re-)initialize some thread-local storage // and then leak the memory allocated for that. Let's just ignore these leaks, // that's not what this test is about. //@compile-flags: -Zmiri-ignore-leaks #[link_section = ".CRT$XLB"] #[used] // Miri only considers explicitly `#[used]` statics for `lookup_link_section` pub static CALLBACK: unsafe extern "system" fn(*const (), u32, *const ()) = tls_callback; unsafe extern "system" fn tls_callback(_h: *const (), _dw_reason: u32, _pv: *const ()) { eprintln!("in tls_callback"); } fn main() {} </del>

Ah, the behaviour was working to spec before: So I think I'd agree that is the wrong approach and should be reverted because this currently ends up conflating different things. Maybe changes elsewhere would fix this but I don't want to speculate.
the separate issue you pointed out earlier in is presumably still relevant for ?
Could this explain recent CI flakiness? The failure at and a couple other failed merges (linked on that thread, also the retries) have been msvc linker errors.
That's unfortunate. :/ Our reachable symbol code is such a spaghetti mess... I guess I'll just have to copy-paste more things into Miri then. :shrug: I am traveling right now, I'd appreciate if someone else could do the revert.
The following patch should fix the incorrect internalization I mentioned earlier: As for the question whether those symbols should be exported in the first place, it might be necessary for COFF and . The following code suggests that would not have the desired effect otherwise I don't have access to windows environment at the moment to verify that, so I don't plan to work on this myself.
Ooh this is also the stuff that also broke several ci-runs already ...
Looks like this did not fully fix the ci failures :melting_face:
Makes sense: some CI failures look non-deterministic, while we'd expect this error not to be.
Alternative approach for Miri:


Question: // option. This file may not be copied, modified, or distributed // except according to those terms. <ins> #![feature(lang_items)] </ins> #![no_std] <ins> #[lang="sized"] pub trait Sized for Sized? {} </ins> // error-pattern:requires `start` lang_item fn main() {}

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


Question: <ins> error[E0728]: `await` is only allowed inside `async` functions and blocks --> $DIR/async-outside-of-await-issue-121096.rs:7:7 | LL | fn main() { |    ---- this is not `async` ... LL |     }.await |       ^^^^^ only allowed inside `async` functions and blocks error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0728`. </ins>

<!-- 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> error: `#[doc(alias = "...")]` isn't allowed on associated constant in trait implementation block --> $DIR/doc-alias-assoc-const.rs:11:11 | LL |     #[doc(alias = "CONST_BAZ")] |           ^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error </ins>

Now that has been merged, only a few checks remain to be in order to stabilize this feature. First, we need to actually perform those checks in the compiler directly instead of rustdoc. You mentioned other checks too ? This issue is part of .
We should reject on items that don't actually appear in the search index such as blocks and s.
Ok, makes sense! Last question: I remember you telling that you'd prefer this check in rustc directly instead of rustdoc. I can move things there, just wanted to check one last time before doing it.
Yeah, rustc validates some attributes in and it might make sense to validate the attribute there as well.
Since has been merged, we can close this issue.
We're still not rejecting on associated s in trait impls like:
Ok! Putting on hold then!


Question: <ins> // run-rustfix // Regression test for #54505 - range borrowing suggestion had // incorrect syntax (missing parentheses). use std::ops::RangeBounds; // take a reference to any built-in range fn take_range(_r: &impl RangeBounds<i8>) {} fn main() { take_range(&(0..1)); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &(0..1) take_range(&(1..)); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &(1..) take_range(&(..)); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &(..) take_range(&(0..=1)); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &(0..=1) take_range(&(..5)); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &(..5) take_range(&(..=42)); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &(..=42) } </ins>

is an incorrect suggestion because has higher precedence than . It should suggest .
If someone wants to tackle this issue, it should be straightforward to fix. In: there should be another branch for , where the path of the call is . This code is a good reference: This issue affects the other range syntaxes too, so those should also be fixed (although these are not — look at for clues).
Hi I'd like to tackle this and take the plunge into the Rust compiler code :)
great! Let me know if you hit any snags or need any more tips. You'll want to add tests for these (in ). The is a good place for general information about the compiler. When you're done, include in the pull request and I'll review it!
you've anticipated most of my newbie questions already :) Thanks for that info, very useful! I'm now in the process of stressing my PC with lots of compiling to actually get started. Skimming the test code I'm really impressed by how easy it is to add "UI" tests for these sorts of things (compile this, expect this error on this line). Snazzy! That's all great, but do you anticipate I should also add "deeper" tests? I guess I'm trying to understand if the scope of this is just pure UI or do I need to touch some syntax parsing/immediate representations, since you mentioned code in . Because the compiler is emitting a syntax suggestion, we might want to assert that the suggestion is correct syntax in the first place. I don't know if that's how deep the rabbit hole goes and if there's a facility to help out, but my hunch is that since we have all of the compiler at hand, why not use it to validate the suggestion syntax? EDIT: OK, reading up on adding new tests to the compiler I encountered mention of , and it seems to be sort-of what I was after.
The issue here is just a diagnostic issue, so checking that we're getting the updated hint is enough. The code in is just helpful to see what ranges like and are desugared into, so you can catch them in — you shouldn't need to modify anything (apart from the test) outside of . It would technically be possible to do something like this, but it would probably be more trouble than it's worth.


Question: <ins> // run-rustfix // Regression test for #54505 - range borrowing suggestion had // incorrect syntax (missing parentheses). use std::ops::RangeBounds; // take a reference to any built-in range fn take_range(_r: &impl RangeBounds<i8>) {} fn main() { take_range(&(0..1)); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &(0..1) take_range(&(1..)); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &(1..) take_range(&(..)); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &(..) take_range(&(0..=1)); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &(0..=1) take_range(&(..5)); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &(..5) take_range(&(..=42)); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &(..=42) } </ins>

(I'm not aware of a facility to do this easily already.) I think manually going through the possible s and checking that the parenthesisation behaviour is correct in each case would be a lot simpler: if we handle the different s in an exhaustive now (it's likely that if the ranges were handled incorrectly, there could be some others that are also missed at the moment), then this should be a one-time fix and the tests should prevent it regressing. A simple UI test should be sufficient here: will generate the output files, which will include all the relevant notes.
There was a similar problem with the suggestions, and it was fixed in . Further use of the operator precedence list can be seen in (which introduced the error fixed in the other PR).
Thanks for your guidance and much appreciated. I have dug into HIR and built-in ranges a bit more. Decided to check all the built-in range types and concluded they are all indeed affected by this problem. The following test I came up with demonstrates my intended fix (fails with nightly as well as stage 1 compiled from master): None of the fix suggestions, when applied, constitute valid syntax. My test checks for syntax I believe should be suggested by the compiler. I'm keen to tackle all of the range types at once in the scope of this issue. The problem I see though is just how wildly different each of the range types is represented in HIR. Adding a call just above this line: Revealed the following: for isfor isfor isfor isfor isfor is I'm quite bewildered by this non-uniformity and I guess I need some help unifying all of these into a elegant condition to tell "is this a built-in range?". I could probably brute-force it in a with explicit checks for , but maybe we can do better. Thanks in advance! EDIT realized that this non-uniformity was actually mentioned in the second comment from , but my plea still stands. Thanks for your patience.
I think you can match on all of these with something along the lines of (pseudocode):
Right, that's what I had in mind, but was also wondering if something like a check for  trait would work better. I guess we want to match against built-in range literals though, and explicitly.


Question: <ins> // run-rustfix // Regression test for #54505 - range borrowing suggestion had // incorrect syntax (missing parentheses). use std::ops::RangeBounds; // take a reference to any built-in range fn take_range(_r: &impl RangeBounds<i8>) {} fn main() { take_range(&(0..1)); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &(0..1) take_range(&(1..)); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &(1..) take_range(&(..)); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &(..) take_range(&(0..=1)); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &(0..=1) take_range(&(..5)); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &(..5) take_range(&(..=42)); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &(..=42) } </ins>

Here's how I rationalize it: because they are parsed and desugared by the compiler, the check needs to be explicit and hardcode all paths to builtin ranges. Handle a special case with a special case.
Yes, this is where the lowering code comes in handy, because you can see exactly how the different syntax is desugared differently, to make sure you really are catching all the cases. Yes, I agree. It'd be nice if there was a more uniform way to handle them, but it's not convenient at the moment. You could include a reference back to in a comment to where the desugaring takes place, which will provide some motivation for matching in .
All clear now, thanks. I have succeeded in matching all range types and getting the test to pass. Needs some cleanups, but hopefully should be ready for PR soon. I have a few more questions before that though :smile: I have noticed that most of my code would actually be irrelevant if I re-used functions and constants defined in , e.g.: Can't deny that I have used these as inspiration / guideline (albeit I did not do a stupid copy-paste). What's the policy on using clippy code (clippy is a submodule of main repo)? This is purely in the interest of pursuing . The diff is not that big (52 new lines to , fairly specific to matching paths) -- but still, my clean code sense tingles because of possible DRY violation. Another conundrum I have is whether we should address and paths (and if so, how to work out we're not using at compile time)?
Unfortunately, there's not much sharing from clippy to rustc. I wouldn't worry about it. If you can encapsulate it easily, it's possible that clippy could make use of the code in rustc instead. The function in picks the correct path for / — you should be able to use that.
Thanks for the suggestion for , unfortunately I can't really make the association of and . It seems to me they are disjoint -- in : lowering happens in , whereas typechecking happens in . in takes : The it uses needs an awful lot of things to be instantiated. Not sure if I can get the hold of it all in .


Question: <ins> // run-rustfix // Regression test for #54505 - range borrowing suggestion had // incorrect syntax (missing parentheses). use std::ops::RangeBounds; // take a reference to any built-in range fn take_range(_r: &impl RangeBounds<i8>) {} fn main() { take_range(&(0..1)); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &(0..1) take_range(&(1..)); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &(1..) take_range(&(..)); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &(..) take_range(&(0..=1)); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &(0..=1) take_range(&(..5)); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &(..5) take_range(&(..=42)); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &(..=42) } </ins>

Another problem I encountered while writing tests is that the changes I have made will affect suggestions for code like this: With my changes, the suggestion would be . I believe the correct suggestion would not involve the needless parentheses. This is due to not differentiating between "de-sugared" form coming from and between these de-sugared forms being supplied explicitly as input source code. With this in mind, I think current code is not PR worthy just yet. If of interest, here's the branch:
Left a couple of comments on possible approaches on that commit. The code looks fine.


Question: <ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. struct X(int); enum Enum { Variant1, Variant2 } impl Drop for X { fn drop(&mut self) {} } impl Drop for Enum { fn drop(&mut self) {} } fn main() { let foo = X(1i); drop(foo); match foo { //~ ERROR use of moved value X(1i) => (), _ => unreachable!() } let e = Variant2; drop(e); match e { //~ ERROR use of moved value Variant1 => unreachable!(), Variant2 => () } } </ins>

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: } } <ins> /// Check if node is an impl block. pub fn is_impl_block(&self) -> bool { matches!(self, OwnerNode::Item(Item { kind: ItemKind::Impl(_), .. })) } </ins> expect_methods_self! { expect_item,         &'hir Item<'hir>,        OwnerNode::Item(n),        n; expect_foreign_item, &'hir ForeignItem<'hir>, OwnerNode::ForeignItem(n), n;

<!-- ICE: Rustc '--crate-type=lib -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error[E0107]: trait takes 1 generic argument but 0 generic arguments were supplied', 'error: internal compiler error[E0107]: trait takes 1 generic argument but 0 generic arguments were supplied' 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: --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc :thinking:
claim


Question: <ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. pub fn main() { struct Fun<F>(F); let f = Fun(|x| 3*x); let Fun(g) = f; println!("{:?}",g(4)); } </ins>

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


Question: sources::render(&mut cx, &krate)?; } <del> // Build our search index let index = build_index(&krate, &mut Rc::get_mut(&mut cx.shared).unwrap().cache, tcx); </del> <ins> if !no_emit_shared { // Build our search index let index = build_index(&krate, &mut Rc::get_mut(&mut cx.shared).unwrap().cache, tcx); // Write shared runs within a flock; disable thread dispatching of IO temporarily. Rc::get_mut(&mut cx.shared).unwrap().fs.set_sync_only(true); write_shared(&cx, &krate, index, &md_opts)?; Rc::get_mut(&mut cx.shared).unwrap().fs.set_sync_only(false); } </ins> <del> // Write shared runs within a flock; disable thread dispatching of IO temporarily. Rc::get_mut(&mut cx.shared).unwrap().fs.set_sync_only(true); write_shared(&cx, &krate, index, &md_opts)?; Rc::get_mut(&mut cx.shared).unwrap().fs.set_sync_only(false); </del> Ok((cx, krate)) }

<!-- 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 rendering docs for a crate with: That puts this in the sidebar: ! In this case, and are dependencies (which I don't want to document). And is the name of one of the examples, this is a dead link.
cc - running on dependencies seems like a cargo bug, but showing them in the sidebar seems like it's an issue in rustdoc.
Thanks for the report I will take a look this week.
Ok, I have fixed the issue where examples show up in the crates list. However, I wasn't able to reproduce the issue with non-examples appearing in the crates list. Specifically, my setup was: I could not get to appear in the sidebar when using .
Thanks I tried some more things, and I think what happened is that I used it without at first, and then without clearing the folder, did it with , which apparently doesn't remove the dependencies from the sidebar. So I guess that part of the issue is about not working quite right when these artefacts already exist, and unrelated to .


Question: <del> warning: `$crate` may not be imported --> $DIR/import-crate-var.rs:7:5 </del> <ins> error: `$crate` may not be imported --> $DIR/import-crate-var.rs:6:5 </ins> | LL |     m!(); |     ^^^^^ | <del> = note: `use $crate;` was erroneously allowed and will become a hard error in a future release = note: this warning originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info) </del> <ins> = note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info) error: aborting due to previous error </ins>

The warning was introduced in to avoid breakage from .
Presumably the next step is to make this an error by default.
Triage: Digging through all the linked issues is tough, and it's not clear to me exactly what this warning is or does. can you maybe elaborate a little?
This needs to be turned into an error, i.e. behave like basically:
Relevant code is here: Should be easy to turn that into and then do a crater run.


Question: //@ aux-build:issue-76736-1.rs //@ aux-build:issue-76736-2.rs <ins> // https://github.com/rust-lang/rust/issues/124635 </ins> #![crate_name = "foo"] #![feature(rustc_private)]

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


Question: use crate::cgu_reuse_tracker::CguReuseTracker; use crate::code_stats::CodeStats; pub use crate::code_stats::{DataTypeKind, FieldInfo, SizeKind, VariantInfo}; <del> use crate::config::{self, CrateType, OutputType, PrintRequest, SwitchWithOptPath}; </del> <ins> use crate::config::{self, CrateType, OutputType, SwitchWithOptPath}; </ins> use crate::filesearch; use crate::lint::{self, LintId}; use crate::parse::ParseSess;

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: ty::Alias(kind @ (ty::Projection | ty::Opaque), alias_ty) => (kind, alias_ty), ty::Alias(ty::Inherent | ty::Weak, _) => { <del> unreachable!("Weak and Inherent aliases should have been normalized away already") </del> <ins> self.tcx().sess.dcx().span_delayed_bug( DUMMY_SP, format!("could not normalize {self_ty}, it is not WF"), ); return; </ins> } };

<!-- ICE: Rustc '-Znext-solver=coherence -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'internal error: entered unreachable code: Weak and Inherent aliases should have been normalized away already'', 'thread 'rustc' panicked at 'internal error: entered unreachable code: Weak and Inherent aliases should have been normalized away already'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [specializationgraphof] building specialization graph of trait [coherent_trait] coherence checking all impls of trait [analysis] running analysis passes on this crate --
cc


Question: enum priv_enum { foo2, bar2 } //~ ERROR: enum is never used enum used_enum { foo3, <del> bar3 //~ ERROR variant is never used </del> <ins> bar3 //~ ERROR variant is never constructed </ins> } fn f<T>() {}

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> error[E0412]: cannot find type `Bar` in this scope --> $DIR/issue-36836.rs:13:17 | LL | impl<T> Foo for Bar<T> {} |                 ^^^ not found in this scope error: aborting due to previous error For more information about this error, try `rustc --explain E0412`. </ins>

The second error in this snippet is "nonsense" because it says the type parameter is not constrained, while the real error was already reported — the actual type could not be imported. Found in: rustc 1.13.0-nightly ( 2016-09-26)
.


Question: //! A copy of the `Qualif` trait in `qualify_consts.rs` that is suitable for the new validator. <del> use rustc::hir::def_id::DefId; </del> use rustc::mir::*; use rustc::ty::{self, Ty}; use syntax_pos::DUMMY_SP;

root: gb2260-0.1.1: v. root: imperative - 3 (1 gh, 2 ) detected crates which regressed due to this <detailscommitted-0.1.11: v. imperative-1.0.1: v. epage/committed: v. </detailscc (likely MIR borrowck related, though not the transition itself as that happened last cycle)
Probably a result of the soundness fixes in
This is a change in promotion. cc
Minimized:
Maybe ?
or . No, it's neither of these.
It's , likely .


Question: assert!(plan.iter().all(|s| s.host == "A")); assert!(plan.iter().all(|s| s.target == "C")); <del> assert!(plan.iter().any(|s| s.name.contains("-ui"))); assert!(plan.iter().any(|s| s.name.contains("cfail"))); </del> <ins> assert!(!plan.iter().any(|s| s.name.contains("-ui"))); </ins> assert!(plan.iter().any(|s| s.name.contains("cfail"))); assert!(!plan.iter().any(|s| s.name.contains("cfail-full"))); assert!(plan.iter().any(|s| s.name.contains("codegen-units")));

Inlined from Another issue. If a struct has two different custom derives on it and the second one panics, the error span will point to the first one, not the one which panicked. Reproduction Script
was "Reproduction Script" supposed to be a link? I'm spinning this off from as I don't think it's going to block stabilization and/or closing that issue.
Reproduction script there is a summary tag
<details<summaryReproduction Script</summaryIn a crate called In another crate The error will highlight even though panicked. </details
This seems to be fixed now, so this issue can be closed.
I ran this as a test, and got the following output:


Question: fn default() -> BinaryHeap<T> { BinaryHeap::new() } } <ins> #[stable(feature = "binaryheap_debug", since = "1.4.0")] impl<T: fmt::Debug + Ord> fmt::Debug for BinaryHeap<T> { fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { f.debug_list().entries(self.iter()).finish() } } </ins> impl<T: Ord> BinaryHeap<T> { /// Creates an empty `BinaryHeap` as a max-heap. ///

If I run the following code : I get the following error : I don't see any reason for the trait Debug not to be implemented for BinaryHeap. If seeing the nodes of it is a problem, at least a could be enough.
Should be fine to display the elements -- probably an oversight?
Probably an oversight. Implementing the solution shouldn't take more than a line (few at most) and it is annoying that you can't easily implement debug for struct owning one BinaryHeap.


Question: TyUint(uty) => (Integer::from_attr(tcx, UnsignedInt(uty)), false), _ => bug!("non integer discriminant"), }; <ins> let bit_size = int.size().bits(); let amt = 128 - bit_size; </ins> if signed { <del> let (min, max) = match int { Integer::I8 => (i8::min_value() as i128, i8::max_value() as i128), Integer::I16 => (i16::min_value() as i128, i16::max_value() as i128), Integer::I32 => (i32::min_value() as i128, i32::max_value() as i128), Integer::I64 => (i64::min_value() as i128, i64::max_value() as i128), Integer::I128 => (i128::min_value(), i128::max_value()), </del> <ins> let sext = |u| { let i = u as i128; (i << amt) >> amt </ins> }; <del> let val = self.val as i128; </del> <ins> let min = sext(1_u128 << (bit_size - 1)); let max = i128::max_value() >> amt; let val = sext(self.val); assert!(n < (i128::max_value() as u128)); </ins> let n = n as i128; let oflo = val > max - n; let val = if oflo {

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


Question: <ins> #![feature(non_lifetime_binders)] //~^ WARN the feature `non_lifetime_binders` is incomplete trait Trait<Input> { type Assoc; } fn uwu(_: impl for<T> Trait<(), Assoc = impl Trait<T>>) {} //~^ ERROR `impl Trait` can only mention type parameters from an fn or impl fn main() {} </ins>

<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
minimized
Bisected to :sweatsmile:


Question: fn read_port(&mut self) -> Option<u16> { self.read_atomically(|p| { p.read_given_char(':')?; <del> p.read_number(10, None) </del> <ins> p.read_number(10, None, true) </ins> }) }

According to the , "The four octets are in decimal notation, divided by . (this is called 'dot-decimal notation'). Notably, octal numbers and hexadecimal numbers are not allowed per IETF RFC 6943"; however the parsing of the violates the "strict" form mentioned in —this form is what prohibits octal and hexadecimal numbers—meanwhile the conforms to it. IETF RFC 6943 Section 3.1.1. states: If the af argument of inetpton() is AFINET, the src string shall be in the standard IPv4 dotted-decimal form: where "ddd" is a one to three digit decimal number between 0 and The inetpton() function does not accept other formats (such as the octal numbers, hexadecimal numbers, and fewer than four numbers that inetaddr() accepts). As shown above, inetpton() uses what we will refer to as the "strict" form of an IPv4 address literal. Some platforms also use the strict form with getaddrinfo() when the AINUMERICHOST flag is passed to it. I tried this code: I expected to see this happen: both s not causing a panic since the first has an octet represented by more than three base-10 numbers despite the requirement per RFC 6943 stating each octet be a "one to three digit decimal number". The second is valid per RFC 6943 since it is a string of exactly 4 octets separated by where each octet is a "one to three digit decimal number". Instead, this happened: Both lines cause a panic. : : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details
I believe that the second input () is not valid, since the spec explicitly says that octal numbers are disallowed, and is an octal number in the loose form. The example in the RFC for an octal number is , which parses to if you use octal, but if you use decimal. If you instead have it parse it always as , that means that bad things can happen, such as different tools interpreting as different things.


Question: fn read_port(&mut self) -> Option<u16> { self.read_atomically(|p| { p.read_given_char(':')?; <del> p.read_number(10, None) </del> <ins> p.read_number(10, None, true) </ins> }) }

If you read the source code where the ipv4 address is parsed, it specifically disallows that: Regarding , the documentation only says that the disallowing of hexadecimal and octal numbers are according to IETF RFC 6943, and does not say anything about only allowing three digits. Also, four or more zeroes are an edge case, and thus the only numbers that can be parsed there with more than three digits, due to the disallowing of octal numbers apart from .
From the :
I'm confused by these comments. Padded zeros is not unique to the base-8 numeral system. Base-2, Base-3, etc. all have the property of having an infinite number of padded zeros with the convention being to truncate them all. After all is also valid in base-8, base-9, etc. The documentation is quite clear that the octets are to be interpreted in base-10 though, so this problem of how to interpret the octets is solved. Consequently the last octet in is interpreted as 1 in base-10 for the same reason the first octet in is interpreted as 127 in base-10 and not some other value (e.g., 87 in base-10) namely because the documentation says so. After all objecting to on the grounds that the last octet could be in base-8—again, all of the octets there could be in base-8—doesn't apply to the fact that is also rejected by the parsing algorithm since clearly each of those octets are not in base-8 since is not a symbol in the base-8 numeral system. This is of course nothing more than a consequence of incorrectly assuming padded 0s means base-8. The inconsistent treatment of 0 (in base-10) is also a consequence of this incorrect assumption. Why is 0 (in base-10) allowed to be represented by one or more s, but 1 (in base-10) cannot have padded s? There is nothing special about the syntactic representation of 0 (in base-10) that warrants this inconsistent treatment. To me the solution is clear: more strictly follow IETF RFC 6943 and enforce that each octet be one-to-three digits in length.


Question: fn read_port(&mut self) -> Option<u16> { self.read_atomically(|p| { p.read_given_char(':')?; <del> p.read_number(10, None) </del> <ins> p.read_number(10, None, true) </ins> }) }

One could even follow a stricter format and require that there be no padded s at all—since the RFC doesn't actually specify that. This would then lead to consistent behavior (that's also more easily predictable since it follows a well-established convention) in that both and will either be accepted (since they both follow RFC 6943) or rejected (if a stricter form is required that requires the minimal number of digits necessary to represent each octet).
This is not an incorrect assumption, as octal numbers in the loose format are specified by the number having a leading zero. (See for the PR that banned octal numbers) This is an implementation detail in the way that it checks for leading zeroes: it checks if the number starts with a zero and rejects it if the resultant parsed number is not zero.
So we are re-defining how mathematics defines numeral systems? Saying that is in base-8 (i.e., octal) because of the leading makes no sense since none of those symbols except exist in that system. Rust certainly doesn't treat the in base-8 here: . Also the documentation clearly states that each octet is in "decimal notation". Suddenly treating the octet as base-8 is a clear contradiction to the documentation.
Using leading zeros to designate octal literals is a fairly common convention. In other languages like JS and C, . Rust doesn't have that as an octal prefix because it is confusing. When using leading zeros to indicate octal numbers, isn't a valid number at all (in the same way that isn't a valid base-10 number).
So it sounds like the documentation needs to be modified. It is confusing (because it is contradictory to reality) to say that each octet is in decimal notation when the actual implementation requires each octet to be either base-10 or base-8 where the latter is assumed when there are leading s and the value is not 0—at which point any positive-integer amount of s are allowed—and furthermore error when any octet is interpreted as base-8. Seems much easier to both document and comprehend to simply require at most 3 decimal digits for each octet and either forbid leading s (including for the integer 0) or allow leading s (including ).
"The actual implementation" is relevant only insofar as its behavior is externally observable.


Question: fn read_port(&mut self) -> Option<u16> { self.read_atomically(|p| { p.read_given_char(':')?; <del> p.read_number(10, None) </del> <ins> p.read_number(10, None, true) </ins> }) }

And -- correct me if I'm wrong -- in every case where the function succeeds, it (behaves as if it) interprets all digits in decimal, right? So I'd say it is correct to say that everything is "in decimal notation". The only weird bit is that is accepted, but is not. This is strange, but not in contradiction with saying things are "in decimal notation".
When the documentation says the "four octets are in decimal notation", that is effectively a definition which in turn can be phrased as a logical biconditional. In this case, the logical biconditional I formed in my head was something like: "a will be parsed into an iff it is a sequence of exactly 4 base-10 numbers delimited by a ". Only one of those directions is true: if an is produced from parsing a , then the was a sequence of exactly 4 base-10 numbers delimited by a . The other direction, which is observable via a parsing failure, is not true as can be seen with something like . That is a sequence of exactly 4 base-10 numbers delimited by a , but it leads to a parsing failure. As was discovered in the discussion , it sounds like "decimal notation" as used in the documentation is not what it has meant my entire life nor what it means in a lot of areas in Rust. Specifically, any number that has leading s is not a base-10 number but in fact a base-8 number. With this modified definition of "decimal"; then my counterexample, , is in fact not a counterexample since each of those octets are not in "decimal" notation but in fact base-8. Even more perplexing as stated by is that "a lone 0 is technically octal as well in C, not that it matters" which means the definition of "decimal" used in the documentation is neither the mathematical definition nor the C definition—since something like is successfully parsed despite each of those octets being in base-8 per the C definition.
That's true in C. (Specifically, it is how C converts series of digits to numbers. "Numbers" don't have leading 0s, numbers are elements of the set of integers. The representation of a number as a string of digits can have leading 0s.


Question: fn read_port(&mut self) -> Option<u16> { self.read_atomically(|p| { p.read_given_char(':')?; <del> p.read_number(10, None) </del> <ins> p.read_number(10, None, true) </ins> }) }

At least that's how I think the term is usually used when one needs to be precise about series of digits vs. the thing they represent.) However, it's not true for this function. Any number that has leading 0s is rejected by this function. This fact about C was brought up only to explain why leading 0s are rejected. No base-8 occurs anywhere in the behavior of this function. If you disagree, please show an input-output pair for this function which demonstrates that base 8 is used. (The code inside the function doesn't matter, of course. Only its observable behavior does.) I really don't understand why you keep insisting that this function has anything to do with base 8. I think it might be because of some quirk in how it is implemented, but unobservable implementation details are irrelevant. As a mathematician you should be even more used to this than most programmers, since the usual way of defining mathematical functions consists entirely of input-output pairs, there is not even such a thing as an "implementation"... but I am digressing. ;) Even mathematically speaking, the sequence of digits "0" represents the same number in any base system. So, in a very precise formal sense, "not that it matters" is accurate. A base is just a way to convert a series of digits into a number, and for series of digits consisting only of 0s, the result is always the same. The definition of "decimal" used in the documentation exactly matches the mathematical definition. The documentation just fails to mention that there is an additional restriction, namely that no leading 0s are accepted (except if all digits of an octet are 0). However, it remains the case that if an input is accepted by this function, then all octets are interpreted as decimal -- and moreover, all decimal representations without leading 0s are accepted by this function.
Saying a definition matches exactly with another definition before subsequently changing the definition by adding other restrictions does not make sense to me. Does the definition of an even integer "match exactly" with the definition of an integer? No. Adding or removing restrictions to a definition changes the definition. So the fact that leading s is not allowed means we are not talking about mathematical base-10.


Question: fn read_port(&mut self) -> Option<u16> { self.read_atomically(|p| { p.read_given_char(':')?; <del> p.read_number(10, None) </del> <ins> p.read_number(10, None, true) </ins> }) }

If I define a function that takes an integer and it errors any time the integer is not even; however the documentation of that function makes no mention of that seems very problematic. I would not defend such documentation by saying "my definition of integer matches exactly with the definition of the mathematical definition of an integer except I also require the integer to be divisible by 2". My documentation should very clearly define what I mean by "integer", or better, simply state "even integer".
Okay, I guess I should have said that it is strictly a restriction of the mathematical definition (a subset, if you take the graph view of a function). But it doesn't disagree on any inputs where it is defined. Your talking about base 8 makes it sound like sometimes it is not matching the base 10 function even when it does produce a result (but matches the base 8 function instead), and it took a quite a lot of time to realize that is not what happens. Moreover, the subset still contains the full graph of the inverse of the full "base 10" function where you always pick the shortest representation (i.e., the most common "serialization" function of numbers into base 10 representation). So unlike your "even" example it is a pretty reasonable parsing function still. There are only some "non-canonical" representations being rejected.
Well, I think we are talking in circles at this point honestly, lol. While I would agree my example is a more extreme example of documentation failure since conflating the definition of "even integer" with "integer" is more absurd than conflating the definition of "base-10 in the shortest representation (with the exception of 0 which is allowed any non-negative integer amount of leading 0s)" with "base-10", both examples suffer from the fact that additional failures occur than otherwise would occur based on the exact definition of the term that is used (in my example "integer" and in this example "decimal"). For me, as I mentioned in the other discussion, this really is not me being "pedantic". I wrote code based on the documentation that ended being invalid since I (mis-)interpreted "decimal" to be more general than what it actually means in this context.


Question: fn read_port(&mut self) -> Option<u16> { self.read_atomically(|p| { p.read_given_char(':')?; <del> p.read_number(10, None) </del> <ins> p.read_number(10, None, true) </ins> }) }

Ideally, in my opinion at least, that should not happen especially since it is not that much additional effort to more properly document what certain terms mean even if that means just adding one or two more examples highlighting parsing failures (or successes) that one (like myself) would not expect.
We already agree that the docs need to be improved. :) The rest of this discussion is then mostly philosophical and not going to lead to a productive outcome, so maybe we better stop it. ;)


Question: build.verbose = args.verbose build.clean = args.clean <del> # Read from `RUST_BOOTSTRAP_CONFIG`, then `--config`, then fallback to `config.toml` (if it </del> <ins> # Read from `--config`, then `RUST_BOOTSTRAP_CONFIG`, then fallback to `config.toml` (if it </ins> # exists). <del> toml_path = os.getenv('RUST_BOOTSTRAP_CONFIG') or args.config </del> <ins> toml_path = args.config or os.getenv('RUST_BOOTSTRAP_CONFIG') </ins> if not toml_path and os.path.exists('config.toml'): toml_path = 'config.toml'

It seems pretty strange to me that the env variable would take precedence over --config. It would be nice to switch the precedence. cc Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Added in ; it seems like it makes sense for --config to override, though probably not typically all that useful. Happy to see a PR, should be pretty easy so marking as such.
claim


Question: // Version of LLDB pub lldb_version: Option<String>, <ins> // Version of LLVM pub llvm_version: Option<String>, </ins> // Path to the android tools pub android_cross_path: PathBuf,

I believe this is due to travis using system llvm which misses the fix backported in . cc
Can we do anything about this?
Our best bet is to add a for tests, I think (alternative is to drop support for LLVM pre 3.9, which would be a shame, even if its buggy in certain cases). Implementation of such directive could be implemented by injecting an environment variable or some such (done ) and checking for that in
There's no need to set an extra environment variable, just check if is set (or if you're boring :wink: )
but… but… what if people have on their own systems too?
cc
no we do not have existing infrastructure for this. I'd prefer to avoid as that's not the relevant piece here, but rather something like or . Distros or anyone else building with an older LLVM are likely to hit this and we'd need a solution for them as well. That being said I think it's fine to temporarily disable the test until we get that. There's basically a 0% chance of us regressing that test as it's just an LLVM bug, and they already have a regression test upstream as well.
Another option would be to create a base Docker image (publishing it to Docker Hub) that is just and the appropriate steps to build whatever version of LLVM we want.
We currently advertise ourselves as supporting LLVM 3.7+, and Travis is kinda our test for that, so I'd prefer to not pull that forward just yet (but instead just fix this)
For the record, I downgraded our LLVM version in a botched rebase and only this test stopped it at bors. Hopefully, someone would have noticed the absence of a fix, but you can't count of that.
touche!


Question: match ocx.eq(&misc_cause, param_env, opaque_ty, hidden_ty) { Ok(()) => {} Err(ty_err) => { <ins> // Some types may be left "stranded" if they can't be reached // from an astconv'd bound but they're mentioned in the HIR. This // will happen, e.g., when a nested opaque is inside of a non- // existent associated type, like `impl Trait<Missing = impl Trait>`. // See <tests/ui/impl-trait/stranded-opaque.rs>. </ins> let ty_err = ty_err.to_string(tcx); <del> tcx.dcx().span_bug( </del> <ins> let guar = tcx.dcx().span_delayed_bug( </ins> span, format!("could not unify `{hidden_ty}` with revealed type:n{ty_err}"), ); <ins> return Err(guar); </ins> } }

<!-- ICE: Rustc '' 'error: internal compiler error: could not unify with revealed type:', 'error: internal compiler error: could not unify with revealed type:' 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: [checkwellformed] checking that is well-formed [checkmodtype_wf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --
crashes since cc
Note: ICEs aren't crashes, we have a separate label for crashes (they mean segfaults and similar)
ungraceful exit of the compiler has been observed since :upsidedownface:
This has nothing to do with non-lifetime binders. I somewhat expect that when a "minimized" repro is tagged with a feature tag, there has been an attempt to check that the ICE is actually dependent on the feature, since that affects the prioritization of the issue.


Question: #![no_std] #![feature(lang_items)] <ins> #[lang="sized"] pub trait Sized for Sized? {} </ins> #[lang="fail"] fn fail(_: &(&'static str, &'static str, uint)) -> ! { loop {} }

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


Question: .chain(features.declared_lib_features.iter().map(|(name, span)| (name, span))) .filter(|(&name, _)| features.incomplete(name) || features.internal(name)) .for_each(|(&name, &span)| { <del> let note = rustc_feature::find_feature_issue(name, GateIssue::Language) .map(|n| BuiltinFeatureIssueNote { n }); </del> if features.incomplete(name) { <ins> let note = rustc_feature::find_feature_issue(name, GateIssue::Language) .map(|n| BuiltinFeatureIssueNote { n }); </ins> let help = HAS_MIN_FEATURES.contains(&name).then_some(BuiltinIncompleteFeaturesHelp); cx.emit_spanned_lint( INCOMPLETE_FEATURES, span, BuiltinIncompleteFeatures { name, note, help }, ); } else { <del> cx.emit_spanned_lint( INTERNAL_FEATURES, span, BuiltinInternalFeatures { name, note }, ); </del> <ins> cx.emit_spanned_lint(INTERNAL_FEATURES, span, BuiltinInternalFeatures { name }); </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: note the duplicate <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
feature, not a bug: we want people to be very strongly discouraged, so we say it twice.
the more repetions, the more discouraged. lang_items should go up to 10.
Maybe we should print it in an infinite loop, just to be on the save side?
This is happening on as well.
claim The source of the problem is the decorator for which is adding two to the Diagnostic instead of one. I'm trying to dig further and decipher the marco-generated decorator code here: I also noticed that the behaviour seems to differ across gates. E.g. building this: emits one note for and two notes for : Not sure what's different about these gates. I'm new to this area, so if you can provide any pointers based on the above, please do.
This program tests all the internal gates: It produces the following output: Of the 21 internal gates, only the last 6 result in duplicate notes.
These should be more, there's a file somewhere that defines all the features but I can't check it right now on mobile
I think that should be all of them. This is super weird indeed, no idea
Thanks & I found what's different about gates with duplicate notes: they all have an associated issue. Here's the full list grepped from : Notice that the second last field in the last 6 lines is unlike the rest where it is . Apparently having an associated issue causes this problem.
The root cause is the being passed on this line: Its value is for gates that have an associated issue and for others. Since already has a attribute: this results in duplicates. The solution is to always pass for internal gates.


Question: <ins> error: expected pattern, found `$` --> $DIR/issue-116781.rs:4:16 | LL |     field: fn(($),), |                ^ expected pattern error: expected pattern, found `$` --> $DIR/issue-116781.rs:4:16 | LL |     field: fn(($),), |                ^ expected pattern | = note: duplicate diagnostic emitted due to `-Z deduplicate-diagnostics=no` error: aborting due to 2 previous errors </ins>

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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regression in nightly-2021-04-12 finding bors merge commits found 9 bors merge commits in the specified range commit[0] 2021-04-10: Auto merge of - Aaron1011:new-preexp-tests, r=petrochenkov commit[1] 2021-04-10: Auto merge of - Aaron1011:derive-invoc-order, r=petrochenkov commit[2] 2021-04-11: Auto merge of - RalfJung:liballoc-miri, r=Manishearth commit[3] 2021-04-11: Auto merge of - nagisa:nixos-patching-fix, r=Mark-Simulacrum commit[4] 2021-04-11: Auto merge of - JohnTitor:issue-, r=estebank commit[5] 2021-04-11: Auto merge of - Aaron1011:feature/final-preexp-tts, r=petrochenkov commit[6] 2021-04-11: Auto merge of - LingMan:patch-1, r=nagisa commit[7] 2021-04-11: Auto merge of - tweksteen:androidsetmessage, r=m-ou-se commit[8] 2021-04-11: Auto merge of - hyd-dev:uwtable, r=nagisa
claim
Reduced reproduction:
claim


Question: mod a { mod b { <del> use self as A; //~ ERROR `self` imports are only allowed within a { } list //~^ ERROR unresolved import `self` [E0432] //~| no `self` in the root </del> <ins> use self as A; //~^ ERROR `self` imports are only allowed within a { } list </ins> use super as B; //~^ ERROR unresolved import `super` [E0432] //~| no `super` in the root

It currently gives two - one for outside and one for an unknown import. The latter should be silenced. e.g.,
I will work on this
On an related note, shouldn't there be a lint for . Maybe say "you can just use ."


Question: source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)", <del> "phf 0.7.22 (registry+https://github.com/rust-lang/crates.io-index)", "phf_codegen 0.7.22 (registry+https://github.com/rust-lang/crates.io-index)", </del> <ins> "phf 0.7.24 (registry+https://github.com/rust-lang/crates.io-index)", "phf_codegen 0.7.24 (registry+https://github.com/rust-lang/crates.io-index)", </ins> "serde 1.0.92 (registry+https://github.com/rust-lang/crates.io-index)", "serde_derive 1.0.81 (registry+https://github.com/rust-lang/crates.io-index)", "serde_json 1.0.33 (registry+https://github.com/rust-lang/crates.io-index)",

I noticed this scrolling by while "Building stage0 compiler artifacts" today: Optimistically flagging E-easy
I'd like to work on this, how can I fix? make rustc use one version(maybe v0.6.1)?
You will need to look into each dependency that depends on (by searching through ), check if they have a newer version that depends on new , and finally use to upgrade those crates.
Thanks! When I checked, it seems each rand version is used.
Yeah, it's natural that they are all used, and you could try to eliminate those crates using old by upgrading or refactoring. That said, there isn't much drawback with an older , so in that case this issue can be just closed.
Oh, I'm sorry, I misunderstood. Hmmm, I think we don't have to fix this quickly and this may be a catalyst for a newbie like me to contribute, so I leave this, okay?
but one could argue that it will lower the time to compile so it's worth to fix IMHO ;)
Uh, would it be better to fix?
Disclaimer: I'm not a core member, but IMHO this is worth fixing. Also scottmcm who is a core member opened this issue, so I guess you're good to go and fix that issue :)
Okay, I want to try to fix. For instance, depends on , how can I update or refactor this?
That's one thing you can't edit, because rand is a dependency of crossbeam-channel here, so the crate crossbeam-channel needs to update its dependecy (maybe it already did and you just need to update crossbeam-channel itself)?
For future reference, running  from is an easy way to identify the source of all duplicates.
Thanks ! I got this tree(). I updated , but is latest and depends on (). What should I do?
I'm not on compiler (or core), so don't take my word on this one :slightlysmilingface: It looks like upstream rayon needs 0.5, so you could consider making a PR to upgrade it to 0.6. (Maybe .) Also, it seems that , so they'd probably appreciate a PR to upgrade it to newer upstream.
Current rayon only uses rand as a dev-dependency, since rayon-rs/rayon.


Question: source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)", <del> "phf 0.7.22 (registry+https://github.com/rust-lang/crates.io-index)", "phf_codegen 0.7.22 (registry+https://github.com/rust-lang/crates.io-index)", </del> <ins> "phf 0.7.24 (registry+https://github.com/rust-lang/crates.io-index)", "phf_codegen 0.7.24 (registry+https://github.com/rust-lang/crates.io-index)", </ins> "serde 1.0.92 (registry+https://github.com/rust-lang/crates.io-index)", "serde_derive 1.0.81 (registry+https://github.com/rust-lang/crates.io-index)", "serde_json 1.0.33 (registry+https://github.com/rust-lang/crates.io-index)",

That wouldn't show up in here at all, if rustc-rayon follows suit.
So the latest versions are and , but is used in this repository. They come from . Maybe those dependencies should be updated or made optional?
It looks like this was fixed in PR and merged by bors. Should this issue be closed now?
There are still 3 versions of rand in use:
will remove rand 0.5, I can get rid of 0.4 anytime but there are many PRs modifying right now.
Update: is used by , and (via ).
That's with -- only uses as a dev-dependency.
I didn't check now, but at some point was using an old version of a custom fork of .
has rebased since then, so it already reflects that dependency change.
I tried to fix a part of this in , but it didn't come out as planned. There is dependency and license whitelist that needs to be updated. I think just running leaves only one usage of via and (which can be updated). But then there is the licensing story, and it's not very clear to me which dependencies are used by the tools, and which by the compiler.
Last time I checked and were the only thing preventing of , otherwise I'd fix it already. We are working on removing it but it's blocked on releasing new version of .
I think goes away after a , so that one might be easy to fix. I don't know how dependencies are updated across the repository. Is it just that most of them are for the tools, not for and ? Does somebody run from time to time? And why does the license check fail on bors on my PR, but not on Travis or on my computer?
So released new version since. Correct, dependencies of everything that is created by are tracked by single . Dependencies are often updated separately as needed because upgrading everything at once is likely to break something and it's easier to find what is wrong when you change like 5 dependencies instead of 50. I think it should error when you run .
Also you can run the same image that found the error ( in this case) by using these steps


Question: ss_size: SIGSTKSZ, }; sigaltstack(&stack, ptr::null_mut()); <del> munmap(handler._data, SIGSTKSZ); </del> <ins> // We know from `get_stackp` that the alternate stack we installed is part of a mapping // that started one page earlier, so walk back a page and unmap from there. munmap(handler._data.sub(page_size()), SIGSTKSZ + page_size()); </ins> } } }

Rust's runtime installs a signal handler to distinguish stack overflows from other faults. This requires using an alternate signal stack (), which we create with the default size . That's usually quite small, 8KB or so depending on the target, but it's still plenty for what the handler is doing. There's currently no guard page like we have on normal stacks. That alternate stack is shared by all signals for a thread, so if a user installs any other signal handler, and they opt in with the flag , they'll be limited to the same tiny stack. If their handler happens to be more involved and overflows that stack, it may silently clobber other memory. If we had a guard page on the signal stack, that would cause a process abort instead. This was reported to the Security Response WG with a reproducer in . However, after discussion we decided to treat this as a normal issue for a few reasons: Setting a custom signal handler requires code. Signal handlers already run in a quite constrained environment, e.g. . It's unusual to use for signals other than , and if you choose so, you also bear responsibility to make sure that stack suffices. Nevertheless, as a defensive measure, it's still a reasonable idea to map a guard page when Rust is creating its signal stack, so an unexpected overflow will abort rather than silently corrupting memory. For full protection, that would also depend on the guard page not being skipped, but not all targets have stack probes yet (). Thanks to for reporting this in accordance with our , even though we have decided not to treat this as a security issue at this time. cc
cc This is another reason we perhaps shouldn't be registering the signal handler... cc


Question: <ins> // run-rustfix pub enum Range { //~^ ERROR `enum` and `struct` are mutually exclusive Valid { begin: u32, len: u32, }, Out, } fn main() { } </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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: <!-- Please provide a link to --The current output is: <!-- The following is not always necessary. --Ideally the output should look like: Highlight to the user that the keywords and are mutually exclusive. Replace with . <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim


Question: if !fail { return None; } <del> bug!("unexpected const parent in type_of_def_id(): {:?}", x); </del> <ins> tcx.sess.delay_span_bug( DUMMY_SP, &format!( "unexpected const parent in type_of_def_id(): {:?}", x ), ); tcx.types.err </ins> } } }

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


Question: last_import_segment: false, unusable_binding: None, <ins> pat_span_map: Default::default(), </ins> partial_res_map: Default::default(), import_res_map: Default::default(), label_res_map: Default::default(),

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> // Regression test for ICE #129503 // Tests that we come up with decent error spans // when the template fed to `asm!()` is itself a // macro call like `concat!()` and should not ICE use std::arch::asm; fn main() { // Should not ICE asm!(concat!(r#"lJ𐏿Æ�.𐏿�"#, "r} {}")); //~^ ERROR invalid asm template string: unmatched `}` found // Macro call template: should point to // everything within `asm!()` as error span asm!(concat!("abc", "r} {}")); //~^ ERROR invalid asm template string: unmatched `}` found // Literal template: should point precisely to // just the `}` as error span asm!("abc", "r} {}"); //~^ ERROR invalid asm template string: unmatched `}` found } </ins>

<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'', 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'' 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: [resolverforlowering_raw] getting the resolver for lowering --
cc
(without looking at the code, is it ?) EDIT: ah no this might be the other class of macro-related unicode troubles, seems similar to