Question: <ins> error: lifetime may not live long enough --> $DIR/issue-54779-anon-static-lifetime.rs:34:24 | LL |         cx: &dyn DebugContext, |             - let's call the lifetime of this reference `'1` ... LL |         bar.debug_with(cx); |                        ^^ cast requires that `'1` must outlive `'static` error: aborting due to previous error </ins>

This example: gives this error: It took me some time to puzzle out what was happening here: expands to the default from the impl however is the impl method is accepted because it is more general than the trait definition but it fails to recursively invoke The error message without NLL, of course, is also not very illuminating.
Assigning myself to bookmark.
This seems to be a persistent ergonomics wart where traits get evaluated to (happens as well with returning and others I can't remember now) where it isn't expected. It is a bit sad, and we can improve the diagnostic errors, but I'm worried we'll be unable to preempt all the cases from being caught by accurate diagnostics, pushing people away from deeply nested structures. Maybe that is for the best, though.
I just want to note that the use of is, I think, a red herring in terms of the complaint about the diagnostic here. That is, I get the exact same diagnostic even if I add an explicit binder to the method, and then one can remove the . This is relevant because it means that if that feature is a red herring, then this bug may be relevant to the 2018 edition.
discussed with . We agreed this is not a blocker for 2018 edition. Tagging with NLL-deferred so it does not clog up our triage process.
I forgot to actual test how migration-mode (enabled for the 2018 edition) compares to . <detailsCurrent (nightly) 2018 edition output (): Current (nightly) output with (): </details
As for this week's triage, tagging this as P-medium priority.
I recently landed some changes ( and ) that are tangentially related to this but a similar strategy to them could be applied to this case.
Since feature has been removed, can this issue be closed as obsolete?
The example without : The error message isn't the same as migrate mode, but is on-par in terms of information (pointing out that the anonymous lifetime doesn't live as long as ). This issue can be closed by adding the above as a test.


Question: <ins> // Copyright 2016 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // forbid-output: &mut mut self struct Struct; impl Struct { fn foo(&mut self) { (&mut self).bar(); //~^ ERROR cannot borrow immutable argument `self` as mutable // ... and no SUGGESTION that suggests `&mut mut self` } // In this case we could keep the suggestion, but to distinguish the // two cases is pretty hard. It's an obscure case anyway. fn bar(self: &mut Self) { (&mut self).bar(); //~^ ERROR cannot borrow immutable argument `self` as mutable } } fn main () {} </ins>

Output:
The argument is of type but it is, itself, immutable. You can't redefine to point at somebody else. The rest of the message is nonsensical because it fails to realize that is the specialest of special cases in terms of method signature parsing.


Question: .map_or(false, |output| output.status.success()) } <ins> fn ensure_stage1_toolchain_placeholder_exists(stage_path: &str) -> bool { let pathbuf = PathBuf::from(stage_path); if fs::create_dir_all(pathbuf.join("lib")).is_err() { return false; }; let pathbuf = pathbuf.join("bin"); if fs::create_dir_all(&pathbuf).is_err() { return false; }; let pathbuf = pathbuf.join(format!("rustc{}", EXE_SUFFIX)); if pathbuf.exists() { return true; } // Take care not to overwrite the file let result = File::options().append(true).create(true).open(&pathbuf); if result.is_err() { return false; } return true; } </ins> // Used to get the path for `Subcommand::Setup` pub fn interactive_path() -> io::Result<Profile> { fn abbrev_all() -> impl Iterator<Item = ((String, String), Profile)> {

I tried this code on a fresh git clone of rust-lang/rust: I expected to see this happen: setup works without errors. Instead, this happened: x.py gives an error: This feature was introduced in and worked at that time. do you have time to look into this? The original bug report was from Nazar Mokrynskyi , not sure their github username. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Yes, I'll take a look over the next few days.
Hello. Is there a workaround for this issue for now? I got But when I ran , I got .
OK. After reading the zulip thread, I figured out how to work around it. After running , succeeded.
claim


Question: } } <del> impl<'tcx> Debug for TerminatorKind<'tcx> { fn fmt(&self, fmt: &mut Formatter<'_>) -> fmt::Result { self.fmt_head(fmt)?; let successor_count = self.successors().count(); let labels = self.fmt_successor_labels(); assert_eq!(successor_count, labels.len()); match successor_count { 0 => Ok(()), 1 => write!(fmt, " -> {:?}", self.successors().next().unwrap()), _ => { write!(fmt, " -> [")?; for (i, target) in self.successors().enumerate() { if i > 0 { write!(fmt, ", ")?; } write!(fmt, "{}: {:?}", labels[i], target)?; } write!(fmt, "]") } } } } impl<'tcx> TerminatorKind<'tcx> { /// Writes the "head" part of the terminator; that is, its name and the data it uses to pick the /// successor basic block, if any. The only information not included is the list of possible /// successors, which may be rendered differently between the text and the graphviz format. pub fn fmt_head<W: Write>(&self, fmt: &mut W) -> fmt::Result { use self::TerminatorKind::*; match self { Goto { .. } => write!(fmt, "goto"), SwitchInt { discr, .. } => write!(fmt, "switchInt({:?})", discr), Return => write!(fmt, "return"), GeneratorDrop => write!(fmt, "generator_drop"), Resume => write!(fmt, "resume"), Abort => write!(fmt, "abort"), Yield { value, resume_arg, .. } => write!(fmt, "{:?} = yield({:?})", resume_arg, value), Unreachable => write!(fmt, "unreachable"), Drop { place, .. } => write!(fmt, "drop({:?})", place), DropAndReplace { place, value, .. } => { write!(fmt, "replace({:?} <- {:?})", place, value) } Call { func, args, destination, .. } => { if let Some((destination, _)) = destination { write!(fmt, "{:?} = ", destination)?; } write!(fmt, "{:?}(", func)?; for (index, arg) in args.iter().enumerate() { if index > 0 { write!(fmt, ", ")?; } write!(fmt, "{:?}", arg)?; } write!(fmt, ")") } Assert { cond, expected, msg, .. } => { write!(fmt, "assert(")?; if !expected { write!(fmt, "!")?; } write!(fmt, "{:?}, ", cond)?; msg.fmt_assert_args(fmt)?; write!(fmt, ")") } FalseEdge { .. } => write!(fmt, "falseEdge"), FalseUnwind { .. } => write!(fmt, "falseUnwind"), InlineAsm { template, ref operands, options, .. } => { write!(fmt, "asm!("{}"", InlineAsmTemplatePiece::to_string(template))?; for op in operands { write!(fmt, ", ")?; let print_late = |&late| if late { "late" } else { "" }; match op { InlineAsmOperand::In { reg, value } => { write!(fmt, "in({}) {:?}", reg, value)?; } InlineAsmOperand::Out { reg, late, place: Some(place) } => { write!(fmt, "{}out({}) {:?}", print_late(late), reg, place)?; } InlineAsmOperand::Out { reg, late, place: None } => { write!(fmt, "{}out({}) _", print_late(late), reg)?; } InlineAsmOperand::InOut { reg, late, in_value, out_place: Some(out_place), } => { write!( fmt, "in{}out({}) {:?} => {:?}", print_late(late), reg, in_value, out_place )?; } InlineAsmOperand::InOut { reg, late, in_value, out_place: None } => { write!(fmt, "in{}out({}) {:?} => _", print_late(late), reg, in_value)?; } InlineAsmOperand::Const { value } => { write!(fmt, "const {:?}", value)?; } InlineAsmOperand::SymFn { value } => { write!(fmt, "sym_fn {:?}", value)?; } InlineAsmOperand::SymStatic { def_id } => { write!(fmt, "sym_static {:?}", def_id)?; } } } write!(fmt, ", options({:?}))", options) } } } /// Returns the list of labels for the edges to the successor basic blocks. pub fn fmt_successor_labels(&self) -> Vec<Cow<'static, str>> { use self::TerminatorKind::*; match *self { Return | Resume | Abort | Unreachable | GeneratorDrop => vec![], Goto { .. } => vec!["".into()], SwitchInt { ref values, switch_ty, .. } => ty::tls::with(|tcx| { let param_env = ty::ParamEnv::empty(); let switch_ty = tcx.lift(&switch_ty).unwrap(); let size = tcx.layout_of(param_env.and(switch_ty)).unwrap().size; values .iter() .map(|&u| { ty::Const::from_scalar(tcx, Scalar::from_uint(u, size), switch_ty) .to_string() .into() }) .chain(iter::once("otherwise".into())) .collect() }), Call { destination: Some(_), cleanup: Some(_), .. } => { vec!["return".into(), "unwind".into()] } Call { destination: Some(_), cleanup: None, .. } => vec!["return".into()], Call { destination: None, cleanup: Some(_), .. } => vec!["unwind".into()], Call { destination: None, cleanup: None, .. } => vec![], Yield { drop: Some(_), .. } => vec!["resume".into(), "drop".into()], Yield { drop: None, .. } => vec!["resume".into()], DropAndReplace { unwind: None, .. } | Drop { unwind: None, .. } => { vec!["return".into()] } DropAndReplace { unwind: Some(_), .. } | Drop { unwind: Some(_), .. } => { vec!["return".into(), "unwind".into()] } Assert { cleanup: None, .. } => vec!["".into()], Assert { .. } => vec!["success".into(), "unwind".into()], FalseEdge { .. } => vec!["real".into(), "imaginary".into()], FalseUnwind { unwind: Some(_), .. } => vec!["real".into(), "cleanup".into()], FalseUnwind { unwind: None, .. } => vec!["real".into()], InlineAsm { destination: Some(_), .. } => vec!["".into()], InlineAsm { destination: None, .. } => vec![], } } } </del> /////////////////////////////////////////////////////////////////////////// // Statements

moved the file to over 3k LOC, but I didn't fix it there and instead just annotated the file so tidy ignores it. We should probably split the mir types into separate submodules by the way they are used in MIR. I think we can start by pulling out e.g. terminators and all their sub-types to a submodule <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim Will be interested in picking this up


Question: <ins> #![deny(improper_ctypes_definitions)] #[repr(C)] pub struct Foo { a: u8, b: (), } extern "C" fn foo(x: Foo) -> Foo { todo!() } struct NotSafe(u32); #[repr(C)] pub struct Bar { a: u8, b: (), c: NotSafe, } extern "C" fn bar(x: Bar) -> Bar { //~^ ERROR `extern` fn uses type `NotSafe`, which is not FFI-safe //~^^ ERROR `extern` fn uses type `NotSafe`, which is not FFI-safe todo!() } fn main() {} </ins>

The function itself is considered FFI-safe and does not trigger the warning (). Its function pointer should also be allowed, to be consistent. Discovered on CI The original code has several more levels of indirection, but is also considered FFI-safe before. <details<summaryExtracted original code</summary</detailsAccording to CI logs, the warning occurs since rust 1.72.0-nightly ( 2023-07-03). Probably caused by . cc
Okay, so, I had a fix for this that just got rid of the regression, but I'm not sure that's the correct solution here - I think this is correct to be linting in the fn-ptr case and should be linting for the function case. is FFI-unsafe, but we allow a function to return because that's the default, but that doesn't mean that a within a type is okay (with the exception of a wrapper around the - because that's just returning , which we've already decided is okay). In the function case that works right now, that's being allowed because of this code.. ..which is there to support the case. However, it's not quite the right check. It doesn't actually check for ! It checks that the type - however nested - which was deemed FFI-unsafe is and that type is part of a return type. So any FFI-unsafe in a return type makes the entire return type FFI-safe - which is clearly incorrect. That's making the example below compile, which absolutely shouldn't. I've submitted , which makes this even more of a regression by making the function case fail too. We already had a simple "is it a unit" check, so I extended that to check for transparent newtype wrappers too, and removed the incorrect check.
This is unfortunate since I'm trying to return a where is likely to be . What should I do instead if I want to be FFI-safe with layout ?
I'm not so sure anymore after reading comment (). It's clear that some changes are required regardless - our current implementation wrong as demonstrated in the final example from my previous comment, but it's also inconsistent, in that this example... lint for the argument use of , but not the return use of , when really it should be both or neither. After my pull request, it's both.


Question: <ins> #![deny(improper_ctypes_definitions)] #[repr(C)] pub struct Foo { a: u8, b: (), } extern "C" fn foo(x: Foo) -> Foo { todo!() } struct NotSafe(u32); #[repr(C)] pub struct Bar { a: u8, b: (), c: NotSafe, } extern "C" fn bar(x: Bar) -> Bar { //~^ ERROR `extern` fn uses type `NotSafe`, which is not FFI-safe //~^^ ERROR `extern` fn uses type `NotSafe`, which is not FFI-safe todo!() } fn main() {} </ins>

With and without my pull request, when you change this to , it doesn't lint.
I'll nominate this issue so that it sees some discussion - see also and .
I posted some more info on zulip but it may also worth mentioning here. ZST is still zero-sized under repr(C), rather than FFI-unsafe.
The issue now also exists in beta. I also found uitests which seems to expect ZST to be FFI-safe, but ends in to suppress the warning and tests nothing.
We discussed this in today's meeting. We didn't have consensus that this should warn; at least some people thought the code in the top comment should continue to compile without warnings. We did have consensus that changing that (to warn) would need an FCP. So, we felt that we'd like to see a fix removing the warning applied to beta and nightly, and then separately if someone wants to propose that we change this to warn, we could evaluate that and do an FCP on it. But at the moment the temperature of the team seems to be that we don't have consensus for such an FCP.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
labels -I-lang-nominated We rendered our opinion


Question: <ins> #![warn(unused)] #![allow(dead_code)] #![deny(non_snake_case)] mod Impl {} //~^ ERROR module `Impl` should have a snake case name fn While() {} //~^ ERROR function `While` should have a snake case name fn main() { let Mod: usize = 0; //~^ ERROR variable `Mod` should have a snake case name //~^^ WARN unused variable: `Mod` let Super: usize = 0; //~^ ERROR variable `Super` should have a snake case name //~^^ WARN unused variable: `Super` } </ins>

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


Question: } } <ins> fn record_pat_span(&mut self, node: NodeId, span: Span) { debug!("(recording pat) recording {:?} for {:?}", node, span); self.pat_span_map.insert(node, span); } </ins> fn is_accessible_from(&self, vis: ty::Visibility, module: Module<'a>) -> bool { vis.is_accessible_from(module.nearest_parent_mod, self) }

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


Question: never_suggest_borrow.push(self.tcx.get_diagnostic_item(sym::send_trait).unwrap()); let param_env = obligation.param_env; <del> let trait_ref = trait_ref.skip_binder(); </del> <ins> let trait_ref = poly_trait_ref.skip_binder(); </ins> let found_ty = trait_ref.self_ty(); let found_ty_str = found_ty.to_string();

<!-- 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. --When creating this I found that it did not error if the function was not called and it also seemed to require it to be a function not just an argument of type T or (from what I tested) a different impl Trait although it could be any Fn* trait <!-- 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. --: This appears to only happen on nightly while stable and beta generate useful error reports <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label regression-from-stable-to-nightly
does not ICE but errors correctly while does ICE
glacier ""
searched nightlies: from nightly-2021-09-17 to nightly-2021-09-18 regressed nightly: nightly-2021-09-18 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-apple-darwin Reproduce with: </detailsThat's , so cc
I've got this. claim Interestingly, this is precisely the kind of thing that is hopefully going to help harden against: "hidden" s when calling and such
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium


Question: return tcx.arena.alloc(IndexVec::new()); } <del> let tainted_by_errors = tcx.mir_borrowck(def).tainted_by_errors; </del> <ins> tcx.ensure_with_value().mir_borrowck(def); </ins> let mut promoted = tcx.mir_promoted(def).1.steal(); for body in &mut promoted { <del> if let Some(error_reported) = tainted_by_errors { body.tainted_by_errors = Some(error_reported); } </del> run_analysis_to_runtime_passes(tcx, body); }

I tried : I expected to see this happen: an error about not being able to move out of a slice Instead, this happened: the error and a bunch of Fails on , works fine on
It also applies to way simpler code like:
searched nightlies: from nightly-2023-04-01 to nightly-2023-04-26 regressed nightly: nightly-2023-04-22 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </detailsHost triple: x8664-unknown-linux-gnu Reproduce with: </details Intestingly, the same day also contained two PRs but I have bisected this twice (with manual promt) and const prop lint really does seem to be the cause: commit[0] 2023-04-20: Auto merge of - m-ou-se:fmt-lang-items, r=jyn514 commit[1] 2023-04-20: Auto merge of - m-ou-se:flatten-format-args, r=oli-obk
WG-prioritization assigning priority (). label -I-prioritize +P-medium


Question: Variant2, } <ins> #[derive(Debug)] enum TupleVariant { Variant1(i32), //~ ERROR: variant `Variant1` is never constructed Variant2, } #[derive(Debug)] enum StructVariant { Variant1 { id: i32 }, //~ ERROR: variant `Variant1` is never constructed Variant2, } </ins> fn main() { let e = Enum::Variant2; e.clone(); <ins> let _ = TupleVariant::Variant2; let _ = StructVariant::Variant2; </ins> }

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: build cleanly Instead, this happened: Running the program shows the field is used: <!-- 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. --Rust version 1.77.0 (tested in playground) </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Derived code is intentionally ignored for dead code analysis - if you try just You'll get a note explaining this. The note doesn't seem to be attached for warnings, just
Ah, so it's intentional. Interesting. I assume the solution is to mark it with then.
claim
release-assignment so can claim it
Error: Parsing assign command in failed: ...'assignment' ' so Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
claim
Note that while getting a warning if is just derived but never explicitly used may be understandable (as discussed in other issues), you will get a warning if you do use it explicitly (see ) which, in my opinion, should not be the case.
As mentioned above, the fix for this issue is adding a note about how derived traits are intentionally ignored, not to stop ignoring them.


Question: tool::Rustfmt, tool::Miri, tool::CargoMiri, <del> native::Lld </del> <ins> native::Lld, native::CrtBeginEnd </ins> ), Kind::Check | Kind::Clippy { .. } | Kind::Fix | Kind::Format => describe!( check::Std,

Upstream issue: The version of used in the (and possibly the one too?) standard library has a bug where it will sometimes walk off the end of the segment containing the section and segfault. I've struggled to reproduce this except in some proprietary code, but the backtrace looks like: There's a proposed fix in the linked LLVM issue, which can possibly be patched into libunwind before building the musl target if taking an updated libunwind isn't possible.
I ran into this as well.
There doesn't seem to be any movement on the LLVM issue since I raised it, not even an assignee. Do you know if this is normal behaviour for them? Or if I've mis-raised the issue?
Running into this as well at OneSignal
I can reproduce this on latest stable on an open source project: On the second run of the final command, the background process will segfault.
After much investigation, I think there's two bugs here, one that LLVM's unwinder will consider unreadable memory as part of the section, and one that the rust compiler creates invalid (unusual?) unwind information. The crash is specifically happening when trying to find unwind information for the frame above (not but the "c-runtime" main. Since the frames above the C entry point are provided by the runtime (musl in this case), they are contained in / which, in rust's musl-targeting stdlib have been provided. The provided object files have no unwind information in them: This in and of itself isn't a huge problem, the code stops trying to unwind when it can't find unwind information for the next frame (), so it should stop after which would be fine. so long as we can safely fail to find the unwind information. The issue is that libunwind's logic for searching for FDE (frame description entry) for the parent frame is pretty all-encompassing and runs in many phases, and one of these crashes (sometimes) if there searched for address is not present in the unwind information).


Question: tool::Rustfmt, tool::Miri, tool::CargoMiri, <del> native::Lld </del> <ins> native::Lld, native::CrtBeginEnd </ins> ), Kind::Check | Kind::Clippy { .. } | Kind::Fix | Kind::Format => describe!( check::Std,

At a high level the process looks like () Look for a "compact unwinding table" Look for "DWARF unwind information" Look for ARM EHABI unwind info Look for dynamically created DWARF unwind entries For Rust x8664 musl binaries, the compiler has provided DWARF unwind information, so we fall into the second bullet (): No compact encoding hint, so the first section isn't interesting Search the section for an index for the frame - not present Check the local cache in case we've seen this frame before - we haven't Scan the whole of the section for the address of interest - CRASH! Digging further, we see that the logic for scanning the sector looks like (): Read a length field If it's 0 stop, we're done - rustc never seems to generate this "end-of-information" marker Skip over CIE entries For non-CIE entries work out if the address we're looking for is in the range of the entry, if so we've got our FDE Jump forward by the length of the CFI entry In each loop we check that the newly found CIE entry is in a reasonable place (between and ). If it's not, bail out for safety and fail the lookup. Unfortunately, as in the linked issue originally is incorrectly set too big (it's set to which is almost always wrong) so the unwind code will step right off the end of the segment and into one of: (LSDA) - This starts with a signature that is approximately , which is bigger than the error introduced by the miscalculation, so (after failing to parse the LSDA as a CFI entry) it jumps forward out of the range and bails out because the of the "reasonable location" check I mentioned above. The gap before (if the did not have a length that's a multiple of 32 and thus there's padding between the sections). In this case when it tries to read the next entry one of three things happens: The padding bytes happen to have a large value (when interpreted as a ) and we're in a similar position to the case where there's no padding, fail to parse the CFI entry, try to jump to the next one, realise we're jumping out of the allowed range and bail out for safety.


Question: tool::Rustfmt, tool::Miri, tool::CargoMiri, <del> native::Lld </del> <ins> native::Lld, native::CrtBeginEnd </ins> ), Kind::Check | Kind::Clippy { .. } | Kind::Fix | Kind::Format => describe!( check::Std,

The padding bytes are medium sized when interpreted as a , in this case, after the failed parse, the unwinder jumps far enough to be off the end of the loaded segment, but not far enough to be past the so the sanity check passes and the unwinder attempts to read the next CFI entry, reads a 32-bit number from an invalid address and... :boom: The padding bytes are small when interpreted as a , and the unwinder jumps into a random part of the LSDA and we're back in a situation that's functionally similar to when we're reading the padding bytes and the same three options are still applicable in the next lookup. So, what's the bug(s) here? LLVM is miscalculating the section length (the original issue) Rustc (or the linker?) doesn't include the marker at the end of Either of these would fix this issue, probably both should be done?
Ah, there's another possible route for the crash: If the LOAD segement is really big, the signature at the start of the LSDA might not be big enough to jump past leading to an invalid read and a :boom:
I've ran into this issue as well. What's the status of this?
I've been looking at a proper fix for this and neither of the two paths I proposed above are yeilding simple results: LLVM miscalculating the section length: The simple fix I proposed in the upstream issue allows the unwinder to read arbitrary parts of the LOAD segment before bailing, which might have unexpected effects A more complex fix needs to calculate the section length at runtime, which is tricky as sections don't exist at runtime... Neither the nor section contains a length field so we're not simply told the length Maybe read the executable off disk (look in ) and parse the section table? Might not be readable to the current user. Might not even exist (not sure if this is possible, can you create a linux executable from an in-memory image?) Add terminator entry to the end of the section This relies on the static linker's behaviour, which is a shame as allows you to bring your own linker and both seem inconsistent about whether they add terminator entries, sometimes they do, sometimes they don't This feels like something that rustc can't fix locally or rely on externally Another option would be for LLVM to skip walking the section if the lookup in the fails.


Question: tool::Rustfmt, tool::Miri, tool::CargoMiri, <del> native::Lld </del> <ins> native::Lld, native::CrtBeginEnd </ins> ), Kind::Check | Kind::Clippy { .. } | Kind::Fix | Kind::Format => describe!( check::Std,

It's unlikely to ever reveal anything new, and it seems that this section is just un-walkable with any kind of reliability.
Here are two tested workarounds, neither very pretty, but both work: to your Cargo config a build, extract the link script from the linker verbose output the lines: .ehframe : ONLYIFRO { KEEP ((.ehframe)) (.ehframe.) } ... .ehframe : ONLYIFRW { KEEP ((.ehframe)) (.ehframe.) } them to: .ehframe : ONLYIFRO { KEEP ((.ehframe)) (.ehframe.) LONG(0x0) } ... .ehframe : ONLYIFRW { KEEP ((.ehframe)) (.ehframe.) LONG(0x0) } ( is the CIE terminator) off this script somewhere in Cargo config (probably under the Musl target) an object containing just the terminator: 2, Add to your Cargo config (probably under the Musl target)
Hi! Is this still an issue? If so, is there perhaps a simpler way to reproduce this than the instructions linked above?
The setup that's needed is: A large LOAD segment (the one containing and ) Specifically the section needs to be deep into the segment How deep it has to be is roughly determined by the first of the section So something like the following should trigger the fault: This builds a huge section, which lives before the section so should lead to the crash. Hedging words because I can't reproduce the issue on my development machine (I run out of RAM and get OOM-killered).
Hmm, that doesn't seem to be sufficient (tested on the current stable and nightly). I get this output when building and running this on Arch Linux: I also get the same output when using to capture the backtrace.
I noticed the wrong ehSectionEnd calculation independently and filed
It looks like the gcc driver on Alpine adds the file to the link, which includes a terminator in . It seems that the rustc driver doesn't add something like this? (LLVM has a that has an .ehframe terminator, so maybe that's relevant to rustc.)


Question: tool::Rustfmt, tool::Miri, tool::CargoMiri, <del> native::Lld </del> <ins> native::Lld, native::CrtBeginEnd </ins> ), Kind::Check | Kind::Clippy { .. } | Kind::Fix | Kind::Format => describe!( check::Std,

FWIW, it looks like LLVM's LLD linker automatically adds a terminator to the end of .ehframe, even if one isn't present in the linker inputs, so that could be a workaround: I think libunwind should stop scanning .ehframe when it finds unwind info from .ehframehdr (i.e. the GNUEH_FRAME segment).
Rustc's musl-targeting link includes: I don't exactly know where the files come from (they're shipped with the compiler toolchain, e.g. mine are in ) but looking at the musl codebase, there's no terminator in : (Intriguingly there's also no in the musl codebase, suggesting Rustc gets these objects from somewhere else?)_ I wouldn't expect to see a or since the rustc musl target doesn't include a C++ runtime and musl libc doesn't define either of these objects for the C runtime either.
It looks like musl's crt1 is a C file, not assembly. crt/{S,r,}crt1.c When crtbegin and crtend were to LLVM (), there was some discussion about which project is responsible for which aspects of the CRT begin/end files. Apparently the status quo on Linux is that: the compiler (e.g. libgcc) provides crtbegin/crtend the libc provides crti/crte (and maybe crt1, too?) That is the case on my gLinux (i.e. Debian) system: /usr/lib/x8664-linux-gnu/crt[1ie].o all come from the libc6-dev:amd64 package /usr/lib/gcc/x8664-linux-gnu/9/{crtbegin.o,crtend.o} come from libgcc-9-dev:amd64 The .ehframe terminator is usually in crtend, which is part of libgcc (not glibc or musl). LLVM's compiler-rt also provides crtbegin/crtend files. The gcc and clang drivers link a crtend object even for C programs. On Alpine, the gcc driver links a libgcc crtend object. It looks like rustc typically invokes the driver, but when it's targeting musl, it enters a mode where it provides the start files explicitly, and in this mode, it doesn't include crtbegin/crtend. For Alpine, I see , , , and .


Question: tool::Rustfmt, tool::Miri, tool::CargoMiri, <del> native::Lld </del> <ins> native::Lld, native::CrtBeginEnd </ins> ), Kind::Check | Kind::Clippy { .. } | Kind::Fix | Kind::Format => describe!( check::Std,

For rustc/glibc, I don't see any of those flags, so the cc driver uses the default CRT begin/end/i/n/1 files. I see that rustc documents a lot of this at The unwinder needs the .ehframe terminator, because the .ehframehdr search table is optional, and because .ehframehdr has the start address of .ehframe, but not its size. ( / ). I don't think it's reasonable to open the ELF file indicated by dlpiname -- in principle, that duplicates the work done by the loader, and I can think of many specific things that wouldn't work. (e.g. the vdso, the executable w/glibc, Android's androiddlopen_ext and ability to map DSOs from zip files, unlinked files, etc).
Using self-contained mode is not generally recommended for serious work. If the compiler heuristics enable it by default, then it can be explicitly disabled with , then gcc will be used for linking without and will find all the necessary CRT objects by itself. Then it's important to make sure that gcc for the right target (musl in this case) is used by rustc.
If the compiler heuristics enable it by default Here's a FIXME for improving the heuristic for musl targets:
Thanks for that, very interesting. I think there are two separate use cases for musl-targeting builds: an environment where there's a full "native musl" toolchain (like on Alpine etc) where I think you're correct that we shouldn't use and should let the toolchain sort it out for us though I can't see an easy way to tell if a real toolchain is available a generic linux environment where the goal is fully static binaries (for easy of redistribution/embedding in thin container images/etc.)


Question: tool::Rustfmt, tool::Miri, tool::CargoMiri, <del> native::Lld </del> <ins> native::Lld, native::CrtBeginEnd </ins> ), Kind::Check | Kind::Clippy { .. } | Kind::Fix | Kind::Format => describe!( check::Std,

where there's likely not a native toolchain and rustc is forced to work out the answers for itself (as an aside no longer works as the "linker" for musl targets, since it doesn't support which is enabled in rustc as of the last release) I'm worrying about the latter case and I think from above the fix for that is: to add the terminator in builds as well as ones and include it in the target package alongside the (so rustup etc fetch it) the link command rustc emits for the musl target to include before Some side questions: Does the above sound sensible to people? Do we need to include any of too? (I think not, but I'm no expert :shrug:) Do other targets need similar treatment? musl?
In the latter case it would make sense to me for rustc to invoke an actual linker (///etc) since at the moment it goes via a compiler but has to tell the compiler to not do anything and just to pass the link args to the linker anyway. This is off topic for this discussion though.
If we need to improve the self-contained mode specifically, then I think we can just ship the begin/end objects and link to them like gcc does obsoleting the comment cited in That appears to be the simplest solution. If that doesn't work out (e.g. due to licensing), then the necessary parts can be to and linked as , as you suggested above.
Which / objects were you thinking? 's? LLVM's? If you're right and it's the compiler that ships the begin/end then maybe it's right for to have it's own (though given that the link might contain code compiled by random compilers (from scripts) as well as compiled by , which is "the compiler" for the sake of this discussion)?
's? LLVM's? I don't know, but looks like they should be compatible. At least on Ubuntu both gcc and clang link to gcc's objects. The gcc ones can be just copied by rustbuild if the license allows, the LLVM ones can be used if we need to build them by ourselves (they are a part of compiler-rt).
adds crtbegin/crtend objects to Rust distribution and links to them in self-contained mode as was suggested in , so it should fix this issue.
I still have this problem with clang's compiler-rt:


Question: #[derive(Copy, Clone, RustcEncodable, RustcDecodable)] enum EntryKind { <ins> AnonConst(mir::ConstQualifs, Lazy<RenderedConst>), </ins> Const(mir::ConstQualifs, Lazy<RenderedConst>), ImmStatic, MutStatic,

Currently with const generics you can create a "specialized" implementation, such as: Which has the following output: (playground link: ) However, when using such a type in another crate this causes a stack overflow in the compiler. For example, with the following code (full example: ): I would expect it to produce the same output as the playground link above, however it produces the following:
A bisect shows this stopped crashing after , marked as needing a test
I was still encountering this in my code with and after trying to minimize it seems that the original example is fixed but the stack overflow still occurs when the const expression in the has braces around it. After experimenting I found some more examples of what works and what doesn't: (see to try it) compiles and runs successfully while and (or ) crash the compiler with the same error as the original: :


Question: }; // rhs has holes ( `$id` and `$(...)` that need filled) let tts = transcribe(&cx.parse_sess.span_diagnostic, Some(named_matches), rhs); <ins> if cx.trace_macros() { trace_macros_note(cx, sp, format!("to `{}`", tts)); } </ins> let directory = Directory { path: cx.current_expansion.module.directory.clone(), ownership: cx.current_expansion.directory_ownership,

Output is: The first message here is inaccurate. The macro-use does not expand to that macro-use. shows the input to macros, not the output. So instead of "expands to:", it should say "expanding:". But changing the behavior to match what the message says would be even better. ;) This is a regression because the error messages are new. used to just dump token streams to stdout (lol).
Introduced in .
Closing -- I believe fixed this.


Question: }); cx.emit_spanned_lint(DEREF_INTO_DYN_SUPERTRAIT, cx.tcx.def_span(item.owner_id.def_id), SupertraitAsDerefTarget { t, <del> target_principal: target_principal.to_string(), </del> <ins> target_principal, </ins> label, }); }

<!-- 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. --ICE with in I just noticed the error actually says openpgp-card at the bottom, perhaps compilation doesn't even get to the final crate. In any case, I'm no good at minimizing these things, so I'm handing this off to people who are good at that. <!-- 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 label +E-needs-mcve
searched nightlies: from nightly-2023-01-01 to nightly-2023-01-15 regressed nightly: nightly-2023-01-14 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
This fixes the ICE, although I'm not sure if that's the right approach
label -E-needs-mcve


Question: return; }; let coroutine_ty = body.local_decls[ty::CAPTURE_STRUCT_LOCAL].ty; <del> let ty::Coroutine(_, args) = *coroutine_ty.kind() else { bug!() }; </del> <ins> if coroutine_ty.references_error() { return; } let ty::Coroutine(_, args) = *coroutine_ty.kind() else { bug!("{body:#?}") }; </ins> let coroutine_kind = args.as_coroutine().kind_ty().to_opt_closure_kind().unwrap(); if coroutine_kind == ty::ClosureKind::FnOnce {

<!-- ICE: Rustc '-Zvalidate-mir -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: unexpected body ty: {type error} phase Runtime(PostCleanup)', 'error: internal compiler error: unexpected body ty: {type error} phase Runtime(PostCleanup)' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [mirdropselaboratedandconstchecked] elaborating drops for [analysis] running analysis passes on this crate --
cc :D (note you'll need which was merged 10 minutes ago ^^ )


Question: return; }; let coroutine_ty = body.local_decls[ty::CAPTURE_STRUCT_LOCAL].ty; <del> let ty::Coroutine(_, args) = *coroutine_ty.kind() else { bug!() }; </del> <ins> if coroutine_ty.references_error() { return; } let ty::Coroutine(_, args) = *coroutine_ty.kind() else { bug!("{body:#?}") }; </ins> let coroutine_kind = args.as_coroutine().kind_ty().to_opt_closure_kind().unwrap(); if coroutine_kind == ty::ClosureKind::FnOnce {

<!-- ICE: Rustc '--edition=2021 -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: impossible case reached', 'error: internal compiler error: impossible case reached' File: --auto-reduced (treereduce-rust): <details<summary<strongoriginal code</strong</summary<poriginal: </p</detailsVersion information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [mirconst] preparing for borrow checking [mirpromoted] promoting constants in MIR for [mir_borrowck] borrow-checking [analysis] running analysis passes on this crate --
cc


Question: }; if let ObligationCauseCode::ImplDerivedObligation(obligation) = &*code { <del> let expected_trait_ref = obligation.parent_trait_ref.skip_binder(); let new_imm_trait_ref = ty::TraitRef::new(obligation.parent_trait_ref.def_id(), imm_substs); let new_mut_trait_ref = ty::TraitRef::new(obligation.parent_trait_ref.def_id(), mut_substs); </del> <ins> let expected_trait_ref = obligation.parent_trait_ref; let new_imm_trait_ref = poly_trait_ref .rebind(ty::TraitRef::new(obligation.parent_trait_ref.def_id(), imm_substs)); let new_mut_trait_ref = poly_trait_ref .rebind(ty::TraitRef::new(obligation.parent_trait_ref.def_id(), mut_substs)); </ins> return try_borrowing(new_imm_trait_ref, new_mut_trait_ref, expected_trait_ref, &[]); } else if let ObligationCauseCode::BindingObligation(_, _) | ObligationCauseCode::ItemObligation(_) = &*code { return try_borrowing( <del> ty::TraitRef::new(trait_ref.def_id, imm_substs), ty::TraitRef::new(trait_ref.def_id, mut_substs), trait_ref, </del> <ins> poly_trait_ref.rebind(ty::TraitRef::new(trait_ref.def_id, imm_substs)), poly_trait_ref.rebind(ty::TraitRef::new(trait_ref.def_id, mut_substs)), *poly_trait_ref, </ins> &never_suggest_borrow[..], ); } else {


Question: error: invalid register `invalid`: unknown register <del> --> $DIR/issue-72570.rs:7:18 </del> <ins> --> $DIR/issue-72570.rs:9:18 </ins> | LL |         asm!("", in("invalid") "".len()); |                  ^^^^^^^^^^^^^^^^^^^^^^

<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --code from ./src/test/ui/asm/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. --repo is @ <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Does this still happen with (now merged)
I can confirm its fixed. We can probably close this issue.
Closing this, thanks for taking a look!


Question: <ins> error[E0004]: non-exhaustive patterns: `(A, Some(A))`, `(A, Some(B))`, `(B, Some(B))` and 2 more not covered --> $DIR/issue-72377.rs:8:11 | LL |     match (x, y) { |           ^^^^^^ patterns `(A, Some(A))`, `(A, Some(B))`, `(B, Some(B))` and 2 more not covered | = help: ensure that all possible cases are being handled, possibly by adding wildcards or more match arms = note: the matched value is of type `(X, Option<X>)` error: aborting due to previous error For more information about this error, try `rustc --explain E0004`. </ins>

A small demo: . I expected to see this happen The usual error message indicating that patterns and are not covered. Instead, this happened Patterns and are detected as not covered. :
If you add the suggested arms, it will in fact detect the other ones as missing. It is expected that is detected as not covered since the match guard is not taken into account when checking exhaustiveness (and couldn't be, since it's an arbitrary expression).
Closing as expected behavior.
Wouldn't you then expect that it mentions , , , and as not covered? Or is the number of outputs always restricted to two? In that case, I think it would be useful to indicate that some patterns might be missing, e.g.:
Yeah that's true


Question: #[test] #[cfg(unix)] <del> #[cfg_attr(any(target_os = "vxworks", target_os = "android"), ignore)] </del> <ins> #[cfg_attr(any(target_os = "vxworks"), ignore)] </ins> fn signal_reported_right() { use crate::os::unix::process::ExitStatusExt; <del> let mut p = Command::new("/bin/sh").arg("-c").arg("read a").stdin(Stdio::piped()).spawn().unwrap(); </del> <ins> let mut p = shell_cmd().arg("-c").arg("read a").stdin(Stdio::piped()).spawn().unwrap(); </ins> p.kill().unwrap(); match p.wait().unwrap().signal() { Some(9) => {}

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: <ins> // check-pass // https://github.com/rust-lang/rust/issues/113257 #![deny(trivial_casts)] // The casts here are not trivial. struct Foo<'a> { a: &'a () } fn extend_lifetime_very_very_safely<'a>(v: *const Foo<'a>) -> *const Foo<'static> { // This should pass because raw pointer casts can do anything they want. v as *const Foo<'static> } trait Trait {} fn assert_static<'a>(ptr: *mut (dyn Trait + 'a)) -> *mut (dyn Trait + 'static) { ptr as _ } fn main() { let unit = (); let foo = Foo { a: &unit }; let _long: *const Foo<'static> = extend_lifetime_very_very_safely(&foo); } </ins>

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: . I expected to see this happen: it compiles, since raw pointer casts should be allowed even for completely different types. Instead, this happened: it fails with: It looks like for some reason the compiler creates a lifetime obligation here. Strangely, it works with : .
I've looked into this. The issue is that typeck considers this cast to be a "coercion cast", because typeck thinks that you could replace the function body with just since the types are the same (it also triggers the lint (allow-by-default)). HIR typeck isn't aware of lifetimes. So then THIR building and MIR building build MIR that doesn't contain a cast but instead just assigns one to the other. The borrow checker is rightfully not pleased. The bug here is that the THIR does not contain an explicit cast anymore. I'm not sure how to best fix this, as the current logic for "is this a no-op cast (called coercion cast in the code)" is just "try to coerce the types in the same way that happens on coercion sites and if it works it has to be useless". Which is wrong in the presence of lifetimes. It seems like the current strategy works this way because it reuses some code in THIR building. Thinking about it a little more, this is very special to pointer casts, because only pointer casts are allowed to change the type like this. Maybe THIR building should just special case pointer casts to always be emitted?
Unfortunately due to this bug there is that should be turned into a raw pointer cast, but we cannot.
I think that's a different case, these are boxes and not raw pointers, and box-box casts are not allowed to do arbitrary changes (and are in fact coercion casts, so the doesn't actually do anything). The error there is correct and this needs a transmute.
I'd like to replace the transmutes by raw pointer casts, which IMO is much preferable, similar to But this bug is in the way of that.


Question: // If this is a floating point literal that ends with '.', // get rid of it to stop this from becoming a member access. let snippet = snippet.strip_suffix('.').unwrap_or(&snippet); err.span_suggestion( lit.span, &format!(

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should something like this: label +D-confusing +D-invalid-suggestion <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim


Question: let _a = stderr(); let _a = _a.lock(); } <ins> #[test] #[cfg_attr(target_os = "emscripten", ignore)] fn test_lock_stderr() { test_lock(stderr, stderr_locked); } #[test] #[cfg_attr(target_os = "emscripten", ignore)] fn test_lock_stdin() { test_lock(stdin, stdin_locked); } #[test] #[cfg_attr(target_os = "emscripten", ignore)] fn test_lock_stdout() { test_lock(stdout, stdout_locked); } // Helper trait to make lock testing function generic. trait Stdio<'a>: 'static where Self::Lock: 'a, { type Lock; fn lock(&'a self) -> Self::Lock; } impl<'a> Stdio<'a> for Stderr { type Lock = StderrLock<'a>; fn lock(&'a self) -> StderrLock<'a> { self.lock() } } impl<'a> Stdio<'a> for Stdin { type Lock = StdinLock<'a>; fn lock(&'a self) -> StdinLock<'a> { self.lock() } } impl<'a> Stdio<'a> for Stdout { type Lock = StdoutLock<'a>; fn lock(&'a self) -> StdoutLock<'a> { self.lock() } } // Helper trait to make lock testing function generic. trait StdioOwnedLock: 'static {} impl StdioOwnedLock for StderrLock<'static> {} impl StdioOwnedLock for StdinLock<'static> {} impl StdioOwnedLock for StdoutLock<'static> {} // Tests locking on stdio handles by starting two threads and checking that // they block each other appropriately. fn test_lock<T, U>(get_handle: fn() -> T, get_locked: fn() -> U) where T: for<'a> Stdio<'a>, U: StdioOwnedLock, { // State enum to track different phases of the test, primarily when // each lock is acquired and released. #[derive(Debug, PartialEq)] enum State { Start1, Acquire1, Start2, Release1, Acquire2, Release2, } use State::*; // Logging vector to be checked to make sure lock acquisitions and // releases happened in the correct order. let log = Arc::new(Mutex::new(Vec::new())); let ((tx1, rx1), (tx2, rx2)) = (sync_channel(0), sync_channel(0)); let th1 = { let (log, tx) = (Arc::clone(&log), tx1); thread::spawn(move || { log.lock().unwrap().push(Start1); let handle = get_handle(); { let locked = handle.lock(); log.lock().unwrap().push(Acquire1); tx.send(Acquire1).unwrap(); // notify of acquisition tx.send(Release1).unwrap(); // wait for release command log.lock().unwrap().push(Release1); } tx.send(Acquire1).unwrap(); // wait for th2 acquire { let locked = handle.lock(); log.lock().unwrap().push(Acquire1); } log.lock().unwrap().push(Release1); }) }; let th2 = { let (log, tx) = (Arc::clone(&log), tx2); thread::spawn(move || { tx.send(Start2).unwrap(); // wait for start command let locked = get_locked(); log.lock().unwrap().push(Acquire2); tx.send(Acquire2).unwrap(); // notify of acquisition tx.send(Release2).unwrap(); // wait for release command log.lock().unwrap().push(Release2); }) }; assert_eq!(rx1.recv().unwrap(), Acquire1); // wait for th1 acquire log.lock().unwrap().push(Start2); assert_eq!(rx2.recv().unwrap(), Start2); // block th2 assert_eq!(rx1.recv().unwrap(), Release1); // release th1 assert_eq!(rx2.recv().unwrap(), Acquire2); // wait for th2 acquire assert_eq!(rx1.recv().unwrap(), Acquire1); // block th1 assert_eq!(rx2.recv().unwrap(), Release2); // release th2 th2.join().unwrap(); th1.join().unwrap(); assert_eq!( *log.lock().unwrap(), [Start1, Acquire1, Start2, Release1, Acquire2, Release2, Acquire1, Release1] ); } </ins>

Given the following code: The current output is: I think it's typical for a newcomer to want to get a iterator by chaining method calls like . There's no obvious reason why that shouldn't work. The examples in the documentation do typically show being assigned to a variable prior to calling its method, but don't explain why that's necessary. I think the "borrow" terminology is misleading, but there might not be a concise way to describe what's actually going on to the user. The "temporary value is freed at the end of this statement" is probably correct. The "creates a temporary which is freed while still in use" is probably more correctly "creates a temporary that is required to outlive (or live exactly as long as) the result of...", followed by a pointer to the method invocation, with text of " method call". Maybe it should also point out the lifetime argument in the return type. I tried and failed to find a satisfactory explanation of what exactly was borrowing from the temporary value produced by . When I looked through the library source code, the only references in were those created by locking a , and the in question is static. I'm guessing the existence of a borrow is assumed rather than inferred from analyzing the function body of . The assumption might be the result of the anonymous lifetime argument on the output type from , which imposes a requirement that the doesn't outlive (or has the same lifetime as?) the value that is the receiver of . The correct fix might be to change the locked stdin handles to all use lifetimes, but I will probably file that as a separate issue.
label +A-borrow-checker +A-lifetimes +D-confusing +D-incorrect +D-newcomer-roadblock
IMO the intent is clear here. Without changing the API, why exactly is Rust unable to lift 'a &'static X to 'static & 'static X, if X also contains only 'static lifetimes? I don't think raw references have a meaningful dropper; borrowck is able to freely resolve any derived lifetimes on impls that don't depend on anything else to 'static; I'm pretty sure under current rules we should be able to substitute latter for earlier and get exactly the same behaviour.
This is due to .


Question: let _a = stderr(); let _a = _a.lock(); } <ins> #[test] #[cfg_attr(target_os = "emscripten", ignore)] fn test_lock_stderr() { test_lock(stderr, stderr_locked); } #[test] #[cfg_attr(target_os = "emscripten", ignore)] fn test_lock_stdin() { test_lock(stdin, stdin_locked); } #[test] #[cfg_attr(target_os = "emscripten", ignore)] fn test_lock_stdout() { test_lock(stdout, stdout_locked); } // Helper trait to make lock testing function generic. trait Stdio<'a>: 'static where Self::Lock: 'a, { type Lock; fn lock(&'a self) -> Self::Lock; } impl<'a> Stdio<'a> for Stderr { type Lock = StderrLock<'a>; fn lock(&'a self) -> StderrLock<'a> { self.lock() } } impl<'a> Stdio<'a> for Stdin { type Lock = StdinLock<'a>; fn lock(&'a self) -> StdinLock<'a> { self.lock() } } impl<'a> Stdio<'a> for Stdout { type Lock = StdoutLock<'a>; fn lock(&'a self) -> StdoutLock<'a> { self.lock() } } // Helper trait to make lock testing function generic. trait StdioOwnedLock: 'static {} impl StdioOwnedLock for StderrLock<'static> {} impl StdioOwnedLock for StdinLock<'static> {} impl StdioOwnedLock for StdoutLock<'static> {} // Tests locking on stdio handles by starting two threads and checking that // they block each other appropriately. fn test_lock<T, U>(get_handle: fn() -> T, get_locked: fn() -> U) where T: for<'a> Stdio<'a>, U: StdioOwnedLock, { // State enum to track different phases of the test, primarily when // each lock is acquired and released. #[derive(Debug, PartialEq)] enum State { Start1, Acquire1, Start2, Release1, Acquire2, Release2, } use State::*; // Logging vector to be checked to make sure lock acquisitions and // releases happened in the correct order. let log = Arc::new(Mutex::new(Vec::new())); let ((tx1, rx1), (tx2, rx2)) = (sync_channel(0), sync_channel(0)); let th1 = { let (log, tx) = (Arc::clone(&log), tx1); thread::spawn(move || { log.lock().unwrap().push(Start1); let handle = get_handle(); { let locked = handle.lock(); log.lock().unwrap().push(Acquire1); tx.send(Acquire1).unwrap(); // notify of acquisition tx.send(Release1).unwrap(); // wait for release command log.lock().unwrap().push(Release1); } tx.send(Acquire1).unwrap(); // wait for th2 acquire { let locked = handle.lock(); log.lock().unwrap().push(Acquire1); } log.lock().unwrap().push(Release1); }) }; let th2 = { let (log, tx) = (Arc::clone(&log), tx2); thread::spawn(move || { tx.send(Start2).unwrap(); // wait for start command let locked = get_locked(); log.lock().unwrap().push(Acquire2); tx.send(Acquire2).unwrap(); // notify of acquisition tx.send(Release2).unwrap(); // wait for release command log.lock().unwrap().push(Release2); }) }; assert_eq!(rx1.recv().unwrap(), Acquire1); // wait for th1 acquire log.lock().unwrap().push(Start2); assert_eq!(rx2.recv().unwrap(), Start2); // block th2 assert_eq!(rx1.recv().unwrap(), Release1); // release th1 assert_eq!(rx2.recv().unwrap(), Acquire2); // wait for th2 acquire assert_eq!(rx1.recv().unwrap(), Acquire1); // block th1 assert_eq!(rx2.recv().unwrap(), Release2); // release th2 th2.join().unwrap(); th1.join().unwrap(); assert_eq!( *log.lock().unwrap(), [Start1, Acquire1, Start2, Release1, Acquire2, Release2, Acquire1, Release1] ); } </ins>

is declared as follows: Because there is only one input lifetime (the elided lifetime of ), it is assigned to the output lifetime , which is why the lock can live at most as long as the temporary.
Thanks. I think this might be a bug in libstd (using instead of as the return type), but I'll file that separately. What I think is a diagnostic inaccuracy is that the error message refers to a borrow, when, by inspection of the library source code, no borrow is taking place in . (Unless I'm missing something?) What I think is happening is that the compiler is enforcing that lives no longer than the temporary produced by , and is misleadingly calling that a borrow in the error message.
As a simplified example: The error message refers to a borrow even when the output type of does not refer to at all!
that's because of the elision rules: on the declaration you're implicitly telling the compiler that the lifetime of the borrow matches the lifetime of the type. .
Thanks. I think the error messages could use a little more detail about how something that the borrow checker sees as a borrow may be an artifact of lifetime constraints in a function signature rather than an actual borrow in the function body. It certainly surprised me the first time I ran into it. (Maybe only in the explanatory text in the compiler error index. It looks like E0597 could also benefit from that detail, because it's a similar case, and an example in E0716 produces E0597.)
Shorter example, probably better suited for an example in the compiler error index:


Question: use rustc_metadata::creader::{CStore, LoadedMacro}; use rustc_middle::ty::fast_reject::SimplifiedType; use rustc_middle::ty::{self, TyCtxt}; <ins> use rustc_span::def_id::LOCAL_CRATE; </ins> use rustc_span::hygiene::MacroKind; use rustc_span::symbol::{kw, sym, Symbol};

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


Question: } } <ins> /// Suggest using `while let` for call `next` on an iterator in a for loop. /// /// For example: /// ```ignore (illustrative) /// /// for x in iter { ///     ... ///     iter.next() /// } /// ``` pub(crate) fn explain_iterator_advancement_in_for_loop_if_applicable( &self, err: &mut Diagnostic, span: Span, issued_spans: &UseSpans<'tcx>, ) { let issue_span = issued_spans.args_or_use(); let tcx = self.infcx.tcx; let hir = tcx.hir(); let Some(body_id) = hir.get(self.mir_hir_id()).body_id() else { return }; let typeck_results = tcx.typeck(self.mir_def_id()); struct ExprFinder<'hir> { issue_span: Span, expr_span: Span, body_expr: Option<&'hir hir::Expr<'hir>>, loop_bind: Option<Symbol>, } impl<'hir> Visitor<'hir> for ExprFinder<'hir> { fn visit_expr(&mut self, ex: &'hir hir::Expr<'hir>) { if let hir::ExprKind::Loop(hir::Block{ stmts: [stmt, ..], ..}, _, hir::LoopSource::ForLoop, _) = ex.kind && let hir::StmtKind::Expr(hir::Expr{ kind: hir::ExprKind::Match(call, [_, bind, ..], _), ..}) = stmt.kind && let hir::ExprKind::Call(path, _args) = call.kind && let hir::ExprKind::Path(hir::QPath::LangItem(LangItem::IteratorNext, _, _, )) = path.kind && let hir::PatKind::Struct(path, [field, ..], _) = bind.pat.kind && let hir::QPath::LangItem(LangItem::OptionSome, _, _) = path && let PatField { pat: hir::Pat{ kind: hir::PatKind::Binding(_, _, ident, ..), .. }, ..} = field && self.issue_span.source_equal(call.span) { self.loop_bind = Some(ident.name); } if let hir::ExprKind::MethodCall(body_call, _recv, ..) = ex.kind && body_call.ident.name == sym::next && ex.span.source_equal(self.expr_span) { self.body_expr = Some(ex); } hir::intravisit::walk_expr(self, ex); } } let mut finder = ExprFinder { expr_span: span, issue_span, loop_bind: None, body_expr: None }; finder.visit_expr(hir.body(body_id).value); if let Some(loop_bind) = finder.loop_bind && let Some(body_expr) = finder.body_expr && let Some(def_id) = typeck_results.type_dependent_def_id(body_expr.hir_id) && let Some(trait_did) = tcx.trait_of_item(def_id) && tcx.is_diagnostic_item(sym::Iterator, trait_did) { err.note(format!( "a for loop advances the iterator for you, the result is stored in `{}`.", loop_bind )); err.help("if you want to call `next` on a iterator within the loop, consider using `while let`."); } } </ins> /// Suggest using closure argument instead of capture. /// /// For example:

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: or similar. The note and/or help are both subject to changes, this is just a basic idea. We could also conceivably rewrite the error message to expand on what the note says, like so: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
It's hard to get 'c' in line 3 during the context where the compiler errors out the second mutable borrow message, because the mutable borrow happens between
I don't think it's critical to mention in the diagnostic. We shouldn't let the difficulty of doing that stop us from trying to improve the message. label +D-newcomer-roadblock
I'd love to try to fix this, but sadly I'm not familiar with the internals of rustc. If someone could point me towards the section where this error is, I could give it a try.
Hi ! Whenever I try to dive into fixing a problem with rustc, I usually start with a search through the codebase. In this case, I'd search for strings that come from the error message: , , or : <img width="528" alt="image" src="https://user-"And that leads me to here: So then I'd use rust-analyzer to try to find all the usages of that method.


