Question: pub fn foo(arg: Option<&Vec<i32>>) -> Option<&[i32]> { arg //~ ERROR 5:5: 5:8: mismatched types [E0308] } <ins> pub fn bar(arg: Option<&Vec<i32>>) -> &[i32] { arg.unwrap_or(&[]) //~ ERROR 9:19: 9:22: mismatched types [E0308] } pub fn barzz<'a>(arg: Option<&'a Vec<i32>>, v: &'a [i32]) -> &'a [i32] { arg.unwrap_or(v) //~ ERROR 13:19: 13:20: mismatched types [E0308] } pub fn convert_result(arg: Result<&Vec<i32>, ()>) -> &[i32] { arg.unwrap_or(&[]) //~ ERROR 17:19: 17:22: mismatched types [E0308] } </ins>

Given : Current error, for the motivating use case above: It should be possible for rustc to suggest replacing this specific instantiation of with . Maybe similarly for some other common cases: . Originally posted by in label -T-rustdoc T-compiler


Question: <ins> error[E0706]: trait fns cannot be declared `async` --> $DIR/async-trait-fn.rs:3:5 | LL |     async fn foo() {} |     ^^^^^^^^^^^^^^^^^ | = note: `async` trait functions are not currently supported = note: consider using the `async-trait` crate: https://crates.io/crates/async-trait error[E0706]: trait fns cannot be declared `async` --> $DIR/async-trait-fn.rs:4:5 | LL |     async fn bar(&self) {} |     ^^^^^^^^^^^^^^^^^^^^^^ | = note: `async` trait functions are not currently supported = note: consider using the `async-trait` crate: https://crates.io/crates/async-trait error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0706`. </ins>

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


Question: #[rustc_doc_primitive = "f128"] #[doc(alias = "quad")] <del> /// A 128-bit floating point type (specifically, the "binary128" type defined in IEEE 754-2008). </del> <ins> /// A 128-bit floating-point type (specifically, the "binary128" type defined in IEEE 754-2008). </ins> /// /// This type is very similar to [`prim@f32`] and [`prim@f64`], but has increased precision by using twice /// as many bits as `f64`. Please see [the documentation for `f32`](prim@f32) or [Wikipedia on

Pointed out by in the float docs are using the term "arithmetic" operations in a few places, but that term is never defined. Furthermore, the new NaN docs probably should use that term as well when discussing which operations the NaN rules apply to (instead of "non-bitwise floating point operations" which they use currently). By "arithmetic operations", the docs likely mean all operations except for unary , , , , , and .


Question: <ins> #[doc(hidden)] pub enum HiddenType {} #[doc(hidden)] pub trait HiddenTrait {} </ins>

Last line yields several occurrences of in the generated file. ## Expected behavior No occurrences of anywhere since it was label C-bug T-rustdoc cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I expect the fix is to check for just after
claim
cc I checked for doc(hidden) like this: But it doesn't seem to work, as my test would fail. I also tried using the same way to check for but it also failed. I noticed that the issue involves so I might need to iterate over generic parameters, I cannot find any function that does that in , so can someone point me in the right direction? Thanks :)
You can look at how the pass works:
am I right in understanding this only happens for cross-crate traits, and impls for hidden traits in the same crate are still hidden? In other words, just makes the cross-crate case consistent?
I believe so, yes: the pass was already taking care of such cases for local types. FWIW, the thing that motivated this discussion was noticing a leaking on the docs for , but not on the ones for


Question: <ins> error[E0261]: use of undeclared lifetime name `'short` --> $DIR/issue-107090.rs:4:9 | LL |     Foo<'short, 'out, T>: Convert<'a, 'b>; |         ^^^^^^ undeclared lifetime | = note: for more information on higher-ranked polymorphism, visit https://doc.rust-lang.org/nomicon/hrtb.html help: consider making the bound lifetime-generic with a new `'short` lifetime | LL |     for<'short> Foo<'short, 'out, T>: Convert<'a, 'b>; |     +++++++++++ help: consider introducing lifetime `'short` here | LL | struct Foo<'short, 'a, 'b, T>(PhantomData<(&'a (), &'b (), T)>) |            +++++++ error[E0261]: use of undeclared lifetime name `'out` --> $DIR/issue-107090.rs:4:17 | LL |     Foo<'short, 'out, T>: Convert<'a, 'b>; |                 ^^^^ undeclared lifetime | help: consider making the bound lifetime-generic with a new `'out` lifetime | LL |     for<'out> Foo<'short, 'out, T>: Convert<'a, 'b>; |     +++++++++ help: consider introducing lifetime `'out` here | LL | struct Foo<'out, 'a, 'b, T>(PhantomData<(&'a (), &'b (), T)>) |            +++++ error[E0261]: use of undeclared lifetime name `'b` --> $DIR/issue-107090.rs:13:47 | LL | impl<'long: 'short, 'short, T> Convert<'long, 'b> for Foo<'short, 'out, T> { |      -                                        ^^ undeclared lifetime |      | |      help: consider introducing lifetime `'b` here: `'b,` error[E0261]: use of undeclared lifetime name `'out` --> $DIR/issue-107090.rs:13:67 | LL | impl<'long: 'short, 'short, T> Convert<'long, 'b> for Foo<'short, 'out, T> { |      - help: consider introducing lifetime `'out` here: `'out,`   ^^^^ undeclared lifetime error[E0261]: use of undeclared lifetime name `'out` --> $DIR/issue-107090.rs:17:49 | LL |     fn cast(&'long self) -> &'short Foo<'short, 'out, T> { |                                                 ^^^^ undeclared lifetime | help: consider introducing lifetime `'out` here | LL |     fn cast<'out>(&'long self) -> &'short Foo<'short, 'out, T> { |            ++++++ help: consider introducing lifetime `'out` here | LL | impl<'out, 'long: 'short, 'short, T> Convert<'long, 'b> for Foo<'short, 'out, T> { |      +++++ error[E0261]: use of undeclared lifetime name `'short` --> $DIR/issue-107090.rs:24:68 | LL | fn badboi<'in_, 'out, T>(x: Foo<'in_, 'out, T>, sadness: &'in_ Foo<'short, 'out, T>) -> &'out T { |           -                                                        ^^^^^^ undeclared lifetime |           | |           help: consider introducing lifetime `'short` here: `'short,` error[E0308]: mismatched types --> $DIR/issue-107090.rs:4:27 | LL |     Foo<'short, 'out, T>: Convert<'a, 'b>; |                           ^^^^^^^^^^^^^^^ lifetime mismatch | = note: expected trait `Convert<'static, 'static>` found trait `Convert<'a, 'b>` note: the lifetime `'a` as defined here... --> $DIR/issue-107090.rs:2:12 | LL | struct Foo<'a, 'b, T>(PhantomData<(&'a (), &'b (), T)>) |            ^^ = note: ...does not necessarily outlive the static lifetime error[E0308]: mismatched types --> $DIR/issue-107090.rs:4:27 | LL |     Foo<'short, 'out, T>: Convert<'a, 'b>; |                           ^^^^^^^^^^^^^^^ lifetime mismatch | = note: expected trait `Convert<'static, 'static>` found trait `Convert<'a, 'b>` note: the lifetime `'b` as defined here... --> $DIR/issue-107090.rs:2:16 | LL | struct Foo<'a, 'b, T>(PhantomData<(&'a (), &'b (), T)>) |                ^^ = note: ...does not necessarily outlive the static lifetime error[E0495]: cannot infer an appropriate lifetime for lifetime parameter `'long` due to conflicting requirements --> $DIR/issue-107090.rs:13:55 | LL | impl<'long: 'short, 'short, T> Convert<'long, 'b> for Foo<'short, 'out, T> { |                                                       ^^^^^^^^^^^^^^^^^^^^ | note: first, the lifetime cannot outlive the lifetime `'short` as defined here... --> $DIR/issue-107090.rs:13:21 | LL | impl<'long: 'short, 'short, T> Convert<'long, 'b> for Foo<'short, 'out, T> { |                     ^^^^^^ = note: ...but the lifetime must also be valid for the static lifetime... note: ...so that the types are compatible --> $DIR/issue-107090.rs:13:55 | LL | impl<'long: 'short, 'short, T> Convert<'long, 'b> for Foo<'short, 'out, T> { |                                                       ^^^^^^^^^^^^^^^^^^^^ = note: expected `Convert<'short, 'static>` found `Convert<'_, 'static>` error: incompatible lifetime on type --> $DIR/issue-107090.rs:24:29 | LL | fn badboi<'in_, 'out, T>(x: Foo<'in_, 'out, T>, sadness: &'in_ Foo<'short, 'out, T>) -> &'out T { |                             ^^^^^^^^^^^^^^^^^^ | note: because this has an unmet lifetime requirement --> $DIR/issue-107090.rs:4:27 | LL |     Foo<'short, 'out, T>: Convert<'a, 'b>; |                           ^^^^^^^^^^^^^^^ introduces a `'static` lifetime requirement note: the lifetime `'out` as defined here... --> $DIR/issue-107090.rs:24:17 | LL | fn badboi<'in_, 'out, T>(x: Foo<'in_, 'out, T>, sadness: &'in_ Foo<'short, 'out, T>) -> &'out T { |                 ^^^^ note: ...does not necessarily outlive the static lifetime introduced by the compatible `impl` --> $DIR/issue-107090.rs:13:1 | LL | impl<'long: 'short, 'short, T> Convert<'long, 'b> for Foo<'short, 'out, T> { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error[E0759]: `x` has lifetime `'in_` but it needs to satisfy a `'static` lifetime requirement --> $DIR/issue-107090.rs:24:29 | LL | fn badboi<'in_, 'out, T>(x: Foo<'in_, 'out, T>, sadness: &'in_ Foo<'short, 'out, T>) -> &'out T { |                             ^^^^^^^^^^^^^^^^^^ |                             | |                             this data with lifetime `'in_`... |                             ...is used and required to live as long as `'static` here error[E0495]: cannot infer an appropriate lifetime for lifetime parameter `'long` due to conflicting requirements --> $DIR/issue-107090.rs:17:13 | LL |     fn cast(&'long self) -> &'short Foo<'short, 'out, T> { |             ^^^^^^^^^^^ | note: first, the lifetime cannot outlive the lifetime `'short` as defined here... --> $DIR/issue-107090.rs:13:21 | LL | impl<'long: 'short, 'short, T> Convert<'long, 'b> for Foo<'short, 'out, T> { |                     ^^^^^^ = note: ...but the lifetime must also be valid for the static lifetime... note: ...so that the types are compatible --> $DIR/issue-107090.rs:17:13 | LL |     fn cast(&'long self) -> &'short Foo<'short, 'out, T> { |             ^^^^^^^^^^^ = note: expected `Convert<'short, 'static>` found `Convert<'_, 'static>` error: aborting due to 12 previous errors Some errors have detailed explanations: E0261, E0308, E0495, E0759. For more information about an error, try `rustc --explain E0261`. </ins>

[ ] Previous Stable [ ] Current Stable [ ] Current Beta [X] Current Nightly No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This is another case for And except for the missing argument issue, there is an copy-paste bug in :


Question: } } <ins> impl<'a, 'tcx> TypeVisitor<TyCtxt<'tcx>> for WfPredicates<'a, 'tcx> { type Result = (); fn visit_ty(&mut self, t: <TyCtxt<'tcx> as ty::Interner>::Ty) -> Self::Result { debug!("wf bounds for t={:?} t.kind={:#?}", t, t.kind()); match *t.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) => { self.compute_projection(data); return; // Subtree handled by compute_projection. } ty::Alias(ty::Inherent, data) => { self.compute_inherent_projection(data); return; // Subtree handled by compute_inherent_projection. } 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(t)); self.out.push(traits::Obligation::with_depth( self.tcx(), cause, self.recursion_depth, self.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) => { // 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); // 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. let upvars = args.as_closure().tupled_upvars_ty(); return upvars.visit_with(self); } ty::CoroutineClosure(did, args) => { // See the above comments. The same apply to coroutine-closures. let obligations = self.nominal_obligations(did, args); self.out.extend(obligations); let upvars = args.as_coroutine_closure().tupled_upvars_ty(); return upvars.visit_with(self); } ty::FnPtr(_) => { // Let the visitor 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(t, 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)), self.recursion_depth, self.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, self.param_env, ty::Binder::dummy(ty::PredicateKind::Clause(ty::ClauseKind::WellFormed( t.into(), ))), )); } } t.super_visit_with(self) } fn visit_const(&mut self, c: <TyCtxt<'tcx> as ty::Interner>::Const) -> Self::Result { match c.kind() { ty::ConstKind::Unevaluated(uv) => { if !c.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(c), )); 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( c.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(c), )); 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. } } c.super_visit_with(self) } fn visit_predicate(&mut self, _p: <TyCtxt<'tcx> as ty::Interner>::Predicate) -> Self::Result { bug!("predicate should not be checked for well-formedness"); } } </ins> /// Given an object type like `SomeTrait + Send`, computes the lifetime /// bounds that must hold on the elided self type. These are derived /// from the declarations of `SomeTrait`, `Send`, and friends -- if

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: <ins> error: recursion limit reached while expanding `concat!` --> $DIR/issue-84632-eager-expansion-recursion-limit.rs:8:28 | LL |     (A, $($A:ident),*) => (concat!("", a!($($A),*))) |                            ^^^^^^^^^^^^^^^^^^^^^^^^ ... LL |     a!(A, A, A, A, A, A, A, A, A, A, A); |     ------------------------------------ in this macro invocation | = help: consider adding a `#![recursion_limit="30"]` attribute to your crate (`issue_84632_eager_expansion_recursion_limit`) = note: this error originates in the macro `a` (in Nightly builds, run with -Z macro-backtrace for more info) error: aborting due to previous error </ins>

I tried this code: I expected to see this happen: An error message about exceeding some recursion limit Instead, this happened: Tested on stable 1.51.0 + <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Note that the crash also occurs without . Based on testing with Godbolt, this doesn't seem to be a regression, or at least not a recent one.
Assigning as part of the prioritization working group discussion and removing . modify labels -I-prioritize +P-medium
Issue might be in this line: Calls , which then calls : And sets to , which would result in stack overflow because the recursion limit is never reached.
claim
Bug is confusing to track down, so I am no longer working on this. For people who are interested, here is the log when the loop is encountered: release-assignment
The issue is part of a bigger problem, that seems to ignore the recursion limit. This snippet below compiles successfully instead of reporting an error:
Seems to be a regression between and by testing on Godbolt. I suspect from caused the regression, but I'm not sure. label regression-untriaged


Question: } } <ins> /// Appends an element if there is sufficient spare capacity, otherwise an error is returned /// with the element. /// /// Unlike [`push`] this method will not reallocate when there's insufficient capacity. /// The caller should use [`reserve`] or [`try_reserve`] to ensure that there is enough capacity. /// /// [`push`]: Vec::push /// [`reserve`]: Vec::reserve /// [`try_reserve`]: Vec::try_reserve /// /// # Examples /// /// A manual, panic-free alternative to [`FromIterator`]: /// /// ``` /// #![feature(vec_push_within_capacity)] /// /// use std::collections::TryReserveError; /// fn from_iter_fallible<T>(iter: impl Iterator<Item=T>) -> Result<Vec<T>, TryReserveError> { ///     let mut vec = Vec::new(); ///     for value in iter { ///         if let Err(value) = vec.push_within_capacity(value) { ///             vec.try_reserve(1)?; ///             // this cannot fail, the previous line either returned or added at least 1 free slot ///             let _ = vec.push_within_capacity(value); ///         } ///     } ///     Ok(vec) /// } /// assert_eq!(from_iter_fallible(0..100), Ok(Vec::from_iter(0..100))); /// ``` #[inline] #[unstable(feature = "vec_push_within_capacity", issue = "100486")] pub fn push_within_capacity(&mut self, value: T) -> Result<(), T> { if self.len == self.buf.capacity() { return Err(value); } unsafe { let end = self.as_mut_ptr().add(self.len); ptr::write(end, value); self.len += 1; } Ok(()) } </ins> /// Removes the last element from a vector and returns it, or [`None`] if it /// is empty. ///

