Question: <ins> use crate::mir::interpret::Scalar; use crate::ty::{self, Ty, TyCtxt}; use rustc_ast::ast::{InlineAsmOptions, InlineAsmTemplatePiece}; use super::{ AssertMessage, BasicBlock, InlineAsmOperand, Operand, Place, SourceInfo, Successors, SuccessorsMut, }; pub use rustc_ast::ast::Mutability; use rustc_macros::HashStable; use rustc_span::Span; use std::borrow::Cow; use std::fmt::{self, Debug, Formatter, Write}; use std::iter; use std::slice; pub use super::query::*; #[derive(Clone, RustcEncodable, RustcDecodable, HashStable, PartialEq)] pub enum TerminatorKind<'tcx> { /// Block should have one successor in the graph; we jump there. Goto { target: BasicBlock }, /// Operand evaluates to an integer; jump depending on its value /// to one of the targets, and otherwise fallback to `otherwise`. SwitchInt { /// The discriminant value being tested. discr: Operand<'tcx>, /// The type of value being tested. /// This is always the same as the type of `discr`. /// FIXME: remove this redundant information. Currently, it is relied on by pretty-printing. switch_ty: Ty<'tcx>, /// Possible values. The locations to branch to in each case /// are found in the corresponding indices from the `targets` vector. values: Cow<'tcx, [u128]>, /// Possible branch sites. The last element of this vector is used /// for the otherwise branch, so targets.len() == values.len() + 1 /// should hold. // // This invariant is quite non-obvious and also could be improved. // One way to make this invariant is to have something like this instead: // // branches: Vec<(ConstInt, BasicBlock)>, // otherwise: Option<BasicBlock> // exhaustive if None // // However we’ve decided to keep this as-is until we figure a case // where some other approach seems to be strictly better than other. targets: Vec<BasicBlock>, }, /// Indicates that the landing pad is finished and unwinding should /// continue. Emitted by `build::scope::diverge_cleanup`. Resume, /// Indicates that the landing pad is finished and that the process /// should abort. Used to prevent unwinding for foreign items. Abort, /// Indicates a normal return. The return place should have /// been filled in before this executes. This can occur multiple times /// in different basic blocks. Return, /// Indicates a terminator that can never be reached. Unreachable, /// Drop the `Place`. Drop { place: Place<'tcx>, target: BasicBlock, unwind: Option<BasicBlock> }, /// Drop the `Place` and assign the new value over it. This ensures /// that the assignment to `P` occurs *even if* the destructor for /// place unwinds. Its semantics are best explained by the /// elaboration: /// /// ``` /// BB0 { ///   DropAndReplace(P <- V, goto BB1, unwind BB2) /// } /// ``` /// /// becomes /// /// ``` /// BB0 { ///   Drop(P, goto BB1, unwind BB2) /// } /// BB1 { ///   // P is now uninitialized ///   P <- V /// } /// BB2 { ///   // P is now uninitialized -- its dtor panicked ///   P <- V /// } /// ``` DropAndReplace { place: Place<'tcx>, value: Operand<'tcx>, target: BasicBlock, unwind: Option<BasicBlock>, }, /// Block ends with a call of a converging function. Call { /// The function that’s being called. func: Operand<'tcx>, /// Arguments the function is called with. /// These are owned by the callee, which is free to modify them. /// This allows the memory occupied by "by-value" arguments to be /// reused across function calls without duplicating the contents. args: Vec<Operand<'tcx>>, /// Destination for the return value. If some, the call is converging. destination: Option<(Place<'tcx>, BasicBlock)>, /// Cleanups to be done if the call unwinds. cleanup: Option<BasicBlock>, /// `true` if this is from a call in HIR rather than from an overloaded /// operator. True for overloaded function call. from_hir_call: bool, /// This `Span` is the span of the function, without the dot and receiver /// (e.g. `foo(a, b)` in `x.foo(a, b)` fn_span: Span, }, /// Jump to the target if the condition has the expected value, /// otherwise panic with a message and a cleanup target. Assert { cond: Operand<'tcx>, expected: bool, msg: AssertMessage<'tcx>, target: BasicBlock, cleanup: Option<BasicBlock>, }, /// A suspend point. Yield { /// The value to return. value: Operand<'tcx>, /// Where to resume to. resume: BasicBlock, /// The place to store the resume argument in. resume_arg: Place<'tcx>, /// Cleanup to be done if the generator is dropped at this suspend point. drop: Option<BasicBlock>, }, /// Indicates the end of the dropping of a generator. GeneratorDrop, /// A block where control flow only ever takes one real path, but borrowck /// needs to be more conservative. FalseEdge { /// The target normal control flow will take. real_target: BasicBlock, /// A block control flow could conceptually jump to, but won't in /// practice. imaginary_target: BasicBlock, }, /// A terminator for blocks that only take one path in reality, but where we /// reserve the right to unwind in borrowck, even if it won't happen in practice. /// This can arise in infinite loops with no function calls for example. FalseUnwind { /// The target normal control flow will take. real_target: BasicBlock, /// The imaginary cleanup block link. This particular path will never be taken /// in practice, but in order to avoid fragility we want to always /// consider it in borrowck. We don't want to accept programs which /// pass borrowck only when `panic=abort` or some assertions are disabled /// due to release vs. debug mode builds. This needs to be an `Option` because /// of the `remove_noop_landing_pads` and `no_landing_pads` passes. unwind: Option<BasicBlock>, }, /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly, with placeholders. template: &'tcx [InlineAsmTemplatePiece], /// The operands for the inline assembly, as `Operand`s or `Place`s. operands: Vec<InlineAsmOperand<'tcx>>, /// Miscellaneous options for the inline assembly. options: InlineAsmOptions, /// Source spans for each line of the inline assembly code. These are /// used to map assembler errors back to the line in the source code. line_spans: &'tcx [Span], /// Destination block after the inline assembly returns, unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option<BasicBlock>, }, } #[derive(Clone, Debug, RustcEncodable, RustcDecodable, HashStable)] pub struct Terminator<'tcx> { pub source_info: SourceInfo, pub kind: TerminatorKind<'tcx>, } impl<'tcx> Terminator<'tcx> { pub fn successors(&self) -> Successors<'_> { self.kind.successors() } pub fn successors_mut(&mut self) -> SuccessorsMut<'_> { self.kind.successors_mut() } pub fn unwind(&self) -> Option<&Option<BasicBlock>> { self.kind.unwind() } pub fn unwind_mut(&mut self) -> Option<&mut Option<BasicBlock>> { self.kind.unwind_mut() } } impl<'tcx> TerminatorKind<'tcx> { pub fn if_( tcx: TyCtxt<'tcx>, cond: Operand<'tcx>, t: BasicBlock, f: BasicBlock, ) -> TerminatorKind<'tcx> { static BOOL_SWITCH_FALSE: &[u128] = &[0]; TerminatorKind::SwitchInt { discr: cond, switch_ty: tcx.types.bool, values: From::from(BOOL_SWITCH_FALSE), targets: vec![f, t], } } pub fn successors(&self) -> Successors<'_> { use self::TerminatorKind::*; match *self { Resume | Abort | GeneratorDrop | Return | Unreachable | Call { destination: None, cleanup: None, .. } | InlineAsm { destination: None, .. } => None.into_iter().chain(&[]), Goto { target: ref t } | Call { destination: None, cleanup: Some(ref t), .. } | Call { destination: Some((_, ref t)), cleanup: None, .. } | Yield { resume: ref t, drop: None, .. } | DropAndReplace { target: ref t, unwind: None, .. } | Drop { target: ref t, unwind: None, .. } | Assert { target: ref t, cleanup: None, .. } | FalseUnwind { real_target: ref t, unwind: None } | InlineAsm { destination: Some(ref t), .. } => Some(t).into_iter().chain(&[]), Call { destination: Some((_, ref t)), cleanup: Some(ref u), .. } | Yield { resume: ref t, drop: Some(ref u), .. } | DropAndReplace { target: ref t, unwind: Some(ref u), .. } | Drop { target: ref t, unwind: Some(ref u), .. } | Assert { target: ref t, cleanup: Some(ref u), .. } | FalseUnwind { real_target: ref t, unwind: Some(ref u) } => { Some(t).into_iter().chain(slice::from_ref(u)) } SwitchInt { ref targets, .. } => None.into_iter().chain(&targets[..]), FalseEdge { ref real_target, ref imaginary_target } => { Some(real_target).into_iter().chain(slice::from_ref(imaginary_target)) } } } pub fn successors_mut(&mut self) -> SuccessorsMut<'_> { use self::TerminatorKind::*; match *self { Resume | Abort | GeneratorDrop | Return | Unreachable | Call { destination: None, cleanup: None, .. } | InlineAsm { destination: None, .. } => None.into_iter().chain(&mut []), Goto { target: ref mut t } | Call { destination: None, cleanup: Some(ref mut t), .. } | Call { destination: Some((_, ref mut t)), cleanup: None, .. } | Yield { resume: ref mut t, drop: None, .. } | DropAndReplace { target: ref mut t, unwind: None, .. } | Drop { target: ref mut t, unwind: None, .. } | Assert { target: ref mut t, cleanup: None, .. } | FalseUnwind { real_target: ref mut t, unwind: None } | InlineAsm { destination: Some(ref mut t), .. } => Some(t).into_iter().chain(&mut []), Call { destination: Some((_, ref mut t)), cleanup: Some(ref mut u), .. } | Yield { resume: ref mut t, drop: Some(ref mut u), .. } | DropAndReplace { target: ref mut t, unwind: Some(ref mut u), .. } | Drop { target: ref mut t, unwind: Some(ref mut u), .. } | Assert { target: ref mut t, cleanup: Some(ref mut u), .. } | FalseUnwind { real_target: ref mut t, unwind: Some(ref mut u) } => { Some(t).into_iter().chain(slice::from_mut(u)) } SwitchInt { ref mut targets, .. } => None.into_iter().chain(&mut targets[..]), FalseEdge { ref mut real_target, ref mut imaginary_target } => { Some(real_target).into_iter().chain(slice::from_mut(imaginary_target)) } } } pub fn unwind(&self) -> Option<&Option<BasicBlock>> { match *self { TerminatorKind::Goto { .. } | TerminatorKind::Resume | TerminatorKind::Abort | TerminatorKind::Return | TerminatorKind::Unreachable | TerminatorKind::GeneratorDrop | TerminatorKind::Yield { .. } | TerminatorKind::SwitchInt { .. } | TerminatorKind::FalseEdge { .. } | TerminatorKind::InlineAsm { .. } => None, TerminatorKind::Call { cleanup: ref unwind, .. } | TerminatorKind::Assert { cleanup: ref unwind, .. } | TerminatorKind::DropAndReplace { ref unwind, .. } | TerminatorKind::Drop { ref unwind, .. } | TerminatorKind::FalseUnwind { ref unwind, .. } => Some(unwind), } } pub fn unwind_mut(&mut self) -> Option<&mut Option<BasicBlock>> { match *self { TerminatorKind::Goto { .. } | TerminatorKind::Resume | TerminatorKind::Abort | TerminatorKind::Return | TerminatorKind::Unreachable | TerminatorKind::GeneratorDrop | TerminatorKind::Yield { .. } | TerminatorKind::SwitchInt { .. } | TerminatorKind::FalseEdge { .. } | TerminatorKind::InlineAsm { .. } => None, TerminatorKind::Call { cleanup: ref mut unwind, .. } | TerminatorKind::Assert { cleanup: ref mut unwind, .. } | TerminatorKind::DropAndReplace { ref mut unwind, .. } | TerminatorKind::Drop { ref mut unwind, .. } | TerminatorKind::FalseUnwind { ref mut unwind, .. } => Some(unwind), } } } 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![], } } } </ins>

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: //! //! * Should probably have something like this for strings. //! * Should they implement Closable? Would take extra state. <ins> use cmp::max; </ins> use cmp::min; use prelude::*; use super::*;