Question: } } <ins> /// Suggest using `while let` for call `next` on an iterator in a for loop. /// /// For example: /// ```ignore (illustrative) /// /// for x in iter { ///     ... ///     iter.next() /// } /// ``` pub(crate) fn explain_iterator_advancement_in_for_loop_if_applicable( &self, err: &mut Diagnostic, span: Span, issued_spans: &UseSpans<'tcx>, ) { let issue_span = issued_spans.args_or_use(); let tcx = self.infcx.tcx; let hir = tcx.hir(); let Some(body_id) = hir.get(self.mir_hir_id()).body_id() else { return }; let typeck_results = tcx.typeck(self.mir_def_id()); struct ExprFinder<'hir> { issue_span: Span, expr_span: Span, body_expr: Option<&'hir hir::Expr<'hir>>, loop_bind: Option<Symbol>, } impl<'hir> Visitor<'hir> for ExprFinder<'hir> { fn visit_expr(&mut self, ex: &'hir hir::Expr<'hir>) { if let hir::ExprKind::Loop(hir::Block{ stmts: [stmt, ..], ..}, _, hir::LoopSource::ForLoop, _) = ex.kind && let hir::StmtKind::Expr(hir::Expr{ kind: hir::ExprKind::Match(call, [_, bind, ..], _), ..}) = stmt.kind && let hir::ExprKind::Call(path, _args) = call.kind && let hir::ExprKind::Path(hir::QPath::LangItem(LangItem::IteratorNext, _, _, )) = path.kind && let hir::PatKind::Struct(path, [field, ..], _) = bind.pat.kind && let hir::QPath::LangItem(LangItem::OptionSome, _, _) = path && let PatField { pat: hir::Pat{ kind: hir::PatKind::Binding(_, _, ident, ..), .. }, ..} = field && self.issue_span.source_equal(call.span) { self.loop_bind = Some(ident.name); } if let hir::ExprKind::MethodCall(body_call, _recv, ..) = ex.kind && body_call.ident.name == sym::next && ex.span.source_equal(self.expr_span) { self.body_expr = Some(ex); } hir::intravisit::walk_expr(self, ex); } } let mut finder = ExprFinder { expr_span: span, issue_span, loop_bind: None, body_expr: None }; finder.visit_expr(hir.body(body_id).value); if let Some(loop_bind) = finder.loop_bind && let Some(body_expr) = finder.body_expr && let Some(def_id) = typeck_results.type_dependent_def_id(body_expr.hir_id) && let Some(trait_did) = tcx.trait_of_item(def_id) && tcx.is_diagnostic_item(sym::Iterator, trait_did) { err.note(format!( "a for loop advances the iterator for you, the result is stored in `{}`.", loop_bind )); err.help("if you want to call `next` on a iterator within the loop, consider using `while let`."); } } </ins> /// Suggest using closure argument instead of capture. /// /// For example:

