Question: fn main() -> () { let mut _0: ();                      // return place in scope 0 at $DIR/issue-73223.rs:1:11: 1:11 <del> let _1: i32;                         // in scope 0 at $DIR/issue-73223.rs:2:9: 2:14 let mut _2: std::option::Option<i32>; // in scope 0 at $DIR/issue-73223.rs:2:23: 2:30 </del> <ins> let mut _1: std::option::Option<i32>; // in scope 0 at $DIR/issue-73223.rs:2:23: 2:30 let _2: i32;                         // in scope 0 at $DIR/issue-73223.rs:3:14: 3:15 </ins> let mut _4: (&i32, &i32);            // in scope 0 at $SRC_DIR/core/src/macros/mod.rs:LL:COL <del> let mut _5: bool;                    // in scope 0 at $SRC_DIR/core/src/macros/mod.rs:LL:COL let mut _6: bool;                    // in scope 0 at $SRC_DIR/core/src/macros/mod.rs:LL:COL let mut _7: i32;                     // in scope 0 at $SRC_DIR/core/src/macros/mod.rs:LL:COL let mut _8: &std::fmt::Arguments;    // in scope 0 at $SRC_DIR/std/src/macros.rs:LL:COL let _9: std::fmt::Arguments;         // in scope 0 at $SRC_DIR/std/src/macros.rs:LL:COL let mut _10: &[std::fmt::ArgumentV1; 2]; // in scope 0 at $SRC_DIR/std/src/macros.rs:LL:COL let _11: [std::fmt::ArgumentV1; 2];  // in scope 0 at $SRC_DIR/std/src/macros.rs:LL:COL let mut _12: (&&i32, &&i32);         // in scope 0 at $SRC_DIR/std/src/macros.rs:LL:COL let _13: &i32;                       // in scope 0 at $SRC_DIR/core/src/macros/mod.rs:LL:COL let mut _14: &&i32;                  // in scope 0 at $SRC_DIR/core/src/macros/mod.rs:LL:COL </del> <ins> let mut _7: bool;                    // in scope 0 at $SRC_DIR/core/src/macros/mod.rs:LL:COL let mut _8: bool;                    // in scope 0 at $SRC_DIR/core/src/macros/mod.rs:LL:COL let mut _9: i32;                     // in scope 0 at $SRC_DIR/core/src/macros/mod.rs:LL:COL let mut _10: &std::fmt::Arguments;   // in scope 0 at $SRC_DIR/std/src/macros.rs:LL:COL let _11: std::fmt::Arguments;        // in scope 0 at $SRC_DIR/std/src/macros.rs:LL:COL let mut _12: &[std::fmt::ArgumentV1; 2]; // in scope 0 at $SRC_DIR/std/src/macros.rs:LL:COL let _13: [std::fmt::ArgumentV1; 2];  // in scope 0 at $SRC_DIR/std/src/macros.rs:LL:COL let mut _14: (&&i32, &&i32);         // in scope 0 at $SRC_DIR/std/src/macros.rs:LL:COL </ins> let _15: &i32;                       // in scope 0 at $SRC_DIR/core/src/macros/mod.rs:LL:COL <del> let mut _16: std::fmt::ArgumentV1;   // in scope 0 at $SRC_DIR/std/src/macros.rs:LL:COL </del> <ins> let mut _16: &&i32;                  // in scope 0 at $SRC_DIR/core/src/macros/mod.rs:LL:COL </ins> let mut _17: std::fmt::ArgumentV1;   // in scope 0 at $SRC_DIR/std/src/macros.rs:LL:COL <ins> let mut _18: std::fmt::ArgumentV1;   // in scope 0 at $SRC_DIR/std/src/macros.rs:LL:COL </ins> scope 1 { <del> debug split => _1;               // in scope 1 at $DIR/issue-73223.rs:2:9: 2:14 </del> <ins> debug split => _2;               // in scope 1 at $DIR/issue-73223.rs:2:9: 2:14 </ins> let _3: std::option::Option<i32>; // in scope 1 at $DIR/issue-73223.rs:7:9: 7:14 scope 3 { debug _prev => _3;           // in scope 3 at $DIR/issue-73223.rs:7:9: 7:14 <ins> let _5: &i32;                // in scope 3 at $SRC_DIR/core/src/macros/mod.rs:LL:COL let _6: &i32;                // in scope 3 at $SRC_DIR/core/src/macros/mod.rs:LL:COL </ins> scope 4 { <del> debug left_val => _13;   // in scope 4 at $SRC_DIR/core/src/macros/mod.rs:LL:COL debug right_val => _15;  // in scope 4 at $SRC_DIR/core/src/macros/mod.rs:LL:COL </del> <ins> debug left_val => _5;    // in scope 4 at $SRC_DIR/core/src/macros/mod.rs:LL:COL debug right_val => _6;   // in scope 4 at $SRC_DIR/core/src/macros/mod.rs:LL:COL </ins> scope 5 { <del> debug arg0 => _20;   // in scope 5 at $SRC_DIR/core/src/macros/mod.rs:LL:COL debug arg1 => _23;   // in scope 5 at $SRC_DIR/core/src/macros/mod.rs:LL:COL </del> <ins> debug arg0 => _21;   // in scope 5 at $SRC_DIR/core/src/macros/mod.rs:LL:COL debug arg1 => _24;   // in scope 5 at $SRC_DIR/core/src/macros/mod.rs:LL:COL </ins> scope 6 { <del> debug x => _20;  // in scope 6 at $SRC_DIR/core/src/fmt/mod.rs:LL:COL debug f => _19;  // in scope 6 at $SRC_DIR/core/src/fmt/mod.rs:LL:COL let mut _18: for<'r, 's, 't0> fn(&'r core::fmt::Opaque, &'s mut std::fmt::Formatter<'t0>) -> std::result::Result<(), std::fmt::Error>; // in scope 6 at $SRC_DIR/std/src/macros.rs:LL:COL let mut _19: for<'r, 's, 't0> fn(&'r &i32, &'s mut std::fmt::Formatter<'t0>) -> std::result::Result<(), std::fmt::Error>; // in scope 6 at $SRC_DIR/std/src/macros.rs:LL:COL let mut _20: &&i32; // in scope 6 at $SRC_DIR/std/src/macros.rs:LL:COL </del> <ins> debug x => _21;  // in scope 6 at $SRC_DIR/core/src/fmt/mod.rs:LL:COL debug f => _20;  // in scope 6 at $SRC_DIR/core/src/fmt/mod.rs:LL:COL let mut _19: for<'r, 's, 't0> fn(&'r core::fmt::Opaque, &'s mut std::fmt::Formatter<'t0>) -> std::result::Result<(), std::fmt::Error>; // in scope 6 at $SRC_DIR/std/src/macros.rs:LL:COL let mut _20: for<'r, 's, 't0> fn(&'r &i32, &'s mut std::fmt::Formatter<'t0>) -> std::result::Result<(), std::fmt::Error>; // in scope 6 at $SRC_DIR/std/src/macros.rs:LL:COL let mut _21: &&i32; // in scope 6 at $SRC_DIR/std/src/macros.rs:LL:COL </ins> } scope 8 { <del> debug x => _23;  // in scope 8 at $SRC_DIR/core/src/fmt/mod.rs:LL:COL debug f => _22;  // in scope 8 at $SRC_DIR/core/src/fmt/mod.rs:LL:COL let mut _21: for<'r, 's, 't0> fn(&'r core::fmt::Opaque, &'s mut std::fmt::Formatter<'t0>) -> std::result::Result<(), std::fmt::Error>; // in scope 8 at $SRC_DIR/std/src/macros.rs:LL:COL let mut _22: for<'r, 's, 't0> fn(&'r &i32, &'s mut std::fmt::Formatter<'t0>) -> std::result::Result<(), std::fmt::Error>; // in scope 8 at $SRC_DIR/std/src/macros.rs:LL:COL let mut _23: &&i32; // in scope 8 at $SRC_DIR/std/src/macros.rs:LL:COL </del> <ins> debug x => _24;  // in scope 8 at $SRC_DIR/core/src/fmt/mod.rs:LL:COL debug f => _23;  // in scope 8 at $SRC_DIR/core/src/fmt/mod.rs:LL:COL let mut _22: for<'r, 's, 't0> fn(&'r core::fmt::Opaque, &'s mut std::fmt::Formatter<'t0>) -> std::result::Result<(), std::fmt::Error>; // in scope 8 at $SRC_DIR/std/src/macros.rs:LL:COL let mut _23: for<'r, 's, 't0> fn(&'r &i32, &'s mut std::fmt::Formatter<'t0>) -> std::result::Result<(), std::fmt::Error>; // in scope 8 at $SRC_DIR/std/src/macros.rs:LL:COL let mut _24: &&i32; // in scope 8 at $SRC_DIR/std/src/macros.rs:LL:COL </ins> } } scope 10 { <del> debug pieces => (_9.0: &[&str]); // in scope 10 at $SRC_DIR/core/src/fmt/mod.rs:LL:COL debug args => _25;   // in scope 10 at $SRC_DIR/core/src/fmt/mod.rs:LL:COL let mut _24: std::option::Option<&[std::fmt::rt::v1::Argument]>; // in scope 10 at $SRC_DIR/std/src/macros.rs:LL:COL let mut _25: &[std::fmt::ArgumentV1]; // in scope 10 at $SRC_DIR/std/src/macros.rs:LL:COL </del> <ins> debug pieces => _25; // in scope 10 at $SRC_DIR/core/src/fmt/mod.rs:LL:COL debug args => _27;   // in scope 10 at $SRC_DIR/core/src/fmt/mod.rs:LL:COL let mut _25: &[&str]; // in scope 10 at $SRC_DIR/std/src/macros.rs:LL:COL let mut _26: std::option::Option<&[std::fmt::rt::v1::Argument]>; // in scope 10 at $SRC_DIR/std/src/macros.rs:LL:COL let mut _27: &[std::fmt::ArgumentV1]; // in scope 10 at $SRC_DIR/std/src/macros.rs:LL:COL </ins> } } } } scope 2 { <del> debug v => _1;                   // in scope 2 at $DIR/issue-73223.rs:3:14: 3:15 </del> <ins> debug v => _2;                   // in scope 2 at $DIR/issue-73223.rs:3:14: 3:15 </ins> } scope 7 { }

This little matrix processing code shows miscompilation if compiled with: But it compiles correctly with: With:
Hmm, on first glance the replacement it performs looks correct: It replaces local () with the return place . Previously the return place was only used in the block by a copy statement, so this transformation should be correct. Maybe this part of the diff causes a problem? We're using our return place as the return destination for the inner call. It's possible that there's an undocumented (and maybe unintended) assumption that the return place is not reused like this, either in other MIR optimizations or in codegen. Haven't looked too deeply yet though.
Ah, there's this bad call in LLVM IR: It passes a reference to as both the return pointer, and the second (immutable) argument.
we have this corresponding MIR, where we already incorrectly pass a reference to as an argument, while also assigning the call result to it: The destination propagation pass already has code that prevents merging a call destination with one of the arguments, but here we pass a reference instead. Curiously, the was produced by merging with , which is not really something the pass should be doing since a reference is taken to , and we avoid touching any local that has its address taken.
The propagation is disabled only if both locals have their address taken. Changing that to be more conservative does fix this issue. Minimized:
Oof, this should have been an , not an
Thanks
Opened with a fix


Question: visibilities: FxHashMap<LocalDefId, ty::Visibility>, has_pub_restricted: bool, used_imports: FxHashSet<NodeId>, <del> maybe_unused_trait_imports: FxHashSet<LocalDefId>, </del> <ins> maybe_unused_trait_imports: FxIndexSet<LocalDefId>, </ins> maybe_unused_extern_crates: Vec<(LocalDefId, Span)>, /// Privacy errors are delayed until the end in order to deduplicate them.

The resolver gathers a list of possibly unused trait imports in . This list is passed to resolver outputs, into the query. This query takes a and returns whether the import is possibly unused. This is used by the post-typeck unused import check in . This query iterates over all the statements in the crate, checks whether they may be unused trait imports, and warns if they are indeed unused. As there are typically very few unused trait imports compared to the number of items in a crate, it would make sense to directly iterate on . Steps: make an both in and , this will ensure a deterministic iteration order; rename query and give it the signature , and adapt the call site; we do not want to access directly, as this would prevent the query system from detecting that the set has not changed; in , inline and replace the loop over by a loop over ; the filter over there can be removed too (or replaced by a debug-assertion): the set may only point to use statements. Extra: investigate why we check for , and the consequences of removing that check; investigate the impact on perf of converting the to a simple when producing from . I am available on Zulip for any question. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
are you still working on this?
Hello yes sorry for the super slow pace. I am still working on it (mostly reading the rustc dev guide so far). Is that alright or is it important to get this done quickly?
no worries, I am a beginner looking for tasks, hence the qn.


Question: && self.can_eq(self.param_env, ty, found).is_ok() { // We only point at the first place where the found type was inferred. <ins> if !segment.ident.span.overlaps(mismatch_span) { </ins> err.span_label( segment.ident.span, with_forced_trimmed_paths!(format!( "here the type of `{ident}` is inferred to be `{ty}`", )), <del> ); </del> <ins> );} </ins> break; } else if !param_args.is_empty() { break;

I tried this code on nightly: I expected to see this happen: compiler does not panic. Instead, this happened: compiler panics and suggests I open a bug report. I initially posted to , but says this is a different issue, despite panicking on the same line in . (Though I'm realizing now that might be the proximal cause but not very related to the root cause.) : <details<summaryPanic message</summary<p</p</detailsThanks all for maintaining Rust, by the way.
Thanks!
searched nightlies: from nightly-2022-12-01 to nightly-2023-01-21 regressed nightly: nightly-2023-01-07 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
It's , i'll fix it unless someone beats me to it since I'm busy this weekend
Hi it's Justin from Commure :wave:. I found a compiler panic you made :grinning:
sorry for causing you trouble


Question: impl<'d,'t,'a,'tcx> ExprUseVisitor<'d,'t,'a,'tcx> { pub fn new(delegate: &'d mut Delegate<'tcx>, typer: &'t infer::InferCtxt<'a, 'tcx>) <del> -> ExprUseVisitor<'d,'t,'a,'tcx> </del> <ins> -> ExprUseVisitor<'d,'t,'a,'tcx> where 'tcx:'a </ins> { ExprUseVisitor { typer: typer,

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


Question: /// let err = into_inner_err.into_error(); /// assert_eq!(err.kind(), ErrorKind::WriteZero); /// ``` <del> #[unstable(feature = "io_into_inner_error_parts", issue = "79704")] </del> <ins> #[stable(feature = "io_into_inner_error_parts", since = "1.55.0")] </ins> pub fn into_error(self) -> Error { self.1 }

<!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilisation. Make sure to include the relevant RFC for the feature if it has one. Otherwise provide a short summary of the feature and link any relevant PRs or issues, and remove any sections that are not relevant to the feature. Remember to add team labels to the tracking issue. For a language team feature, this would e.g., be . Such a feature should also be labeled with e.g., . This label is used to associate issues (e.g., bugs and design questions) to the feature. --This is a tracking issue for and . The feature gate for the issue is . Tracking issues are used to record the overall progress of implementation. They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label. <!-- Include each step required to complete the feature. Typically this is a PR implementing a feature, followed by a PR that stabilises the feature. However for larger features an implementation could be broken up into multiple PRs. --- [x] Implement these methods - see [x] Adjust documentation [x] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide]) [stabilization-guide]: https://rustc-dev- [doc-guide]: https://rustc-dev- <!-- Include any open questions that need to be answered before the feature can be stabilised. --These new methods are being introduced as an unstable feature to give time to validate their names, types, and documentation, before stabilisation. Implementation (with docs) is in , currently in review/rework.
fcp merge Check out recap of this API in
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [ ] [x] [ ] [x] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!


Question: /// let err = into_inner_err.into_error(); /// assert_eq!(err.kind(), ErrorKind::WriteZero); /// ``` <del> #[unstable(feature = "io_into_inner_error_parts", issue = "79704")] </del> <ins> #[stable(feature = "io_into_inner_error_parts", since = "1.55.0")] </ins> pub fn into_error(self) -> Error { self.1 }

See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.


Question: } } <del> impl FromInternal<( TreeAndJoint, Option<&'_ tokenstream::TokenTree>, &'_ ParseSess, &'_ mut Vec<Self>, )> for TokenTree<Group, Punct, Ident, Literal> </del> <ins> impl FromInternal<(TreeAndJoint, &'_ ParseSess, &'_ mut Vec<Self>)> for TokenTree<Group, Punct, Ident, Literal> </ins> { fn from_internal( <del> ((tree, is_joint), look_ahead, sess, stack): ( TreeAndJoint, Option<&tokenstream::TokenTree>, &ParseSess, &mut Vec<Self>, ), </del> <ins> ((tree, is_joint), sess, stack): (TreeAndJoint, &ParseSess, &mut Vec<Self>), </ins> ) -> Self { use rustc_ast::token::*; <del> let joint = is_joint == Joint && matches!(look_ahead, Some(tokenstream::TokenTree::Token(t)) if t.is_op()); </del> <ins> let joint = is_joint == Joint; </ins> let Token { kind, span } = match tree { tokenstream::TokenTree::Delimited(span, delim, tts) => { let delimiter = Delimiter::from_internal(delim);

Between nightly-2020-09-05 and nightly-2020-09-06, libproc_macro stopped preserving the jointness of a trailing joint punctuation token in a TokenStream (likely ; This breaks some real-world code such as the following, though only with old versions of some libraries as far as I have found. I don't know which behavior above is correct but I would like it to be intentionally decided so that we know what behavior to implement in proc-macro2. fails to compile since nightly-2020-09-06:
This has also broken 's webrender-wrench, which relied on this behavior in one of the dependencies. -- do you think a revert makes sense perhaps? Is there a patch expected soon-ish?
Marking this as P-critical based on the


Question: // Note that we could skip one of the .. but this ensures we at least loosely find the right // directory. let out_dir = PathBuf::from(env::var("OUT_DIR").unwrap()); <del> let dest = out_dir.join("error_codes.rs"); </del> let error_codes_path = "../../../compiler/rustc_error_codes/src/error_codes.rs";

Steps: Checkout commit Have in . In particular, this implies Run Output (on the second run):
cc
For what it’s worth is just what I happened to get after running today. I mentioned it in case something changes later, it’s a coincidence that that commit happens to be related to downloading LLVM from Rust CI.
I think this is a duplicate of
That issue is closed, and its final comment points to this issue.
I just hit this on the following sequence. Do a fresh clone of Run Select option (b) "compiler: Contribute to the compiler itself" Run The build finished like so:
IMO the proper fix for this is to remove error-index's dependency on rustdoc, either by moving the relevant code out into a library that doesn't use rustc_private, or by duplicating the code altogether. There are other ways to solve this but they'll be more complicated and take longer to compile for no real benefit.
by making it invoke rustdoc-the-binary (through ), rather than using rustdoc-the-library.
you should be able to work around this by adding --stage 2 I think.
Thanks, that worked
I think you're right that the binary will be easier - parsing the markdown requires parsing doctests so that it can generate the "Run" button, and parsing doctests requires all of .


Question: // the address of the symbol to ensure it sticks around. #[link_section = ".CRT$XLB"] <del> #[linkage = "external"] </del> #[allow(dead_code, unused_variables)] <ins> #[used] // we don't want LLVM eliminating this symbol for any reason, and // when the symbol makes it to the linker the linker will take over </ins> pub static p_thread_callback: unsafe extern "system" fn(c::LPVOID, c::DWORD, c::LPVOID) = on_tls_callback;

nightly-2017-10-24 contains a libtest with bad DWARF: I can reproduce this if I recompile libtest locally: The problem can be fixed by disabling thinlto (and keeping the codegen units is ok). I noticed this with nightly-2017-10-24 because it is the first nightly compiled with thinlto, but the problem also occurs if I compile libtest with thinlto enabled using earlier compilers (eg nightly-2017-10-17). Inspecting the DWARF, a DIE at that local ref offset does exist in another codegen unit, so the problem seems to be that we should be using a global ref instead.
cc'ing since he's been poking around in LLVM's DWARF generation code recently.
Sorta smells like an LLVM bug -- but hard to say. Who should investigate?
triage: P-medium if you are able to investigate as part of ThinLTO work would be great.
It's likely that this is the cause of , which even if the underlying segfault were fixed would likely prevent backtraces from happening on OSX.
This is unfortunately not "automagically fixed" if we upgrade to LLVM 5
Making progress. First up, minimized Rust source code via creduce to get: Next up let's see if we can reduce it to one object file: Ok looks like only one object file is invalid! Let's take a look the LLVM IR: Ok let's see what's happening by minimizing the LLVM IR: yielding which I . I checked out LLVM trunk, , and looks like the error is still on LLVM trunk.
I'm not sure at this point if this is an LLVM bug, a rustc bug, or a ThinLTO bug. I've managed to extract what I believe is a for this which reproduces the error. I'm hoping fixing that IR will fix all other related issues to this at this point in time. For those of you more familiar with debug information (probably everyone other than me!) mind taking a look at that IR? Does it look "obviously wrong"? If it's "obviously wrong" I can try to work backwards to figure out what piece of the pipeline introduced such a wrong piece, but if it looks correct I can open an LLVM bug saying that we think it may be broken (and maybe they'll say it's "obviously wrong"!)


Question: // the address of the symbol to ensure it sticks around. #[link_section = ".CRT$XLB"] <del> #[linkage = "external"] </del> #[allow(dead_code, unused_variables)] <ins> #[used] // we don't want LLVM eliminating this symbol for any reason, and // when the symbol makes it to the linker the linker will take over </ins> pub static p_thread_callback: unsafe extern "system" fn(c::LPVOID, c::DWORD, c::LPVOID) = on_tls_callback;

cc
Er, I went ahead and to go ahead and broaden the search.
The DWARF is definitely badly formed: it's using a unit-relative offset to reference the parameter type, when it should be using a section-relative offset because the type is in a different unit. The bad offset is occurring for a parameter to subprogram in . The problem is that subprograms and share the same , but have different units ( and ). Based on some print debugging, it appears that LLVM doesn't handle this case. So and are constructed in unit , but when is constructed, it reuses the existing DIE as its parent, and so it also ends up in unit . So my guess is that when the parameter is constructed, it uses the unit that was specified to determine if the parameter and type are in the same unit, and thus gets it wrong.
thanks for the info! I know basically nothing about DWARF though and malformed whatnots, so the IR here is heavily edited by both machines (creduce/bugpoint) and me (to make it more readable). My assumption is that if LLVM accepts IR and generates an object file it shouldn't yield such a dwarfdump error, but are you thinking that given possibly valid LLVM IR the dwarfdump error is possible? If so that may make reduction far more difficult... Or do you think that this looks like upstream LLVM needs to get updated?
I don't think the editing of the IR caused the problem. I'll check later, but I think it's quite likely that the same problem occurs for the unedited IR. I don't know if the LLVM developers intend for this to be valid IR, or if they are missing a validation check somewhere. I think they may have never encountered this possibility. clang divides code into units based on files, so I don't think it ever splits code in the same scope across multiple units, whereas I think rust splits code into units quite differently. That's a bit of conjecture on my part though, it might be better to ask someone who knows more (I only know about DWARF, not LLVM or rustc). Reading the LLVM code a bit more, I think it will be possible to fix there by stopping it from sharing the scope (the scope creation is initiated and the sharing check is ). It's also worth reconsidering how rust splits code into units though.


Question: // the address of the symbol to ensure it sticks around. #[link_section = ".CRT$XLB"] <del> #[linkage = "external"] </del> #[allow(dead_code, unused_variables)] <ins> #[used] // we don't want LLVM eliminating this symbol for any reason, and // when the symbol makes it to the linker the linker will take over </ins> pub static p_thread_callback: unsafe extern "system" fn(c::LPVOID, c::DWORD, c::LPVOID) = on_tls_callback;

It might make sense to ensure all code for a given type is kept in the same unit.
Ah ok that all makes sense. Note though that rustc is very much like clang when it comes to debuginfo/codegen units. The major difference here is that LLVM is doing inlining across codegen units via ThinLTO, and that's likely where these new situations are arising from.
I see, yep my understanding of how rust partitions units was wrong. So when using ThinLTO, the additional units by ThinLTO only contain information needed for the additional inlined functions? Do these inlined functions always share scopes/types with unit , or can we determine when they do? If so, it'd be nice to add them to unit instead of creating additonal units. I think this would get us DWARF that looks the same as that generated for . eg dwarfdump is happy if I run:
interesting! I'd have to look into the internals of ThinLTO to know for sure though. It seems like LLVM isn't ready (maybe?) for multiple codegen units in debug info in one LLVM module (a codegen unit), but it makes sense to me what you're thinking about having all inlined debug info share the same codegen unit information. Now where that change would go in LLVM I'm not entirely sure...
Does firefox use fat LTO? There's been a couple of bugs that have some similarities to this ( and maybe ). Also note that absence of dwarfdump errors doesn't mean the offsets are all okay. dwarfdump is only complaining if the offset is larger than the unit length, but even if it's less it may still incorrectly be a local ref. So there may be more instances that are unnoticed.
cc ^
I can reproduce using normal LTO. Library crate is: Binary crate is: Also here's a thin LTO version that gives smaller IR than the previous Vec test case:
Thanks It definitely sounds like at this point this is an existing bug we've just never hit before. My inclination would be to paper over this if we can. Unfortunately though I don't know how to fix this at the LLVM IR layer. My naive idea would be to just point everything at one codegen unit for each LLVM module (debug-info-wise) but I don't know how to change existing debuginfo of a module.


Question: // the address of the symbol to ensure it sticks around. #[link_section = ".CRT$XLB"] <del> #[linkage = "external"] </del> #[allow(dead_code, unused_variables)] <ins> #[used] // we don't want LLVM eliminating this symbol for any reason, and // when the symbol makes it to the linker the linker will take over </ins> pub static p_thread_callback: unsafe extern "system" fn(c::LPVOID, c::DWORD, c::LPVOID) = on_tls_callback;

I'm not able to access currently, so not sure exactly what Adrian's suggestions were, but here's a that fixes LLVM to use a global ref when needed. It's not as simple as comparing parent DIEs, because the variable is initially , so the check . I don't have a lot of confidence in the patch, but maybe it's a useful starting point for someone who knows more about LLVM.
awesome thanks! I think LLVM's bugzilla is back now so indicating such.
I've confirmed that applying your patch to LLVM fixes having malformed debug information. Next up I'm confirming that it
Sure enough it fixes the issue! would you be interested in sending the patch upstream?
I prefer if someone who knows more about LLVM could upstream the patch.
Would this be something you could do, You can evaluate the changes to the generated DWARF best, I think.
We do use for Firefox builds, yes.
Sure, I will do this. I think the issue is more an LLVM thing than a DWARF thing, though; not certain I know enough there to say whether the patch is good, but I will at least do the shepherding. Also I wanted to point out that knows quite a bit about DWARF; he's one of the principals on
Actually maybe there's nothing to do here except merge this into rust-llvm?
Yes, I think so. I'll do that.
Cool, thanks!
oh no worries! I've tested it locally now and will submit a PR soon (with another change or two)
Ok, thanks
I've opened up which I think should close this out (and also re-enables ThinLTO in a few locations)
Hi, I get a Dwarf Error with GDB 8.0.1 on one of the files of Rust 1.23.0 that was built was Rust 1.23.0 on Fedora 27, in a build enabled with debuginfo. Is it related to this issue or should I open a new one? Relevant build flags:
yeah I believe that's this issue, it should be fixed in 1.24 though!


Question: retry aws s3 cp --no-progress --recursive --acl public-read ./$upload_dir s3://$DEPLOY_BUCKET/$deploy_dir/$BUILD_SOURCEVERSION env: AWS_SECRET_ACCESS_KEY: $(AWS_SECRET_ACCESS_KEY) <del> condition: and(succeeded(), or(eq(variables.DEPLOY, '1'), eq(variables.DEPLOY_ALT, '1'))) </del> <ins> condition: and(succeeded(), not(variables.SKIP_JOB), or(eq(variables.DEPLOY, '1'), eq(variables.DEPLOY_ALT, '1'))) </ins> displayName: Upload artifacts # Upload CPU usage statistics that we've been gathering this whole time. Always

This issue is meant to track where on Travis we currently whenever the commit message looks like it updates a submodule. We should enable something similar for Azure Pipelines where whenever a PR is detected as updating a submodule (either via actually looking at the git history or at the git commit message) then we schedule the builder on the PR. The purpose of this PR build is to help weed out errors even sooner than before where we're just running a smoke tests on Linux on each PR.


Question: extern_return_twou64s(); foreign_fn_with_byval(); issue_28676(); <ins> issue_62350(); </ins> struct_return(); }

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


Question: extern_return_twou64s(); foreign_fn_with_byval(); issue_28676(); <ins> issue_62350(); </ins> struct_return(); }

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


Question: -include ../../run-make-fulldeps/tools.mk <del> all: $(TMPDIR)/$(call BIN,directly_linked) $(TMPDIR)/$(call BIN,indirectly_linked) $(TMPDIR)/$(call BIN,indirectly_linked_via_attr) </del> <ins> all: $(TMPDIR)/$(call BIN,directly_linked)  $(TMPDIR)/$(call BIN,directly_linked_test_plus_whole_archive)  $(TMPDIR)/$(call BIN,directly_linked_test_minus_whole_archive)  $(TMPDIR)/$(call BIN,indirectly_linked)  $(TMPDIR)/$(call BIN,indirectly_linked_via_attr) </ins> $(call RUN,directly_linked) | $(CGREP) 'static-initializer.directly_linked.' <ins> $(call RUN,directly_linked_test_plus_whole_archive) --nocapture | $(CGREP) 'static-initializer.' $(call RUN,directly_linked_test_minus_whole_archive) --nocapture | $(CGREP) -v 'static-initializer.' </ins> $(call RUN,indirectly_linked) | $(CGREP) 'static-initializer.indirectly_linked.' $(call RUN,indirectly_linked_via_attr) | $(CGREP) 'static-initializer.native_lib_in_src.'

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


Question: Scope::Binder { where_bound_origin: Some(hir::PredicateOrigin::ImplTrait), .. } => { <del> let mut err = self.tcx.sess.struct_span_err( lifetime_ref.ident.span, "`impl Trait` can only mention lifetimes bound at the fn or impl level", ); err.span_note(self.tcx.def_span(region_def_id), "lifetime declared here"); err.emit(); </del> <ins> self.tcx.sess.emit_err(errors::LateBoundInApit::Lifetime { span: lifetime_ref.ident.span, param_span: self.tcx.def_span(region_def_id), }); </ins> return; } Scope::Root { .. } => break,

<!-- 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: use libc::types::os::arch::c95::{c_int, size_t}; pub static SIGTRAP : c_int = 5; <ins> pub static SIGPIPE: c_int = 13; pub static SIG_IGN: size_t = 1; </ins> pub static GLOB_APPEND   : c_int = 0x0001; pub static GLOB_DOOFFS   : c_int = 0x0002;

Scripts to reproduce Steps to reproduce: Output:  Backtrace: None Exit code: 141 Version:
What are you expecting to happen? When you send a TERM signal to a process without a registered handler, it terminates promptly. The runtime currently doesn't register any TERM/INT handlers, that's up to you.
I was expecting the runtime to return some upon requesting an action from a defunct process. I also tried polling the state of the defunct process using (as mentioned in the ), but this returned as well. Even if the runtime dosn't "catch" the SIG{TERM,INT}, is it not possible at all to or return in any of the two cases mentioned above?
Oh whoops, sorry! I had my understanding backwards, and apparently this isn't a bug on OSX which caused more confusion for me. Anyway, closing as a dupe of , it's the same cause.
Oh wow, I've done it again. I'm sorry, again! I apologize for not investigating more thoroughly. This is indeed separate from


Question: eprint('ERROR: vendoring required, but vendor directory does not exist.') eprint('       Run `cargo vendor {}` to initialize the ' 'vendor directory.'.format(sync_dirs)) <del> eprint('Alternatively, use the pre-vendored `rustc-src` dist component.') </del> <ins> eprint('       Alternatively, use the pre-vendored `rustc-src` dist component.') eprint('       To get a stable/beta/nightly version, download it from: ') eprint('       ' 'https://forge.rust-lang.org/infra/other-installation-methods.html#source-code') eprint('       To get a specific commit version, download it using the below URL,') eprint('       replacing <commit> with a specific commit checksum: ') eprint('       ' 'https://ci-artifacts.rust-lang.org/rustc-builds/<commit>/rustc-nightly-src.tar.xz') eprint('       Once you have the source downloaded, place the vendor directory') eprint('       from the archive in the root of the rust project.') </ins> raise Exception("{} not found".format(vendor_dir)) if not os.path.exists(cargo_dir):

While logged in as on Linux:: the Rust repo The suggestion to run isn't helpful if you don't already have a Rust toolchain installed. That leaves: "Alternatively, use the pre-vendored dist component." It's completely unclear to me what this means or how to do it. Perhaps providing a link to documentation would be useful. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Oh this is very funny, is what rustup calls it, which is of course completely unhelpful in this scenario where you don't have rustup and are building from source. Mentoring instructions: should link to
Hmm, I guess for this particular scenario you might be building from a commit other than latest master as well. We do technically package it for individual commits: but AFAIK that isn't documented anywhere. Maybe we should add it to forge?
claim
hello, i'm taking the liberty of claiming this pull request, but I'd like some information. Should I propose a solution (like the curl command with the right url?) or just propose the documentation page?
claim
claim


Question: <ins> // https://github.com/rust-lang/rust/issues/100252 #![feature(no_core)] #![no_core] mod bar { // @set baz = import_from_private.json "$.index[*][?(@.kind=='struct')].id" pub struct Baz; // @set impl = - "$.index[*][?(@.kind=='impl')].id" impl Baz { // @set doit = - "$.index[*][?(@.kind=='method')].id" pub fn doit() {} } } // @set import = - "$.index[*][?(@.kind=='import')].id" pub use bar::Baz; // FIXME(adotinthevoid): Use hasexact once #99474 lands // @has - "$.index[*][?(@.kind=='module')].inner.items[*]" $import // @is  - "$.index[*][?(@.kind=='import')].inner.id" $baz // @has - "$.index[*][?(@.kind=='struct')].inner.impls[*]" $impl // @has - "$.index[*][?(@.kind=='impl')].inner.items[*]" $doit </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. --Given a public type, I expected all traits implemented by that type to be part of rustdoc JSON output. However, rustdoc JSON output sometimes does not include information about all the traits implemented by a type unless is specified. For example, in this : The following invocation on v3.1.18 generates JSON stating that is implemented for : However, the following invocation has no mention of for at all: Related to: :
cc
modify labels: +E-needs-mcve
Interestingly, rustdoc-json is providing no impls at all: norunn# use clap::{Command, Arg};nlet matches = Command::new("MyApp")n .arg(Arg::new("out")n .long("output")n .required(true)n .takesvalue(true))n .arg(Arg::new("debug")n .short('d')n .multipleoccurrences(true))n .arg(Arg::new("cfg")n .short('c')n .takesvalue(true))n .getmatches(); // builds the instance of ArgMatchesnn// to get information about the "cfg" argument we created, such as the value supplied we usen// various ArgMatches methods, such as ArgMatches::valueofnif let Some(c) = matches.valueof("cfg") {n println!("Value for -c: {}", c);n}nn// The ArgMatches::valueof method returns an Option because the user may not have suppliedn// that argument at runtime. But if we specified that the argument was "required" as we didn// with the "out" argument, we can safely unwrap because verifies that was actuallyn// used at runtime.nprintln!("Value for --output: {}", matches.valueof("out").unwrap());nn// You can check the presence of an argumentnif matches.ispresent("out") {n // Another way to check if an argument was present, or if it occurred multiple times is ton // use occurrencesof() which returns 0 if an argument isn't found at runtime, or then // number of times that it occurred, if it was.


Question: <ins> // https://github.com/rust-lang/rust/issues/100252 #![feature(no_core)] #![no_core] mod bar { // @set baz = import_from_private.json "$.index[*][?(@.kind=='struct')].id" pub struct Baz; // @set impl = - "$.index[*][?(@.kind=='impl')].id" impl Baz { // @set doit = - "$.index[*][?(@.kind=='method')].id" pub fn doit() {} } } // @set import = - "$.index[*][?(@.kind=='import')].id" pub use bar::Baz; // FIXME(adotinthevoid): Use hasexact once #99474 lands // @has - "$.index[*][?(@.kind=='module')].inner.items[*]" $import // @is  - "$.index[*][?(@.kind=='import')].inner.id" $baz // @has - "$.index[*][?(@.kind=='struct')].inner.impls[*]" $impl // @has - "$.index[*][?(@.kind=='impl')].inner.items[*]" $doit </ins>

To allow an argument to appear more thann // once, you must use the .multipleoccurrences(true) method, otherwise it will only return 1 or 0.n if matches.occurrences_of("debug") 2 {n println!("Debug mode is REALLY on, don't be crazy");n } else {n println!("Debug mode kind of on");n }n}n
Missing impls is probably a recent regression, see
MCVE produces () and with () modify labels: -E-needs-mcve
This is almost certanly due to searched nightlies: from nightly-2022-07-01 to nightly-2022-08-08 regressed nightly: nightly-2022-07-17 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
More minimal (no_core) Is correct in html ! and wrong in json


Question: <ins> // https://github.com/rust-lang/rust/issues/100252 #![feature(no_core)] #![no_core] mod bar { // @set baz = import_from_private.json "$.index[*][?(@.kind=='struct')].id" pub struct Baz; // @set impl = - "$.index[*][?(@.kind=='impl')].id" impl Baz { // @set doit = - "$.index[*][?(@.kind=='method')].id" pub fn doit() {} } } // @set import = - "$.index[*][?(@.kind=='import')].id" pub use bar::Baz; // FIXME(adotinthevoid): Use hasexact once #99474 lands // @has - "$.index[*][?(@.kind=='module')].inner.items[*]" $import // @is  - "$.index[*][?(@.kind=='import')].inner.id" $baz // @has - "$.index[*][?(@.kind=='struct')].inner.impls[*]" $impl // @has - "$.index[*][?(@.kind=='impl')].inner.items[*]" $doit </ins>

running produces this record for the type : I would expect "impls" to not be blank, since the matrix implements many traits and has a non-trait implementation as well. The paths entry also does not contain as well as many other types exported by the crate, is this expected ? I know that these paths included all exported types before : :
Now running with produces: So i think there's been a regression since then
Thank you for reporting labels +A-rustdoc-json +T-rustdoc
Seems like this could be another symptom of the regression reported as
This is the same issue as Items in a non-public module (ie accessed only via imports) have no impls


Question: fn bar() -> Self::Output; } <ins> // @has foo/trait.Safe.html // @!has - '//div[@class="sidebar-elems"]//h3/a[@href="#object-safety"]' '' pub trait Safe { fn access(&self); } </ins> // @has foo/struct.Bar.html // @has - '//div[@class="sidebar-elems"]//h3/a[@href="#fields"]' 'Fields' // @has - '//*[@class="sidebar-elems"]//section//a[@href="#structfield.f"]' 'f'