Currently all of its functions immediately . We need to either remove this or implement it. I vote for implementing it.


Question: <ins> #![feature(intrinsics)] extern "C" { pub static FOO: extern "rust-intrinsic" fn(); } fn main() { FOO() //~ ERROR: use of extern static is unsafe } </ins>

rustc+cargo 1.40.0 Debian testing packages report the following ICE (which does not go away after a cargo clean): It can be reproduced by trying to build against
Can you try this on nightly?
Once the ICEBreakers-CleanupCrew is announced (which I think will be happening very soon), we should advertise this bug on it (at least the reduction to MCVE part of it); see
triage: P-high for initial investigation (i.e. identifying actual severity), removing nomination.
ping icebreakers-cleanup-crew
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rust- cc
Note that when I had a go at building on my Mac laptop, it failed with this message: This is due to in the source crate: So if you are on a Mac laptop, it may or may not be worth your effort to investigate this. (It is probably easy to work around, but I figure I'd let people know up front.)
Oops, right, you'll want to just drop that line. It shouldn't have any other effect, its only there due to (at least previously, based on my super-cursory read) libstd calling regular fsync() on OSX, which historically, well, didn't fsync.
I looked at this a bit more. I see the ICE on stable and beta. I do not see the ICE on nightly.


Question: <ins> #![feature(intrinsics)] extern "C" { pub static FOO: extern "rust-intrinsic" fn(); } fn main() { FOO() //~ ERROR: use of extern static is unsafe } </ins>

On nightly, I instead get the following error: <details<summaryClick here to see error diagnostics</summary</details
Possibly associated: Possibly associated: I am not seeing the ICE in: searched nightlies: from nightly-2019-10-01 to nightly-2019-11-01 regressed nightly: nightly-2019-10-08 searched commits: from to regressed commit: source code: built against <details<summaryCOLLAPSIBLE ERROR STACKTRACE</summary<p</detailssearched nightlies: from nightly-2019-11-01 to nightly-2020-01-31 fixed nightly: nightly-2019-12-08 searched commits: from to fix commit: source code: built against Possibly here: -
Reduced for in the crate (still depends on ):
This is happening somewhere in item-bodies checking, if I remove the body of with the error goes away.
Ok, I don't have more time to spend on this, I pushed some deletions to
Got it down to two files, but they have to be in different crates: : :
A little smaller: : : <details<summarybacktrace</summary</details
This is a duplicate of , judging by the error message and the fact that I just confirmed as the fixing commit for the reduced example that I created over there. modify labels to -E-needs-mcve.


Question: <ins> #![feature(intrinsics)] extern "C" { pub static FOO: extern "rust-intrinsic" fn(); } fn main() { FOO() //~ ERROR: use of extern static is unsafe } </ins>

Take the following code: Attempting to compile this results in the following: I think the compiler should fail with something along the lines of "you attempted to use a complex type () where I expected an immediate".
edit: not sure if these symptoms are the same, but here's what I stumbled across. The following code generates a similar result for me: The and struct seem to be required, else the ICE is not triggered. Output
No longer reproduces:


Question: <ins> #![feature(intrinsics)] extern "C" { pub static FOO: extern "rust-intrinsic" fn(); } fn main() { FOO() //~ ERROR: use of extern static is unsafe } </ins>

We handle intrinsics in an odd way, we "inline" them in the current crate, and this might be a symptom of that twisted logic.
intrinsic-ABI functions should probably be disallowed as function pointers. That is, you should only be allowed to call them. This is the current situation, as calls to intrinsics actually just generate code at the call site.
That's not the problem, really, I believe we already have code to generate the shims. The problem is that we don't resolve intrinsics sanely and we rely on the ABI in the type, instead of always dealing with the paths to them and whatnot.
I don't think we have code for creating the shims, even. It's more that the ABI isn't actually defined anywhere, and we use an alternate callee to avoid generating an actual call.
We haven't had code for generating shims around intrinsics for a long time. As alludes to, this is because in almost all cases the actual function would be one or two instructions long. This is consistent with how C/C++ compilers handle intrinsics, generating code inline. Best I can tell, whether or not a given intrinsic can be used as a function in C is dependent on the intrinsic in question.
No longer ICEs ()
It requires now.
Ah, ok. Still no longer ICEs, but fails with a linker error (), if the distinction matters.
I think this has been fixed -- marking as E-needstest. Did you mean to self-assign this?
This seems like it could be made into an easy issue for newcomers.
This is now caught by .


Question: <ins> #![feature(intrinsics)] extern "C" { pub static FOO: extern "rust-intrinsic" fn(); } fn main() { FOO() //~ ERROR: use of extern static is unsafe } </ins>

rustc just crashes with no useful errors. I guess you're not supposed to be able to do this anyway and it works if either are const instead of static but it shouldn't crash. Tested with latest nightly and 1.0.0-beta.2 on windows 64-bit.
No longer crashes:
E-needstest.
Triage: not aware of any tests being .
It seems that the E0394 error was removed in and the tests were moved from compile-fail and ui/error-codes to run-pass.


Question: <del> use std::iter; </del> use either::Either; <ins> use hir::PatField; </ins> use rustc_data_structures::captures::Captures; use rustc_data_structures::fx::FxIndexSet; use rustc_errors::{

<!-- 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: <del> use std::iter; </del> use either::Either; <ins> use hir::PatField; </ins> use rustc_data_structures::captures::Captures; use rustc_data_structures::fx::FxIndexSet; use rustc_errors::{

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: <ins> error[E0371]: the object type `(dyn Object + Marker2 + 'static)` automatically implements the trait `Marker1` --> $DIR/coherence-impl-trait-for-marker-trait-positive.rs:14:1 | LL | impl Marker1 for dyn Object + Marker2 { }   //~ ERROR E0371 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `(dyn Object + Marker2 + 'static)` automatically implements trait `Marker1` error[E0371]: the object type `(dyn Object + Marker2 + 'static)` automatically implements the trait `Marker2` --> $DIR/coherence-impl-trait-for-marker-trait-positive.rs:16:1 | LL | impl Marker2 for dyn Object + Marker2 { }   //~ ERROR E0371 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `(dyn Object + Marker2 + 'static)` automatically implements trait `Marker2` error[E0117]: only traits defined in the current crate can be implemented for arbitrary types --> $DIR/coherence-impl-trait-for-marker-trait-positive.rs:22:1 | LL | unsafe impl Send for dyn Marker2 {} //~ ERROR E0117 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ impl doesn't use types inside crate | = note: the impl does not reference only types defined in this crate = note: define and implement a trait or new type instead error[E0321]: cross-crate traits with a default impl, like `std::marker::Send`, can only be implemented for a struct/enum type, not `(dyn Object + 'static)` --> $DIR/coherence-impl-trait-for-marker-trait-positive.rs:26:1 | LL | unsafe impl Send for dyn Object {} //~ ERROR E0321 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ can't implement cross-crate trait with a default impl for non-struct/enum type error[E0321]: cross-crate traits with a default impl, like `std::marker::Send`, can only be implemented for a struct/enum type, not `(dyn Object + Marker2 + 'static)` --> $DIR/coherence-impl-trait-for-marker-trait-positive.rs:27:1 | LL | unsafe impl Send for dyn Object + Marker2 {} //~ ERROR E0321 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ can't implement cross-crate trait with a default impl for non-struct/enum type error: aborting due to 5 previous errors Some errors occurred: E0117, E0321, E0371. For more information about an error, try `rustc --explain E0117`. </ins>

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


Question: E0696, // `continue` pointing to a labeled block //  E0702, // replaced with a generic attribute input check E0703, // invalid ABI <del> E0706, // `async fn` in trait </del> //  E0707, // multiple elided lifetimes used in arguments of `async fn` E0708, // `async` non-`move` closures with parameters are not currently // supported

we currently emit We should tell people that trait functions are not possible , and possibly point them to . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Created


Question: stride * field } layout::FieldPlacement::Union(count) => { <ins> // This is a narrow bug-fix for rust-lang/rust#69191: if we are // trying to access absent field of uninhabited variant, then // signal UB (but don't ICE the compiler). // FIXME temporary hack to work around incoherence between // layout computation and MIR building if field >= count as u64 && base.layout.abi == layout::Abi::Uninhabited { throw_ub!(Unreachable); } </ins> assert!( field < count as u64, "Tried to access field {} of union {:#?} with {} fields",

cc I suspect (but have not verified) that this would be fixed by a backport of
was merged in October, I don't think it's related
Does this need an mcve?
Yeah, but I think at this point a bisection might be more helpful since we're not yet sure what caused this.
Here's a somewhat small-ish MCVE: Haven't managed to remove mio yet, but that's just a matter of time ;) Note, that this doesn't depend on the feature. You can use as well.
Here's a "M"CVE without any dependencies: regression in nightly-2020-01-11 <details<summaryBacktrace</summary</details modify labels: -E-needs-bisection -E-needs-mcve
searched nightlies: from nightly-2019-11-01 to nightly-2020-02-16 regressed nightly: nightly-2020-01-11 searched commits: from to regressed commit: source code: Reproduce bisection with: <details<summaryCOLLAPSIBLE ERROR STACKTRACE</summary<p</p</details<details<summaryERROR BEFORE ICE REGRESSION</summary<p</p</details
It would be good to continue the bisection into the rollup PR, among the following PRs: (Point at opaque and closure type definitions in type errors) (Reduce special treatment for zsts) (Parse the syntax described in RFC 2632) (rustcastlowering: misc cleanup & rustc dep reductions) (Extend support of in type parameters) (expect after / )
triage: P-high, removing nomination, assigning to self.
Given the backtrace, I think it's probably (Reduce special treatment for zsts)
I can indeed reproduce the ICE at , seems to be the culprit. cc <details<summaryBacktrace</summary</details
Here is a more minimal MCVE: /me needs to invest some time in tools like rust-reduce or creduce...
Okay so now we have two different PR's to fix this. PR is almost certainly the right call for nightly itself. My only Question is whether we should also land PR and also then backport that to beta. My argument for why is that it is "obviously" less risky, which is important because the beta is going to be imminently promoted to stable.


Question: //! [`Iterator`]: trait.Iterator.html //! [`next`]: trait.Iterator.html#tymethod.next //! [`Option`]: ../../std/option/enum.Option.html <ins> //! [`TryIter`]: ../../std/sync/mpsc/struct.TryIter.html </ins> //! //! # The three forms of iteration //!

If the wrapped iterator implements then blindly delegates to it. The underlying iterator may know its exact size but return spurious results anyway, on which will stop iterating even though the source knows that there are elements left to iterate, meaning will indicate that there are elements left but never return them. The behavior was introduced in but didn't see any discussion.
Implementations of have soundness implications, thus marking as . That being said, the documentation for is fairly exact in its wording that the first means "end of iteration".
Hm, seeing as is not an unsafe trait, I would not expect code to be able to rely on it for soundness? Maybe we do so internally for std types though...
Unsafe code can't rely on correctness (there's for that). The length of an iterator is defined as the number of items yielded before it returns None, so Fuse's implementation is correct.
Oh my bad, I was confusing it with TrustedLen.
Ok, makes sense. But I will be pedantic here since I prefer documentation to have slightly more formal flavor. docs: The module documentation: Now resume can be interpreted as continuing the the previous iteration instead of starting a new iteration (conceptually a new iteration would require a new iterator then). Under this interpretation should report the complete length of all iteration including possible resumptions which must be known when claiming exact sizing knowledge. The documentation could use a more precise definition of what an iteration is and that resumption is really considered a new iteration.


Question: <ins> error[E0229]: associated type bindings are not allowed here --> $DIR/issue-102335-const.rs:4:17 | LL |     type A: S<C<X = 0i32> = 34>; |                 ^^^^^^^^ associated type not allowed here error: aborting due to previous error For more information about this error, try `rustc --explain E0229`. </ins>

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


Question: If you’d like to dive into this topic in greater detail, [this paper][wilson] is a great introduction. <del> [wilson]: http://www.cs.northwestern.edu/~pdinda/icsclass/doc/dsa.pdf </del> <ins> [wilson]: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.143.4688 </ins> ## Semantic impact

I've come across quite a few broken links just while browsing the online documentation generated by rustdoc (particularly when clicking on links from search results). There are already issues relating to specific cases, but perhaps there should be a catch-all test on the output of rustdoc to check that all generated hyperlinks are valid?
The problem with things like this is that services that go down then break your build. We did this for Rust By Example, but then a bad deploy caused the whole site to 404, and we couldn't bring it back up because the site was 404'ing :wink: Specific cases should be looked into, and bugs should get filed, for sure, but running checks like this takes about an hour and a half, I've done it with linkchecker.
I was thinking more of something which ran on the files offline - it can ignore external urls, but just check that internal urls point to a file that was actually generated. That wouldn't be affected by anything outside the current build.
Also, rather than using , which – as is saying – usually is not an expedient process, we could have record all the URLs produced when generating the HTML and then validate them against the directory structure.
One example: From Link is broken.
That's due to a Rustdoc... Mis-feature, for which we already have a bug open.
Another instance of a broken link is found in It says where 'this paper' is a dead link to
So, I'm going to give this bug a close. If there are specific things that are causing to generate invalid links, they should be filed as bugs, and if there are specific, manually linked links that are wrong, they should have a bug, but I don't see under what conditions this bug will ever get closed.


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. // error-pattern:bad input fn main() { Some("foo").unwrap_or(fail!("bad input")).to_string(); } </ins>

Here is the error Here is the code that generates the error My system is x86_64 archlinux. The rust compiler version is Let me know if you guys need anything else. (The code is really short so it shouldn't be hard to just type it in to duplicate the bug)
It only needs one line for me
Workaround (in the sense that the compiler no longer ICE's): I think there is some unfortunate interaction here with the way we attempt to infer which kind of numeric literals are in the array (, , etc) and other code not being prepared to handle the that results when you don't have that information available.
This is almost certainly a duplicate of (but maybe the integer inference codepath is slightly different?).
This also causes the same ICE -
Similarly:
Looks like it's been fixed.


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. // error-pattern:bad input fn main() { Some("foo").unwrap_or(fail!("bad input")).to_string(); } </ins>

Swapping the order of the branches compiles fine. cc
Just checked: this fails with a normal closure too, not just a proc.
Compiles fine now but potentially needs a test.


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. // error-pattern:bad input fn main() { Some("foo").unwrap_or(fail!("bad input")).to_string(); } </ins>

Versions: Code to reproduce the ICE: Compilation output:
Seems to be fine now but potentially needs a test.
Nope, still failing. An updated example:
That code example fails to compile, but it's because the function signature for is wrong. It should be: When you make that change and make the struct fields public, the code compiles fine. Without the change I also didn't see any internal compiler errors. Rust Version: 0.12.0-pre-nightly, , Linux x8664
Yeah, I think this can be closed.
Flagging as needstest (not sure if one is checked in already)


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. // error-pattern:bad input fn main() { Some("foo").unwrap_or(fail!("bad input")).to_string(); } </ins>

It gives
cc
Looks like it no longer causes an ICE.
I agree, it is fixed, I close it.


Question: } #[test] <del> #[cfg_attr(any(target_os = "vxworks", target_os = "android"), ignore)] </del> <ins> #[cfg_attr(any(target_os = "vxworks"), ignore)] </ins> fn test_process_output_output() { let Output { status, stdout, stderr } = if cfg!(target_os = "windows") { Command::new("cmd").args(&["/C", "echo hello"]).output().unwrap() } else { <del> Command::new("echo").arg("hello").output().unwrap() </del> <ins> shell_cmd().arg("-c").arg("echo hello").output().unwrap() </ins> }; let output_str = str::from_utf8(&stdout).unwrap();

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> #![feature(prelude_import)] #![no_std] // This test certify that we can mix attribute macros from Rust and external proc-macros. // For instance, `#[derive(Default)]` uses `#[default]` and `#[derive(SmartPointer)]` uses // `#[pointee]`. // The scoping rule should allow the use of the said two attributes when external proc-macros // are in scope. //@ check-pass //@ aux-build: another-proc-macro.rs //@ compile-flags: -Zunpretty=expanded #![feature(derive_smart_pointer)] #[prelude_import] use ::std::prelude::rust_2015::*; #[macro_use] extern crate std; #[macro_use] extern crate another_proc_macro; const _: () = { const POINTEE_MACRO_ATTR_DERIVED: () = (); }; const _: () = { const DEFAULT_MACRO_ATTR_DERIVED: () = (); }; </ins>

https://crater- https://crater- cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc
label F-derivesmartpointer
Thread on zulip: https://rust-
claim
WG-prioritization assigning priority (). label -I-prioritize +P-high


Question: } fn write_u16s(handle: c::HANDLE, data: &[u16]) -> io::Result<usize> { <ins> debug_assert!(data.len() < u32::MAX as usize); </ins> let mut written = 0; cvt(unsafe { c::WriteConsoleW(

(and similarly, should call ) Windows provides these nice functions which performantly implement utf-8 <-utf-16 conversions. We should probably call them in the standard library when possible.
Do we get measurable performance wins that make calling more unsafe C APIs worth it? Especially with the inlining barrier across languages. And I would assume console printing is bottlenecked on the console rendering part anyway, not on string conversions.
Do we have any good benchmarks for console I/O perf?
A simple main writing 100MB worth of lines to stdout and measuring the time it takes should do?
For sure. I was just wondering if we had something already. I mean, we'd probably want to be testing a few different languages as well to make sure we're not just optimizing for ASCII only.
I don't think we do because most benchmarks suppress console output.
I did do a benchmark, and interestingly, ASCII text was about twice as fast with as with rust-native code; however, Chinese text was slightly slower. Given that most of the actual cost of printing to the screen is in the actual printing, I no longer think it's a good idea to do this. See benchmarks at [strega-nil/rust-bench-cvt-utf8-utf16][]. [strega-nil/rust-bench-cvt-utf8-utf16]: Run on M1 chip: someone may want to check on an x64 chip, since that might be faster.
Just to check my understanding: The utf16 conversion only happens when one writes to an actually rendered console. There isn't some stuff like virtual consoles that act more like NUL where speeding up the conversion could help because the data will be discarded by the OS. And output to files is binary anyway.
There are now (since Windows 10, 1809) which are consoles without the rendering part. Though the intent would be for the rendering to be implemented by another program, it would also be possible to skip or delay (e.g. by writing a log) rendering.
In that case a speedup may be useful, but is the optimization potential of the built-in conversion already squeezed dry?
yeah, I think it's unlikely that the complexity is worth it given what the benchmarks show; I would really appreciate if someone ran the benchmark on x64, since it may be that Windows implements faster algorithms on that platform.


Question: } fn write_u16s(handle: c::HANDLE, data: &[u16]) -> io::Result<usize> { <ins> debug_assert!(data.len() < u32::MAX as usize); </ins> let mut written = 0; cvt(unsafe { c::WriteConsoleW(

I don't think anyone has worked on optimizing this so I'm sure there's plenty of optimization potential. The results from I got from an AMD Ryzen 5 3600 machine are:
Mmh, thanks I'll also push some benchmarks for testing other cases later, since there are plenty of other cases than just "bulk-converting a bunch of text". Thanks! Nicole


Question: /// [`slice_from_raw_parts`]: fn.slice_from_raw_parts.html /// [`from_raw_parts_mut`]: ../../std/slice/fn.from_raw_parts_mut.html #[inline] <del> #[unstable(feature = "slice_from_raw_parts", reason = "recently added", issue = "36925")] </del> <ins> #[stable(feature = "slice_from_raw_parts", since = "1.42.0")] </ins> #[rustc_const_unstable(feature = "const_slice_from_raw_parts", issue = "67456")] pub const fn slice_from_raw_parts_mut<T>(data: *mut T, len: usize) -> *mut [T] { unsafe { Repr { raw: FatPtr { data, len } }.rust_mut }

In stable Rust, the only way to get a with an arbitrary length is through . Unfortunately, that function returns a , which makes it very dubious to use with arbitrary raw pointers.
Given that isn't defined for , what would be the value of being able to create ?
Why would you want one, but also, this seems like it depends on (yet to be decided?) details of the memory model. Is the fleeting moment where a reference exists in enough to invoke UB if the pointer is invalid?
If the reference is , then this is insta-UB for sure.
Is there anything holding [] from stabilizing? If not, I'd like to propose stabilization of these functions, as they are rather simple in concept and allow avoiding manifesting references during (slice) pointer manipulation. cc If I'm reading the various issue threads correctly, the validity invariant of pointer metadata is at max that of the metadata type. For slice pointers, the metadata is typed at . Context: I happen to currently be writing a library that cannot use the reference-based functions, because though the pointers are known to be non-null (and valid), it is not (and cannot be, with the current abstraction) known whether the pointer has unique or shared provenance (thus should use or to be sound). (Specifically, I'm now adding the bits required to handle erasing slice types. I can bifurcate my function into and , but so far, it works fine with one operating over , and it'd be sad to have the / split hanging around even after these functions stabilize (assuming they can)).
I don't recall any reason that cannot be stabilized.
The implementation PR used this feature requested as a tracking issue, but this wasn’t labelled properly. Doing so now.
By the way, would also cover this :)


Question: <del> error: expected expression, found reserved keyword `try` --> $DIR/try-block-in-match.rs:6:11 | LL |     match try { false } { _ => {} } |     ----- ^^^ expected expression |     | |     while parsing this match expression error: aborting due to previous error </del>

This produces a lint: But removing the parentheses produces an error. This bug was already mentioned in , but that issue is lost in feature-request purgatory since it asks for the version without parentheses to be allowed. I'm opening this issue to track the incorrect lint specifically. (Edit: Fixed the example.) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim Will wait for to get merged before this is fixed though.


Question: <del> error: expected expression, found reserved keyword `try` --> $DIR/try-block-in-match.rs:6:11 | LL |     match try { false } { _ => {} } |     ----- ^^^ expected expression |     | |     while parsing this match expression error: aborting due to previous error </del>

The following code fails to compile (): The compiler error is: Adding parentheses or braces, it will compile fine: The same issue happens with other constructs such as:
cc
I believe the error is expected here, the same as with : Which also needs to be to compile. That said, the warning to remove the necessary parens is definitely wrong. EDIT: Hmm, I might be wrong, actually. The following compiles, which surprised me: as does this: So maybe the parser restriction is only for struct literals, not for keyword-introduced expressions.
Yeah I think is the better comparison here so it's probably a bug.
This is exactly what a thought. I didn't know that this:
For , hmmm... well, I can't come up with a truly devastating example, but eliminating the parentheses could hurt diagnostics.


Question: } #[test] <del> #[cfg_attr(any(target_os = "vxworks", target_os = "android"), ignore)] </del> <ins> #[cfg_attr(any(target_os = "vxworks"), ignore)] </ins> fn stdout_works() { if cfg!(target_os = "windows") { let mut cmd = Command::new("cmd"); cmd.args(&["/C", "echo foobar"]).stdout(Stdio::piped()); assert_eq!(run_output(cmd), "foobarrn"); } else { <del> let mut cmd = Command::new("echo"); cmd.arg("foobar").stdout(Stdio::piped()); </del> <ins> let mut cmd = shell_cmd(); cmd.arg("-c").arg("echo foobar").stdout(Stdio::piped()); </ins> assert_eq!(run_output(cmd), "foobarn"); } } #[test] <del> #[cfg_attr(any(windows, target_os = "android", target_os = "vxworks"), ignore)] </del> <ins> #[cfg_attr(any(windows, target_os = "vxworks"), ignore)] </ins> fn set_current_dir_works() { <del> let mut cmd = Command::new("/bin/sh"); </del> <ins> let mut cmd = shell_cmd(); </ins> cmd.arg("-c").arg("pwd").current_dir("/").stdout(Stdio::piped()); assert_eq!(run_output(cmd), "/n"); } #[test] <del> #[cfg_attr(any(windows, target_os = "android", target_os = "vxworks"), ignore)] </del> <ins> #[cfg_attr(any(windows, target_os = "vxworks"), ignore)] </ins> fn stdin_works() { <del> let mut p = Command::new("/bin/sh") </del> <ins> let mut p = shell_cmd() </ins> .arg("-c") .arg("read line; echo $line") .stdin(Stdio::piped())


Question: <ins> // Regression test for #81899. // The `panic!()` below is important to trigger the fixed ICE. const _CONST: &[u8] = &f(&[], |_| {}); const fn f<F>(_: &[u8], _: F) -> &[u8] where F: FnMut(&u8), { panic!() //~ ERROR: evaluation of constant value failed } fn main() {} </ins>

The following code causes compiler panics due to the first line without which the issue isn't reproducible. Calling the function outside of a constant context emits the right compiler errors. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <details<summary<strongBacktrace</strong</summary<p</p</details
FWIW, replacing the function body with still gives an ICE:
Minimized slightly further, without const generics: <details<summarybacktrace</summary</detailsThe ICE occurs back to . In , it errors with By making small changes such as making the closure no longer take paramters or removing the reference at It errors, instead of an ICE, on stable and nightly with
searched nightlies: from nightly-2020-08-16 to nightly-2021-02-03 regressed nightly: nightly-2020-12-28 searched commits: from to regressed commit: edit: for this code sample <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with:
cc
Just to clarify, AFAICT, this issue is not due to , the stabilization just allowed code with const generics to run into this. MCVE ICEs before and shows that this is a borrowck bug not related to const generics
Assigning as discussed as part of the and removing .
I'm not sure if this is identical problem or not. The error message is: and my code is: I need both parts or the COPY tuple for the error to trigger and I'm unsure why. And also, if I put in its own const the bug is not triggered.
Triage: No longer ICE with the latest nightly, I guess fixed it? Marking as .


Question: use rustc_middle::ty::{ self, fold::BottomUpFolder, print::TraitPredPrintModifiersAndPath, Ty, TypeFoldable, }; <del> use rustc_span::Span; </del> <ins> use rustc_span::{symbol::kw, Span}; </ins> use rustc_trait_selection::traits; use rustc_trait_selection::traits::query::evaluate_obligation::InferCtxtExt;

When using the flag, I stumbled upon a warning that I don't understand and assume to be a bug/missed implementation. If this is the intended behavior, could anyone please explain why? This is simplified code that generates the warning: But when adding a type restriction on self (in this case Sized)_ the warning does not appear anymore. <!-- 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 is in fact a bug.
Update: This issue is still present, and has now sneaked into stable with the release of ; as such I'm updating the title to reflect that.
This is similar to the bug report
This isn't the same bug. This just has to do with a false warning of the lint.
on this, also encountering this bug
Also encountering with


Question: fn the(&self); } } <ins> #[cfg(any())] mod nonexistent_file; // Check that unconfigured non-inline modules are not loaded or parsed. </ins>

This fails on stable because rust still parses the unstable module: It's possible to work around this by conditionally defining a macro and then having the macro define the module but that's a bit messy:
Or implement the module in another file. I think this is a fundamental limitation -- you can't skip forward over an item if you don't understand the syntax that the item is using. The only way we could solve it is with time travel, i.e., doing a point release of stable that knows the syntax but not what it means.
That's actually what I'm doing in my project (still the same problem). That is, I have the following in my : And a module,
Modules are parsed before 's are parsed, which has been an issue for as long as I can remember. Can someone find whether there is an issue tracking this?
Dupe of . cc ( expert!)
Though this'll be fixed by the above PR, the workaround for current stable is


Question: fn the(&self); } } <ins> #[cfg(any())] mod nonexistent_file; // Check that unconfigured non-inline modules are not loaded or parsed. </ins>

The ABI string for is validated while being parsed, meaning one can get errors about in 'd off modules: (Compiled without .) This isn't necessarily wrong, but it is weird and somewhat annoying if one needs it. (It can be worked-around by hiding the block behind a macro: .)
Any ideas where we could move the check into? Any of borrowck, typeck, lints, privacy and resolve don’t exactly fit. I think trans thematically is the best place to have it, but it is a shame to have it error out so late for such an easy to detect and obvious error. I’m personally fine keeping it a parse error, IMO there’s no reason to have cfg blocks with code that does not compile.
NB. we can add a special pass if necessary (i.e. there's no reason for us to compromise by putting the error in trans). Yeah, of course. However, there are cases when the d code does compile, e.g. I encountered this in where I an ABI and had to use it in inside a module. Similarly, if we add ABIs in future, someone might have code designed to compile with Rust 1.0.0, but can take advantage of the newer ABI if it is available.
The block might be to gate nightly-only code. The code within the gated block is compiled only when a cargo feature is enabled; the code outside it works both on stable and nightly. I hit it myself; I'm playing with the SIMD work from pull request, but I want to keep the crate working on stable. .


Question: (&TestKind::Range { .. }, _) => None, (&TestKind::Eq { .. } | &TestKind::Len { .. }, _) => { <ins> // The call to `self.test(&match_pair)` below is not actually used to generate any // MIR. Instead, we just want to compare with `test` (the parameter of the method) // to see if it is the same. // // However, at this point we can still encounter or-patterns that were extracted // from previous calls to `sort_candidate`, so we need to manually address that // case to avoid panicking in `self.test()`. if let PatKind::Or { .. } = &*match_pair.pattern.kind { return None; } </ins> // These are all binary tests. // // FIXME(#29623) we can be more clever here

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


Question: <ins> // Copyright 2014-2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. //! Scoped thread-local storage //! //! This module provides the ability to generate *scoped* thread-local //! variables. In this sense, scoped indicates that thread local storage //! actually stores a reference to a value, and this reference is only placed //! in storage for a scoped amount of time. //! //! There are no restrictions on what types can be placed into a scoped //! variable, but all scoped variables are initialized to the equivalent of //! null. Scoped thread local storage is useful when a value is present for a known //! period of time and it is not required to relinquish ownership of the //! contents. //! //! # Examples //! //! ``` //! # #![feature(scoped_tls)] //! scoped_thread_local!(static FOO: u32); //! //! // Initially each scoped slot is empty. //! assert!(!FOO.is_set()); //! //! // When inserting a value, the value is only in place for the duration //! // of the closure specified. //! FOO.set(&1, || { //!     FOO.with(|slot| { //!         assert_eq!(*slot, 1); //!     }); //! }); //! ``` #![unstable(feature = "thread_local_internals")] use prelude::v1::*; // macro hygiene sure would be nice, wouldn't it? #[doc(hidden)] pub mod __impl { pub use super::imp::KeyInner; pub use sys_common::thread_local::INIT as OS_INIT; } /// Type representing a thread local storage key corresponding to a reference /// to the type parameter `T`. /// /// Keys are statically allocated and can contain a reference to an instance of /// type `T` scoped to a particular lifetime. Keys provides two methods, `set` /// and `with`, both of which currently use closures to control the scope of /// their contents. #[unstable(feature = "scoped_tls", reason = "scoped TLS has yet to have wide enough use to fully consider  stabilizing its interface")] pub struct ScopedKey<T> { #[doc(hidden)] pub inner: __impl::KeyInner<T> } /// Declare a new scoped thread local storage key. /// /// This macro declares a `static` item on which methods are used to get and /// set the value stored within. #[macro_export] #[allow_internal_unstable] macro_rules! scoped_thread_local { (static $name:ident: $t:ty) => ( __scoped_thread_local_inner!(static $name: $t); ); (pub static $name:ident: $t:ty) => ( __scoped_thread_local_inner!(pub static $name: $t); ); } #[macro_export] #[doc(hidden)] #[allow_internal_unstable] macro_rules! __scoped_thread_local_inner { (static $name:ident: $t:ty) => ( #[cfg_attr(not(any(windows, target_os = "android", target_os = "ios", target_os = "openbsd", target_arch = "aarch64")), thread_local)] static $name: ::std::thread::ScopedKey<$t> = __scoped_thread_local_inner!($t); ); (pub static $name:ident: $t:ty) => ( #[cfg_attr(not(any(windows, target_os = "android", target_os = "ios", target_os = "openbsd", target_arch = "aarch64")), thread_local)] pub static $name: ::std::thread::ScopedKey<$t> = __scoped_thread_local_inner!($t); ); ($t:ty) => ({ use std::thread::ScopedKey as __Key; #[cfg(not(any(windows, target_os = "android", target_os = "ios", target_os = "openbsd", target_arch = "aarch64")))] const _INIT: __Key<$t> = __Key { inner: ::std::thread::__scoped::KeyInner { inner: ::std::cell::UnsafeCell { value: 0 as *mut _ }, } }; #[cfg(any(windows, target_os = "android", target_os = "ios", target_os = "openbsd", target_arch = "aarch64"))] const _INIT: __Key<$t> = __Key { inner: ::std::thread::__scoped::KeyInner { inner: ::std::thread::__scoped::OS_INIT, marker: ::std::marker::PhantomData::<::std::cell::Cell<$t>>, } }; _INIT }) } #[unstable(feature = "scoped_tls", reason = "scoped TLS has yet to have wide enough use to fully consider  stabilizing its interface")] impl<T> ScopedKey<T> { /// Insert a value into this scoped thread local storage slot for a /// duration of a closure. /// /// While `cb` is running, the value `t` will be returned by `get` unless /// this function is called recursively inside of `cb`. /// /// Upon return, this function will restore the previous value, if any /// was available. /// /// # Examples /// /// ``` /// # #![feature(scoped_tls)] /// scoped_thread_local!(static FOO: u32); /// /// FOO.set(&100, || { ///     let val = FOO.with(|v| *v); ///     assert_eq!(val, 100); /// ///     // set can be called recursively ///     FOO.set(&101, || { ///         // ... ///     }); /// ///     // Recursive calls restore the previous value. ///     let val = FOO.with(|v| *v); ///     assert_eq!(val, 100); /// }); /// ``` pub fn set<R, F>(&'static self, t: &T, cb: F) -> R where F: FnOnce() -> R, { struct Reset<'a, T: 'a> { key: &'a __impl::KeyInner<T>, val: *mut T, } #[unsafe_destructor] impl<'a, T> Drop for Reset<'a, T> { fn drop(&mut self) { unsafe { self.key.set(self.val) } } } let prev = unsafe { let prev = self.inner.get(); self.inner.set(t as *const T as *mut T); prev }; let _reset = Reset { key: &self.inner, val: prev }; cb() } /// Get a value out of this scoped variable. /// /// This function takes a closure which receives the value of this /// variable. /// /// # Panics /// /// This function will panic if `set` has not previously been called. /// /// # Examples /// /// ```no_run /// # #![feature(scoped_tls)] /// scoped_thread_local!(static FOO: u32); /// /// FOO.with(|slot| { ///     // work with `slot` /// }); /// ``` pub fn with<R, F>(&'static self, cb: F) -> R where F: FnOnce(&T) -> R { unsafe { let ptr = self.inner.get(); assert!(!ptr.is_null(), "cannot access a scoped thread local  variable without calling `set` first"); cb(&*ptr) } } /// Test whether this TLS key has been `set` for the current thread. pub fn is_set(&'static self) -> bool { unsafe { !self.inner.get().is_null() } } } #[cfg(not(any(windows, target_os = "android", target_os = "ios", target_os = "openbsd", target_arch = "aarch64")))] mod imp { use std::cell::UnsafeCell; #[doc(hidden)] pub struct KeyInner<T> { pub inner: UnsafeCell<*mut T> } unsafe impl<T> ::marker::Sync for KeyInner<T> { } #[doc(hidden)] impl<T> KeyInner<T> { #[doc(hidden)] pub unsafe fn set(&self, ptr: *mut T) { *self.inner.get() = ptr; } #[doc(hidden)] pub unsafe fn get(&self) -> *mut T { *self.inner.get() } } } #[cfg(any(windows, target_os = "android", target_os = "ios", target_os = "openbsd", target_arch = "aarch64"))] mod imp { use marker; use std::cell::Cell; use sys_common::thread_local::StaticKey as OsStaticKey; #[doc(hidden)] pub struct KeyInner<T> { pub inner: OsStaticKey, pub marker: marker::PhantomData<Cell<T>>, } unsafe impl<T> ::marker::Sync for KeyInner<T> { } #[doc(hidden)] impl<T> KeyInner<T> { #[doc(hidden)] pub unsafe fn set(&self, ptr: *mut T) { self.inner.set(ptr as *mut _) } #[doc(hidden)] pub unsafe fn get(&self) -> *mut T { self.inner.get() as *mut _ } } } #[cfg(test)] mod tests { use cell::Cell; use prelude::v1::*; scoped_thread_local!(static FOO: u32); #[test] fn smoke() { scoped_thread_local!(static BAR: u32); assert!(!BAR.is_set()); BAR.set(&1, || { assert!(BAR.is_set()); BAR.with(|slot| { assert_eq!(*slot, 1); }); }); assert!(!BAR.is_set()); } #[test] fn cell_allowed() { scoped_thread_local!(static BAR: Cell<u32>); BAR.set(&Cell::new(1), || { BAR.with(|slot| { assert_eq!(slot.get(), 1); }); }); } #[test] fn scope_item_allowed() { assert!(!FOO.is_set()); FOO.set(&1, || { assert!(FOO.is_set()); FOO.with(|slot| { assert_eq!(*slot, 1); }); }); assert!(!FOO.is_set()); } } </ins>

I have no idea what's causing this, but on the current nightly, this fails: with "use of unstable library feature 'threadlocalinternals'." Enabling the feature works, but this should be a stable function. Interestingly, tweaking the works: I wonder if it's because there is a (private) sub-module called which has a module-wide marker. Version info:
This change was introduced just recently: I reproduced the problem without using anything thread-related: Commands: Output: If I remove the attribute from the module, the code gives me the error. I mark as stable, then the code compiles. If I instead remove the function, I get the bar error. cc
With merged, is this fixed?
The exact issue at hand has been resolved, but the underlying issue remains. Specifically a module and free-function of the same name but different stability level will cause problems.
Also hit by this; still affecting the nightly for osx right now, but hopefully the next build will include the fix.
Stability is an internal detail. This is unlikely to impact out-of-tree code.


Question: <ins> error: this file contains an un-closed delimiter --> $DIR/issue-58094-missing-right-square-bracket.rs:4:4 | LL | #[Ѕ |  - ^ |  | |  un-closed delimiter error: expected item after attributes --> $DIR/issue-58094-missing-right-square-bracket.rs:4:4 | LL | #[Ѕ |    ^ error: aborting due to 2 previous errors </ins>

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: <ins> error: this file contains an un-closed delimiter --> $DIR/issue-58094-missing-right-square-bracket.rs:4:4 | LL | #[Ѕ |  - ^ |  | |  un-closed delimiter error: expected item after attributes --> $DIR/issue-58094-missing-right-square-bracket.rs:4:4 | LL | #[Ѕ |    ^ error: aborting due to 2 previous errors </ins>

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: <ins> error: this file contains an un-closed delimiter --> $DIR/issue-58094-missing-right-square-bracket.rs:4:4 | LL | #[Ѕ |  - ^ |  | |  un-closed delimiter error: expected item after attributes --> $DIR/issue-58094-missing-right-square-bracket.rs:4:4 | LL | #[Ѕ |    ^ error: aborting due to 2 previous errors </ins>

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: <ins> error: this file contains an un-closed delimiter --> $DIR/issue-58094-missing-right-square-bracket.rs:4:4 | LL | #[Ѕ |  - ^ |  | |  un-closed delimiter error: expected item after attributes --> $DIR/issue-58094-missing-right-square-bracket.rs:4:4 | LL | #[Ѕ |    ^ error: aborting due to 2 previous errors </ins>

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> impl rustc_errors::IntoDiagnosticArg for PolyExistentialTraitRef<'_> { fn into_diagnostic_arg(self) -> rustc_errors::DiagnosticArgValue<'static> { self.to_string().into_diagnostic_arg() } } </ins> #[derive(Copy, Clone, PartialEq, Eq, PartialOrd, Ord, Hash, Debug, TyEncodable, TyDecodable)] #[derive(HashStable)] pub enum BoundVariableKind {

<!-- 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: } let sig = tcx.erase_late_bound_regions(sig); <del> if !sig.output().is_unit() { let r = self.check_type_for_ffi(cache, sig.output()); match r { FfiSafe => {} _ => { return r; } } } </del> for arg in sig.inputs() { <del> let r = self.check_type_for_ffi(cache, *arg); match r { </del> <ins> match self.check_type_for_ffi(cache, *arg) { </ins> FfiSafe => {} <del> _ => { return r; } </del> <ins> r => return r, </ins> } } <del> FfiSafe </del> <ins> let ret_ty = sig.output(); if ret_ty.is_unit() { return FfiSafe; } self.check_type_for_ffi(cache, ret_ty) </ins> } ty::Foreign(..) => FfiSafe,

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: } let sig = tcx.erase_late_bound_regions(sig); <del> if !sig.output().is_unit() { let r = self.check_type_for_ffi(cache, sig.output()); match r { FfiSafe => {} _ => { return r; } } } </del> for arg in sig.inputs() { <del> let r = self.check_type_for_ffi(cache, *arg); match r { </del> <ins> match self.check_type_for_ffi(cache, *arg) { </ins> FfiSafe => {} <del> _ => { return r; } </del> <ins> r => return r, </ins> } } <del> FfiSafe </del> <ins> let ret_ty = sig.output(); if ret_ty.is_unit() { return FfiSafe; } self.check_type_for_ffi(cache, ret_ty) </ins> } ty::Foreign(..) => FfiSafe,

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: .filter_map(|lang_item| self.tcx.lang_items().require(*lang_item).ok()) .collect(); <del> never_suggest_borrow.push(self.tcx.get_diagnostic_item(sym::Send).unwrap()); </del> <ins> if let Some(def_id) = self.tcx.get_diagnostic_item(sym::Send) { never_suggest_borrow.push(def_id); } </ins> let param_env = obligation.param_env; let trait_ref = poly_trait_ref.skip_binder();

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


Question: continue; } <del> let missing = match source { PathSource::Trait(..) | PathSource::TraitItem(..) | PathSource::Type => true, </del> <ins> let node_ids = self.r.next_node_ids(expected_lifetimes); self.record_lifetime_res( segment_id, LifetimeRes::ElidedAnchor { start: node_ids.start, end: node_ids.end }, LifetimeElisionCandidate::Ignore, ); let inferred = match source { PathSource::Trait(..) | PathSource::TraitItem(..) | PathSource::Type => false, </ins> PathSource::Expr(..) | PathSource::Pat | PathSource::Struct <del> | PathSource::TupleStruct(..) => false, </del> <ins> | PathSource::TupleStruct(..) => true, </ins> }; <del> if !missing && !segment.has_generic_args { </del> <ins> if inferred { // Do not create a parameter for patterns and expressions: type checking can infer // the appropriate lifetime for us. for id in node_ids { self.record_lifetime_res( id, LifetimeRes::Infer, LifetimeElisionCandidate::Named, ); } </ins> continue; }

This code: compiles on stable but not on nightly. Error: I bisected it to and then refined it; reverting fixes the issue. This is the cause for
ping since you're the author of the commit
WG-prioritization assigning priority (). label -I-prioritize +P-critical
note: there's a fix in ready for review


Question: move_place: &Place<'tcx>, deref_target_place: &Place<'tcx>, span: Span, <ins> use_spans: Option<UseSpans>, </ins> ) -> DiagnosticBuilder<'a> { // Inspect the type of the content behind the // borrow to provide feedback about why this

gives the error: Error0507 gives a wrong suggestion here:
Error: Label D-invalid-suggestion can only be set by Rust team members Please let know if you're having trouble with this bot.
modify labels: A-suggestion-diagnostics C-bug T-compiler


Question: <ins> // compile-flags: -Znext-solver #![feature(lazy_type_alias)] //~^ WARN the feature `lazy_type_alias` is incomplete trait Foo {} type A<T: Foo> = T; struct W<T>(T); // For `W<A<usize>>` to be WF, `A<usize>: Sized` must hold. However, when assembling // alias bounds for `A<usize>`, we try to normalize it, but it doesn't hold because // `usize: Foo` doesn't hold. Therefore we ICE, because we don't expect to still // encounter weak types in `assemble_alias_bound_candidates_recur`. fn hello(_: W<A<usize>>) {} //~^ ERROR the type `W<A<usize>>` is not well-formed fn main() {} </ins>

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


Question: <ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn main() { let mut c = (1, "".to_owned()); match c { c2 => { c.0 = 2; assert_eq!(c2.0, 1); } } } </ins>

Actually what happens here is the following: The tuple you create in is moved, because it is not . When you perform the you move out of , into , leaving uninitialized. Your assignment to is basically to uninitialized memory, and doesn't have an effect. When you perform the assertion you see the old value of , because your assignment to had no effect. The whole thing is confusing because Rust does not warn when you perform useless assignments to moved variables, and it probably should. The whole thing becomes obviously when you add a statement that uses in the match arm: Edit: the labels you have assigned to this issue are incorrect.
Don't we see the new value , even though we're accessing , when performing the assertion, which causes it to fail? Doing this without a match statement passes the same assertion sucessfully:
Oops, you are correct, I am mistaken :( , mitaa wrote:
heh, I made the same mistake. Typed out most of a response and then realised that I'd mis-read the code.