In this case, turns out there's only one: And there we see that there is already some conditional suggestion being made; it calls . And it seems there's a family of those . So I think it would make sense to try to write your own or something like that. You'll need to figure out how to sort of "back track" from the MIR back to the HIR or the AST so you can figure out whether you're inside a loop. I would study the code in to try to figure out how to do that. And don't forget to write a handful of regression tests in somewhere, maybe in : https://rustc-dev- It might also be possible to perform this check at a higher level, say, in . If you can figure out that you're in a for loop, and that the user is trying to call on the iterator, then you could raise the error then.


Question: _ => false, } } <ins> fn is_local(&self) -> bool { self.normal_ancestor_id.is_some() } </ins> } impl<'a> fmt::Debug for ModuleS<'a> {

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


Question: [dependencies] core = { path = "../core" } <del> compiler_builtins = { version = "0.1.114", features = ['rustc-dep-of-std'] } [target.'cfg(not(any(target_arch = "aarch64", target_arch = "x86", target_arch = "x86_64")))'.dependencies] compiler_builtins = { version = "0.1.114", features = ["no-f16-f128"] } </del> <ins> compiler_builtins = { version = "0.1.117", features = ['rustc-dep-of-std'] } </ins> [dev-dependencies] rand = { version = "0.8.5", default-features = false, features = ["alloc"] }

I do not have minimised code. This was a sudden CI build failure on nightly for aarch64-unknown-linux-musl () Note that this is a cross compile using cross-rs. It fails on rust version 1.82.0-nightly ( 2024-07-29) but works on 1.82.0-nightly ( 2024-07-28). Needless to say it also works perfectly fine on stable. The error is reproducible on rebuild and locally with cross-rs. It is not reproducible with cargo-zigbuild interestingly enough. I also checked that the version of cross-rs didn't change between the successful and failing builds (no new releases of that project since february). The only change between the successful and failing CI runs were a typo fix to an unrelated CI pipeline (the release one, so it didn't even run yet). As such I'm forced to conclude that the blame lies with Rustc. Steps to reproduce: I expected to see this happen: Compilation successful (as it is with stable for same target, or with -gnu and nightly) Instead, this happened () It most recently worked on: 1.82.0-nightly ( 2024-07-28) (or stable 1.80.0 or beta 1.81.0, take your pick for triaging) :
cc (of cross-rs fame) in case he has any insight on this regression
I have hit the same issue in a similar situation. Cross compiling to aarch64-unknown-linux-musl from x86_64 linux in a Github CI pipeline using cross-rs. Link to pipeline failing logs:
Seems rune isn't needed based on the comment by Updated the title.
This is probably
WG-prioritization assigning priority (). label -I-prioritize +P-high
Yeah that's probably it. We used to build the C version of those symbols but switched to Rust versions with the compiler builtins update. Unfortunately we can't enable them on all platforms because LLVM has crashes, and the logic that would allow optional configuration is apparently not working.