This enhancement suggestion looks a bit silly to me, but I think it's worth asking for an opinion in this bug tracker. I think this is a reasonable usage pattern of and . I've used it with a larger SomeData to avoid both an useless initialization and the use of that in those cases is slightly slower, the disadvantage is that this code contains and it's a bit fiddly: An API that removes the unsafety could be: is similar to , but it doesn't include any growing strategy (and doesn't include such growing/realloc code in the binary), so it just uses the capacity. If the capacity isn't enough it panics (just like the first code panics if the capacity is finished at ).
label C-enhancement
label -C-enhancement C-feature-request
It might be better to return a instead to let the user handle the failure case.
An extra note. Currently on this code: I think LLVM12 isn't able to see that code will never realloc and doesn't need a bound test:
The naive implementation of already optimizes out the reallocation case with . Since (parts of) the reallocation code is inlined into , this would give smaller code size (). Here is a use case that I encounter fairly frequently: I want to construct a , so I preallocate one and push elements into it. However, if there is an off-by-one error in the preallocation, then it would reallocate every time. Having a function (followed by unwrap) would help catch these errors.
I suggest creating a fixed-capacity type wrapper instead, so that it can also be used with and many more methods without realloc code bloat.
I suggest creating a fixed-capacity Vec type wrapper instead, so that it can also be used with Extend and many more methods without realloc code bloat. A question: such wrapper doesn't cause bloat itself?
No, I don't think it'd be much different from deref that gives you the as a slice.
What do you envision to do when the vector runs out of space?
Panic. I also hope that the wrapper type with a fixed-size storage would be easier for optimizer to reason about (similarly how taking a slice of a vec before a loop helps remove bounds checks in the loop). If the optimizer is able to remove capacity checks, then failure handling code doesn't matter, because it will be optimized out too.


Question: } } <ins> /// Appends an element if there is sufficient spare capacity, otherwise an error is returned /// with the element. /// /// Unlike [`push`] this method will not reallocate when there's insufficient capacity. /// The caller should use [`reserve`] or [`try_reserve`] to ensure that there is enough capacity. /// /// [`push`]: Vec::push /// [`reserve`]: Vec::reserve /// [`try_reserve`]: Vec::try_reserve /// /// # Examples /// /// A manual, panic-free alternative to [`FromIterator`]: /// /// ``` /// #![feature(vec_push_within_capacity)] /// /// use std::collections::TryReserveError; /// fn from_iter_fallible<T>(iter: impl Iterator<Item=T>) -> Result<Vec<T>, TryReserveError> { ///     let mut vec = Vec::new(); ///     for value in iter { ///         if let Err(value) = vec.push_within_capacity(value) { ///             vec.try_reserve(1)?; ///             // this cannot fail, the previous line either returned or added at least 1 free slot ///             let _ = vec.push_within_capacity(value); ///         } ///     } ///     Ok(vec) /// } /// assert_eq!(from_iter_fallible(0..100), Ok(Vec::from_iter(0..100))); /// ``` #[inline] #[unstable(feature = "vec_push_within_capacity", issue = "100486")] pub fn push_within_capacity(&mut self, value: T) -> Result<(), T> { if self.len == self.buf.capacity() { return Err(value); } unsafe { let end = self.as_mut_ptr().add(self.len); ptr::write(end, value); self.len += 1; } Ok(()) } </ins> /// Removes the last element from a vector and returns it, or [`None`] if it /// is empty. ///