So that it is easy for user to recognize object-safe traits. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
for the rustdoc side, just query the doc context with a given traitdef_id.
claim
Can you tell what are the relevant parts of rustdoc that needs to be changed?
sorry for late rely :) Add a field to , its value can be queried with like . Then you can append the object-safety info into the render part here I know little about the render code, could you leave some notes about that?
No, please do not add more fields to Trait. Query at the place it is used. I don't know much about render, may have suggestions.
I'm actually not sure what they want the end result to look like, so I don't know where to tell them to update the code. ;)
maybe it could be a cube icon to the right of the new button? On hover, there would be a tooltip saying or . I'm not sure where you get icons for rustdoc, but have a cube and cube-transparent icon that could be used for object-safe, and object-unsafe traits respectively. The could be reduced to fit in with the rest of the icons in rustdoc. If doesn't want to work on it I'd be happy to give it a go.
Following up from the PR with some UI discussion. I'd prefer not to add more icons up at the top of the page; we're already a bit crowded with icons. And there's no icon that has a broadly understood meaning of "object safe". I like the approach in , to write out "This trait is object-safe." But that PR puts it all the way at the top of the page, which is very high priority - and I would say object safety is more medium priority, so it should be lower on the page. One possibility would be to make an subheading in the top-doc docblock, but that results in using a lot of space for this. Our h2's are big! What about this: Under "Implementors", we could have at the very top "This trait is object safe. References to types that implement this trait can be automatically coerced to ".