Question: [dependencies] core = { path = "../core" } <del> compiler_builtins = { version = "0.1.114", features = ['rustc-dep-of-std'] } [target.'cfg(not(any(target_arch = "aarch64", target_arch = "x86", target_arch = "x86_64")))'.dependencies] compiler_builtins = { version = "0.1.114", features = ["no-f16-f128"] } </del> <ins> compiler_builtins = { version = "0.1.117", features = ['rustc-dep-of-std'] } </ins> [dev-dependencies] rand = { version = "0.8.5", default-features = false, features = ["alloc"] }

After that part is fixed, we will need to enable the symbols on all platforms where is f128 (which includes aarch64), since these errors probably come from here I think anyone who needs a quick workaround can add to their dependencies to get the symbols directly, as described near the top of Note that this requires nightly.
Is it possible to add a dependency conditionally based on if it is nightly? (In a specific range of dates even?) I cannot and will not depend on nightly, but I do test my code on nightly in CI (in order to find breakages like this early). For now I just disabled that nightly build on aarch64 musl.
Same for me. Not using cross-rs though. Logs are here:
Same for me, both using as host toolchain and cross compiling.
Looks like it is happening now too for x86_64.
Not for my projects, so you should probably provide a reproducer on x86-64 GNU if possible, since that is a tier 1 platform (unlike Aarch64 on Musl). Or is this about some other x8664 variation that is also tier 2?
Woops, sorry, the x86_64 build failed too, but then i looked at the aarch64 build logs :) which still fail.