Interestingly, it can't be as simply implemented outside of , because the field can't be directly borrowed, but if you need to use reference and , then you can't have the slice at the same time, because it'd violate mutable aliasing rules. If necessary, the capacity error behavior could be configurable via a type parameter, e.g. or (that silently ignores excess elements). The extra argument would allow compile-time specialized code (so no extra runtime check), and inflexibility of a type argument wouldn't get in the way, because it's a temporary object that you'd create on demand, so you can create a different one for each use.
why not add unchecked versions of functions with capacity check (, , , , , ...)?


Question: ) { // Every lifetime used in an associated type must be constrained. let impl_self_ty = tcx.type_of(impl_def_id); <ins> if impl_self_ty.references_error() { // Don't complain about unconstrained type params when self ty isn't known due to errors. // (#36836) tcx.sess.delay_span_bug( tcx.def_span(impl_def_id), "potentially unconstrained type parameters weren't evaluated", ); return; } </ins> let impl_generics = tcx.generics_of(impl_def_id); let impl_predicates = tcx.predicates_of(impl_def_id); let impl_trait_ref = tcx.impl_trait_ref(impl_def_id);

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


Question: <del> Subproject commit a18df16181947edd5eb593ea0f2321e0035448ee </del> <ins> Subproject commit 5db91c7b94ca81eead6b25bcf6196b869a44ece0 </ins>

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


Question: }; let ident = Ident::new(kw::UnderscoreLifetime, elided_lifetime_span); <del> let node_ids = self.r.next_node_ids(expected_lifetimes); self.record_lifetime_res( segment_id, LifetimeRes::ElidedAnchor { start: node_ids.start, end: node_ids.end }, LifetimeElisionCandidate::Ignore, ); if !missing { // Do not create a parameter for patterns and expressions. for id in node_ids { self.record_lifetime_res( id, LifetimeRes::Infer, LifetimeElisionCandidate::Named, ); } continue; } </del> let missing_lifetime = MissingLifetime { id: node_ids.start, span: elided_lifetime_span,

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


Question: <ins> // run-rustfix fn main() { for _ in 0..256 as u8 {} //~ ERROR range endpoint is out of range for _ in 0..(256 as u8) {} //~ ERROR range endpoint is out of range } </ins>

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: printing all numbers from 0 to 255 (inclusive) Instead, this happened: : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The error is correct, 256 is indeed out of range for u8. You need to use .
You can run that code if you want, by allowing the lint: if you do you'll see that it will print nothing because the overflows and becomes , so it's which is empty. Examples like this where allowing the literal overflow would do something you don't want are exactly why this lint is deny-by-default
I've renamed this issue because the lint is correct. If there's anything to be done here, it would be to add a range-specific suggestion for this situation to help guide towards the correct code.
claim


Question: impl Stdio { fn to_handle(&self, stdio_id: c::DWORD, pipe: &mut Option<AnonPipe>) -> io::Result<Handle> { match *self { <del> // If no stdio handle is available, then inherit means that it // should still be unavailable so propagate the // INVALID_HANDLE_VALUE. </del> Stdio::Inherit => match stdio::get_handle(stdio_id) { Ok(io) => unsafe { let io = Handle::from_raw_handle(io);

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: App P: App C: Build this in Windows. Since has "windows" subsystem, it will create no console window (i.e. no process). Since is a console app, when the process is created, I expect to see one console window that prints "Hello World" infinitely. App creates its console window but no text is printed. In Windows, spawn() eventually calls to with a , whose  is hard coded to . Additionally, it also with , and set them to the . Since app uses "windows" subsystem, it does not have console. stdout is always . Combining with in causes the unexpected behavior. If I make a call to with same parameters except a "zeroed" , it exhibits the correct behavior. spawn() should only conditionally set the flag if it can obtain those device handles, and never set any of those handles . Like this (pseudo code): <!-- 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. --:
I think this will need a T-libs-api decision as the current documentation for  (and stdin/stderr) is: I would guess that this "inherit by default" is why it's implemented the way it is. But perhaps there's some wiggle room with what it means to inherit handles that don't exist so we can change it. In either case it would be good to have some way to use platform default behaviour here. label -T-libs +T-libs-api
That's exactly my point. If there is nothing to inherit in the first place, just inherit nothing. The current behavior () is simply wrong. I believe fixing it doesn't violate the current specification.
Basically, currently there are only two options when handling the stdout/stderr: inherit or pipe. I think there should be a third option: isolated - make the child handle its console by itself. For example, if user calls and , he basically says "the parent process doesn't care about the child's output". It is the same as the "windows" subsystem case above. In this case, the flag should never be set, regardless if or is called.


Question: impl Stdio { fn to_handle(&self, stdio_id: c::DWORD, pipe: &mut Option<AnonPipe>) -> io::Result<Handle> { match *self { <del> // If no stdio handle is available, then inherit means that it // should still be unavailable so propagate the // INVALID_HANDLE_VALUE. </del> Stdio::Inherit => match stdio::get_handle(stdio_id) { Ok(io) => unsafe { let io = Handle::from_raw_handle(io);

More importantly, this is de facto the default way of how a process is created in Windows. Defaulting to really makes me confused before reading the internal source code.
Not always. Parent process can still set those handles to something other than . For example, if you launch App P from IntelliJ it actually prints "Hello World!" in a loop but not in the spawned console which is empty, but in IntelliJ internal terminal. returns non invalid handle. This solution would make behaviour different depending on how you launch your app. Also, you can explicitly ask to create new console with even if your app already uses console subsystem. In this case you also likely want to avoid inheriting handles because you want output of the spawned process to be displayed in the new console, not in the existing one. This solution doesn't help with this.
I can't verify your statements since I don't have IntelliJ atm, but even it's true, isn't it IntelliJ setting up the console with maybe some special debugging API? How to you modify the code of P to achieve the same? And realistically speaking, do people actually do that with GUI apps? I think in this case, it's impossible to be 100% sure where the user wants the output at. New option might be the way to go.
Your prediction was dead-on, as it came true in While we can do this, as is proposing, it seems best here that we create a function, or set of functions, that explicitly handle this kind of situation rather than guessing.
Even with new APIs, we still need reasonable default behaviour. And the Command API is documented as inheriting handles by default. However, currently the API neglects the "no handle set" case entirely as that's not really a thing in POSIX or ISO C (well, you can close stdio but that's usually considered a Bad Thing unless you're being very very careful).


Question: "env_logger 0.4.3 (registry+https://github.com/rust-lang/crates.io-index)", "jsonrpc-core 7.0.1 (registry+https://github.com/rust-lang/crates.io-index)", "languageserver-types 0.12.0 (registry+https://github.com/rust-lang/crates.io-index)", <ins> "lazy_static 0.2.8 (registry+https://github.com/rust-lang/crates.io-index)", </ins> "log 0.3.8 (registry+https://github.com/rust-lang/crates.io-index)", "racer 2.0.9 (registry+https://github.com/rust-lang/crates.io-index)", "rls-analysis 0.4.5 (registry+https://github.com/rust-lang/crates.io-index)", "rls-data 0.9.0 (registry+https://github.com/rust-lang/crates.io-index)", "rls-span 0.4.0 (registry+https://github.com/rust-lang/crates.io-index)", "rls-vfs 0.4.4 (registry+https://github.com/rust-lang/crates.io-index)", <del> "rustfmt-nightly 0.1.9 (registry+https://github.com/rust-lang/crates.io-index)", </del> <ins> "rustfmt-nightly 0.2.1 (registry+https://github.com/rust-lang/crates.io-index)", </ins> "serde 1.0.10 (registry+https://github.com/rust-lang/crates.io-index)", "serde_derive 1.0.10 (registry+https://github.com/rust-lang/crates.io-index)", "serde_json 1.0.2 (registry+https://github.com/rust-lang/crates.io-index)",

First seen on as , looks like: compilefail,E0422nfn main () {n let x = Foo { x: 1, y: 2 };n}ncompilefailnfn main () {n let foo = 1;n let x = foo { x: 1, y: 2 };n}n cc
Also hit this on Travis (same test) in .
cc me
This is causing lots of CI failures. Should this test be disabled until a fix can be found?
We believe a fix is pending in , once that lands we should be good to go.
I just saw this again, reopening...
These haven't shown up in quite some time, so closing.


Question: <ins> // edition:2018 #![feature(unboxed_closures)] use std::future::Future; async fn wrapper<F>(f: F) //~^ ERROR: expected a `FnOnce<(&'a mut i32,)>` closure, found `i32` //~| ERROR: expected a `FnOnce<(&'a mut i32,)>` closure, found `i32` //~| ERROR: expected a `FnOnce<(&'a mut i32,)>` closure, found `i32` where F:, for<'a> <i32 as FnOnce<(&'a mut i32,)>>::Output: Future<Output = ()> + 'a, { //~^ ERROR: expected a `FnOnce<(&'a mut i32,)>` closure, found `i32` let mut i = 41; &mut i; } fn main() {} </ins>

File: auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details
Regression in cc :sweat_smile:
I knew this was a source of ICEs Most of these should already be reachable if they are in the body of a constant used in an array length. If you want to try fuzzing by sticking code into a const body...


Question: <ins> fn bar() -> impl Fn() { wrap(wrap(wrap(wrap(foo())))) } fn foo() -> impl Fn() { //~^ WARNING 5:1: 5:22: function cannot return without recursing [unconditional_recursion] //~| ERROR 5:13: 5:22: cannot resolve opaque type [E0720] wrap(wrap(wrap(wrap(wrap(wrap(wrap(foo()))))))) } fn wrap(f: impl Fn()) -> impl Fn() { move || f() } fn main() { } </ins>

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


Question: <ins> fn bar() -> impl Fn() { wrap(wrap(wrap(wrap(foo())))) } fn foo() -> impl Fn() { //~^ WARNING 5:1: 5:22: function cannot return without recursing [unconditional_recursion] //~| ERROR 5:13: 5:22: cannot resolve opaque type [E0720] wrap(wrap(wrap(wrap(wrap(wrap(wrap(foo()))))))) } fn wrap(f: impl Fn()) -> impl Fn() { move || f() } fn main() { } </ins>

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


Question: nested: Vec<Ty<'tcx>>) -> VtableDefaultImplData<PredicateObligation<'tcx>> { <del> let derived_cause = self.derived_cause(obligation, ImplDerivedObligation); let obligations = nested.iter().map(|&nested_ty| { // the obligation might be higher-ranked, e.g. for<'a> &'a // int : Copy. In that case, we will wind up with // late-bound regions in the `nested` vector. So for each // one we instantiate to a skolemized region, do our work // to produce something like `&'0 int : Copy`, and then // re-bind it. This is a bit of busy-work but preserves // the invariant that we only manipulate free regions, not // bound ones. self.infcx.try(|snapshot| { let (skol_ty, skol_map) = self.infcx().skolemize_late_bound_regions(&ty::Binder(nested_ty), snapshot); let skol_predicate = util::predicate_for_default_trait_impl( self.tcx(), derived_cause.clone(), trait_def_id, obligation.recursion_depth + 1, skol_ty); match skol_predicate { Ok(skol_predicate) => Ok(self.infcx().plug_leaks(skol_map, snapshot, &skol_predicate)), Err(ErrorReported) => Err(ErrorReported) } }) }).collect::<Result<_, _>>(); let mut obligations = match obligations { Ok(o) => o, Err(ErrorReported) => Vec::new() }; </del> <ins> let mut obligations = self.collect_predicates_for_types(obligation, trait_def_id, nested); </ins> let _: Result<(),()> = self.infcx.try(|snapshot| { let (_, skol_map) =

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


Question: nested: Vec<Ty<'tcx>>) -> VtableDefaultImplData<PredicateObligation<'tcx>> { <del> let derived_cause = self.derived_cause(obligation, ImplDerivedObligation); let obligations = nested.iter().map(|&nested_ty| { // the obligation might be higher-ranked, e.g. for<'a> &'a // int : Copy. In that case, we will wind up with // late-bound regions in the `nested` vector. So for each // one we instantiate to a skolemized region, do our work // to produce something like `&'0 int : Copy`, and then // re-bind it. This is a bit of busy-work but preserves // the invariant that we only manipulate free regions, not // bound ones. self.infcx.try(|snapshot| { let (skol_ty, skol_map) = self.infcx().skolemize_late_bound_regions(&ty::Binder(nested_ty), snapshot); let skol_predicate = util::predicate_for_default_trait_impl( self.tcx(), derived_cause.clone(), trait_def_id, obligation.recursion_depth + 1, skol_ty); match skol_predicate { Ok(skol_predicate) => Ok(self.infcx().plug_leaks(skol_map, snapshot, &skol_predicate)), Err(ErrorReported) => Err(ErrorReported) } }) }).collect::<Result<_, _>>(); let mut obligations = match obligations { Ok(o) => o, Err(ErrorReported) => Vec::new() }; </del> <ins> let mut obligations = self.collect_predicates_for_types(obligation, trait_def_id, nested); </ins> let _: Result<(),()> = self.infcx.try(|snapshot| { let (_, skol_map) =

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


Question: #[license = "MIT/ASL2"]; #[crate_type = "rlib"]; #[crate_type = "dylib"]; <del> #[doc(html_logo_url = "http://www.rust-lang.org/logos/rust-logo-128x128-blk.png", </del> <ins> #[doc(html_logo_url = "http://www.rust-lang.org/logos/rust-logo-128x128-blk-v2.png", </ins> html_favicon_url = "http://www.rust-lang.org/favicon.ico", html_root_url = "http://static.rust-lang.org/doc/master")]; #[deny(unused_result, unused_must_use)];

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


Question: let out = p.wait_with_output().unwrap(); assert!(!out.status.success()); let s = str::from_utf8(&out.stderr).unwrap(); <del> assert!(!s.contains("stack backtrace") && !s.contains("foo::h"), </del> <ins> assert!(!s.contains("stack backtrace") && !s.contains(" - foo"), </ins> "bad output2: {}", s); // Make sure a stack trace is printed

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: version = "0.0.0" dependencies = [ "arena 0.0.0", <del> "backtrace 0.3.25 (registry+https://github.com/rust-lang/crates.io-index)", </del> <ins> "backtrace 0.3.29 (registry+https://github.com/rust-lang/crates.io-index)", </ins> "bitflags 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)", "byteorder 1.2.7 (registry+https://github.com/rust-lang/crates.io-index)", "chalk-engine 0.9.0 (registry+https://github.com/rust-lang/crates.io-index)",

Every since a recent nightly update, both distributed nightlies and locally built produce backtraces where every level of the stack is represented only by their memory address and the label : Sadly I don't have a more specific repro case, but I can consistently reproduce locally. Older distributed nightlies do not present this behavior.
This happens consistently for me as well (also macOS).
I've been seeing this on Linux too, though it's been at least a week. (It also may have been fixed in a rustc newer than the one servo uses)
We should have tests for backtraces, so they don't regress again in the future.
this is certainly happening on master, and it's been happening for a while, but I assumed it was my env.
It just occurred to me that this might be related to the new symbol mangling (although I doubt it).
I've been experiencing this for about a week now (also on macOS). It definitely started prior to being merged. I also have the following in my :
has absolutely no changes if you don't use the flag, so it's not from there.
It's definitely , I tried before and after. It works if you enable the "coresymbolication" feature, though that's obviously not an option for distribution. I tried the latest master of , but it didn't help.
To confirm, is everyone only experiencing problems on OSX for rustc itself? Are there problems with other projects on OSX? can you please confirm or deny your experience from Linux? Throwing in a new platform here changes this quite a lot
Ok I believe I've found the issue for OSX, but if other platforms are still an issue that would be good to know
I've only experienced this with rustc itself on OSX. Things it builds seem ok, and linux/windows seem to be ok.
No, it's still happening on Linux as of yesterday (I can try again today). I also assumed it was my env.
I think the Linux issue is separate since it's been happening much longer than the OSX one
Hey, this seems to an issue on nightly for Windows (msvc) as well: This uses backtrace via :
if that's only using the crate and not using libstd, can you open an issue on the repository? The OSX issue should be fixed in , which I'd like to finish testing and then I'll send an update to libstd.


Question: version = "0.0.0" dependencies = [ "arena 0.0.0", <del> "backtrace 0.3.25 (registry+https://github.com/rust-lang/crates.io-index)", </del> <ins> "backtrace 0.3.29 (registry+https://github.com/rust-lang/crates.io-index)", </ins> "bitflags 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)", "byteorder 1.2.7 (registry+https://github.com/rust-lang/crates.io-index)", "chalk-engine 0.9.0 (registry+https://github.com/rust-lang/crates.io-index)",

That could affect Linux as well but I doubt it, so if there are persisting Linux/Windows issues please feel free to let me know. If you can create an isolated problem which uses the crate rather than libstd that's even better!
Done: rust-lang/backtrace-rs


Question: fi fi <del> # Unless we're using an older version of LLVM, check that all LLVM components # used by tests are available. if [ "$IS_NOT_LATEST_LLVM" = "" ]; then export COMPILETEST_NEEDS_ALL_LLVM_COMPONENTS=1 fi </del> if [ "$ENABLE_GCC_CODEGEN" = "1" ]; then # If `ENABLE_GCC_CODEGEN` is set and not empty, we add the `--enable-new-symbol-mangling` # argument to `RUST_CONFIGURE_ARGS` and set the `GCC_EXEC_PREFIX` environment variable.

In we're trying to test the ABI adjustment logic of all targets. This generally works as the test is nocore and LLVM has backends for all targets available -- except it does not seem possible to test the csky target that way. Trying to add the usual leads to an error from tidy: The test passes just fine locally, so it seems like at least the downloaded LLVM has the component. I don't know why it was not to tidy's list. Cc
cc but also I think this was just an oversight.
FWIW if one just adds this to a test it does pass on CI but of course it may just be silently ignored, hard to say whether the test actually runs... this stuff makes tests quite fragile. :/
Yeah, the tidy check was to reduce the fragility because a lot of people were giving names other than the LLVM component's name, like riscv64 instead of riscv, etc.
The remaining question then is, how sure are we that the components accepted by tidy are all available on some CI runner?
Also, something else must have been going on... I this test before that sanity check was to tidy. Sadly the logs for failure are already gone.


Question: [dependencies] toml = "0.5" serde = { version = "1.0", features = ["derive"] } <ins> serde_json = "1.0" </ins>

Looking at https://rust-, it seems like Miri is getting shipped as a rustup component even though the tests fail. Unfortunately, Miri is currently entirely usable, so it'd probably be better if it did not get shipped in this state. Is that something we can do? Cc
maybe we can make the miri toolstate always go to even if it technically is just
what would be the best place to change this? I think I'd prefer Miri not to be shipped at all when the tests fail; I'd rather people stick to an old-but-working Miri than to a new-but-broken one. I found but that does not seem to decide if a component gets built for distribution or not.
seems to suggest that it is supposed to work as you describe that it should be working. Since it obviously doesn't and I can't see how that comment could be true from looking at the source, I'm guessing this is some refactoring fallout. I'll dig a little into git blame
I found it. The comment was for rls in but then the code making the comment true was removed later
See for why this is hard to fix: the builders don't even run the tool tests, so they cannot know if the tests pass. :/ Also, that's probably for the better actually, as the "tools" builder sets --cfg miri to be more Miri-friendly and we don't want that in the release artifacts.
One (crazy?) thing we could so is have the dist builders query the toolstate repo to figure out if the tests are passing...
That will either retrieve an outdated toolstate or will need to block until the toolstate is uploaded ...
Without blocking it would lag behind by 1 merged PR, yes.
would it be possible to add some kind of build assert so Miri fails on builders when Rust internals change too much?
Well builders already know when Miri fails to build because internals change too much. The issue is things that make Miri still compile but break the test suite.
would it be possible to at least change the logic that opens issues such that for Miri, it opens an issue like when the tests fail? I could also try to implement that if you point me to the right place. So far we have had zero cases of Miri tests spuriously failing.


Question: [dependencies] toml = "0.5" serde = { version = "1.0", features = ["derive"] } <ins> serde_json = "1.0" </ins>

That should be easy to do:
Gave it a shot at
had an interesting idea: can't we do the "don't ship broken tools" as part of a post-processing step? We anyway do some little amount of work when a commit hits (as opposed to ), such as actually updating the toolstate repo. So maybe that could also either delete the broken components from the S3 bucket, or else generate a file to be put into the S3 bucket that says which of the components are really there so that the broken ones can be considered "not there"? do you think something like that would be possible?
Thinking about this again, probably the most natural place to do this is in the . That could "just" also check the toolstate database for the commit it is promoting, and then (possibly only for certain tools) not add them to the nightly if their toolstate is not green.
This is biting us again right now, where CI knows that Miri is broken but we ship the component anyway, leading to CI failures in downstream projects that have Miri in their CI.
For another case where this issue got quite painful, see
My PR is because I was incorrectly assuming that all commits have their toolstate recorded in the toolstate repo. Reopening.
FTR, for testing , I downloaded some artifacts: then I edited my : and finally I ran This produces stuff in .
So looks like we have logic in that specifically does not commit to the toolstate repo if nothing changed: Unfortunately, this means that we cannot easily fetch the toolstate of the to-be-produced release in build-manifest, which caused my to fail. Would it be okay for you to change this logic to record the toolstate of all commits in the toolstate repo? Or would you prefer if I try to find another approach for solving this issue? Right now I am somewhat out of ideas though if we cannot even use the toolstate repo to communicate this information.
Wouldn't it be simpler to save list of "good" components to something like and upload it alongside tarballs? Running would show what you need.
I guess we could upload the two JSON files from the two tool runners somehow? Not sure which would be the right places to hook for that, though.
Status: blocked on which is blocked on
This seems to be finally fixed!


Question: [dependencies] toml = "0.5" serde = { version = "1.0", features = ["derive"] } <ins> serde_json = "1.0" </ins>

Today nightly was shipped with , and everything looks normal :tada:
Miri is "test-fail" now, so with the next nightly we should be able to see if indeed it gets removed from rustup as it should.
Confirmed it's working! On miri is missing.


Question: <ins> mod a { use std::marker::PhantomData; enum Bug { V = [PhantomData; { [ () ].len() ].len() as isize, //~^ ERROR mismatched closing delimiter: `]` //~| ERROR mismatched closing delimiter: `]` //~| ERROR mismatched closing delimiter: `]` //~| ERROR mismatched closing delimiter: `]` } } mod b { enum Bug { V = [Vec::new; { [].len()  ].len() as isize, //~^ ERROR mismatched closing delimiter: `]` //~| ERROR mismatched closing delimiter: `]` //~| ERROR mismatched closing delimiter: `]` //~| ERROR mismatched closing delimiter: `]` //~| ERROR type annotations needed } } mod c { enum Bug { V = [Vec::new; { [0].len() ].len() as isize, //~^ ERROR mismatched closing delimiter: `]` //~| ERROR mismatched closing delimiter: `]` //~| ERROR mismatched closing delimiter: `]` //~| ERROR mismatched closing delimiter: `]` //~| ERROR type annotations needed } } fn main() {} </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: linker_error.emit(); if sess.target.target.options.is_like_msvc && linker_not_found { <del> sess.note_without_error("the msvc targets depend on the msvc linker  but `link.exe` was not found"); sess.note_without_error("please ensure that VS 2013, VS 2015 or VS 2017  was installed with the Visual C++ option"); </del> <ins> sess.note_without_error( "the msvc targets depend on the msvc linker  but `link.exe` was not found", ); sess.note_without_error( "please ensure that VS 2013, VS 2015, VS 2017 or VS 2019  was installed with the Visual C++ option", ); </ins> } sess.abort_if_errors(); }

A localized (e.g. German) MSVC can produce non-UTF-8 output, which can become almost unreadable in the way it's currently forwarded to the user. This can be seen in an (otherwise unrelated) issue comment: Note especially this line: That output might be a lot longer for multiple LNK errors (one line per error, but the lines are not properly separated in the output, because they are converted to ) and become really hard to read. If possible, the output should be converted to Unicode in this case. (previously reported as ) NOTE from Please install Visual Studio English Language Pack side by side with your favorite language pack for UI
I’m surprised we try to interpret any output in Windows as UTF-8 as opposed to UTF-16, like we should.
I suspect that the MSVC compiler's raw output is encoded as Windows-1252 or Windows-1250 (for German) depending on the current console code page and not as UTF-16. Does solve the encoding problem?
No, neither in nor in (usually I'm working with the latter). It prints but the encoding problems persist.
Is it just MSVC which is localized, or is your system codepage itself different? If we know that a certain program's output is the system codepage we could use with to convert it. Perhaps we could check whether the output is UTF-8, and attempt to do the codepage conversion if it isn't.
I am using a German localized Windows. How can I find out the system codepage? The default CP for console windows is "850 (OEM - Multilingual Lateinisch I)".
You can call  with or .
That returns codepage numbers 1252 for and 850 for .
In which case the output from the linker appears to be , so now someone just has to add code to rustc which detects when the linker output isn't utf-8 on windows and use with instead.
I ran into this problem as well (also on a German Windows 10). As a workaround it helps if you go to in Win 10 to Settings -Region and Language -Language and add English as a language and make it default ( you may have to log out and back in again). After that, programs like should output using a locale that works with rust as it is right now.


Question: linker_error.emit(); if sess.target.target.options.is_like_msvc && linker_not_found { <del> sess.note_without_error("the msvc targets depend on the msvc linker  but `link.exe` was not found"); sess.note_without_error("please ensure that VS 2013, VS 2015 or VS 2017  was installed with the Visual C++ option"); </del> <ins> sess.note_without_error( "the msvc targets depend on the msvc linker  but `link.exe` was not found", ); sess.note_without_error( "please ensure that VS 2013, VS 2015, VS 2017 or VS 2019  was installed with the Visual C++ option", ); </ins> } sess.abort_if_errors(); }

It would still be great if this could be fixed in rust :)
Just saw another instance of this in , except with ) (a common encoding in China), where got printed instead of the desired .
Using nightly 2019-07-04, we can confirm that this issue is fixed. (I'm using Chinese version of Visual Studio).
For me, it still does not work even with nightly build (1.38 x86_64-pc-windows-msvc, Russian version of VS). I try to compile a Hello world project in Intellij Idea but always get the exception:
Could you execute and see what that outputs?
That's a little strange. Could you open "x64 Native Tools Command Prompt for Visual Studio 2019" from start menu, and execute the following command: And see whether the output is English? If the output's still not in English, would you mind open "Visual Studio Installer" from start menu, choose "Modify" for the corresponding Visual Studio edition, and in the Language packs tab, install the English language pack. And try the instructions above again?
thanks! The hint about installing the English language pack has made the previous error disappear. But now I have another message while running in Idea: I haven't changed the path to the std library, it's looks like
Yes, this is the same error as before, it's because you didn't install windows sdk. Choose the newest one in the visual studio installer too.
thank you again. Now it's compiling and running. I'm happy ;) Just out of curiosity: was I supposed to know in advance that I would need an English lang pack and a Windows SDK when installing Visual Studio?
Please feel free to point out places where Rust tells you to install Visual Studio but does not tell you to install the Windows SDK, so that we can fix those places. It might still be worth implementing the text encoding version of the fix for people who don't have the English language pack, though I really wish we could just get unicode output out of VS without having to specify a language.
sorry, seems I was a bit inattentive. Now I double-checked: after starting rustup- the screen info says, I should assure that I have Windows SDK installed. So my fault, nothing to fix there :) Thanks.
This is not a fix anymore.


Question: linker_error.emit(); if sess.target.target.options.is_like_msvc && linker_not_found { <del> sess.note_without_error("the msvc targets depend on the msvc linker  but `link.exe` was not found"); sess.note_without_error("please ensure that VS 2013, VS 2015 or VS 2017  was installed with the Visual C++ option"); </del> <ins> sess.note_without_error( "the msvc targets depend on the msvc linker  but `link.exe` was not found", ); sess.note_without_error( "please ensure that VS 2013, VS 2015, VS 2017 or VS 2019  was installed with the Visual C++ option", ); </ins> } sess.abort_if_errors(); }

refer to
Please make sure you have installed Visual Studio English Language Pack side by side with your favorite language pack for UI for this to work.
I'm not sure this problem is really fixed. The PR that closed this kinda works around the issue because English is usually ASCII which is the same in UTF-8. However, as noted above, this relies on the Visual Studio English language pack being installed which it isn't always. And that there's no non-ascii output (e.g. file paths, etc). The suggestion to use with seems like a better fix, imho.


Question: use std::ffi::CString; <del> use rustc::hir::CodegenFnAttrFlags; </del> <ins> use rustc::hir::{CodegenFnAttrFlags, CodegenFnAttrs}; </ins> use rustc::hir::def_id::{DefId, LOCAL_CRATE}; use rustc::session::Session; use rustc::session::config::Sanitizer;

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: COMPILE_FLAGS=-g -Cprofile-generate="$(TMPDIR)" <del> # LLVM doesn't yet support instrumenting binaries that use unwinding on MSVC: # https://github.com/rust-lang/rust/issues/61002 # # Things work fine with -Cpanic=abort though. ifdef IS_MSVC COMPILE_FLAGS+= -Cpanic=abort endif </del> all: $(RUSTC) $(COMPILE_FLAGS) test.rs $(call RUN,test) || exit 1

LLVM's "IR-level" instrumentation, which is used by to generate PGO instrumented binaries, does not yet work with exception handling on Windows MSVC. The problem has been reported to LLVM for C++ here: This also affects Rust programs built with for Windows MSVC. As long as LLVM does not support exception handling there, it is a known limitation that PGO can only be used with on this platform.
PGO does not yet work on for other reasons (see ). Once it does, we should check if this problem is specific to MSVC.
I have working x86_64 windows-gnu (64 bit builds use SEH) build with PGO I'll open PR once is merged. I can do testing in meantime. FWIW simple hello world example works fine after going through PGO.
if you test, be sure to compile your LLVM with assertions: Thanks for looking into it!
I'll recompile it with assertions today later. Should the test case be using any specific code like ?
The following test case runs into the problem with MSVC: See for how the file is compiled.
It does not reproduce with gnu toolchain with Rust and LLVM assertions enabled, I'll try to remember about fixing along with gnu profiler.
Cool!
I just confirmed that (for me locally) PGO seems to work on Windows GNU. That is, I built with instrumentation, ran it, and rebuilt it with the profiling data collected. It worked just fine, no crashes. So I updated the original issue text to just mention MSVC instead of Windows in general.
It looks like is a bit too aggressive with its error reporting. For example when invoking rustc, but not compiling in our Firefox build we can the following : I'm not sure the best solution while mw is away; perhaps we should revert for now.
Maybe we can just convert the error to a warning?
Not the best long-term solution but seems ok
It looks like the was marked fixed a year ago. What's the status of this issue in rustc?


Question: offset: Size, ) -> Self { let alloc_align = alloc.inner().align; <del> assert_eq!(alloc_align, layout.align.abi); </del> <ins> assert!(alloc_align >= layout.align.abi); </ins> let read_scalar = |start, size, s: abi::Scalar, ty| { match alloc.0.read_scalar(

Error: That's this: The GVN MIR diff is this: searched nightlies: from nightly-2023-06-01 to nightly-2023-11-08 regressed nightly: nightly-2023-10-30 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
This issue is a bit old but I've now minimized the reproducer, it's in the description. the assertion that's failing here looks to me like it is simply too picky, and it should be checking if the alignment of the allocation is the alignment of the type we're reading from it, instead of exactly equal. Do you agree that this is just a too-picky assertion?
I agree the assertion is just too picky. I expect the subtlety of needing to pass the larger alignment for the llvm constant.
I can't figure out what you mean here. What LLVM constant? Why is there subtelty? Maybe I just don't understand what's going on with GVN here, I'm assuming that GVN has merged two constants together so that we're now loading part of a more-aligned constant to get a less-aligned one. Is that wrong?
I mean, this is codegen code. It creates a constant for llvm. That constant has some alignment. We need to pick the right one, between the lhs and rhs of the assert.
Where are we picking an alignment? Is it down here?
smaller repro: <!-- ICE: Rustc '-Zmir-opt-level=5 -Cdebuginfo=2 -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'assertion failed'', 'thread 'rustc' panicked at 'assertion failed'' 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: --
I don't really know.


Question: offset: Size, ) -> Self { let alloc_align = alloc.inner().align; <del> assert_eq!(alloc_align, layout.align.abi); </del> <ins> assert!(alloc_align >= layout.align.abi); </ins> let read_scalar = |start, size, s: abi::Scalar, ty| { match alloc.0.read_scalar(

TBH, the simplest solution is a codegen test, and check that the generated constant has the right over-alignment.
I don't have confidence in my ability to do that, so I think it would unblock you faster if you took this issue. I feel like just this diff is a fix for this ICE: But I don't understand why the assertion was exact in the first place, or what the hazard would be from over-aligning the allocation.


Question: Ok(true) } ty::Float(_) | ty::Int(_) | ty::Uint(_) => { <del> let value = self.ecx.read_scalar(value)?; </del> <ins> let value = try_validation!( self.ecx.read_scalar(value), self.path, err_unsup!(ReadPointerAsBytes) => { "read of part of a pointer" }, ); </ins> // NOTE: Keep this in sync with the array optimization for int/float // types below! if self.ctfe_mode.is_some() {

<!-- 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
glacier ""
Error: Parsing glacier command in failed: ...'cier https' ''... Please let know if you're having trouble with this bot.
Compiler error on but ICE on label +regression-from-stable-to-stable
cc
A previous (now-fixed) ICE with the same error message is
Thanks for the report! Would be good to get a better backtrace; this one seems to be missing many frames and there are no line numbers.
, I updated the backtrace in my first post. I used rustup to get the latest trunk version, and the one I have been using does not have line numbers. If there is a flag or configuration for rustup to get rustc binaries with line numbers, I would be happy to change the settings on my testing machine.
I think getting line numbers requires a debug build of the compiler, so it's not quite as easy as installing something via rustup.
Labeling .
Here's a backtrace with debug info: <details</details
Unfortunately, this bottoms out ; more digging will be needed to determine the true underlying cause of the error.
Here is the actual backtrace of the underlying CTFE/Miri error: <details</detailsIt points to this line: can handle pointer values just fine, so I think what is happening is that we are reading parts of a pointer value here, which indeed is not supported in CTFE.
So... I guess the fix is to make this kind of error also be permitted during validation and turn it into a proper validation error?
Permitting it at the top-level is no good, since then we don't know "where in the value" it arose. We need a version of that catches this error and turns it into a validation error with the current "path".
Oh... right, we should fix this in general, and not just wrap in .


Question: Ok(true) } ty::Float(_) | ty::Int(_) | ty::Uint(_) => { <del> let value = self.ecx.read_scalar(value)?; </del> <ins> let value = try_validation!( self.ecx.read_scalar(value), self.path, err_unsup!(ReadPointerAsBytes) => { "read of part of a pointer" }, ); </ins> // NOTE: Keep this in sync with the array optimization for int/float // types below! if self.ctfe_mode.is_some() {

Maybe we should not have any automatic way to bubble up errors and require all sites to use ?
I think we should wrap it but put the wrapped thing into a helper function sow e can also use it for the other places. So basically, you want to use a different error type for validation, one that excludes all the other errors? I am open to refactorings here.
Let's start out with wrapping, and then I can experiment with the refactoring so we can have a look at the usability effect of it Instructions: wrap the call at in a macro invocation and capture the error. Emit a validation message about the fact that reading parts of a pointer is not possible during CTFE. Don't forget to add a test (the failing example from this issue works great as a test) and run the test with
There are quite a few calls in that will all have this problem, so ideally they should all be treated this way. To avoid code duplication, it will probably make sense to move this into a helper function.
Reopening this to track that is still called unguarded a few times in , so e.g. the issue can still arise with .


Question: use middle::typeck::astconv::ast_ty_to_ty; use middle::typeck::infer; use middle::{typeck, ty, def, pat_util, stability}; <ins> use middle::const_eval::{eval_const_expr_partial, const_int, const_uint}; </ins> use util::ppaux::{ty_to_string}; use util::nodemap::NodeSet; use lint::{Context, LintPass, LintArray};

Currently overlong bit shifts are undefined behavior because that's how llvm rolls--. But even when they aren't, we should warn on something like where happens to be , since it's a useless operation that couldn't possibly return anything interesting. There's a and I imagine it'd be a common gotcha since other languages tend to read unadorned integral literals as 32bit s and then promote the in before doing the actual shift.
I think this can be closed, resolved in
Hooray!


Question: pub fn takes_non_exhaustive(_: NonExhaustiveEnum) { let _closure = |_: NonExhaustiveEnum| {}; } <ins> // ICE #117033 enum Void {} #[deny(non_exhaustive_omitted_patterns)] pub fn void(v: Void) -> ! { match v {} } </ins>

File: auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details
What is intriguing is that the transmute doesn't fail, as it is a transmute from a 1ZST to a Never-like type, which has no representations. This code is definitely unsound, but I guess this is already a known thing.
Regression in cc
:facepalm: Oops, fix here: Good catch!


Question: <ins> error[E0433]: failed to resolve: use of undeclared crate or module `should_panic` --> $DIR/check-builtin-attr-ice.rs:43:7 | LL |     #[should_panic::skip] |       ^^^^^^^^^^^^ use of undeclared crate or module `should_panic` error[E0433]: failed to resolve: use of undeclared crate or module `should_panic` --> $DIR/check-builtin-attr-ice.rs:47:7 | LL |     #[should_panic::a::b::c] |       ^^^^^^^^^^^^ use of undeclared crate or module `should_panic` error[E0433]: failed to resolve: use of undeclared crate or module `deny` --> $DIR/check-builtin-attr-ice.rs:55:7 | LL |     #[deny::skip] |       ^^^^ use of undeclared crate or module `deny` error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0433`. </ins>

<!-- ICE: Rustc '' 'error: internal compiler error: builtin attribute "shouldpanic" not handled by ', 'error: internal compiler error: builtin attribute "shouldpanic" not handled by ' 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: [checkmodattrs] checking attributes in top-level module [analysis] running analysis passes on this crate --
there are a bunch more which probably all follow the pattern... 2 "errorreason": "error: internal compiler error: builtin attribute "allow" not handled by ", 2 "errorreason": "error: internal compiler error: builtin attribute "cfgattr" not handled by ", 4 "errorreason": "error: internal compiler error: builtin attribute "cfg" not handled by ", 2 "errorreason": "error: internal compiler error: builtin attribute "cmsenonsecureentry" not handled by ", 2 "errorreason": "error: internal compiler error: builtin attribute "collapsedebuginfo" not handled by ", 6 "errorreason": "error: internal compiler error: builtin attribute "deny" not handled by ", 2 "errorreason": "error: internal compiler error: builtin attribute "doc" not handled by ", 4 "errorreason": "error: internal compiler error: builtin attribute "inline" not handled by ", 2 "errorreason": "error: internal compiler error: builtin attribute "macroexport" not handled by ", 2 "errorreason": "error: internal compiler error: builtin attribute "optimize" not handled by ", 4 "errorreason": "error: internal compiler error: builtin attribute "procmacroderive" not handled by ", 14 "errorreason": "error: internal compiler error: builtin attribute "procmacro" not handled by ", 2 "errorreason": "error: internal compiler error: builtin attribute "shouldpanic" not handled by ",
cc
Taking a look
Problem is the previous match falls through to the fallback case for etc. because it has 1 segments ... and then since et al. is a attribute, it triggers the ICE.
I have a candidate fix locally, doing some more testing
Opened as a candidate fix.


Question: } } <del> match r.read(&mut g.buf[g.len..]) { Ok(0) => { ret = Ok(g.len - start_len); break; </del> <ins> let buf = &mut g.buf[g.len..]; match r.read(buf) { Ok(0) => return Ok(g.len - start_len), Ok(n) => { // We can't allow bogus values from read. If it is too large, the returned vec could have its length // set past its capacity, or if it overflows the vec could be shortened which could create an invalid // string if this is called via read_to_string. assert!(n <= buf.len()); g.len += n; </ins> } <del> Ok(n) => g.len += n, </del> Err(ref e) if e.kind() == ErrorKind::Interrupted => {} <del> Err(e) => { ret = Err(e); break; } </del> <ins> Err(e) => return Err(e), </ins> } } <del> ret </del> } pub(crate) fn default_read_vectored<F>(read: F, bufs: &mut [IoSliceMut<'_>]) -> Result<usize>

At line 393, the guard object's field is incremented by the value returned from a read implementation. If a questionable returns a value larger than the buffer size, it will take that value and set the length of the vector over the boundary. This bug is reachable from and . Here is a that demonstrates the bug. It segfaults with .
This is definitely broken - nice find. A simple fix would be to just add an in the drop impl: You can still get weird behavior in readtoendwithreservation, but it should be memory safe and it seems best to avoid a bunch of extra logic in the main loop.
It looks like the bug was introduced in
Assigning as and removing .


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)] #![deny(non_snake_case)] #[no_mangle] pub extern "C" fn SparklingGenerationForeignFunctionInterface() {} #[rustc_error] fn main() {} //~ ERROR compilation successful </ins>

Since the function is tagged the exact name presumably has to exactly match something that another system is expecting, which may not be snake case. For example, JNI bindings will look something like
Modifying lints requires an RFC now, as it can impact a LOT of code.
(By modifying I mean "major changes" not bugfixes)
Hm, while I think new lints definitely want an RFC, modifications to existing ones can probably go through the lang team's nomination process, leading to either an immediate decision or request for RFC.
I'm fine with that, just following (what I thought was) procedure. :smile:


Question: test(parse(""), None); { <del> let build_dir = if cfg!(windows) { Some("C:tmp") } else { Some("/tmp") }; test(parse("build.build-dir = "/tmp""), build_dir); </del> <ins> let build_dir = if cfg!(windows) { "C:tmp" } else { "/tmp" }; test(parse(&format!("build.build-dir = '{build_dir}'")), Some(build_dir)); </ins> } }

On native Windows:
This looks sus: That's a which is an absolute Unix path. On Windows it will be interpreted relative to the root of the current directory. For example, if your current directory is then it'll be . (Also it'd be nice to use raw strings here because the is confusing in the context of paths)


Question: <ins> // check-pass // check that `deref_into_dyn_supertrait` doesn't cause ICE by eagerly converting // a cancelled lint #![allow(deref_into_dyn_supertrait)] trait Trait {} impl std::ops::Deref for dyn Trait + Send + Sync { type Target = dyn Trait; fn deref(&self) -> &Self::Target { self } } fn main() {} </ins>

<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --ICE with in I just noticed the error actually says openpgp-card at the bottom, perhaps compilation doesn't even get to the final crate. In any case, I'm no good at minimizing these things, so I'm handing this off to people who are good at that. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details label +E-needs-mcve
searched nightlies: from nightly-2023-01-01 to nightly-2023-01-15 regressed nightly: nightly-2023-01-14 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
This fixes the ICE, although I'm not sure if that's the right approach
label -E-needs-mcve


Question: <del> A control-flow expression was used inside a const context. </del> <ins> An unsupported expression was used inside a const context. </ins> Erroneous code example:

I have to use some sort of loop construct within a const function. does explain that loop constructs are at the moment not supported, but as I was trying out first and the compiler rejected it, it would have been helpful if the explanation would hint me towards working. I think the doc just needs a small update and I think the file to update is I tried this code: <!-- 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. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
, , and are also allowed, but is not.
if it helps, the reason is forbidden but the others work is that uses and traits in const functions are still unstable (search for 'for loops' on https://rust-).
yeah, that's understandable. The confusion on my side was simply that I didn't know I was allowed to user other control flow constructs until somebody mentioned it on IRC I actually could.


Question: // error-pattern: too big for the current fn main() { <del> let fat : [u8, ..(1<<61)+(1<<31)] = [0, ..(1<<61)+(1<<31)]; </del> <ins> let fat : [u8, ..(1<<61)+(1<<31)] = [0, ..(1u64<<61) as uint +(1u64<<31) as uint]; </ins> }


Question: | LL | fn d<const C: S>() {} |               ^ expected named lifetime parameter <del> | help: consider introducing a named lifetime parameter | LL | fn d<'a, const C: S<'a>>() {} |      +++           ++++ </del> error[E0770]: the type of const parameters must not depend on other generic parameters --> $DIR/unusual-rib-combinations.rs:29:22

<!-- 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
searched nightlies: from nightly-2023-02-17 to nightly-2023-02-19 regressed nightly: nightly-2023-02-18 searched commit range: regressed commit: - -cc <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details


Question: <del> Subproject commit 68ff8b19bc6705724d1e77a8dc17ffb8dfbbe26b </del> <ins> Subproject commit edd90473ec5ba29b9ae1ee706c982e7046a6e63e </ins>

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


Question: IfExpression(a) => { format!("IfExpression({})", a.repr(tcx)) } <ins> IfExpressionWithNoElse(a) => { format!("IfExpressionWithNoElse({})", a.repr(tcx)) } </ins> } } }

I apologize in advance if this is a separate issue. With the map() generic function from the tutorial: That code gives a nice error message: However, remove the assignment and what should be the same error message becomes:
Yes, that is unrelated to this issue. You're seeing an expected type mismatch error since the return type of main() is () and your samples result in two different non-() results.
Thanks I was one hour into learning Rust when I came across this. I understand what is going on now. I still think the error message could be improved to mention that "expected " is referring to the return type of main(). That simple clue could help people not as familiar with Rust to remember the semicolon rule to turn a statement into an expression.
Not critical for 0.7, but improving error messages is always good. Nominating for milestone 5.
declined. this is bad but it's not a blocker.
Confirmed that the situation is unchanged.
This is still an issue.
Bug triage. Still an issue.
Very, very small change:


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

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


Question: #![feature(try_blocks)] fn main() { <del> while try { false } {} //~ ERROR expected expression, found reserved keyword `try` </del> <ins> while try { false } {} //~^ ERROR the trait bound `bool: std::ops::Try` is not satisfied </ins> }

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


Question: #![feature(try_blocks)] fn main() { <del> while try { false } {} //~ ERROR expected expression, found reserved keyword `try` </del> <ins> while try { false } {} //~^ ERROR the trait bound `bool: std::ops::Try` is not satisfied </ins> }

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


Question: } } } <del> // FIXME: also check auto-trait def-ids? (e.g. `impl Sync for Foo+Sync`)? </del> } }

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


Question: <ins> error[E0106]: missing lifetime specifier --> $DIR/lifetime-in-const-param.rs:5:23 | LL | struct S<'a, const N: S2>(&'a ()); |                       ^^ expected named lifetime parameter error: `S2<'_>` is forbidden as the type of a const generic parameter --> $DIR/lifetime-in-const-param.rs:5:23 | LL | struct S<'a, const N: S2>(&'a ()); |                       ^^ | = note: the only supported types are integers, `bool` and `char` = help: more complex types are supported with `#![feature(adt_const_params)]` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0106`. </ins>


Question: <ins> error: repetition matches empty token tree --> $DIR/issue-57597.rs:8:7 | LL |     ($($($i:ident)?)+) => {}; |       ^^^^^^^^^^^^^^ error: repetition matches empty token tree --> $DIR/issue-57597.rs:13:7 | LL |     ($($($i:ident)?)*) => {}; |       ^^^^^^^^^^^^^^ error: repetition matches empty token tree --> $DIR/issue-57597.rs:18:7 | LL |     ($($($i:ident)?)?) => {}; |       ^^^^^^^^^^^^^^ error: repetition matches empty token tree --> $DIR/issue-57597.rs:23:7 | LL |     ($($($($i:ident)?)?)?) => {}; |       ^^^^^^^^^^^^^^^^^^ error: repetition matches empty token tree --> $DIR/issue-57597.rs:28:7 | LL |     ($($($($i:ident)*)?)?) => {}; |       ^^^^^^^^^^^^^^^^^^ error: repetition matches empty token tree --> $DIR/issue-57597.rs:33:7 | LL |     ($($($($i:ident)?)*)?) => {}; |       ^^^^^^^^^^^^^^^^^^ error: repetition matches empty token tree --> $DIR/issue-57597.rs:38:7 | LL |     ($($($($i:ident)?)?)*) => {}; |       ^^^^^^^^^^^^^^^^^^ error: repetition matches empty token tree --> $DIR/issue-57597.rs:43:7 | LL |     ($($($($i:ident)*)*)?) => {}; |       ^^^^^^^^^^^^^^^^^^ error: repetition matches empty token tree --> $DIR/issue-57597.rs:48:7 | LL |     ($($($($i:ident)?)*)*) => {}; |       ^^^^^^^^^^^^^^^^^^ error: repetition matches empty token tree --> $DIR/issue-57597.rs:53:7 | LL |     ($($($($i:ident)?)*)+) => {}; |       ^^^^^^^^^^^^^^^^^^ error: repetition matches empty token tree --> $DIR/issue-57597.rs:58:7 | LL |     ($($($($i:ident)+)?)*) => {}; |       ^^^^^^^^^^^^^^^^^^ error: repetition matches empty token tree --> $DIR/issue-57597.rs:63:7 | LL |     ($($($($i:ident)+)*)?) => {}; |       ^^^^^^^^^^^^^^^^^^ error: aborting due to 12 previous errors </ins>

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