Question: fn bar() -> Self::Output; } <ins> // @has foo/trait.Safe.html // @!has - '//div[@class="sidebar-elems"]//h3/a[@href="#object-safety"]' '' pub trait Safe { fn access(&self); } </ins> // @has foo/struct.Bar.html // @has - '//div[@class="sidebar-elems"]//h3/a[@href="#fields"]' 'Fields' // @has - '//*[@class="sidebar-elems"]//section//a[@href="#structfield.f"]' 'f'

My reasoning here is that conceptually, is somewhat like an implementor of the trait.
I don't think this is necessarily true, you can have a that doesn't implement . But putting the text under "implementors" seems as good a place as any
Just out of curiosity, how can I have a that doesn’t implement ?
I don't think that's actually true, I misremembered.
We have one on: Would anyone else like to weigh in? Good enough to proceed with implementation?
Any update on this? :)
I'm not sure if it's already been suggested, but what about only showing a note if the trait is not object-safe?
I like suggestion to only show when a trait is not object safe, since that's the more unusual condition. If we do that, it doesn't fit logically under "Implementors" anymore. If we proceed with only marking non-object-safe traits, here are a couple of ideas: Add a section after the top-doc, but before "Implementors", called "Object Safety", and put the text there. Add information to the documentation of any method that causes the trait to be not object-safe.
I think it’s still fine to mention under “Implementors” like “This trait is not object safe: doesn’t implement ”, but I also like the idea of the new section. I see this issue doesn’t have an assignee currently, can I claim this?
You can but since we didn't reach a consensus, any PR would hang around until we reach one.