Question: <ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. pub trait AbstractRenderer {} fn _create_render(_: &()) -> AbstractRenderer //~^ ERROR: the trait `core::kinds::Sized` is not implemented { match 0u { _ => unimplemented!() } } fn main() { } </ins>

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


Question: <del> Subproject commit a416c5e0f7c4c9473069a58410d3ec3e86b1ac0d </del> <ins> Subproject commit fc24fce73f878e641094b1802df1e748c5fe233a </ins>

use std; import std::vec; fn main() { let vec[int] a = [0]; auto i = 20; while (i 0) { a += a; i -= 1; } } I suspect, but haven't confirmed, the following: If a vector that is in the process of self-appending (v += v) grows, we can realloc the existing vector pointer and invalidate the memory that is being copied.
I'm the last person who touched the vec append glue. I'll look into it.
Yeah, you were exactly right. Fixed by .


Question: <del> error[E0308]: mismatched types --> $DIR/issue-30904.rs:20:45 | LL |     let _: for<'a> fn(&'a str) -> Str<'a> = Str; |                                             ^^^ expected concrete lifetime, found bound lifetime parameter 'a | = note: expected type `for<'a> fn(&'a str) -> Str<'a>` found type `fn(&str) -> Str<'_> {Str::<'_>}` error[E0631]: type mismatch in function arguments --> $DIR/issue-30904.rs:26:10 | LL | fn test<F: for<'x> FnOnce<(&'x str,)>>(_: F) {} |    ----    -------------------------- required by this bound in `test` ... LL | struct Str<'a>(&'a str); | ------------------------ found signature of `fn(&str) -> _` ... LL |     test(Str); |          ^^^ expected signature of `for<'x> fn(&'x str) -> _` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0308`. </del>

Reproduction branch: When applying the change from the last commit I get a panic in my code during the call to . <details<summaryBacktrace</summary</details
Cannot reproduce on my linux. Can you provide a small ? Is that possible? Maybe without all the externals :/
I can reproduce a very similar problem (appears to involve the same origin and failing assertion of ) compiling rust-lang/regex with and compiler flags: For me, setting to 2 or greater is required to present this failure. <details<summarybacktrace</summary<code<preRUSTBACKTRACE=1 cargo build Compiling regex v1.1.2 (/home/kent/rust/regex) thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32', stack backtrace: 0: std::sys::unix::backtrace::tracing::imp::unwindbacktrace at 1: std::syscommon::backtrace::print at 2: std::panicking::defaulthook::{{closure}} at at 3: std::panicking::defaulthook at 4: rustc::util::common::panichook 5: std::panicking::rustpanicwithhook at 6: std::panicking::beginpanic 7: syntax::sourcemap::SourceMap::bytepostofilecharpos 8: syntax::sourcemap::SourceMap::lookupcharpos 9: <rustccodegenssa::mir::FunctionCx<'a, 'tcx, Bx::scopemetadataforloc 10: <rustccodegenssa::mir::FunctionCx<'a, 'tcx,


Question: <del> error[E0308]: mismatched types --> $DIR/issue-30904.rs:20:45 | LL |     let _: for<'a> fn(&'a str) -> Str<'a> = Str; |                                             ^^^ expected concrete lifetime, found bound lifetime parameter 'a | = note: expected type `for<'a> fn(&'a str) -> Str<'a>` found type `fn(&str) -> Str<'_> {Str::<'_>}` error[E0631]: type mismatch in function arguments --> $DIR/issue-30904.rs:26:10 | LL | fn test<F: for<'x> FnOnce<(&'x str,)>>(_: F) {} |    ----    -------------------------- required by this bound in `test` ... LL | struct Str<'a>(&'a str); | ------------------------ found signature of `fn(&str) -> _` ... LL |     test(Str); |          ^^^ expected signature of `for<'x> fn(&'x str) -> _` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0308`. </del>

Bx::debugloc 11: rustccodegenssa::mir::codegenmir 12: rustccodegenssa::base::codegeninstance 13: rustccodegenssa::monoitem::MonoItemExt::define 14: rustccodegenllvm::base::compilecodegenunit::modulecodegen 15: rustc::depgraph::graph::DepGraph::withtask 16: rustccodegenllvm::base::compilecodegenunit 17: rustccodegenssa::base::codegencrate 18: <rustccodegenllvm::LlvmCodegenBackend as rustccodegenutils::codegenbackend::CodegenBackend::codegencrate 19: rustc::util::common::time 20: rustcdriver::driver::phase4codegen 21: rustcdriver::driver::compileinput::{{closure}} 22: <std::thread::local::LocalKey<T::with 23: rustc::ty::context::TyCtxt::createandenter 24: rustcdriver::driver::compileinput 25: rustcdriver::runcompilerwithpool 26: <scopedtls::ScopedKey<T::set 27: rustcdriver::runcompiler 28: syntax::withglobals 29: rustmaybecatchpanic at 30: <F as alloc::boxed::FnBox<A::callbox 31: std::sys::unix::thread::Thread::new::threadstart at at at 32: <unknown33: clone query stack during panic: end of query stack error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: rustc 1.34.0-nightly ( 2019-02-26) running on x86_64-unknown-linux-gnu note: compiler flags: -Z mir-opt-level=2 -C debuginfo=2 -C incremental --crate-type lib </pre</code</details
With the help of , I've found a tiny test that reproduces this crash on Linux and Mac:
Got another one: <details</detailsHappens when compiling regex tests with and calling on every span found in the mir of the functions needing codegen.
According to glaicer, the ICE from this example has been gone.
can you confirm that your example does not crash on nightly anymore?


Question: <del> error[E0308]: mismatched types --> $DIR/issue-30904.rs:20:45 | LL |     let _: for<'a> fn(&'a str) -> Str<'a> = Str; |                                             ^^^ expected concrete lifetime, found bound lifetime parameter 'a | = note: expected type `for<'a> fn(&'a str) -> Str<'a>` found type `fn(&str) -> Str<'_> {Str::<'_>}` error[E0631]: type mismatch in function arguments --> $DIR/issue-30904.rs:26:10 | LL | fn test<F: for<'x> FnOnce<(&'x str,)>>(_: F) {} |    ----    -------------------------- required by this bound in `test` ... LL | struct Str<'a>(&'a str); | ------------------------ found signature of `fn(&str) -> _` ... LL |     test(Str); |          ^^^ expected signature of `for<'x> fn(&'x str) -> _` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0308`. </del>

Has been fixed in
is likely the part of the rollup fixing it.
Shouldn't a testcase be instead of closing this?
A similar crash that still happens:


Question: <del> error[E0308]: mismatched types --> $DIR/issue-30904.rs:20:45 | LL |     let _: for<'a> fn(&'a str) -> Str<'a> = Str; |                                             ^^^ expected concrete lifetime, found bound lifetime parameter 'a | = note: expected type `for<'a> fn(&'a str) -> Str<'a>` found type `fn(&str) -> Str<'_> {Str::<'_>}` error[E0631]: type mismatch in function arguments --> $DIR/issue-30904.rs:26:10 | LL | fn test<F: for<'x> FnOnce<(&'x str,)>>(_: F) {} |    ----    -------------------------- required by this bound in `test` ... LL | struct Str<'a>(&'a str); | ------------------------ found signature of `fn(&str) -> _` ... LL |     test(Str); |          ^^^ expected signature of `for<'x> fn(&'x str) -> _` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0308`. </del>

I realize it's kinda nonsensical, but here:
Why didn't WF catch this?
That's because only checks statics/constants.
Still reproducible with .
This ought to be a mostly easy fix. The problem is that the well formedness check, which ought to be rejected this code, is ignoring things in an : They fall through to this `` case: We would need to add support for the HIR item: which in turn has a number of items: which are defined here: presumably we want the to check that the types of are well-formed, roughly analogous to how we current check normal static items: (We probably want similar checks on foreign item fns, though?) One tricky part might be compatibility, we may need to turn this into a compatibility lint in case there is lots of broken code in the wild.
I am trying to fix this bug, and need help moving forward. function is modified to accept a and a , yet it doesn't report any additional errors and the ICE prevails. Test file: Commit: Should I create a pull request or is it too early?
Looks like suggestions are incomplete ( does not require ). Also, I left a comment on your commit about how you can avoid adding . I suspect the only reason regular s are required to be is they have an initializer (and that, not the type, requires ), i.e. for we have these errors:
Oddly, the PR that were previously posted to fix this (PR , following on PR ) was subsequently closed as inactive ... but the bug itself seems like it may have been resolved in the meantime?
I'm going to assume this was fixed. Tagging as E-needstest, but if someone wants to take the time, it'd be even better to bisect to where this was fixed, and see if a regression test for this was at that time.
Compiler no longer panics, tested with


Question: <ins> // aux-build:issue-99221-aux.rs // build-aux-docs // ignore-cross-compile #![crate_name = "foo"] #[macro_use] extern crate issue_99221_aux; pub use issue_99221_aux::*; // @count foo/index.html '//a[@class="macro"]' 1 #[macro_export] macro_rules! print { () => () } </ins>

I tried to create a minimum example from an issue we've seen in our project (). I tried running: On the following crate: : I expected to see this happen: The command should succeed. Instead, this happened: It crashed with an ICE <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details
This issue may be related to , however I can only reproduce it on the nightly build. On the stable channel, rustdoc succeeds.
cc
does this reproduce on beta?
I know I'm not celinval, but I've been able to reduce this to a test case, and yeah, it reproduces on beta.
That was quick. Thank you!
Reopening to track beta breakage.
I was silly and nominated even though the PR has already been nominated, and that's really the thing that's supposed to be. Please ignore, and sorry for the noise.


Question: }) } <del> pub fn predicate_for_default_trait_impl<'tcx>( </del> <ins> pub fn predicate_for_trait_def<'tcx>( </ins> tcx: &ty::ctxt<'tcx>, cause: ObligationCause<'tcx>, trait_def_id: ast::DefId,

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


Question: }) } <del> pub fn predicate_for_default_trait_impl<'tcx>( </del> <ins> pub fn predicate_for_trait_def<'tcx>( </ins> tcx: &ty::ctxt<'tcx>, cause: ObligationCause<'tcx>, trait_def_id: ast::DefId,

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


Question: |                   ^ expected identifier, found reserved identifier error: associated constant in `impl` without body <del> --> $DIR/typeck_type_placeholder_item.rs:203:5 </del> <ins> --> $DIR/typeck_type_placeholder_item.rs:205:5 </ins> | LL |     const C: _; |     ^^^^^^^^^^-

First time filing a bug report, apologies if i missed anything or if this is a duplicate. Encountered this bug while writing some non-sensical associated function types. Searched around for any similar issues and the closest i found was , seems closely related? Minimal example: Playground link: The ICE happens on all channels it seems
Yes, I think so too. The snippet is rejected as expected on 1.42 but ICE occurs instead since 1.43.
Assigning as and removing .


Question: install_sh(builder, "clippy", self.compiler.stage, Some(self.target), &tarball); }; Miri, alias = "miri", Self::should_build(_config), only_hosts: true, { <del> let tarball = builder .ensure(dist::Miri { compiler: self.compiler, target: self.target }) .expect("missing miri"); install_sh(builder, "miri", self.compiler.stage, Some(self.target), &tarball); </del> <ins> if let Some(tarball) = builder.ensure(dist::Miri { compiler: self.compiler, target: self.target }) { install_sh(builder, "miri", self.compiler.stage, Some(self.target), &tarball); } else { // Miri is only available on nightly builder.info( &format!("skipping Install miri stage{} ({})", self.compiler.stage, self.target), ); } </ins> }; LlvmTools, alias = "llvm-tools", Self::should_build(_config), only_hosts: true, { let tarball = builder

On Solaris 11 x86_64, from scratch builds of 1.66.0 from git fails with: A build of the same tag completes successfully, as do and builds of 1.65.0.
Was there an earlier (nonfatal) error? If miri failed to build there should hopefully be a reason mentioned. We turned miri on unconditionally, so builds require it to build successfully. Maybe we should disable that requirement for stable builds,but even so, stable builds should work just like nightly builds for miri
It doesn't even try to build , instead panics soon after its start: Dunno about Solaris build but MSYS2 hack quite a lot patches that theoretically could cause problems.
Found the culprit: Should be easy enough to fix by making install not unwrap anymore. Looks like I was too eager
Glad to see that this is indeed a real issue. Was tearing my hair out for hours wondering WHY x.py install kept failing with missing miri when is set with channel = "stable"
We are still seeing this with 1.66.1. […] Compiling thiserror v1.0.33 Finished release [optimized] target(s) in 38.48s warning: x.py has made several changes recently you may want to look at help: consider looking at the changes in note: to silence this warning, add at the top of note: this message was printed twice to make it more likely to be seen Build completed successfully in 0:28:41 python3 install Building rustbuild Finished dev [unoptimized] target(s) in 0.66s warning: x.py has made several changes recently you may want to look at help: consider looking at the changes in note: to silence this warning, add at the top of thread 'main' panicked at 'missing miri', note: run with environment variable to display a backtrace Build completed unsuccessfully in 0:00:01
The fix has been merged for the future 1.68 release.


Question: <ins> // Copyright 2016 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // Test that methods from shadowed traits cannot be used mod foo { pub trait T { fn f(&self) {} } impl T for () {} } mod bar { pub use foo::T; } fn main() { pub use bar::*; struct T; ().f() //~ ERROR no method } </ins>

This compiles: but this doesn't: More generally, a shadowed trait's methods are usable if it is shadowed by an item, but not if it is shadowed by an import. Should methods from shadowed traits be usable?
cc
cc
Nominating for discussion at meeting. Clearly we should be consistent. I'm inclined to think that they should not be available, ever.
I'm of the same thoughts as A new "thing" with the same name as another outer "thing" should not inherit/infer/have/etc. any part of that outer thing. This is the case with , but—according to the presented opinion—it seems like it needs to be made consistent for trait bindings, right?
Is there a reason to shadow traits by name? What happens here is that it must find a method named among the imported traits, and that name has not been shadowed in any way, so it should be callable.
Well, that's the question, isn't it. Imagine then that did have an method -- would you prefer an ambiguity error here, or success?
Ambiguity error if was implemented for in the example (and this error is already implemented). Otherwise it doesn't interfere in any way.
Another more challenging example might be: should the methods from be available, given that it is shadowed by ?
My feeling is that the simplest rule is to say that methods come from "traits that are in scope", and shadowed traits are not in scope. This interpretation is shadowing of items from prelude and globs, which seem like they should clearly not count towards method resolution.
Discussed in meeting and settled on "methods from shadowed traits should be unavailable". triage: P-medium
We also want methods from to be unavailable (from your more challenging example), right?


Question: <ins> warning: the feature `non_lifetime_binders` is incomplete and may not be safe to use and/or cause compiler crashes --> $DIR/nested-apit-mentioning-outer-bound-var.rs:1:12 | LL | #![feature(non_lifetime_binders)] |            ^^^^^^^^^^^^^^^^^^^^ | = note: see issue #108185 <https://github.com/rust-lang/rust/issues/108185> for more information = note: `#[warn(incomplete_features)]` on by default error: `impl Trait` can only mention type parameters from an fn or impl --> $DIR/nested-apit-mentioning-outer-bound-var.rs:8:52 | LL | fn uwu(_: impl for<T> Trait<(), Assoc = impl Trait<T>>) {} |                    - type parameter declared here  ^ error: aborting due to previous error; 1 warning emitted </ins>

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


Question: // Once we're done with llvm 14 and earlier, this test can be deleted. <del> #![crate_type="lib"] </del> <ins> #![crate_type = "lib"] </ins> use std::mem::MaybeUninit;

The following code generates some really awful LLVM IR: The same happens with . Cc who made me write these tests, and
Feels like an LLVM limitation to me. It should be replacing the with a (or a of poison when that becomes available).
For reference: LLVM is capable of optimizing a memcpy of undef alloca away, this just runs into the usual limitation that all of memcpyopt doesn't work across BBs.
This is such a long-standing issue. Seems like it might be wise to have someone working on fixing this.
Someone has already worked on this, see It's a bit hard to track, but unfortunately this got reverted again (multiple times). I suspect that this is only going to get really resolved once memcpyopt moves to memssa -- which someone has also worked on in the past (), but which never really went anywhere.
The alloca and memcpy are no longer present on nightly, as a result of .
The FIXME in the test is still there, needs a test.


Question: // and about 2 * (len1 + len2) comparisons in the worst case // while `extend` takes O(len2 * log(len1)) operations // and about 1 * len2 * log_2(len1) comparisons in the worst case, <del> // assuming len1 >= len2. </del> <ins> // assuming len1 >= len2. For larger heaps, the crossover point // no longer follows this reasoning and was determined empirically. </ins> #[inline] fn better_to_rebuild(len1: usize, len2: usize) -> bool { <del> 2 * (len1 + len2) < len2 * log2_fast(len1) </del> <ins> let tot_len = len1 + len2; if tot_len <= 2048 { 2 * tot_len < len2 * log2_fast(len1) } else { 2 * tot_len < len2 * 11 } </ins> } if better_to_rebuild(self.len(), other.len()) {

The uses a heuristic based on the worst-case number of comparisons to determine between two strategies: , equivalent to pushing all elements of the other heap. the vector of the other heap and rebuilding the heap from scratch. I've done some benchmarking, and it turns out that method 1 (based on ) is always faster for two heaps based on randomly shuffled data – on the computers I've tested it on, anyway. I've included images of below: first the current strategy, then the strategy (method 1). In the benchmarks, two heaps are merged, one containing the number of elements on the x-axis, the other containing 100,000 minus that number (for the rightmost data points both heaps are equal in size). The red line (sometimes hiding behind the green one) is in both images that corresponding to , the other lines are not relevant to this issue (they aren't standard library types). ! ! From the jump in performance in the first graph, you can clearly see when the switch between the two approaches happens. Graphs are similar for smaller heaps, I didn't test larger ones. It's possible method 2 is faster under other circumstances (maybe if one of the heaps contains mostly very small/large elements?), especially if both heaps are (almost) equal in size. However, I think the benchmark is more close to the "average" real-world use case than such a case would be (I'd be happy to be proven wrong about this, though). <details<summarySimplification of the benchmark that only runs the parts relevant for this issue</summary</details
The comment suggests that the rebuild strategy is more efficient if at least one of the following is true: comparisons are very expensive the appended heap is much much larger than self but self must still contain a handful of elements so that the logarithm is 2 You can see how the slope of the append method is lower, so its advantage would show if you extended your benchmark by an order of magnitude. If you used a more expensive comparison function it would probably show earlier too.
The code for swaps the heaps if is larger than , so the appended heap is always smaller than or equal to the self heap. Indeed, the slope of the rebuild method is smaller, but I can't find conditions where that is outweighed by the higher base cost of the method.