Question: <ins> fn main() { extern { static symbol: [usize]; //~ ERROR: the size for values of type } println!("{}", symbol[0]); } </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> fn main() { extern { static symbol: [usize]; //~ ERROR: the size for values of type } println!("{}", symbol[0]); } </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> fn main() { extern { static symbol: [usize]; //~ ERROR: the size for values of type } println!("{}", symbol[0]); } </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> fn main() { extern { static symbol: [usize]; //~ ERROR: the size for values of type } println!("{}", symbol[0]); } </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: stabilizing its interface")] impl<T> ScopedKey<T> { #[doc(hidden)] <del> pub const fn new() -> ScopedKey<T> { ScopedKey { inner: imp::KeyInner::new() } </del> <ins> pub const fn new(inner: fn() -> &'static imp::KeyInner<T>) -> ScopedKey<T> { ScopedKey { inner: inner } </ins> } /// Inserts a value into this scoped thread local storage slot for a

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


Question: stabilizing its interface")] impl<T> ScopedKey<T> { #[doc(hidden)] <del> pub const fn new() -> ScopedKey<T> { ScopedKey { inner: imp::KeyInner::new() } </del> <ins> pub const fn new(inner: fn() -> &'static imp::KeyInner<T>) -> ScopedKey<T> { ScopedKey { inner: inner } </ins> } /// Inserts a value into this scoped thread local storage slot for a

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


Question: stabilizing its interface")] impl<T> ScopedKey<T> { #[doc(hidden)] <del> pub const fn new() -> ScopedKey<T> { ScopedKey { inner: imp::KeyInner::new() } </del> <ins> pub const fn new(inner: fn() -> &'static imp::KeyInner<T>) -> ScopedKey<T> { ScopedKey { inner: inner } </ins> } /// Inserts a value into this scoped thread local storage slot for a

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


Question: stabilizing its interface")] impl<T> ScopedKey<T> { #[doc(hidden)] <del> pub const fn new() -> ScopedKey<T> { ScopedKey { inner: imp::KeyInner::new() } </del> <ins> pub const fn new(inner: fn() -> &'static imp::KeyInner<T>) -> ScopedKey<T> { ScopedKey { inner: inner } </ins> } /// Inserts a value into this scoped thread local storage slot for a

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


Question: /// Pushes all the predicates needed to validate that `ty` is WF into `out`. #[instrument(level = "debug", skip(self))] fn compute(&mut self, arg: GenericArg<'tcx>) { <del> let mut walker = arg.walk(); let param_env = self.param_env; let depth = self.recursion_depth; while let Some(arg) = walker.next() { debug!(?arg, ?self.out); let ty = match arg.unpack() { GenericArgKind::Type(ty) => ty, // No WF constraints for lifetimes being present, any outlives // obligations are handled by the parent (e.g. `ty::Ref`). GenericArgKind::Lifetime(_) => continue, GenericArgKind::Const(ct) => { match ct.kind() { ty::ConstKind::Unevaluated(uv) => { if !ct.has_escaping_bound_vars() { let obligations = self.nominal_obligations(uv.def, uv.args); self.out.extend(obligations); let predicate = ty::Binder::dummy(ty::PredicateKind::Clause( ty::ClauseKind::ConstEvaluatable(ct), )); let cause = self.cause(traits::WellFormed(None)); self.out.push(traits::Obligation::with_depth( self.tcx(), cause, self.recursion_depth, self.param_env, predicate, )); } } ty::ConstKind::Infer(_) => { let cause = self.cause(traits::WellFormed(None)); self.out.push(traits::Obligation::with_depth( self.tcx(), cause, self.recursion_depth, self.param_env, ty::Binder::dummy(ty::PredicateKind::Clause( ty::ClauseKind::WellFormed(ct.into()), )), )); } ty::ConstKind::Expr(_) => { // FIXME(generic_const_exprs): this doesn't verify that given `Expr(N + 1)` the // trait bound `typeof(N): Add<typeof(1)>` holds. This is currently unnecessary // as `ConstKind::Expr` is only produced via normalization of `ConstKind::Unevaluated` // which means that the `DefId` would have been typeck'd elsewhere. However in // the future we may allow directly lowering to `ConstKind::Expr` in which case // we would not be proving bounds we should. let predicate = ty::Binder::dummy(ty::PredicateKind::Clause( ty::ClauseKind::ConstEvaluatable(ct), )); let cause = self.cause(traits::WellFormed(None)); self.out.push(traits::Obligation::with_depth( self.tcx(), cause, self.recursion_depth, self.param_env, predicate, )); } ty::ConstKind::Error(_) | ty::ConstKind::Param(_) | ty::ConstKind::Bound(..) | ty::ConstKind::Placeholder(..) => { // These variants are trivially WF, so nothing to do here. } ty::ConstKind::Value(..) => { // FIXME: Enforce that values are structurally-matchable. } } continue; } }; debug!("wf bounds for ty={:?} ty.kind={:#?}", ty, ty.kind()); match *ty.kind() { ty::Bool | ty::Char | ty::Int(..) | ty::Uint(..) | ty::Float(..) | ty::Error(_) | ty::Str | ty::CoroutineWitness(..) | ty::Never | ty::Param(_) | ty::Bound(..) | ty::Placeholder(..) | ty::Foreign(..) => { // WfScalar, WfParameter, etc } // Can only infer to `ty::Int(_) | ty::Uint(_)`. ty::Infer(ty::IntVar(_)) => {} // Can only infer to `ty::Float(_)`. ty::Infer(ty::FloatVar(_)) => {} ty::Slice(subty) => { self.require_sized(subty, traits::SliceOrArrayElem); } ty::Array(subty, _) => { self.require_sized(subty, traits::SliceOrArrayElem); // Note that we handle the len is implicitly checked while walking `arg`. } ty::Tuple(tys) => { if let Some((_last, rest)) = tys.split_last() { for &elem in rest { self.require_sized(elem, traits::TupleElem); } } } ty::RawPtr(_) => { // Simple cases that are WF if their type args are WF. } ty::Alias(ty::Projection, data) => { walker.skip_current_subtree(); // Subtree handled by compute_projection. self.compute_projection(data); } ty::Alias(ty::Inherent, data) => { walker.skip_current_subtree(); // Subtree handled by compute_inherent_projection. self.compute_inherent_projection(data); } ty::Adt(def, args) => { // WfNominalType let obligations = self.nominal_obligations(def.did(), args); self.out.extend(obligations); } ty::FnDef(did, args) => { let obligations = self.nominal_obligations(did, args); self.out.extend(obligations); } ty::Ref(r, rty, _) => { // WfReference if !r.has_escaping_bound_vars() && !rty.has_escaping_bound_vars() { let cause = self.cause(traits::ReferenceOutlivesReferent(ty)); self.out.push(traits::Obligation::with_depth( self.tcx(), cause, depth, param_env, ty::Binder::dummy(ty::PredicateKind::Clause( ty::ClauseKind::TypeOutlives(ty::OutlivesPredicate(rty, r)), )), )); } } ty::Coroutine(did, args, ..) => { // Walk ALL the types in the coroutine: this will // include the upvar types as well as the yield // type. Note that this is mildly distinct from // the closure case, where we have to be careful // about the signature of the closure. We don't // have the problem of implied bounds here since // coroutines don't take arguments. let obligations = self.nominal_obligations(did, args); self.out.extend(obligations); } ty::Closure(did, args) => { // Only check the upvar types for WF, not the rest // of the types within. This is needed because we // capture the signature and it may not be WF // without the implied bounds. Consider a closure // like `|x: &'a T|` -- it may be that `T: 'a` is // not known to hold in the creator's context (and // indeed the closure may not be invoked by its // creator, but rather turned to someone who *can* // verify that). // // The special treatment of closures here really // ought not to be necessary either; the problem // is related to #25860 -- there is no way for us // to express a fn type complete with the implied // bounds that it is assuming. I think in reality // the WF rules around fn are a bit messed up, and // that is the rot problem: `fn(&'a T)` should // probably always be WF, because it should be // shorthand for something like `where(T: 'a) { // fn(&'a T) }`, as discussed in #25860. walker.skip_current_subtree(); // subtree handled below // FIXME(eddyb) add the type to `walker` instead of recursing. self.compute(args.as_closure().tupled_upvars_ty().into()); // Note that we cannot skip the generic types // types. Normally, within the fn // body where they are created, the generics will // always be WF, and outside of that fn body we // are not directly inspecting closure types // anyway, except via auto trait matching (which // only inspects the upvar types). // But when a closure is part of a type-alias-impl-trait // then the function that created the defining site may // have had more bounds available than the type alias // specifies. This may cause us to have a closure in the // hidden type that is not actually well formed and // can cause compiler crashes when the user abuses unsafe // code to procure such a closure. // See tests/ui/type-alias-impl-trait/wf_check_closures.rs let obligations = self.nominal_obligations(did, args); self.out.extend(obligations); } ty::CoroutineClosure(did, args) => { // See the above comments. The same apply to coroutine-closures. walker.skip_current_subtree(); self.compute(args.as_coroutine_closure().tupled_upvars_ty().into()); let obligations = self.nominal_obligations(did, args); self.out.extend(obligations); } ty::FnPtr(_) => { // let the loop iterate into the argument/return // types appearing in the fn signature } ty::Alias(ty::Opaque, ty::AliasTy { def_id, args, .. }) => { // All of the requirements on type parameters // have already been checked for `impl Trait` in // return position. We do need to check type-alias-impl-trait though. if self.tcx().is_type_alias_impl_trait(def_id) { let obligations = self.nominal_obligations(def_id, args); self.out.extend(obligations); } } ty::Alias(ty::Weak, ty::AliasTy { def_id, args, .. }) => { let obligations = self.nominal_obligations(def_id, args); self.out.extend(obligations); } ty::Dynamic(data, r, _) => { // WfObject // // Here, we defer WF checking due to higher-ranked // regions. This is perhaps not ideal. self.from_object_ty(ty, data, r); // FIXME(#27579) RFC also considers adding trait // obligations that don't refer to Self and // checking those let defer_to_coercion = self.tcx().features().object_safe_for_dispatch; if !defer_to_coercion { if let Some(principal) = data.principal_def_id() { self.out.push(traits::Obligation::with_depth( self.tcx(), self.cause(traits::WellFormed(None)), depth, param_env, ty::Binder::dummy(ty::PredicateKind::ObjectSafe(principal)), )); } } } // Inference variables are the complicated case, since we don't // know what type they are. We do two things: // // 1. Check if they have been resolved, and if so proceed with //    THAT type. // 2. If not, we've at least simplified things (e.g., we went //    from `Vec<$0>: WF` to `$0: WF`), so we can //    register a pending obligation and keep //    moving. (Goal is that an "inductive hypothesis" //    is satisfied to ensure termination.) // See also the comment on `fn obligations`, describing "livelock" // prevention, which happens before this can be reached. ty::Infer(_) => { let cause = self.cause(traits::WellFormed(None)); self.out.push(traits::Obligation::with_depth( self.tcx(), cause, self.recursion_depth, param_env, ty::Binder::dummy(ty::PredicateKind::Clause(ty::ClauseKind::WellFormed( ty.into(), ))), )); } } debug!(?self.out); } </del> <ins> arg.visit_with(self); debug!(?self.out); </ins> } #[instrument(level = "debug", skip(self))]

we should change the following function to use a instead of Using a walker causes the control-flow to be a lot more complicated and given that this code is soundness-critical, we should make sure it's as easy to understand as possible <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim


Question: CHECK:        [[DEFINE_INTERNAL]] { {{.*}} } @_R{{[a-zA-Z0-9_]+}}testprog14will_be_called() unnamed_addr #{{[0-9]+}} { CHECK-NEXT:   start: CHECK-NOT:    [[DEFINE_INTERNAL]] <del> CHECK:        %pgocount = load i64, {{i64*|ptr}} </del> <ins> CHECK:        atomicrmw add ptr </ins> CHECK-SAME:   @__profc__R{{[a-zA-Z0-9_]+}}testprog14will_be_called, CHECK:        declare void @llvm.instrprof.increment({{i8*|ptr}}, i64, i32, i32) #[[LLVM_INSTRPROF_INCREMENT_ATTR:[0-9]+]]

<!-- 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 have a large-ish project with ~6000 testcases, and for a long time now, code coverage has been hit-or-miss. The issue is that some of the test cases don't seem to get their data included in the files, and so don't show up as having an effect on coverage. The unrecorded tests seem to be essentially random, but with thousands of tests, single-digit-percentage failures are noticed on every test run. It's been annoying. So I finally sat down to try and reduce to a simplest error, but it still takes multiple files, so is difficult to include inline in a GitHub issue. The tree: When I run a test via: which shows 2 tests run: Then report on that particular function via: Most of the time, I see the correct result: But sometimes (about 1 in 170 times), I see this: It seems to be related to having multiple source files; I could not get similar behavior with only a . I've seen the problem appear on both MacOS (Mohave) and on Windows (in Windows Subsystem for Linux 2) The two-source-file tree mentioned up above (including the script I run to repeat the test until a failure happens), is on a bug-report branch here: This really feels like whichever thread is controlling writes to the file is missing messages. Queue overrun maybe? (I haven't looked.) <!-- 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. --:
label A-code-coverage
I see you are using the placeholder for the profile file, which talks about locking and merging these files at runtime. Maybe adding the PID placeholder as well might avoid conflicts here. Can you give that a try?
Gave it a try; still exhibits the same behavior.
is definitely an indication to "please merge"; and doesn't do that, but is really about processes, not threads. I suspect whatever is doing the merging of thread data is what's got the issue here. (Though I get the same effect when I tell the test runner to just use one thread, as well.)


Question: CHECK:        [[DEFINE_INTERNAL]] { {{.*}} } @_R{{[a-zA-Z0-9_]+}}testprog14will_be_called() unnamed_addr #{{[0-9]+}} { CHECK-NEXT:   start: CHECK-NOT:    [[DEFINE_INTERNAL]] <del> CHECK:        %pgocount = load i64, {{i64*|ptr}} </del> <ins> CHECK:        atomicrmw add ptr </ins> CHECK-SAME:   @__profc__R{{[a-zA-Z0-9_]+}}testprog14will_be_called, CHECK:        declare void @llvm.instrprof.increment({{i8*|ptr}}, i64, i32, i32) #[[LLVM_INSTRPROF_INCREMENT_ATTR:[0-9]+]]

Just learned that the option of is not the same thing as (which sends that flag to the test-runner). Adding to my harness removes the intermittent results. Not closing this issue, though. Rust is supposed to be "fearless concurrency" so this should work correctly even if the test runner is using multiple threads.
Still reproducible with I used such script to run against , because of I can not find : at step 854, coverage changed from 4 to 2.
This is in cargo-binutils.
I created bug against upstream llvm/llvm-project
Looks like this is not llvm bug. There is bool flag , that is by default, and depend on it llvm generates different code: So if set it to true via option , then C++ variant of test is unable to reproduce problem. So is any way to set via rustc command line?
or another atomic-counter flag may work, but I have not tested it yet.
I can not see how any of this options can reach here . So I create PR to set to by default.
Looks like should also works. where


Question: ty::Closure(..) => Abi::RustCall, ty::CoroutineClosure(..) => Abi::RustCall, ty::Coroutine(..) => Abi::Rust, <ins> // No need to do MIR validation on error bodies ty::Error(_) => return, </ins> _ => { span_bug!(body.span, "unexpected body ty: {:?} phase {:?}", body_ty, mir_phase) }

<!-- 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: ty::Closure(..) => Abi::RustCall, ty::CoroutineClosure(..) => Abi::RustCall, ty::Coroutine(..) => Abi::Rust, <ins> // No need to do MIR validation on error bodies ty::Error(_) => return, </ins> _ => { span_bug!(body.span, "unexpected body ty: {:?} phase {:?}", body_ty, mir_phase) }

<!-- 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: target_option_val!(limit_rdylib_exports); target_option_val!(override_export_symbols); target_option_val!(merge_functions); <del> target_option_val!(mcount, "target_mcount"); </del> <ins> target_option_val!(mcount, "target-mcount"); </ins> target_option_val!(llvm_abiname); target_option_val!(relax_elf_relocations); target_option_val!(llvm_args);

Hello everyone, this is my first Issue on the Rust project, let me know if I'm doing anthing wrong ! I am in the process of building a library/runtime for the Wii fully written in Rust. To acheive this goal, I need to cross-compile my library to a custom target I named . The json file contains and along other lines to define the architecture. Normally, the build completes without an issue. On the latest nighlty, the compiler fails and return: Of course, is set to in the file, so this shouldn't happen. It most recently worked on: : It fails on this nightly, currently latest at the time of writing: : I can provide any file or other precision if necessary ! Thanks for reading my report !
I was also having the some issue and tracked it to this: That commit broke the equivalence between "target_endian" and "target-endian" by adding a case to the macro without the replace line for it.
cc
I'll fix this today.
Fixed in
I hope this gets merged asap :-)
(Reopening because isn't merged yet.)


Question: } impl Attribute { <ins> #[inline] </ins> pub fn has_name(&self, name: Symbol) -> bool { match self.kind { AttrKind::Normal(ref item, _) => item.path == name,

<!-- 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
This isn't really a bug, it's just that it has bad diagnostics because it uses , which is a perma-unstable attribute. I would recommend against reporting bugs that need attributes unless they cause unsoundness.
MCVE:
Should I exclude all test programs that have a line starting with ? Thanks.
I don't personally feel comfortable setting a policy that we'll never fix ICEs with attributes, but they are definitely less likely to be bugs than other ICEs. Note that this isn't sufficient to catch programs that have an attribute, you can have arbitrary macros that play with conditional compilation, like . Catching and will probably hit the common cases, though (you may want to also include inner attributes).


Question: } impl Attribute { <ins> #[inline] </ins> pub fn has_name(&self, name: Symbol) -> bool { match self.kind { AttrKind::Normal(ref item, _) => item.path == name,

Gives:
cc ICE-ing instead of user error on misuse seems somewhat okay given that it's an internal attribute, IMO.
agreed. We don't protect against mis-use of rustc internal attributes beyond making sure that you can't trivially create buggy code. I don't think we should put any effort into making this nicer to use and instead create the const-generic based replacement.


Question: let s = str::from_utf8(&out.stderr).unwrap(); // loosened the following from double::h to double:: due to // spurious failures on mac, 32bit, optimized <del> assert!(s.contains("stack backtrace") && s.contains("double::"), </del> <ins> assert!(s.contains("stack backtrace") && s.contains(" - double"), </ins> "bad output3: {}", s); // Make sure a stack trace isn't printed too many times

Symbol names are not properly supported yet on msvc, so backtraces are generally unhelpful. As a result, is currently disabled. This issue can be closed when it's been reenabled.


Question: <ins> fn main() { x::<#[a]y::<z>> //~^ ERROR invalid const generic expression //~| ERROR cannot find value `x` in this scope } </ins>

Found with The attribute applies to The was initially lexed as part of a token This seems to be exactly the case described by the : <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Do you have any suggestion for this case? The code path is going like this: Parser eat the first one of '' at here and set : fall pass at here: So this assertion is failed: The result is: and is true. Seems the assertion missed this scenario, do we need to add a TrailingToken::Gt ?
The assertion I wrote is overly conservative - it really just needs to check that we don't simultaneously break a token and 'really' capture a trailing token. Specifically, we only need to panic if we actually incremented in the match block. I think the simplest fix would be to add a variable, which gets set to in the parts of the block that increment . The assertion can then be changed to breaklasttoken


Question: /// ``` #[unstable(feature = "std_misc", reason = "pending integer conventions")] <del> fn ldexp(x: Self, exp: isize) -> Self; </del> <ins> fn ldexp(self, exp: isize) -> Self; </ins> /// Breaks the number into a normalized fraction and a base-2 exponent, /// satisfying: ///

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


Question: <ins> // Copyright 2018 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. // https://github.com/rust-lang/rust/issues/49181 #[derive(Eq, PartialEq)] #[repr(i8)] pub enum A { B = -1, C = 1, } pub const D: A = A::B; fn main() { match A::C { D => {}, _ => {} } } </ins>

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


Question: cx.stats.borrow_mut().n_closures += 1; <del> // The `uwtable` attribute according to LLVM is: // //     This attribute indicates that the ABI being targeted requires that an //     unwind table entry be produced for this function even if we can show //     that no exceptions passes by it. This is normally the case for the //     ELF x86-64 abi, but it can be disabled for some compilation units. // // Typically when we're compiling with `-C panic=abort` (which implies this // `no_landing_pads` check) we don't need `uwtable` because we can't // generate any exceptions! On Windows, however, exceptions include other // events such as illegal instructions, segfaults, etc. This means that on // Windows we end up still needing the `uwtable` attribute even if the `-C // panic=abort` flag is passed. // // You can also find more info on why Windows is whitelisted here in: //      https://bugzilla.mozilla.org/show_bug.cgi?id=1302078 if !cx.sess().no_landing_pads() || cx.sess().target.target.options.requires_uwtable { attributes::emit_uwtable(lldecl, true); } </del> let mir = cx.tcx.instance_mir(instance.def); mir::codegen_mir(cx, lldecl, &mir, instance, sig); }

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


Question: // there's no need to do dep-graph tracking for any of it. tcx.dep_graph.assert_ignored(); <del> join( || encode_metadata_impl(tcx, path), || { if tcx.sess.threads() == 1 { return; } // Prefetch some queries used by metadata encoding. // This is not necessary for correctness, but is only done for performance reasons. // It can be removed if it turns out to cause trouble or be detrimental to performance. join(|| prefetch_mir(tcx), || tcx.exported_symbols(LOCAL_CRATE)); }, ); } </del> <ins> if tcx.sess.threads() != 1 { // Prefetch some queries used by metadata encoding. // This is not necessary for correctness, but is only done for performance reasons. // It can be removed if it turns out to cause trouble or be detrimental to performance. join(|| prefetch_mir(tcx), || tcx.exported_symbols(LOCAL_CRATE)); } </ins> <del> fn encode_metadata_impl(tcx: TyCtxt<'_>, path: &Path) { </del> let mut encoder = opaque::FileEncoder::new(path) .unwrap_or_else(|err| tcx.sess.emit_fatal(FailCreateFileEncoder { err })); encoder.emit_raw_bytes(METADATA_HEADER);

<!-- 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
another one


Question: // there's no need to do dep-graph tracking for any of it. tcx.dep_graph.assert_ignored(); <del> join( || encode_metadata_impl(tcx, path), || { if tcx.sess.threads() == 1 { return; } // Prefetch some queries used by metadata encoding. // This is not necessary for correctness, but is only done for performance reasons. // It can be removed if it turns out to cause trouble or be detrimental to performance. join(|| prefetch_mir(tcx), || tcx.exported_symbols(LOCAL_CRATE)); }, ); } </del> <ins> if tcx.sess.threads() != 1 { // Prefetch some queries used by metadata encoding. // This is not necessary for correctness, but is only done for performance reasons. // It can be removed if it turns out to cause trouble or be detrimental to performance. join(|| prefetch_mir(tcx), || tcx.exported_symbols(LOCAL_CRATE)); } </ins> <del> fn encode_metadata_impl(tcx: TyCtxt<'_>, path: &Path) { </del> let mut encoder = opaque::FileEncoder::new(path) .unwrap_or_else(|err| tcx.sess.emit_fatal(FailCreateFileEncoder { err })); encoder.emit_raw_bytes(METADATA_HEADER);

I just tried out the new parallelization feature of the compiler and it randomly panicked because a deadlock was detected. I tried a couple of times and could not reproduce it unfortunately. : <details<summary<strongBacktrace</strong</summary<p</p</details
Could you provide the minimal example causes the ICE?
The project I compiled was huge and I was not able to consistently reproduce it so reducing my case to a minimal example might take forever. Buy I noticed the issue you linked already contains a fairly small example code so it's probably alright to close my ticket since it seems to be a duplicate of that other ticket anyway.
Can you reproduce this bug using the latest nightly version to get the new error output?
Yes. It appears to be the same issue (albeit while compiling a different dependency but that probably doesn't matter):
BTW with the latest nightly the compiler always and immediately panics and produces multiple back traces. version: nightly-aarch64-apple-darwin unchanged - rustc 1.76.0-nightly ( 2023-12-05) <details<summarycompiler error</summary</details
It would be fixed by


Question: // there's no need to do dep-graph tracking for any of it. tcx.dep_graph.assert_ignored(); <del> join( || encode_metadata_impl(tcx, path), || { if tcx.sess.threads() == 1 { return; } // Prefetch some queries used by metadata encoding. // This is not necessary for correctness, but is only done for performance reasons. // It can be removed if it turns out to cause trouble or be detrimental to performance. join(|| prefetch_mir(tcx), || tcx.exported_symbols(LOCAL_CRATE)); }, ); } </del> <ins> if tcx.sess.threads() != 1 { // Prefetch some queries used by metadata encoding. // This is not necessary for correctness, but is only done for performance reasons. // It can be removed if it turns out to cause trouble or be detrimental to performance. join(|| prefetch_mir(tcx), || tcx.exported_symbols(LOCAL_CRATE)); } </ins> <del> fn encode_metadata_impl(tcx: TyCtxt<'_>, path: &Path) { </del> let mut encoder = opaque::FileEncoder::new(path) .unwrap_or_else(|err| tcx.sess.emit_fatal(FailCreateFileEncoder { err })); encoder.emit_raw_bytes(METADATA_HEADER);

<!-- 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. --I have tried to measure on a 32 core machine and got this ice after several tries. Steps to reproduce: I have got it 2 times in a row, so it should be reproducible. <!-- 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. --:
searched nightlies: from nightly-2023-11-03 to nightly-2023-11-09 regressed nightly: nightly-2023-11-07 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
modify labels: +A-parallel-queries
modify labels: +WG-compiler-parallel
Can you reproduce this bug using the latest nightly version to get the new error output?
I can build rustc from the sources if you need to check something.
That's all right. It's a same error with other issues


Question: pub struct Zip<A, B> { a: A, b: B, <del> // index and len are only used by the specialized version of zip </del> <ins> // index, len and a_len are only used by the specialized version of zip </ins> index: usize, len: usize, <ins> a_len: usize, </ins> } impl<A: Iterator, B: Iterator> Zip<A, B> { pub(in crate::iter) fn new(a: A, b: B) -> Zip<A, B> {

Here is called for potential side effects until , ignoring however that it could have already been called in with those indexes. that demonstrates how this can be exploited to get two mutable references to the same data and cause an use-after-free bug.
Assigning as part of the .
The gift that keeps on giving Maybe it is time to get rid of as it exists today and replace it with a ? One that imposes the additional requirement on the caller that it must bring the iterator back into a safe state after it is done iterating. The upside would be eliminating a lot of code in and enabling the same optimization for and similar sources. While the downside would be that external iteration (i.e. loops and manual calls to ) would cease to benefit from optimizations and only internal iteration methods (including ) would continue to do so.
I don't know, I feel like that would just make more complex to upheld the invariants. IMO a good improvement over the current would be separating forward and backward iteration, this way it becomes easier to keep track of the state and I think would also make it possible to implement them for
I don't see how separating the forward and backward state would help with a drop implementation. The issue is that the source () currently does not have access to that state, instead the consumer drives the iteration by direct access through and never informs the source about it.
It would help because it allows the source iterator to keep track of its state by updating it when the method is called. Anyway, looks like someone already and it resulted in worse optimizations, but maybe LLVM got better in the meantime, or maybe that implementation could have been better. Anyway I don't think this is the right place to discuss this, a topic on zulip would probably be better.
https://rust-


Question: <ins> // run-pass // compile-flags: -C opt-level=1 // Make sure LLVM does not miscompile this match. fn main() { enum Bits { None = 0x00, Low = 0x40, High = 0x80, Both = 0xC0, } let value = Box::new(0x40u8); let mut out = Box::new(0u8); let bits = match *value { 0x00 => Bits::None, 0x40 => Bits::Low, 0x80 => Bits::High, 0xC0 => Bits::Both, _ => return, }; match bits { Bits::None | Bits::Low => { *out = 1; } _ => (), } assert_eq!(*out, 1); } </ins>

Minimized from : This issue was introduced in the build, and so it is likely to be a result of the upgrade to LLVM 17 ().
I have bisected the LLVM pass to the pass on main. I'm trying to get a diff of before/after so I can start tracking down the exact location of the incorrect optimization.
The optimization transforms this switch lookup which appears to correspond to the : with only the calculation of and changing from: to: with the rest of the IR remaining unchanged. The transform of appears to be okay ( by 64 -by 6). The transform of introduces the issue because although the instruction is marked as , is equal to which is negative in the signed representation and so subtracting 128 does cause signed underflow.
The IR output from rustc without any optimization passes outputs is: Which appears correct to me. This suggests that the is being introduced in a later optimization pass. I'll continue bisecting when I get a chance.
Looks like this instruction is being generated by a pass that's run before the pass. Before : Which is correct. So the real errant pass is , it just doesn't cause incorrect x86 to be emitted until a later pass.
Looks like this issue is known and a fix is in progress upstream at


Question: <ins> // check-pass use std::ops::Deref; struct Data { boxed: Box<&'static i32> } impl Data { fn use_data(&self, user: impl for <'a> FnOnce(<Box<&'a i32> as Deref>::Target)) { user(*self.boxed) } } fn main() {} </ins>

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --This code compiles correctly: However, this code does not: The only change was effectively replacing with . My understanding is that these are supposed to be equivalent as it is . The exact compile error is as follows: The error also occurs on the Nightly compiler.
We currently do not normalize projections if they contain unbound variables (stuff which is introduced using a qualifier, in your example). This means that we never actually see that is equal to . cc but I don't think we can do much about cases like this for now.
Is this the same underlying issue as and possibly
I think has a similar cause. is caused by something different, probably related to
Using trait objects instead of has the same issue
Came up with another interesting version. This will fail to typecheck: Replacing the header of foo with this will successfully typecheck: Might be useful for diffing.
Fixed by . Not going to close this because this is a simple example that didn't ICE, but still failed to compile.


Question: <ins> // check-pass use std::ops::Deref; struct Data { boxed: Box<&'static i32> } impl Data { fn use_data(&self, user: impl for <'a> FnOnce(<Box<&'a i32> as Deref>::Target)) { user(*self.boxed) } } fn main() {} </ins>

I believe this should successfully compile, but it currently fails claiming that vec's iterator isn't ExactSizeIterator: Things compile correctly if the bounds are changed to rather than .
It does seem like it should compile... cc
Another instance of this from : fails with
do you know of a workaround for this bug? It's currently blocking me and I'm not entirely sure how else to structure my code.
The only workaround I know of is to remove the lifetime parameter Steven Fackler
I believe this issue I ran in to might be related - . I was trying to put a bound on an associated type from two different types and require them to be , but Rust always just wanted to assume the types must be the same. By creating a separate trait that is implemented without relying on an HRTB, and then using the HRTB around that trait, it did compile. I'm fairly sure this is a bug. rustc ought to still be able to resolve what the associated type actually is and then evaluate traits on that. It seems like it's trying to look for implementations on a hypothetical associated type black box rather than the real type it points to.
Another example, when trying to bind :
Ran into this in one of my own projects, and used this odd workaround (suggested on satck overflow):
Another variation of this issue (as far as I can tell): Fails with:
I just ran into this (): I get the following error on latest stable (1.52.1): The workaround in my case was to pull out the associated type into a type parameter, and require that it be invariant w.r.t. the universally quantified lifetime parameter ():
Fixed by , marking as needs-test because wasn't an ICE and a simple enough example I'd like to have a test for.
This bug might not be completely fixed. Here is another test case that still fails on nightly and beta: EDIT: Made the case a bit smaller:
is the smallest example I can find: This below works: While this doesn't: Can you confirm that the second case works in your PR as well?
is still not fixed on latest nightly. cc EDIT: I suspect that this example is some form of .
Another bug of this kind:


Question: #[cfg(target_os = "macos")] pub mod sysconf { use types::os::arch::c95::c_int; <ins> pub static _SC_ARG_MAX : c_int = 1; pub static _SC_CHILD_MAX : c_int = 2; pub static _SC_CLK_TCK : c_int = 3; pub static _SC_NGROUPS_MAX : c_int = 4; pub static _SC_OPEN_MAX : c_int = 5; pub static _SC_JOB_CONTROL : c_int = 6; pub static _SC_SAVED_IDS : c_int = 7; pub static _SC_VERSION : c_int = 8; pub static _SC_BC_BASE_MAX : c_int = 9; pub static _SC_BC_DIM_MAX : c_int = 10; pub static _SC_BC_SCALE_MAX : c_int = 11; pub static _SC_BC_STRING_MAX : c_int = 12; pub static _SC_COLL_WEIGHTS_MAX : c_int = 13; pub static _SC_EXPR_NEST_MAX : c_int = 14; pub static _SC_LINE_MAX : c_int = 15; pub static _SC_RE_DUP_MAX : c_int = 16; pub static _SC_2_VERSION : c_int = 17; pub static _SC_2_C_BIND : c_int = 18; pub static _SC_2_C_DEV : c_int = 19; pub static _SC_2_CHAR_TERM : c_int = 20; pub static _SC_2_FORT_DEV : c_int = 21; pub static _SC_2_FORT_RUN : c_int = 22; pub static _SC_2_LOCALEDEF : c_int = 23; pub static _SC_2_SW_DEV : c_int = 24; pub static _SC_2_UPE : c_int = 25; pub static _SC_STREAM_MAX : c_int = 26; pub static _SC_TZNAME_MAX : c_int = 27; pub static _SC_ASYNCHRONOUS_IO : c_int = 28; pub static _SC_PAGESIZE : c_int = 29; pub static _SC_MEMLOCK : c_int = 30; pub static _SC_MEMLOCK_RANGE : c_int = 31; pub static _SC_MEMORY_PROTECTION : c_int = 32; pub static _SC_MESSAGE_PASSING : c_int = 33; pub static _SC_PRIORITIZED_IO : c_int = 34; pub static _SC_PRIORITY_SCHEDULING : c_int = 35; pub static _SC_REALTIME_SIGNALS : c_int = 36; pub static _SC_SEMAPHORES : c_int = 37; pub static _SC_FSYNC : c_int = 38; pub static _SC_SHARED_MEMORY_OBJECTS : c_int = 39; pub static _SC_SYNCHRONIZED_IO : c_int = 40; pub static _SC_TIMERS : c_int = 41; pub static _SC_AIO_LISTIO_MAX : c_int = 42; pub static _SC_AIO_MAX : c_int = 43; pub static _SC_AIO_PRIO_DELTA_MAX : c_int = 44; pub static _SC_DELAYTIMER_MAX : c_int = 45; pub static _SC_MQ_OPEN_MAX : c_int = 46; pub static _SC_MAPPED_FILES : c_int = 47; pub static _SC_RTSIG_MAX : c_int = 48; pub static _SC_SEM_NSEMS_MAX : c_int = 49; pub static _SC_SEM_VALUE_MAX : c_int =50; pub static _SC_SIGQUEUE_MAX : c_int = 51; pub static _SC_TIMER_MAX : c_int = 52; pub static _SC_NPROCESSORS_CONF : c_int = 57; </ins> pub static _SC_NPROCESSORS_ONLN : c_int = 58; <ins> pub static _SC_2_PBS : c_int = 59; pub static _SC_2_PBS_ACCOUNTING : c_int = 60; pub static _SC_2_PBS_CHECKPOINT : c_int = 61; pub static _SC_2_PBS_LOCATE : c_int = 62; pub static _SC_2_PBS_MESSAGE : c_int = 63; pub static _SC_2_PBS_TRACK : c_int = 64; pub static _SC_ADVISORY_INFO : c_int = 65; pub static _SC_BARRIERS : c_int = 66; pub static _SC_CLOCK_SELECTION : c_int = 67; pub static _SC_CPUTIME : c_int = 68; pub static _SC_FILE_LOCKING : c_int = 69; pub static _SC_GETGR_R_SIZE_MAX : c_int = 70; pub static _SC_GETPW_R_SIZE_MAX : c_int = 71; pub static _SC_HOST_NAME_MAX : c_int = 72; pub static _SC_LOGIN_NAME_MAX : c_int = 73; pub static _SC_MONOTONIC_CLOCK : c_int = 74; pub static _SC_MQ_PRIO_MAX : c_int = 75; pub static _SC_READER_WRITER_LOCKS : c_int = 76; pub static _SC_REGEXP : c_int = 77; pub static _SC_SHELL : c_int = 78; pub static _SC_SPAWN : c_int = 79; pub static _SC_SPIN_LOCKS : c_int = 80; pub static _SC_SPORADIC_SERVER : c_int = 81; pub static _SC_THREAD_ATTR_STACKADDR : c_int = 82; pub static _SC_THREAD_ATTR_STACKSIZE : c_int = 83; pub static _SC_THREAD_CPUTIME : c_int = 84; pub static _SC_THREAD_DESTRUCTOR_ITERATIONS : c_int = 85; pub static _SC_THREAD_KEYS_MAX : c_int = 86; pub static _SC_THREAD_PRIO_INHERIT : c_int = 87; pub static _SC_THREAD_PRIO_PROTECT : c_int = 88; pub static _SC_THREAD_PRIORITY_SCHEDULING : c_int = 89; pub static _SC_THREAD_PROCESS_SHARED : c_int = 90; pub static _SC_THREAD_SAFE_FUNCTIONS : c_int = 91; pub static _SC_THREAD_SPORADIC_SERVER : c_int = 92; pub static _SC_THREAD_STACK_MIN : c_int = 93; pub static _SC_THREAD_THREADS_MAX : c_int = 94; pub static _SC_TIMEOUTS : c_int = 95; pub static _SC_THREADS : c_int = 96; pub static _SC_TRACE : c_int = 97; pub static _SC_TRACE_EVENT_FILTER: c_int = 98; pub static _SC_TRACE_INHERIT: c_int = 99; pub static _SC_TRACE_LOG: c_int = 100; pub static _SC_TTY_NAME_MAX: c_int = 101; pub static _SC_TYPED_MEMORY_OBJECTS: c_int = 102; pub static _SC_V6_ILP32_OFF32: c_int = 103; pub static _SC_V6_ILP32_OFFBIG: c_int = 104; pub static _SC_V6_LP64_OFF64: c_int = 105; pub static _SC_V6_LPBIG_OFFBIG: c_int = 106; pub static _SC_IPV6: c_int = 118; pub static _SC_RAW_SOCKETS: c_int = 119; pub static _SC_SYMLOOP_MAX: c_int = 120; pub static _SC_ATEXIT_MAX: c_int = 107; pub static _SC_IOV_MAX: c_int = 56; pub static _SC_PAGE_SIZE: cint = _SC_PAGESIZE; pub static _SC_XOPEN_CRYPT: c_int = 108; pub static _SC_XOPEN_ENH_I18N: c_int = 109; pub static _SC_XOPEN_LEGACY: c_int = 110; pub static _SC_XOPEN_REALTIME: c_int = 111; pub static _SC_XOPEN_REALTIME_THREADS: c_int = 112; pub static _SC_XOPEN_SHM: c_int = 113; pub static _SC_XOPEN_STREAMS: c_int = 114; pub static _SC_XOPEN_UNIX: c_int = 115; pub static _SC_XOPEN_VERSION: c_int = 116; pub static _SC_XOPEN_XCU_VERSION: c_int = 121; pub static _SC_XBS5_ILP32_OFF32: c_int = 122; pub static _SC_XBS5_ILP32_OFFBIG: c_int = 123; pub static _SC_XBS5_LP64_OFF64: c_int = 124; pub static _SC_XBS5_LPBIG_OFFBIG: c_int = 125; pub static _SC_SS_REPL_MAX: c_int = 126; pub static _SC_TRACE_EVENT_NAME_MAX: c_int = 127; pub static _SC_TRACE_NAME_MAX: c_int = 128; pub static _SC_TRACE_SYS_MAX: c_int = 129; pub static _SC_TRACE_USER_EVENT_MAX: c_int = 130; pub static _SC_PASS_MAX: c_int = 131; </ins> } #[cfg(target_os = "android")]

We need to add all SC constants for for . There's only two at the moment which I only to quickly fix an issue with .


Question: type Wub = !; //~ ERROR type is experimental } <ins> fn look_ma_no_feature_gate<F: FnOnce() -> !>() {} //~ ERROR type is experimental fn tadam(f: &dyn Fn() -> !) {} //~ ERROR type is experimental fn panic() -> ! { panic!(); } fn toudoum() -> impl Fn() -> ! { //~ ERROR type is experimental panic } </ins> fn main() { }

I tried this code: I expected to see this happen: “error[E0658]: the type is experimental” Instead, this happened: Successful compilation, as long as I'm using a nightly compiler, but the error when on stable 1.75. This is incorrect because nightly features should always require attributes on nightly (until they're stabilized, which hasn't happened yet for ). <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: label +F-never_type +requires-nightly
searched nightlies: from nightly-2023-11-11 to nightly-2024-02-01 regressed nightly: nightly-2024-01-27 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: </detailsThen, bisecting Manually verified that reverting (as ) restored the error. cc
Not sure to understand why fixing the visitor implementation introduced this bug. Maybe it highlighted a limitation? Gonna check.
Ok I think I know why: implementation of the not calling the equivalent function. Checking where it is used.
WG-prioritization assigning priority (). label -I-prioritize +P-high
Fix was already approved in . Waiting for CI to be unlocked.


Question: //! are elements, and once they've all been exhausted, will return `None` to //! indicate that iteration is finished. Individual iterators may choose to //! resume iteration, and so calling [`next`] again may or may not eventually <del> //! start returning `Some(Item)` again at some point. </del> <ins> //! start returning `Some(Item)` again at some point (for example, see [`TryIter`]). </ins> //! //! [`Iterator`]'s full definition includes a number of other methods as well, //! but they are default methods, built on top of [`next`], and so you get

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> goto: file://|DOC_PATH|/test_docs/type.SomeType.html assert-all: (".top-block .docblock p", {"font-weight": "400"}) </ins>

: Local docs: ! But has the same issue: Probably caused by: ()
It seems like this css rule: applies to this element: !. Before () this rule wouldn't have applied because it would've been contrained by instead of .
This also had some other side-effects here: ! The search results have top/bottom margins compared to the previous styling.
The second issue was fixed in I'm checking for the first one, unless you want to send a PR?
Hmm, sorry I didn't/don't have much time to dig into this more. I couldn't think of an immediate fix for this because it kinda looked non-trivial (to me) :/
Don't worry, I'll send a fix in the next hours then.


Question: use crate::cache::{Interned, INTERNER}; use crate::cc_detect::{ndk_compiler, Language}; use crate::channel::{self, GitInfo}; <ins> use crate::compile::CODEGEN_BACKEND_PREFIX; </ins> pub use crate::flags::Subcommand; use crate::flags::{Color, Flags, Warnings}; use crate::util::{exe, output, t};

I tried this code: I expected to see this happen: An error saying that is invalid and should be instead. Instead, this happened: <!-- 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. --HEAD is branched from <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim


Question: // Ignore the notification. None } else { <del> print!( "failed to decode compiler output as json: line: {}noutput: {}", line, output ); panic!() </del> <ins> // This function is called for both compiler and non-compiler output, // so if the line isn't recognized as JSON from the compiler then // just print it as-is. Some(format!("{line}n")) </ins> } } else { // preserve non-JSON lines, such as ICEs

When a process unexpectedly fails/succeeds, compiletest will often print a full dump of its stdout and stderr for diagnostic purposes. When this happens, calls into , which has special handling for lines starting with . It tries to parse the line as JSON in one of a few known compiler-specific formats, in order to replace it with a more human-friendly message. If the line doesn't match any of those formats (or isn't valid JSON), the extractor code will panic, instead of just printing the line as-is. This is awkward in cases where we actually wanted to print the line as-is anyway, because now the error messages are less helpful. label +A-compiletest
The obvious solution (just make it not panic) is complicated by the fact that is called in multiple places, so it's harder to know whether the error is load-bearing in one of those cases.


Question: //      'Deprecated$' #[deprecated] pub struct W; <ins> // @matches deprecated/struct.X.html '//*[@class="stab deprecated"]'  //      'Deprecated: shorthand reason$' #[deprecated = "shorthand reason"] pub struct X; </ins>

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


Question: <ins> error[E0277]: the trait bound `*mut (): Trait<'_>` is not satisfied --> $DIR/issue-101623.rs:21:21 | LL |     Trait::do_stuff({ fun(&mut *inner) }); |     --------------- ^^----------------^^ |     |               | |     |               the trait `Trait<'_>` is not implemented for `*mut ()` |     required by a bound introduced by this call | = help: the trait `Trait<'a>` is implemented for `()` error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>

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


Question: } } } // Visit everything, but enum variants have their own levels. hir::ItemKind::Enum(ref def, _) => { if item_level.is_some() { self.reach(item.def_id, item_level).generics().predicates(); } <del> let enum_level = self.get(item.def_id); </del> for variant in def.variants { <del> let variant_level = self.update_with_hir_id(variant.id, enum_level); </del> <ins> let variant_level = self.get(self.tcx.hir().local_def_id(variant.id)); </ins> if variant_level.is_some() { <del> if let Some(ctor_id) = variant.data.ctor_hir_id() { self.update_with_hir_id(ctor_id, variant_level); } </del> for field in variant.data.fields() { self.reach(self.tcx.hir().local_def_id(field.hir_id), variant_level) .ty();

EDIT (ehuss) Reproduction: Clone <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
We are seeing this too on rustc 1.60.0-nightly ( 2022-01-10) running on aarch64-apple-darwin
label +I-prioritize
cc This seems to have regressed starting with .
I'm taking a look
I can reproduce and I did find some differences in the access level table. seems to be missing when it's supposed to be Reachable in the good version. I'll investigate further Updates: Actually, the whole Impl seems to be missing. It should be marked as Reachable but is not even there. claim
Marking as , as .
Same on Mac, on x86_64-apple-darwin as well, same toolchain version (rustc 1.60.0-nightly ( 2022-01-10))
As an update for those watching: currently, the best workaround is to use an older nightly. The good news is that a fix PR is open (), with people working on getting it in shape to be merged.


Question: tcx: TyCtxt<'tcx>, // typeck errors have subpar spans for opaque types, so delay error reporting until borrowck. ignore_errors: bool, <del> origin: OpaqueTyOrigin, </del> ) -> Self { let OpaqueTypeKey { def_id, substs } = opaque_type_key;

Here is an example which uses a RPIT on a borrowed type in three different ways: IMO this is perfectly reasonable code and (EDIT: see below). On stable () we have the following: And on beta () and nightly () we get some additional errors: EDIT: On second thought, I guess the first error (on stable) is reasonable, since we are actually returning a in that case. If you either use in the body or in the return type then the error goes away. But the second error is still a regression. It most recently worked on: rustc 1.66.0 ( 2022-12-12) : modify labels: +regression-from-stable-to-beta -regression-untriaged
This is . Cc It is related to the invariance: Another case that doesn't rely on member constraints in the second function and yields a different error message: I also found a distantly related regression that doesn't require invariance. It looks like a missed subtyping opportunity:
Another version using TAIT: At this point there are two classes of regression: The first is related to the fact that and the the second requires more subtyping relations. label I-types-nominated T-types T-compiler
WG-prioritization assigning priority (). label -I-prioritize +P-critical
From beta crater: https://crater- https://crater- https://crater- https://crater- https://crater-
unnominating as it will get fixed by which is approved again. Have to try to get this into beta though, only have 1 more day for that


Question: //!    in this case, if one uses the format string `{<arg>:<spec>.*}`, then the `<arg>` part refers //!    to the *value* to print, and the `precision` must come in the input preceding `<arg>`. //! <del> //! For example, these: </del> <ins> //! For example, the following calls all print the same thing `Hello x is 0.01000`: </ins> //! //! ``` <del> //! // Hello {arg 0 (x)} is {arg 1 (0.01) with precision specified inline (5)} </del> <ins> //! // Hello {arg 0 ("x")} is {arg 1 (0.01) with precision specified inline (5)} </ins> //! println!("Hello {0} is {1:.5}", "x", 0.01); //! <del> //! // Hello {arg 1 (x)} is {arg 2 (0.01) with precision specified in arg 0 (5)} </del> <ins> //! // Hello {arg 1 ("x")} is {arg 2 (0.01) with precision specified in arg 0 (5)} </ins> //! println!("Hello {1} is {2:.0$}", 5, "x", 0.01); //! <del> //! // Hello {arg 0 (x)} is {arg 2 (0.01) with precision specified in arg 1 (5)} </del> <ins> //! // Hello {arg 0 ("x")} is {arg 2 (0.01) with precision specified in arg 1 (5)} </ins> //! println!("Hello {0} is {2:.1$}", "x", 5, 0.01); //! <del> //! // Hello {next arg (x)} is {second of next two args (0.01) with precision </del> <ins> //! // Hello {next arg ("x")} is {second of next two args (0.01) with precision </ins> //! //                          specified in first of next two args (5)} //! println!("Hello {} is {:.*}",    "x", 5, 0.01); //! <del> //! // Hello {next arg (x)} is {arg 2 (0.01) with precision </del> <ins> //! // Hello {next arg ("x")} is {arg 2 (0.01) with precision </ins> //! //                          specified in its predecessor (5)} //! println!("Hello {} is {2:.*}",   "x", 5, 0.01); //! <del> //! // Hello {next arg (x)} is {arg "number" (0.01) with precision specified </del> <ins> //! // Hello {next arg ("x")} is {arg "number" (0.01) with precision specified </ins> //! //                          in arg "prec" (5)} //! println!("Hello {} is {number:.prec$}", "x", prec = 5, number = 0.01); //! ``` //! <del> //! All print the same thing: //! //! ```text //! Hello x is 0.01000 //! ``` //! </del> //! While these: //! //! ```

Was just trying to read through std::fmt to understand how format values to a particular decimal point. I came across this set of examples, which don't do a good job of explaining the output of each, so it's difficult to visually pattern match what I type in to what comes out:
Sorry for the mess :sweat_smile: I guess it is clearer now.


Question: pub use idx::Idx; pub use rustc_index_macros::newtype_index; pub use slice::IndexSlice; <ins> #[doc(no_inline)] </ins> pub use vec::IndexVec; /// Type size assertion. The first argument is a type and the second argument is its expected size.

We have some relative links in doc, e.g., the link of in the comments for : but we will get the page if we click it in , which is re-exported. So I think we can fix this by two ways: 't use relative path in rustc doc 't generate new link for re-exported items, use the same links with the original definition but for the second option, we may have private middle mods, so it may be not a solution. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
I'm thinking of tackling this issue, is this Issue aimed at removing this invalid path once and for all? (Sorry if I'm wrong as I'm trying to contribute for the first time)
claim
Hi just checking if you are still working on the issue? If so, apologies please ignore this. Otherwise I'm happy to take over. Thanks
take it


Question: <ins> fn foo<T>(t: T) { || { t; t; }; //~ ERROR: use of moved value } fn main() {} </ins>

I encounter an ICE: with rustc 1.41.0-nightly ( 2019-12-06) running on x86_64-pc-windows-msvc when compiling The Stable compiler outputs But Nightly crashed.
Confirmed on Linux too. <details<summaryBacktrace</summary</details
Reduced slightly:
cc
Really reduced: This comes from this unwrap: The used should be


Question: placeholder_type_error(tcx, None, &[], visitor.0, false); } <del> hir::TraitItemKind::Type(_, None) => {} </del> <ins> hir::TraitItemKind::Type(_, None) => { // #74612: Visit and try to find bad placeholders // even if there is no concrete type. let mut visitor = PlaceholderHirTyCollector::default(); visitor.visit_trait_item(trait_item); placeholder_type_error(tcx, None, &[], visitor.0, false); } </ins> }; tcx.ensure().predicates_of(def_id);

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: <ins> // check-pass // ignore-emscripten no llvm_asm! support #![feature(llvm_asm)] pub fn boot(addr: Option<u32>) { unsafe { llvm_asm!("mov sp, $0"::"r" (addr)); } } fn main() {} </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> // check-pass // ignore-emscripten no llvm_asm! support #![feature(llvm_asm)] pub fn boot(addr: Option<u32>) { unsafe { llvm_asm!("mov sp, $0"::"r" (addr)); } } fn main() {} </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> // check-pass // ignore-emscripten no llvm_asm! support #![feature(llvm_asm)] pub fn boot(addr: Option<u32>) { unsafe { llvm_asm!("mov sp, $0"::"r" (addr)); } } fn main() {} </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> // check-pass // ignore-emscripten no llvm_asm! support #![feature(llvm_asm)] pub fn boot(addr: Option<u32>) { unsafe { llvm_asm!("mov sp, $0"::"r" (addr)); } } fn main() {} </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> // check-pass // ignore-emscripten no llvm_asm! support #![feature(llvm_asm)] pub fn boot(addr: Option<u32>) { unsafe { llvm_asm!("mov sp, $0"::"r" (addr)); } } fn main() {} </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: <ins> error[E0658]: attributes on expressions are experimental --> $DIR/issue-88476.rs:20:13 | LL |     let x = #[rustc_capture_analysis] move || { |             ^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: see issue #15701 <https://github.com/rust-lang/rust/issues/15701> for more information = help: add `#![feature(stmt_expr_attributes)]` to the crate attributes to enable error[E0658]: attributes on expressions are experimental --> $DIR/issue-88476.rs:47:13 | LL |     let c = #[rustc_capture_analysis] move || { |             ^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: see issue #15701 <https://github.com/rust-lang/rust/issues/15701> for more information = help: add `#![feature(stmt_expr_attributes)]` to the crate attributes to enable error: First Pass analysis includes: --> $DIR/issue-88476.rs:20:39 | LL |       let x = #[rustc_capture_analysis] move || { |  _______________________________________^ LL | | LL | | LL | | ...  | LL | | LL | |     }; | |_____^ | note: Capturing f[(0, 0)] -> ImmBorrow --> $DIR/issue-88476.rs:25:26 | LL |         println!("{:?}", f.0); |                          ^^^ error: Min Capture analysis includes: --> $DIR/issue-88476.rs:20:39 | LL |       let x = #[rustc_capture_analysis] move || { |  _______________________________________^ LL | | LL | | LL | | ...  | LL | | LL | |     }; | |_____^ | note: Min Capture f[] -> ByValue --> $DIR/issue-88476.rs:25:26 | LL |         println!("{:?}", f.0); |                          ^^^ error: First Pass analysis includes: --> $DIR/issue-88476.rs:47:39 | LL |       let c = #[rustc_capture_analysis] move || { |  _______________________________________^ LL | | LL | | LL | | ...  | LL | | LL | |     }; | |_____^ | note: Capturing character[(0, 0)] -> ImmBorrow --> $DIR/issue-88476.rs:52:24 | LL |         println!("{}", character.hp) |                        ^^^^^^^^^^^^ error: Min Capture analysis includes: --> $DIR/issue-88476.rs:47:39 | LL |       let c = #[rustc_capture_analysis] move || { |  _______________________________________^ LL | | LL | | LL | | ...  | LL | | LL | |     }; | |_____^ | note: Min Capture character[(0, 0)] -> ByValue --> $DIR/issue-88476.rs:52:24 | LL |         println!("{}", character.hp) |                        ^^^^^^^^^^^^ error: aborting due to 6 previous errors For more information about this error, try `rustc --explain E0658`. </ins>

I tried this code: This does not issue a warning for , however it fails to compile with enabled: I would expect to give a suggestion to add . Found in the 2021 crater run for: I'm uncertain if this is a duplicate of or , they seem very similar, but this case is specific to implementing Drop. : cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim


Question: build::CondBr(bcx, cond.immediate(), lltrue, llfalse, DebugLoc::None); } <del> mir::Terminator::Switch { .. } => { unimplemented!() </del> <ins> mir::Terminator::Switch { ref discr, ref adt_def, ref targets } => { let adt_ty = bcx.tcx().lookup_item_type(adt_def.did).ty; let represented_ty = adt::represent_type(bcx.ccx(), adt_ty); let discr_lvalue = self.trans_lvalue(bcx, discr); let discr = adt::trans_get_discr(bcx, &represented_ty, discr_lvalue.llval, None); // The else branch of the Switch can't be hit, so branch to an unreachable // instruction so LLVM knows that // FIXME it might be nice to have just one such block (created lazilly), we could // store it in the "MIR trans" state. let unreachable_blk = bcx.fcx.new_temp_block("enum-variant-unreachable"); build::Unreachable(unreachable_blk); let switch = build::Switch(bcx, discr, unreachable_blk.llbb, targets.len()); assert_eq!(adt_def.variants.len(), targets.len()); for (adt_variant, target) in adt_def.variants.iter().zip(targets) { let llval = adt::trans_case(bcx, &*represented_ty, adt_variant.disr_val); let llbb = self.llblock(*target); build::AddCase(switch, llval, llbb) } </ins> } mir::Terminator::SwitchInt { ref discr, switch_ty, ref values, ref targets } => {

The Switch terminator, which is used in pattern matching, is currently unimplemented in MIR. This terminator should load the discriminant from an lvalue and branch to the appropriate basic block target based on what is found there. It has to integrate with the code.


Question: <ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #![feature(rustc_attrs)] use std::fmt; // CoerceUnsized is not implemented for tuples. You can still create // an unsized tuple by transmuting a trait object. fn any<T>() -> T { unreachable!() } #[rustc_error] fn main() { //~ ERROR compilation successful let t: &(u8, fmt::Debug) = any(); println!("{:?}", &t.1); } </ins>

This code: produces a helpful error message: But the analogous code using a : gives an error which doesn't point at the binding :
This is fixed today. I'm going to mark as E-needstest since it feels like the kind of thing that's easy to regress on -- a UI test would be best here.


Question: <ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #![feature(rustc_attrs)] use std::fmt; // CoerceUnsized is not implemented for tuples. You can still create // an unsized tuple by transmuting a trait object. fn any<T>() -> T { unreachable!() } #[rustc_error] fn main() { //~ ERROR compilation successful let t: &(u8, fmt::Debug) = any(); println!("{:?}", &t.1); } </ins>

Before , this caused an LLVM error Afterwards, this causes an ICE (the rustc size is the correct one):
I am now getting a segfault in LLVM, but I'm uncertain whether that's actually the case, or just a local build problem.
Looks like called on a NULL pointer? Probably some missing check that something is indeed unsized, with actual metadata to go alongside it.
Appears to be fixed today. E-needstest.
It seems that a better diagnostic output is needed:
Why? I believe it's implemented as a feature now (maybe it should be ?).
it's unrelated to this issue, but rather to 's solution, merits at least a clarifying label pointing at the , as otherwise the compiler output makes you look at the following line exclusively, which isn't the cause for the . I know it definitely confused me_ :) Back to this issue, yes, the test in should be .


Question: <ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #![feature(rustc_attrs)] use std::fmt; // CoerceUnsized is not implemented for tuples. You can still create // an unsized tuple by transmuting a trait object. fn any<T>() -> T { unreachable!() } #[rustc_error] fn main() { //~ ERROR compilation successful let t: &(u8, fmt::Debug) = any(); println!("{:?}", &t.1); } </ins>

Triage: this no longer ICEs. <details<summaryMeta</summary: rustc 1.16.0 ( 2017-03-10) binary: rustc commit-hash: commit-date: 2017-03-10 host: x86_64-pc-windows-gnu release: 1.16.0 LLVM version: 3.9 </details


Question: None } Err(ErrorHandled::TooGeneric) => { <del> span_bug!(tcx.def_span(expr_did), "enum discriminant depends on generic arguments",) </del> <ins> tcx.sess.delay_span_bug( tcx.def_span(expr_did), "enum discriminant depends on generic arguments", ); None </ins> } } }

The following ICE's on stable, beta and nightly: (notice the was NOT closed) <details<summaryBacktrace:</summary</details
Oh, this works with other types as well, except the messages are different ICE's with:
ICE's with:
Its worth nothing explicitly that: these ICE's are happening after we do issue a diagnostic for the parsing error If you address the parsing error (presumably in the same manner that the parser is auto-correcting to make further progress), the ICE goes away
triage: P-medium. Removing nomination.
Triage: The first example still ICEs in MIR building The second and third examples don't ICE anymore and need tests (without closing this issue!).
cc


Question: unsafe { Some((self.a.__iterator_get_unchecked(i), self.b.__iterator_get_unchecked(i))) } <del> } else if A::MAY_HAVE_SIDE_EFFECT && self.index < self.a.size() { </del> <ins> } else if A::MAY_HAVE_SIDE_EFFECT && self.index < self.a_len { </ins> let i = self.index; self.index += 1; self.len += 1;

Here is called for potential side effects until , ignoring however that it could have already been called in with those indexes. that demonstrates how this can be exploited to get two mutable references to the same data and cause an use-after-free bug.
Assigning as part of the .
The gift that keeps on giving Maybe it is time to get rid of as it exists today and replace it with a ? One that imposes the additional requirement on the caller that it must bring the iterator back into a safe state after it is done iterating. The upside would be eliminating a lot of code in and enabling the same optimization for and similar sources. While the downside would be that external iteration (i.e. loops and manual calls to ) would cease to benefit from optimizations and only internal iteration methods (including ) would continue to do so.
I don't know, I feel like that would just make more complex to upheld the invariants. IMO a good improvement over the current would be separating forward and backward iteration, this way it becomes easier to keep track of the state and I think would also make it possible to implement them for
I don't see how separating the forward and backward state would help with a drop implementation. The issue is that the source () currently does not have access to that state, instead the consumer drives the iteration by direct access through and never informs the source about it.
It would help because it allows the source iterator to keep track of its state by updating it when the method is called. Anyway, looks like someone already and it resulted in worse optimizations, but maybe LLVM got better in the meantime, or maybe that implementation could have been better. Anyway I don't think this is the right place to discuss this, a topic on zulip would probably be better.
https://rust-


Question: <ins> // check that we don't forget to drop the Box if we early return before // initializing it // ignore-tidy-linelength // ignore-wasm32-bare compiled with panic=abort by default #![feature(box_syntax)] fn test() -> Option<Box<u32>> { Some(box (None?)) } fn main() { test(); } // END RUST SOURCE // START rustc.test.ElaborateDrops.before.mir // fn test() -> std::option::Option<std::boxed::Box<u32>> { //     ... //     bb0: { //         StorageLive(_1); //         StorageLive(_2); //         _2 = Box(u32); //         StorageLive(_3); //         StorageLive(_4); //         _4 = std::option::Option::<u32>::None; //         _3 = const <std::option::Option<u32> as std::ops::Try>::into_result(move _4) -> [return: bb2, unwind: bb3]; //     } //     bb1 (cleanup): { //         resume; //     } //     bb2: { //         StorageDead(_4); //         _5 = discriminant(_3); //         switchInt(move _5) -> [0isize: bb10, 1isize: bb5, otherwise: bb4]; //     } //     bb3 (cleanup): { //         drop(_2) -> bb1; //     } //     bb4: { //         unreachable; //     } //     bb5: { //         StorageLive(_6); //         _6 = ((_3 as Err).0: std::option::NoneError); //         StorageLive(_8); //         StorageLive(_9); //         _9 = _6; //         _8 = const <std::option::NoneError as std::convert::From<std::option::NoneError>>::from(move _9) -> [return: bb7, unwind: bb3]; //     } //     bb6: { //         return; //     } //     bb7: { //         StorageDead(_9); //         _0 = const <std::option::Option<std::boxed::Box<u32>> as std::ops::Try>::from_error(move _8) -> [return: bb8, unwind: bb3]; //     } //     bb8: { //         StorageDead(_8); //         StorageDead(_6); //         drop(_2) -> bb9; //     } //     bb9: { //         StorageDead(_2); //         StorageDead(_1); //         StorageDead(_3); //         goto -> bb6; //     } //     bb10: { //         StorageLive(_10); //         _10 = ((_3 as Ok).0: u32); //         (*_2) = _10; //         StorageDead(_10); //         _1 = move _2; //         drop(_2) -> [return: bb12, unwind: bb11]; //     } //     bb11 (cleanup): { //         drop(_1) -> bb1; //     } //     bb12: { //         StorageDead(_2); //         _0 = std::option::Option::<std::boxed::Box<u32>>::Some(move _1,); //         drop(_1) -> bb13; //     } //     bb13: { //         StorageDead(_1); //         StorageDead(_3); //         goto -> bb6; //     } // } // END rustc.test.ElaborateDrops.before.mir </ins>

mentioned a leak coming from but not , I think I tracked this down to the use of in when given a comma-separated list. I've made that demonstrates it with , if it gets much simpler than this then the leak doesn't occur when built with --release. I'm testing on rustc 1.37.0-nightly ( 2019-06-30) nightly-x8664-pc-windows-msvc, targeting x8664-pc-windows-msvc.
Valgrind Memcheck also reports heap in use at exit on a Linux VM with the test linked above.
Thanks a lot for creating a reduced test case and creating this issue here. I stumbled over the original issue when carg-fuzz reported a memory leak in this code This PR appears to fix the issue This was also with rustc 1.37.0-nightly on Linux. I can check if I can repro with the fuzz test case on other platforms.
Looks like the early return doesn't interact well with box syntax's preallocation. MIR generation issue? cc
should be here: Now that can only schedule drops for locals, we should get the type from to avoid this sort of problem in the future.
Confirmed with my fuzzing test case that the problem is fixed in the latest rust nightly. Thanks for fixing it so quickly.