Question: [[package]] name = "jsonrpc-core" <del> version = "13.1.0" </del> <ins> version = "13.2.0" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "dd42951eb35079520ee29b7efbac654d85821b397ef88c8151600ef7e2d00217" </del> <ins> checksum = "91d767c183a7e58618a609499d359ce3820700b3ebb4823a18c343b4a2a41a0d" </ins> dependencies = [ "futures", "log",

Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool rls no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.


Question: [63421]: https://github.com/rust-lang/rust/pull/63421/ [cargo/7084]: https://github.com/rust-lang/cargo/pull/7084/ [cargo/7143]: https://github.com/rust-lang/cargo/pull/7143/ <ins> [63048]: https://github.com/rust-lang/rust/pull/63048 </ins> [`<*const T>::cast`]: https://doc.rust-lang.org/std/primitive.pointer.html#method.cast [`<*mut T>::cast`]: https://doc.rust-lang.org/std/primitive.pointer.html#method.cast [`Duration::as_secs_f32`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.as_secs_f32

At some point between Rust 1.34.0 and 1.39.0, the ability to add documentation to reexported items was , but I can't find it mentioned in either or the rust- blog posts. Maybe this should be mentioned in the RELEASE notes for the version that that feature? I have a crate that I use to test stuff, and used to document this: !
This was changed in 1.38 (coincidentally also the release rust-std spiked from a 61.2 MB to 173.3 MB download). are you interested in making a PR?
Sure, what are the PRs that made this possible?
Oh I have no idea :laughing: I found it by bisecting.
Looks like is it


Question: <ins> #[derive(PartialEq, Eq)] pub struct Tag(pub Context, pub u16); #[derive(PartialEq, Eq)] pub enum Context { Tiff, Exif, } impl Tag { const ExifIFDPointer: Tag = Tag(Context::Tiff, 34665); } fn main() { match Tag::ExifIFDPointer { //~^ ERROR: non-exhaustive patterns: `Tag(Exif, _)` not covered Tag::ExifIFDPointer => {} } } </ins>

I hope this is not already known, but my searching has not turned up anything. Compiling a rust binary with the dependency panices in nightly. How to reproduce: a new rust binary. to dependencies in This gives the following output It compiles on stable and beta. Edit: Just running in gives the same result.
Tried a few different nightlies. And it looks like it broke sometime between and
I have managed to get a much smaller example. Compiling this on nightly gives the above panic:
Looks like it's fixed in the newest nightly ()
Bisecting between ... gives as the regression PR.


Question: expanded_cache: FxHashMap<(DefId, SubstsRef<'tcx>), Ty<'tcx>>, primary_def_id: Option<DefId>, found_recursion: bool, <ins> found_any_recursion: bool, </ins> /// Whether or not to check for recursive opaque types. /// This is `true` when we're explicitly checking for opaque type /// recursion, and 'false' otherwise to avoid unnecessary work.

I tried this code: I expected running to produce an error like: It does, but takes time exponential in the number of calls, although doesn't appear to use any extra memory. In the time take looks like: I believe it's also exponential in the number of calls in . The reason I had code like this was because I was using nom's parser combinators which results in lots of nested closures. I spotted it because this caused rust-analyzer to hang because cargo clippy hung (it looks like check was the issue), I had to kill clippy to fix it. I bisected this (with cargo-bisect-rustc) to find the regression in , which contained the following bors commits: merge of - Centril:rollup-rzvry15, r=Centril merge of - tmandry:rollup-0k6jiik, r=tmandry merge of - Manishearth:clippyup, r=Manishearth merge of - tanriol:explain_borrow-use-context-dominators, r=nagisa merge of - ehuss:update-cargo-books, r=alexcrichton modify labels: +regression-from-stable-to-stable -regression-untriaged
what version of rust are you using? Is this also present on nightly?
Good question! This repros on the latest nightly () and on stable (1.53.0 2021-06-17).
Regression means that it was linear, or exponential, but smaller?
I didn't looks to still be exponential just much quicker, and with a smaller base (~2 vs ~14):
looks related
Bisected to innocent-looking commit . Removing the caching from in master does indeed fix the issue. I haven't looked at the how or why or where that causes (other) problems though. cc
Hmm, the only thing that looks expensive there is the hashing - I wonder if it's hashing over and over again without ever getting a cache hit? Hashing has a fixed cost, but can be an arbitrary length:
cuts down on time for this testcase and others with invalid recursive opaque types by bailing out early if a recursion is found.


Question: expanded_cache: FxHashMap<(DefId, SubstsRef<'tcx>), Ty<'tcx>>, primary_def_id: Option<DefId>, found_recursion: bool, <ins> found_any_recursion: bool, </ins> /// Whether or not to check for recursive opaque types. /// This is `true` when we're explicitly checking for opaque type /// recursion, and 'false' otherwise to avoid unnecessary work.

This fixes the regression but the check time is still exponential in the recursion: #wraps|time (s) ---|--- 23|9.2 24|18.3 25|36.6 Not sure if that matters in practice though.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
That's the same as before the regression, right? I definitely think that's a change worth making :) I expect the doubling will have a completely different cause.
Yes, same ballpark.


Question: let _ = make_vec![a 1, a 2, a 3]; } // --- Minified Issue --- // macro_rules! m { <del> ( $()* ) => {} </del> <ins> ( $()* ) => {}; </ins> //~^ ERROR repetition matches empty token tree }

The following code will cause the compiler to fail: Playground link: It should error that the inner matcher can match an empty string and reject it, just as it does if is used in place of .
The fix should be very easy, since this was already fixed for repetitions in (original bug: ): Looks like just needs to be checked against , too.
cc
Note that with on the outside, this errors properly, although with inconsistent error messages: if the inner repetition uses only, the error is "repetition matches empty token tree", but it seems that if any of the repetitions are , then the error is "multiple successful parses".
The behaviour in my previous comment is because the check for "repetition matches empty token tree" is done at definition time, but does not catch ; this is caught at expansion time however. Ideally all of this will be moved to definition time and the expansion-time check should probably be a) corrected to address the first comment and b) possibly become an ICE, since it should never be encountered since the RFC 550 rules should eliminate all ambiguity at definition time?
Hmm... I don't really remember how most of this code works... Just grepping, but it looks like there are a couple of other places we might want to look at:
I've opened


Question: fn main() { let mut s = S { f: 0, sub: Sub { f: 0 } }; field_write(&mut s); <ins> auto_deref(); nested_boxes(); } fn auto_deref() { struct E { x: bool, y: bool, //~ ERROR: field is never read } struct P<'a> { e: &'a mut E } impl P<'_> { fn f(&mut self) { self.e.x = true; self.e.y = true; } } let mut e = E { x: false, y: false }; let mut p = P { e: &mut e }; p.f(); assert!(e.x); } fn nested_boxes() { struct A { b: Box<B>, } struct B { c: Box<C>, } struct C { u: u32, //~ ERROR: field is never read v: u32, //~ ERROR: field is never read } let mut a = A { b: Box::new(B { c: Box::new(C { u: 0, v: 0 }), }), }; a.b.c.v = 10; a.b.c = Box::new(C { u: 1, v: 2 }); </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. --Here's a reduced test-case from Firefox source code: Compiling that program warns with: Which is obviously not true. <!-- 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. --:
Seems like this is a regression from .
cc
Oops, sorry! Technically, field is, in fact, never read. What went wrong is is written and read through other ways. I think restricting the lint to non-reference fields should work, and will submit a PR to do so quickly. Please double check whether my thinking is correct.
Ah, yeah, I somehow thought that the macro was needed to trigger the bug but it is not. That sounds good. Writes to mutable references have side effects so doing that seems ok.
Would that also cover this case here, in the idna crate? (The field is a reference to an type, which is in fact returned to the caller of .)
Yeah, I think it's the same.
Ah, this was closed, but the bug leaked into beta (as mentioned in ) while the fix is only in nightly. Reopening and tagging as stable-to-beta regression
Assigning and removing .
As noted on , we're going to resolve the beta issue by reverting PR on beta (which I have assigned myself to take care of).
This was a regression affecting beta 1.51, closing this.


Question: } #[test] <del> #[cfg_attr(any(target_os = "vxworks", target_os = "android"), ignore)] </del> <ins> #[cfg_attr(any(target_os = "vxworks"), ignore)] </ins> fn test_process_status() { let mut status = if cfg!(target_os = "windows") { Command::new("cmd").args(&["/C", "exit 1"]).status().unwrap() } else { <del> Command::new("false").status().unwrap() </del> <ins> shell_cmd().arg("-c").arg("false").status().unwrap() </ins> }; assert!(status.code() == Some(1)); status = if cfg!(target_os = "windows") { Command::new("cmd").args(&["/C", "exit 0"]).status().unwrap() } else { <del> Command::new("true").status().unwrap() </del> <ins> shell_cmd().arg("-c").arg("true").status().unwrap() </ins> }; assert!(status.success()); }

To enable test on android bot and test/run-pass/rtio- It looks to me RtioProcess does not work properly on android.
logs are
Hm this may be an FFI issue with libuv. I realized during my uv rewrite that libuv is giving us an int64t exit status and we think it's a cint. Once lands this may be fixed.
Hmm, this issue number has propagated to several more tests that are cfg-disabled on android. (Some of which are now failing when I mixed in a Boehm/BDW conservative GC into the runtime, in particular .)
Also, has landed, so it would be good to determine if these tests now work on Android.
Triage: I have no idea how to test this, but a lot has changed in a year (especially the removal of green & libuv), so these may be magically fixed; if someone can check.
Triage: is gone, but all these tests in are still ignored for android.
I tried to run these tests with but they all failed with , which seems suspect (at least for the tests that invoke , , , etc.). Is there a better way to test? I have an android device available.


Question: Some(t) if t.hir_owner == parent_id => t, _ => self.tcx.typeck(parent_id), }; <del> let ty = typeck_results.expr_ty_adjusted(expr); let span = expr.peel_blocks().span; </del> <ins> let expr = expr.peel_blocks(); let ty = typeck_results.expr_ty_adjusted_opt(expr).unwrap_or(tcx.ty_error()); let span = expr.span; </ins> if Some(span) != err.span.primary_span() { err.span_label( span, <del> &if ty.references_error() { </del> <ins> if ty.references_error() { </ins> String::new() } else { format!("this tail expression is of type `{:?}`", ty)

I tried this code: searched nightlies: from nightly-2022-08-18 to nightly-2022-09-09 regressed nightly: nightly-2022-08-23 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </details<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --
Regression introduced in:
This block around is crucial to trigger the ICE.
WG-prioritization assigning priority (). label -I-prioritize +P-medium


Question: "create_substs_for_associated_item(span: {:?}, item_def_id: {:?}, item_segment: {:?}", span, item_def_id, item_segment ); <del> self.create_substs_for_ast_path( </del> <ins> let (args, _) = self.create_substs_for_ast_path( </ins> span, item_def_id, parent_substs,

I expect the following code to be rejected by the compiler but it is actually accepted and compiles successfully: The associated constant does not have any generic parameters / associated items (constants cannot have those anyways in the current version of Rust) and thus the argument list should be flagged as erroneous. Interestingly, if you remove the , the compiler correctly identifies this as an error: . I think is to be interpreted as a nested equality constraint (and not as a “defaulted” parameter, i.e. a parameter with a default value). : label T-compiler requires-nightly (it now does) Hence, I am just going to mention its tracking issue: . CC <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Doesn't need assoc const equality: Let me take a quick stab at this. claim
On a related note, a slightly modified version of the code above leads to an ICE (I was about to create a separate issue for this, should I still do that?): <details<summarystderr (diagnostics & backtrace)</summary</detailsThis only leads to an ICE on the current nightly (2022-09-27) (e.g. on the playground) but not on older ones like (2022-09-21).
If you want to bisect it feel free, but I think fixing the original issue in this report will also fix this one.
Yeah, I think so, too. I guess I won't bisect this.
This regressed in the last day
Oh wait, I caused it: searched nightlies: from nightly-2022-08-01 to nightly-2022-09-26 regressed nightly: nightly-2022-09-26 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details


Question: #![feature(macro_reexport)] #![feature(macro_vis_matcher)] #![feature(needs_panic_runtime)] <del> #![feature(needs_drop)] </del> #![feature(never_type)] #![feature(num_bits_bytes)] #![feature(old_wrapping)]

About to submit a PR for exposing intrinsics::needs_drop under mem. Needs a tracking issue. Here it is!
The PR is
fcp merge Seems like this may be good to stabilize!
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.


Question: <ins> error[E0107]: wrong number of const arguments: expected 0, found 1 --> $DIR/invalid-const-arg-for-type-param.rs:6:34 | LL |     let _: u32 = 5i32.try_into::<32>().unwrap(); |                                  ^^ unexpected const argument error[E0599]: no method named `f` found for type `S` in the current scope --> $DIR/invalid-const-arg-for-type-param.rs:7:7 | LL | struct S; | --------- method `f` not found for this ... LL |     S.f::<0>(); |       ^ error[E0107]: wrong number of const arguments: expected 0, found 1 --> $DIR/invalid-const-arg-for-type-param.rs:8:9 | LL |     S::<0>; |         ^ unexpected const argument error: aborting due to 3 previous errors Some errors have detailed explanations: E0107, E0599. For more information about an error, try `rustc --explain E0107`. </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: <ins> pub trait Example { fn query<Q>(self, q: Q); } impl Example for i32 { fn query<Q>(self, _: Q) { unimplemented!() } } mod nested { use super::Example; fn example() { 1.query::<dyn ToString>("") //~^ ERROR the size for values of type `dyn ToString` cannot be known at compilation time //~| ERROR mismatched types } } fn main() {} </ins>

Issues with this diagnostic: method is not being invoked on a trait object; it's invoked on the concrete value . note suggests importing the same trait that is already being reported about.
/cc also looks relevant based on the title, but appears to have a different enough error message.
Is the following output from enough?
I don't feel like it's at the usual amazing quality . My points still appear to exist: In some magical world, I might hope for something like this (and I'm very flexible in that): I tried to address my points via the s.


Question: host: opt_str2(matches.opt_str("host")), gdb_version: extract_gdb_version(matches.opt_str("gdb-version")), lldb_version: extract_lldb_version(matches.opt_str("lldb-version")), <ins> llvm_version: matches.opt_str("llvm-version"), </ins> android_cross_path: opt_path(matches, "android-cross-path"), adb_path: opt_str2(matches.opt_str("adb-path")), adb_test_dir: format!("{}/{}",

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: .as_ref() .cloned() .map(|version| (version, true)) <del> .unwrap_or_default(); // `is_present` defaults to `false` here. </del> <ins> .unwrap_or_default(); </ins> <del> // Miri is nightly-only; never ship it for other trains. </del> <ins> // miri needs to build std with xargo, which doesn't allow stable/beta: // <https://github.com/japaric/xargo/pull/204#issuecomment-374888868> </ins> if pkgname == "miri-preview" && self.rust_release != "nightly" { <del> is_present = false; // Pretend the component is entirely missing. </del> <ins> is_present = false; // ignore it </ins> } let targets = targets.iter().map(|name| { if is_present { <del> // The component generally exists, but it might still be missing for this target. </del> let filename = self.filename(pkgname, name); let digest = match self.digests.remove(&filename) { Some(digest) => digest, <del> // This component does not exist for this target -- skip it. </del> None => return (name.to_string(), Target::unavailable()), }; let xz_filename = filename.replace(".tar.gz", ".tar.xz");

Seems like no nightly was released today. That might be related to Unfortunately I don't think I have access to the logs. Cc
Logs are missing on the server, let me start a manual release...
Well that is odd. You wouldn't know what commit is is using? ( file in the tarball, if I recall correctly.)
Is there a way for me to download the "dist" artifacts for better testing? Right now I am manually grabbing a bunch of files from https://s3-us-west- (and we only get dir listing for alt builds there it seems so I am using those). That's not very convenient at all.
Apparently not all commits are pushed to toolstate ( vs ), for example the latest one () is missing in toolstate .
Reverting the cause in the meantime --
Alternatively we could land which will just skip of the toolstate is not found. That installs a toolchain based on these artifacts, but I don't think it gives me access to the tarballs. FTR, for now I did So we are only committing when the toolstate changed? Ouch. That kills my entire approach :(
It should print the URLs it's downloading though, and you can use to avoid it actually downloading stuff.


Question: /// [arc]: ../../std/sync/struct.Arc.html /// [ub]: ../../reference/behavior-considered-undefined.html #[stable(feature = "rust1", since = "1.0.0")] <del> #[cfg_attr(not(test), rustc_diagnostic_item = "Send")] </del> <ins> #[cfg_attr(all(not(test), bootstrap), rustc_diagnostic_item = "send_trait")] #[cfg_attr(all(not(test), not(bootstrap)), rustc_diagnostic_item = "Send")] </ins> #[rustc_on_unimplemented( message = "`{Self}` cannot be sent between threads safely", label = "`{Self}` cannot be sent between threads safely"

I came across this while working on . Sadly I wasn't really able to minimize this. this branch: and go to (but other commits will likely work too). to and paste in the following:
See also
Slightly minimized: place in Then run: will produce the ICE.
Caused by , cc That PR renames a lot of diagnostic items, but didn't use to gate the name change, so causes breakage when compiling stage 0 std or stage 1 compiler.
Oops, sorry!


Question: <ins> error: lifetime must precede `mut` --> $DIR/issue-73568-lifetime-after-mut.rs:2:13 | LL | fn x<'a>(x: &mut 'a i32){} |             ^^^^^^^ help: place the lifetime before `mut`: `&'a mut` error[E0178]: expected a path on the left-hand side of `+`, not `&mut 'a` --> $DIR/issue-73568-lifetime-after-mut.rs:14:13 | LL | fn y<'a>(y: &mut 'a + Send) { |             ^^^^^^^^^^^^^^ help: try adding parentheses: `&mut ('a + Send)` error: lifetime must precede `mut` --> $DIR/issue-73568-lifetime-after-mut.rs:6:22 | LL |         fn w<$lt>(w: &mut $lt i32) {} |                      ^^^^^^^^ help: place the lifetime before `mut`: `&$lt mut` ... LL | mac!('a); | --------- in this macro invocation | = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info) error[E0423]: expected value, found trait `Send` --> $DIR/issue-73568-lifetime-after-mut.rs:18:28 | LL |     let z = y as &mut 'a + Send; |                            ^^^^ not a value warning: trait objects without an explicit `dyn` are deprecated --> $DIR/issue-73568-lifetime-after-mut.rs:14:18 | LL | fn y<'a>(y: &mut 'a + Send) { |                  ^^ help: use `dyn`: `dyn 'a` | = note: `#[warn(bare_trait_objects)]` on by default warning: trait objects without an explicit `dyn` are deprecated --> $DIR/issue-73568-lifetime-after-mut.rs:18:23 | LL |     let z = y as &mut 'a + Send; |                       ^^ help: use `dyn`: `dyn 'a` error[E0224]: at least one trait is required for an object type --> $DIR/issue-73568-lifetime-after-mut.rs:14:18 | LL | fn y<'a>(y: &mut 'a + Send) { |                  ^^ error: aborting due to 5 previous errors; 2 warnings emitted Some errors have detailed explanations: E0178, E0224, E0423. For more information about an error, try `rustc --explain E0178`. </ins>

Expected result: a diagnostic suggests placing before Actual diagnostic output: <details</details
Output from rustc 1.43 (): The size of the output appears to be a recent regression.
: searched nightlies: from nightly-2020-03-09 to nightly-2020-06-21 regressed nightly: nightly-2020-03-12 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsLooks like ?
Further testing confirms , specifically  introduced the large number of diagnostics.
Assigning .


Question: // u8 literal, push to vector expression ast::LitUint(v, ast::TyU8) => { if v > 0xFF { <del> cx.span_err(expr.span, "too large u8 literal in bytes!") </del> <ins> cx.span_err(expr.span, "too large u8 literal in bytes!"); err = true; </ins> } else { bytes.push(cx.expr_u8(expr.span, v as u8)); }

With landed, the lifetime of is now problematic. Specifically, the following used to work and now fails: The lifetime of is now limited to that branch of the match, so it doesn't live long enough to be assigned to . I'm not sure if this means lifetimes need to change. The other option is that needs to return a . Unfortunately, the only way to do that right now is to make it equivalent to , which makes it no longer usable as the value of a constant (e.g. ). I'm thinking the right solution is to make it legal for me to say . I can type that right now, but the lifetime seems to be wholly ignored, as I get the exact same error with the following as I do with the example above: If becomes a valid expression with the lifetime, then could start evaluating to that and everything should work as expected. Furthermore, it would be nice (but perhaps not required) if , where all elements are compile-time constants, would implicitly be given the lifetime.
/cc
Yeah, this is kind of annoying. I worked around it in one specific case by having bytes! expand as follows: I certainly think one should be allowed to write a concrete lifetime as part of a slice or borrow expression, and ought to be legal -- we'll obviously have to impose more stringent constant-related rules. In the short term, we could adjust to expand in the pattern I showed above. What was unclear to me was whether this is sufficient workaround, or whether we'll want something more general. Interestingly, even if we used full inference, the expression you gave above would be illegal unless we introduce a special case for static byte strings, because it generates a conditional temporary (only on one arm of the match) and we can't handle the cleanup for such a case without zeroing, which we plan to remove (well, I guess we could also have a special case for temporary types [like ) that do not require drop glue, but I'd rather not).
Perhaps the simplest fix for now is to adjust the macro itself to expand to a static item as I showed. I should probably have done that more generally but I was ready to land that expletive branch already.
Won't that prevent from being able to expand to a static?
I already adjusted like that and is correct, it prevents , which is definitely already used in our codebase.
Ah, unfortunate.


Question: // u8 literal, push to vector expression ast::LitUint(v, ast::TyU8) => { if v > 0xFF { <del> cx.span_err(expr.span, "too large u8 literal in bytes!") </del> <ins> cx.span_err(expr.span, "too large u8 literal in bytes!"); err = true; </ins> } else { bytes.push(cx.expr_u8(expr.span, v as u8)); }

(I actually think we should allow statics to include nested blocks with other statics, but I guess that's a separate bug) Well, I'm not sure what's the easiest fix in that case, I guess just to fix the semantics of so that it guarantees static data. I'm not 100% sure what's implied by such a fix: it doesn't seem too hard ;)
cc


Question: <ins> // Test for issues/115517 which is fixed by pull/115486 // This should not ice trait Test<const C: usize> {} trait Elide<T> { fn call(); } pub fn test() where (): Test<{ 1 + (<() as Elide(&())>::call) }>, //~^ ERROR cannot capture late-bound lifetime in constant { } 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. --: <details<summary<strongError output</strong</summary<p</p</details<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Regression in nightly-2022-09-05 commit[0] 2022-09-03: Auto merge of - cjgillot:old-no-lt, r=estebank commit[1] 2022-09-04: Auto merge of - matthiaskrgr:rollup-9n0257m, r=matthiaskrgr commit[2] 2022-09-04: Auto merge of - nikic:update-llvm-7, r=cuviper commit[3] 2022-09-04: Auto merge of - jswrenn:transmute, r=oli-obk commit[4] 2022-09-04: Auto merge of - klensy:bump-deps-08-22, r=Dylan-DPC commit[5] 2022-09-04: Auto merge of - compiler-errors:head-span-for-enclosing-scope, r=oli-obk commit[6] 2022-09-04: Auto merge of - matthiaskrgr:rollup-uj24yb5, r=matthiaskrgr commit[7] 2022-09-04: Auto merge of - asquared31415:vec-zero-opts, r=thomcc
Minimal: This has nothing to do with the transmutability feature. Also, it's fixed by , since the above desugars to:
WG-prioritization assigning priority (). label -I-prioritize +P-medium -needs-triage
This is but needs a test. To whoever does it, please commit the example I minimized and not the other one, since we don't need to make the test depend on the transmutability feature.


Question: mingw-check: IMAGE: mingw-check <del> # TODO: enable this job if the commit message matches this regex, need tools # figure out how to get the current commit message on azure and stick it in a # condition somewhere #     if: commit_message =~ /(?i:^update.*b(rls|rustfmt|clippy|miri|cargo)b)/ # - job: Linux-x86_64-gnu-tools #   pool: #     vmImage: ubuntu-16.04 #   steps: #     - template: steps/run.yml #   variables: #     IMAGE: x86_64-gnu-tools </del> <ins> - job: LinuxTools pool: vmImage: ubuntu-16.04 steps: - template: steps/run.yml parameters: only_on_updated_submodules: 'yes' variables: IMAGE: x86_64-gnu-tools </ins>

This issue is meant to track where on Travis we currently whenever the commit message looks like it updates a submodule. We should enable something similar for Azure Pipelines where whenever a PR is detected as updating a submodule (either via actually looking at the git history or at the git commit message) then we schedule the builder on the PR. The purpose of this PR build is to help weed out errors even sooner than before where we're just running a smoke tests on Linux on each PR.


Question: <ins> warning: public documentation for `private_from_crate_level` links to private item `my_module` --> $DIR/private-from-crate-level.rs:3:6 | LL | //! [my_module] |      ^^^^^^^^^ this item is private | = note: `#[warn(rustdoc::private_intra_doc_links)]` on by default = note: this link will resolve properly if you pass `--document-private-items` warning: 1 warning emitted </ins>

It should say instead.
Relevant code: I think the fix is to use the crate name instead of .
Also, I would be curious to see if you can remove altogether by using : That might break renamed modules maybe? I don't remember how modules interact with re-exports.


Question: use crate::flags::{Color, Flags, Warnings}; use crate::util::{exe, output, t}; use once_cell::sync::OnceCell; <ins> use semver::Version; </ins> use serde::{Deserialize, Deserializer}; use serde_derive::Deserialize;

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


Question: use crate::flags::{Color, Flags, Warnings}; use crate::util::{exe, output, t}; use once_cell::sync::OnceCell; <ins> use semver::Version; </ins> use serde::{Deserialize, Deserializer}; use serde_derive::Deserialize;

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


Question: <ins> // Regression test for <https://github.com/rust-lang/rust/issues/100529>. #![no_core] #![feature(no_core)] // @has "$.index[*][?(@.name=='ParseError')]" // @has "$.index[*][?(@.name=='UnexpectedEndTag')]" // @is "$.index[*][?(@.name=='UnexpectedEndTag')].inner.variant_kind" '"tuple"' // @is "$.index[*][?(@.name=='UnexpectedEndTag')].inner.variant_inner" [null] pub enum ParseError { UnexpectedEndTag(#[doc(hidden)] u32), } </ins>

At some point their should also be a for , and probably a way to tell what position each of the non stripped items are, as currently each of these 3 variants are documented with the same inner. but HTML gets a good representation:  The solution is probably to do what we do for structs, and store the , and a , such that each field of a varient gets an to hold the . We also should have a numfields, as even in that schema, you can't tell the difference between This also effects struct AFAIKT. I don't think this needs to be done now. I'll file an issue for it. Originally posted by in modify labels: +A-rustdoc-json +T-rustdoc
Related:


Question: let f1: f64 = FromStrRadix::from_str_radix("1p-123", 16).unwrap(); let f2: f64 = FromStrRadix::from_str_radix("1p-111", 16).unwrap(); let f3: f64 = FromStrRadix::from_str_radix("1.Cp-12", 16).unwrap(); <del> assert_eq!(Float::ldexp(1f64, -123), f1); assert_eq!(Float::ldexp(1f64, -111), f2); </del> <ins> assert_eq!(1f64.ldexp(-123), f1); assert_eq!(1f64.ldexp(-111), f2); </ins> assert_eq!(Float::ldexp(1.75f64, -12), f3); assert_eq!(Float::ldexp(0f64, -123), 0f64);

has an unusual format: it takes as it's first parameter where everything else in the trait takes . It should take as it's first parameter for consistency with everything else. It is located in
+1. There are a few different things to consider here, though: does not operate on any FP number per se like most other operations do, but rather constructs a new FP number from two arguments one of which happens to be FP number. This function’s signature is consistent with most other methods that construct some kind of FP number (e.g. ). We might want to consider whether methods such as shouldn’t just go ahead and take instead. can’t currently be chained, but I see literally 0 cases where anybody would chain this function. cc
Okay, but from a consistency standpoint, it's like 1/80 for vs . It it keeps the same format, it and it's similar functions would probably be better to go at the end or beginning of the function list where they won't be so unusual.
Nominating for 1.0-beta P-backcompat-libs
One should be able to call this thing as a method, one way or another. We need to make sure that is resolved.
0 beta, P-backcompat-libs
I started to fix this.


Question:
} if !provided.is_empty() { write!(w, "
Provided Methods

 Provided Methods

 ")?; for m in &provided {

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: } else { "traits define" }, <del> action = if let Some(param) = param_type { format!("restrict type parameter `{}` with", param) } else { "implement".to_string() }, </del> <ins> action = action, </ins> one_of_them = if candidates.len() == 1 { "it" } else {

The following example code yields an error: It's unclear from this error message how to proceed - I'm not sure of the syntax, location, or where I should be putting the "GetString" trait bound. It should be shown with a better example or link when this error is presented, as the current message is not sufficient for a resolution to be arrived at.
cc
Fixing in . To fix your code write:
Thanks!


Question: <ins> // run-pass #![feature(or_patterns)] fn main() { assert!(f("", 0)); assert!(f("a", 1)); assert!(f("b", 1)); assert!(!f("", 1)); assert!(!f("a", 0)); assert!(!f("b", 0)); assert!(!f("asdf", 32)); //// assert!(!g(true, true, true)); assert!(!g(false, true, true)); assert!(!g(true, false, true)); assert!(!g(false, false, true)); assert!(!g(true, true, false)); assert!(g(false, true, false)); assert!(g(true, false, false)); assert!(g(false, false, false)); //// assert!(!h(true, true, true)); assert!(!h(false, true, true)); assert!(!h(true, false, true)); assert!(!h(false, false, true)); assert!(!h(true, true, false)); assert!(h(false, true, false)); assert!(h(true, false, false)); assert!(h(false, false, false)); } fn f(s: &str, num: usize) -> bool { match (s, num) { ("", 0) | ("a" | "b", 1) => true, _ => false, } } fn g(x: bool, y: bool, z: bool) -> bool { match (x, y, x, z) { (true | false, false, true, false) => true, (false, true | false, true | false, false) => true, (true | false, true | false, true | false, true) => false, (true, true | false, true | false, false) => false, } } fn h(x: bool, y: bool, z: bool) -> bool { match (x, (y, (x, (z,)))) { (true | false, (false, (true, (false,)))) => true, (false, (true | false, (true | false, (false,)))) => true, (true | false, (true | false, (true | false, (true,)))) => false, (true, (true | false, (true | false, (false,)))) => false, } } </ins>

When using the feature, attempting to match on a tuple creates a compiler panic. The following code causes the panic. (Also available at the ) This occurs both on the playground and on my local machine on a previous version (details below). Rust version from the playground: Local version: Playground backtrace: Local backtrace: EDIT: Added local machine backtrace too
It looks like the problem is here in . The call to seems to rely on the invariant that the match pairs have been fully simplified at this point, but are a special case and can still show up here.
Reproducible with recent nightlies too: : Triggered by more than 3 pattern condition with this compiler version.
I would have assumed that the implementation merely desugars into a bunch of top-level or-patterns. Is that not the case? Why are tuples special cased? If it isn't too involved, I could take a crack at this with some guidance... very much want to see this over the finish line.


Question: <del> Subproject commit d9e7d2696e41983b6b5a0b4fac604b4e548a84d3 </del> <ins> Subproject commit c7a16bd57c2a9c643a52f0cebecdaf0b6a996da1 </ins>

Was looking at the printout of llvm passes when I noticed that the functions that was inlined everywhere, and due to this was dead code, was optimized more after inlining. So as a test I at the line and this reduces the compile time of release build in racer by an average of 23%. I do not know if this is a good place to add this extra pass but maybe someone that knows how llvm works can use this information to speedup the compilation of release builds. was also wondering how this works in MIR I see that there is an inline pass but I can not find any dead code elimination
the stage1 compilation of rustc went from 828.89 to 691.75 secs with this fix on my computer but that is only a 15% improvement
15% is pretty significant.
Wow, great work!
That's some nice improvements! If you feel up to it, go ahead an submit a pull request with your suggested changes. That way someone with experience with LLVM is guaranteed to look at the patch and it won't get lost.
I believe the PR should be targeted at
:+1: If you want to push through this patch the general process works like this: Submit the patch against the currently active branch of (which is at the moment) Wait for it to get reviewed & merged Submit a pull request against which updates the submodule. If you have any questions about the process or want someone else to do this, just mention it here or contact me or someone else on one of the .
cc
cc
Ideally, the process should include discussion with upstream LLVM too.
Unfortunately it looks like we were a bit too eager to close this in :(
From what I have learned from the llvm maintainers I think that we have received the improvement that can be expected. The to good to be true improvements I measured was probably due to less optimizations was possible and resulted in less optimized code.


Question: /// # Example /// /// ```rust <ins> /// # #![allow(deprecated)] </ins> /// use url::get_scheme; /// /// let scheme = match get_scheme("https://example.com/") {

The common fix for , , and is to rewrite the module based on the spec at and the tests at (Note: the tests assume the API, designed for JavaScript in web browsers. We do not necessarily want the same API for Rust outside of testing code.)
I'm interested in this
I have a work-in-progress implementation. I’ll publish it later today so you can pick it up if you want.
Here it is: Note that I’m targeting Rust , the version used in Servo. (Though there is an upgrade being worked on.) IDNA and the actual URL parser are not there yet, but everything else (host/domain/ipv6, , percent encoding, test harness) is there. This should start being useful as soon as the URL parser is . The host parser returns an error on non-ASCII domains. This is good enough for now, IDNA support can be later. also made an in-progress implementation: It has some known bugs ( is incorrect with non-ASCII input, at least) but the parser code can probably be reused.
Also, be aware that the URL spec itself is still moving and has a number of open bugs:
I Punycode encoding and decoding (with tests) to but not Nameprep, which is the other big part of IDNA.
is now (IMHO) ready to replace . It is not "done" yet (some bugs remain, including in the spec!), but at this point it has more than feature-parity and is probably correct in more corner cases. Given the current tendency to move things out of , rust-url probably shouldn’t move in. It could be distributed with rustc like the rest of the modules moving out of extra, but this has the downside of tying rust-url upgrades to compiler upgrades, and only weak advantages IMO. So, whenever the Rust team decides it’s appropriate, I suggest removing and recommending rust-url as a replacement.
I would generally be in favor of a in the distribution for now. This would certainly not be a package in long-term, but for now putting everything in this repo is the ad-hoc solution we have until we get a real package manager.
In that case, I’d like to iterate a bit on rust-url (port rust-http and Servo to it, …) before it moves into the distribution. Also, rust-url depends on rust-encoding, which I guess would have to move as well.


Question: /// # Example /// /// ```rust <ins> /// # #![allow(deprecated)] </ins> /// use url::get_scheme; /// /// let scheme = match get_scheme("https://example.com/") {

I’d say rust-url is now in "beta" state. I have branches of rust-http and Servo using it: It builds with Cargo. It depends on rust-encoding (which also builds with Cargo), but for something non-essential that could be deactivated if avoiding the additional dependency helps. I’d like people to start using it and give feedback. I think the best way to do that is to get rid of the old liburl. I’ll go through the RFC process, but before that, what would you prefer? Replace liburl with snapshots[] of rust-url. You were in favor of this in February, but Cargo has reached alpha since then. Just remove liburl, and tell people to use rust-url through Cargo. Something else? [] In any case, I’d like to keep a separate rust-url repository that I can update in Servo independently of language upgrades.
+1 on removing liburl. Thanks
Perhaps we can deprecate all of liburl for one release cycle.
This seems like a great place to let cargo shine.
Deprecating sounds reasonable. That means emitting warnings by default, right?
awesome work! I agree with and that I think this is where cargo shines, and we can probably just remove liburl entirely without re-adding rust-url. We can also try to grow more official support for it in terms of documentation and automation (not present currently). We can mark liburl as with a message to use instead which should ferry everyone along quickly.


Question: <ins> // check-pass trait Identity<Q> { type T; } impl<Q, T> Identity<Q> for T { type T = T; } trait Holds { type Q; } struct S; struct X(S); struct XHelper; impl Holds for X { type Q = XHelper; } impl<Q> Clone for X where <S as Identity<Q>>::T: Clone, X: Holds<Q = Q>, { fn clone(&self) -> Self { Self(self.0.clone()) } } 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. --./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?