Question:
When using to create an enum variant in Rust 1.37+, we get an error: results in: but if the enum is constructed explicitly, the compilation succeeds: Looking at , it looks like should be considered a with . Playground links for both variants: ,
Duplicate of (will close in a bit). It seems like folks open this issue because on stable, the error message does not point to the tracking issue, e.g. you don't see: can we fix this?
I think we should just stabilize it
Is this diagnostics problem specific to this feature gate? I meant a more general fix to const-fn related gates.
Not sure. I thought we're using the normal feature gate infra
Reopening this to make sure we add a test per

<del> error: `std::prelude::v1::Some` is not yet stable as a const fn --> $DIR/feature-gate-const_constructor.rs:9:37 | LL | const EXTERNAL_CONST: Option<i32> = {Some}(1); |                                     ^^^^^^^^^ | = help: add `#![feature(const_constructor)]` to the crate attributes to enable error: `E::V` is not yet stable as a const fn --> $DIR/feature-gate-const_constructor.rs:12:24 | LL | const LOCAL_CONST: E = {E::V}(1); |                        ^^^^^^^^^ | = help: add `#![feature(const_constructor)]` to the crate attributes to enable error: `std::prelude::v1::Some` is not yet stable as a const fn --> $DIR/feature-gate-const_constructor.rs:17:13 | LL |     let _ = {Some}(1); |             ^^^^^^^^^ | = help: add `#![feature(const_constructor)]` to the crate attributes to enable error: `E::V` is not yet stable as a const fn --> $DIR/feature-gate-const_constructor.rs:23:13 | LL |     let _ = {E::V}(1); |             ^^^^^^^^^ | = help: add `#![feature(const_constructor)]` to the crate attributes to enable error: aborting due to 4 previous errors </del>


Question:
When using to create an enum variant in Rust 1.37+, we get an error: results in: but if the enum is constructed explicitly, the compilation succeeds: Looking at , it looks like should be considered a with . Playground links for both variants: ,
Duplicate of (will close in a bit). It seems like folks open this issue because on stable, the error message does not point to the tracking issue, e.g. you don't see: can we fix this?
I think we should just stabilize it
Is this diagnostics problem specific to this feature gate? I meant a more general fix to const-fn related gates.
Not sure. I thought we're using the normal feature gate infra
Reopening this to make sure we add a test per

<del> // revisions: min_const_fn const_fn #![cfg_attr(const_fn, feature(const_fn))] enum E { V(i32), } const EXTERNAL_CONST: Option<i32> = {Some}(1); //[min_const_fn]~^ ERROR is not yet stable as a const fn //[const_fn]~^^ ERROR is not yet stable as a const fn const LOCAL_CONST: E = {E::V}(1); //[min_const_fn]~^ ERROR is not yet stable as a const fn //[const_fn]~^^ ERROR is not yet stable as a const fn const fn external_fn() { let _ = {Some}(1); //[min_const_fn]~^ ERROR is not yet stable as a const fn //[const_fn]~^^ ERROR is not yet stable as a const fn } const fn local_fn() { let _ = {E::V}(1); //[min_const_fn]~^ ERROR is not yet stable as a const fn //[const_fn]~^^ ERROR is not yet stable as a const fn } fn main() {} </del>


Question:
This ICEs on stable, probably since March 2018, but it requires the user to do UB in constants, so... I think a possible fix would be to enable validation in const eval (cc ), though we should benchmark the perf considerations around that first. Alternatively we can just not ICE here and instead emit an error. () Errors:
Interesting. ICEs in Miri with are also bugs, so I'd say doing more validation is not the right call. Do you have a backtrace? Which code is responsible for ICEing here and how hard/bad would it be to just error instead?
It's ICEing in and we could indeed just emit a UB error here, but it seems very... odd, since the field access check has very little to do with UB at a first glance. The layout is a union with zero fields, because it's essentially .
TBH this looks like a bug to me. That's the layout of which type, ? It should have a field, and it should not be a union. Cc
It's not a bug. Just like layout for a newtype with a single field is not a bug (E.g. ).
Precisely by analogy with , I think this is a bug. Your has a with exactly 1 field, matching what is declared. It does not have 2 fields which would be the case if it had a "pair layout". So, transparent layout changes the , but it does not change how many "fields" a type is considered to have. Similarly, has 3 fields in its layout, despite still being a . So, correspondingly, should have 1 field.
oh... right. Yea we should totally fix that
This being a layout bug would trivially break codegen, why is only miri affected?
Codegen might skip the field access because the type is uninhabited?
I wouldn't be so sure, codegen calls on layouts a lot without checking. Can the ICE print the whole ? That might be more useful here. EDIT: oh this might be why: we don't check the index at all:
yea but we can't use because that ICEs during const prop in the array case. I have a local branch that I'm playing with to get the entire picture
You can literally remove the assert to get the same effect. But if the field count is wrong I'd rather have an assert in both places and fix the count (if possible).
The full is and so far I haven't figured out how that can happen
Ah, nevermind, I found it:
Ah so that's a micro-optimization. Maybe we should compute the right thing.
computes the layout for structs but keeps returning the never layout for enums without inhabited variants

/// Free-form case. Only for errors that are never caught! Unsupported(String), <del> /// FIXME(#64506) Error used to work around accessing projections of /// uninhabited types. UninhabitedValue, </del> // -- Everything below is not categorized yet -- FunctionAbiMismatch(Abi, Abi), FunctionArgMismatch(Ty<'tcx>, Ty<'tcx>),


Question:
This ICEs on stable, probably since March 2018, but it requires the user to do UB in constants, so... I think a possible fix would be to enable validation in const eval (cc ), though we should benchmark the perf considerations around that first. Alternatively we can just not ICE here and instead emit an error. () Errors:
Interesting. ICEs in Miri with are also bugs, so I'd say doing more validation is not the right call. Do you have a backtrace? Which code is responsible for ICEing here and how hard/bad would it be to just error instead?
It's ICEing in and we could indeed just emit a UB error here, but it seems very... odd, since the field access check has very little to do with UB at a first glance. The layout is a union with zero fields, because it's essentially .
TBH this looks like a bug to me. That's the layout of which type, ? It should have a field, and it should not be a union. Cc
It's not a bug. Just like layout for a newtype with a single field is not a bug (E.g. ).
Precisely by analogy with , I think this is a bug. Your has a with exactly 1 field, matching what is declared. It does not have 2 fields which would be the case if it had a "pair layout". So, transparent layout changes the , but it does not change how many "fields" a type is considered to have. Similarly, has 3 fields in its layout, despite still being a . So, correspondingly, should have 1 field.
oh... right. Yea we should totally fix that
This being a layout bug would trivially break codegen, why is only miri affected?
Codegen might skip the field access because the type is uninhabited?
I wouldn't be so sure, codegen calls on layouts a lot without checking. Can the ICE print the whole ? That might be more useful here. EDIT: oh this might be why: we don't check the index at all:
yea but we can't use because that ICEs during const prop in the array case. I have a local branch that I'm playing with to get the entire picture
You can literally remove the assert to get the same effect. But if the field count is wrong I'd rather have an assert in both places and fix the count (if possible).
The full is and so far I haven't figured out how that can happen
Ah, nevermind, I found it:
Ah so that's a micro-optimization. Maybe we should compute the right thing.
computes the layout for structs but keeps returning the never layout for enums without inhabited variants

not a power of two"), Unsupported(ref msg) => write!(f, "{}", msg), <del> UninhabitedValue => write!(f, "tried to use an uninhabited value"), </del> } } }


Question:
This ICEs on stable, probably since March 2018, but it requires the user to do UB in constants, so... I think a possible fix would be to enable validation in const eval (cc ), though we should benchmark the perf considerations around that first. Alternatively we can just not ICE here and instead emit an error. () Errors:
Interesting. ICEs in Miri with are also bugs, so I'd say doing more validation is not the right call. Do you have a backtrace? Which code is responsible for ICEing here and how hard/bad would it be to just error instead?
It's ICEing in and we could indeed just emit a UB error here, but it seems very... odd, since the field access check has very little to do with UB at a first glance. The layout is a union with zero fields, because it's essentially .
TBH this looks like a bug to me. That's the layout of which type, ? It should have a field, and it should not be a union. Cc
It's not a bug. Just like layout for a newtype with a single field is not a bug (E.g. ).
Precisely by analogy with , I think this is a bug. Your has a with exactly 1 field, matching what is declared. It does not have 2 fields which would be the case if it had a "pair layout". So, transparent layout changes the , but it does not change how many "fields" a type is considered to have. Similarly, has 3 fields in its layout, despite still being a . So, correspondingly, should have 1 field.
oh... right. Yea we should totally fix that
This being a layout bug would trivially break codegen, why is only miri affected?
Codegen might skip the field access because the type is uninhabited?
I wouldn't be so sure, codegen calls on layouts a lot without checking. Can the ICE print the whole ? That might be more useful here. EDIT: oh this might be why: we don't check the index at all:
yea but we can't use because that ICEs during const prop in the array case. I have a local branch that I'm playing with to get the entire picture
You can literally remove the assert to get the same effect. But if the field count is wrong I'd rather have an assert in both places and fix the count (if possible).
The full is and so far I haven't figured out how that can happen
Ah, nevermind, I found it:
Ah so that's a micro-optimization. Maybe we should compute the right thing.
computes the layout for structs but keeps returning the never layout for enums without inhabited variants

}); (present_variants.next(), present_variants.next()) }; <del> if present_first.is_none() { </del> <ins> let present_first = match present_first { present_first @ Some(_) => present_first, </ins> // Uninhabited because it has no variants, or only absent ones. <del> return tcx.layout_raw(param_env.and(tcx.types.never)); } </del> <ins> None if def.is_enum() => return tcx.layout_raw(param_env.and(tcx.types.never)), // if it's a struct, still compute a layout so that we can still compute the // field offsets None => Some(VariantIdx::new(0)), }; </ins> let is_struct = !def.is_enum() || // Only one variant is present.


Question:
This ICEs on stable, probably since March 2018, but it requires the user to do UB in constants, so... I think a possible fix would be to enable validation in const eval (cc ), though we should benchmark the perf considerations around that first. Alternatively we can just not ICE here and instead emit an error. () Errors:
Interesting. ICEs in Miri with are also bugs, so I'd say doing more validation is not the right call. Do you have a backtrace? Which code is responsible for ICEing here and how hard/bad would it be to just error instead?
It's ICEing in and we could indeed just emit a UB error here, but it seems very... odd, since the field access check has very little to do with UB at a first glance. The layout is a union with zero fields, because it's essentially .
TBH this looks like a bug to me. That's the layout of which type, ? It should have a field, and it should not be a union. Cc
It's not a bug. Just like layout for a newtype with a single field is not a bug (E.g. ).
Precisely by analogy with , I think this is a bug. Your has a with exactly 1 field, matching what is declared. It does not have 2 fields which would be the case if it had a "pair layout". So, transparent layout changes the , but it does not change how many "fields" a type is considered to have. Similarly, has 3 fields in its layout, despite still being a . So, correspondingly, should have 1 field.
oh... right. Yea we should totally fix that
This being a layout bug would trivially break codegen, why is only miri affected?
Codegen might skip the field access because the type is uninhabited?
I wouldn't be so sure, codegen calls on layouts a lot without checking. Can the ICE print the whole ? That might be more useful here. EDIT: oh this might be why: we don't check the index at all:
yea but we can't use because that ICEs during const prop in the array case. I have a local branch that I'm playing with to get the entire picture
You can literally remove the assert to get the same effect. But if the field count is wrong I'd rather have an assert in both places and fix the count (if possible).
The full is and so far I haven't figured out how that can happen
Ah, nevermind, I found it:
Ah so that's a micro-optimization. Maybe we should compute the right thing.
computes the layout for structs but keeps returning the never layout for enums without inhabited variants

use rustc::mir::interpret::truncate; use rustc::ty::{self, Ty}; use rustc::ty::layout::{ <del> self, Size, Abi, Align, LayoutOf, TyLayout, HasDataLayout, VariantIdx, PrimitiveExt </del> <ins> self, Size, Align, LayoutOf, TyLayout, HasDataLayout, VariantIdx, PrimitiveExt </ins> }; use rustc::ty::TypeFoldable;


Question:
This ICEs on stable, probably since March 2018, but it requires the user to do UB in constants, so... I think a possible fix would be to enable validation in const eval (cc ), though we should benchmark the perf considerations around that first. Alternatively we can just not ICE here and instead emit an error. () Errors:
Interesting. ICEs in Miri with are also bugs, so I'd say doing more validation is not the right call. Do you have a backtrace? Which code is responsible for ICEing here and how hard/bad would it be to just error instead?
It's ICEing in and we could indeed just emit a UB error here, but it seems very... odd, since the field access check has very little to do with UB at a first glance. The layout is a union with zero fields, because it's essentially .
TBH this looks like a bug to me. That's the layout of which type, ? It should have a field, and it should not be a union. Cc
It's not a bug. Just like layout for a newtype with a single field is not a bug (E.g. ).
Precisely by analogy with , I think this is a bug. Your has a with exactly 1 field, matching what is declared. It does not have 2 fields which would be the case if it had a "pair layout". So, transparent layout changes the , but it does not change how many "fields" a type is considered to have. Similarly, has 3 fields in its layout, despite still being a . So, correspondingly, should have 1 field.
oh... right. Yea we should totally fix that
This being a layout bug would trivially break codegen, why is only miri affected?
Codegen might skip the field access because the type is uninhabited?
I wouldn't be so sure, codegen calls on layouts a lot without checking. Can the ICE print the whole ? That might be more useful here. EDIT: oh this might be why: we don't check the index at all:
yea but we can't use because that ICEs during const prop in the array case. I have a local branch that I'm playing with to get the entire picture
You can literally remove the assert to get the same effect. But if the field count is wrong I'd rather have an assert in both places and fix the count (if possible).
The full is and so far I haven't figured out how that can happen
Ah, nevermind, I found it:
Ah so that's a micro-optimization. Maybe we should compute the right thing.
computes the layout for structs but keeps returning the never layout for enums without inhabited variants

layout::FieldPlacement::Array { stride, .. } => { let len = base.len(self)?; if field >= len { <del> // This can be violated because this runs during promotion on code where the // type system has not yet ensured that such things don't happen. </del> <ins> // This can be violated because the index (field) can be a runtime value // provided by the user. </ins> debug!("tried to access element {} of array/slice with length {}", field, len); throw_panic!(BoundsCheck { len, index: field }); } stride * field } layout::FieldPlacement::Union(count) => { <del> // FIXME(#64506) `UninhabitedValue` can be removed when this issue is resolved if base.layout.abi == Abi::Uninhabited { throw_unsup!(UninhabitedValue); } </del> assert!(field < count as u64, <del> "Tried to access field {} of union with {} fields", field, count); </del> <ins> "Tried to access field {} of union {:#?} with {} fields", field, base.layout, count); </ins> // Offset is always 0 Size::from_bytes(0) }


Question:
This ICEs on stable, probably since March 2018, but it requires the user to do UB in constants, so... I think a possible fix would be to enable validation in const eval (cc ), though we should benchmark the perf considerations around that first. Alternatively we can just not ICE here and instead emit an error. () Errors:
Interesting. ICEs in Miri with are also bugs, so I'd say doing more validation is not the right call. Do you have a backtrace? Which code is responsible for ICEing here and how hard/bad would it be to just error instead?
It's ICEing in and we could indeed just emit a UB error here, but it seems very... odd, since the field access check has very little to do with UB at a first glance. The layout is a union with zero fields, because it's essentially .
TBH this looks like a bug to me. That's the layout of which type, ? It should have a field, and it should not be a union. Cc
It's not a bug. Just like layout for a newtype with a single field is not a bug (E.g. ).
Precisely by analogy with , I think this is a bug. Your has a with exactly 1 field, matching what is declared. It does not have 2 fields which would be the case if it had a "pair layout". So, transparent layout changes the , but it does not change how many "fields" a type is considered to have. Similarly, has 3 fields in its layout, despite still being a . So, correspondingly, should have 1 field.
oh... right. Yea we should totally fix that
This being a layout bug would trivially break codegen, why is only miri affected?
Codegen might skip the field access because the type is uninhabited?
I wouldn't be so sure, codegen calls on layouts a lot without checking. Can the ICE print the whole ? That might be more useful here. EDIT: oh this might be why: we don't check the index at all:
yea but we can't use because that ICEs during const prop in the array case. I have a local branch that I'm playing with to get the entire picture
You can literally remove the assert to get the same effect. But if the field count is wrong I'd rather have an assert in both places and fix the count (if possible).
The full is and so far I haven't figured out how that can happen
Ah, nevermind, I found it:
Ah so that's a micro-optimization. Maybe we should compute the right thing.
computes the layout for structs but keeps returning the never layout for enums without inhabited variants

pub fn offset(&self, i: usize) -> Size { match *self { <del> FieldPlacement::Union(_) => Size::ZERO, </del> <ins> FieldPlacement::Union(count) => { assert!(i < count, "Tried to access field {} of union with {} fields", i, count); Size::ZERO }, </ins> FieldPlacement::Array { stride, count } => { let i = i as u64; assert!(i < count);


Question:
This ICEs on stable, probably since March 2018, but it requires the user to do UB in constants, so... I think a possible fix would be to enable validation in const eval (cc ), though we should benchmark the perf considerations around that first. Alternatively we can just not ICE here and instead emit an error. () Errors:
Interesting. ICEs in Miri with are also bugs, so I'd say doing more validation is not the right call. Do you have a backtrace? Which code is responsible for ICEing here and how hard/bad would it be to just error instead?
It's ICEing in and we could indeed just emit a UB error here, but it seems very... odd, since the field access check has very little to do with UB at a first glance. The layout is a union with zero fields, because it's essentially .
TBH this looks like a bug to me. That's the layout of which type, ? It should have a field, and it should not be a union. Cc
It's not a bug. Just like layout for a newtype with a single field is not a bug (E.g. ).
Precisely by analogy with , I think this is a bug. Your has a with exactly 1 field, matching what is declared. It does not have 2 fields which would be the case if it had a "pair layout". So, transparent layout changes the , but it does not change how many "fields" a type is considered to have. Similarly, has 3 fields in its layout, despite still being a . So, correspondingly, should have 1 field.
oh... right. Yea we should totally fix that
This being a layout bug would trivially break codegen, why is only miri affected?
Codegen might skip the field access because the type is uninhabited?
I wouldn't be so sure, codegen calls on layouts a lot without checking. Can the ICE print the whole ? That might be more useful here. EDIT: oh this might be why: we don't check the index at all:
yea but we can't use because that ICEs during const prop in the array case. I have a local branch that I'm playing with to get the entire picture
You can literally remove the assert to get the same effect. But if the field count is wrong I'd rather have an assert in both places and fix the count (if possible).
The full is and so far I haven't figured out how that can happen
Ah, nevermind, I found it:
Ah so that's a micro-optimization. Maybe we should compute the right thing.
computes the layout for structs but keeps returning the never layout for enums without inhabited variants

<ins> // check-pass #[derive(Copy, Clone)] pub struct ChildStdin { inner: AnonPipe, } #[derive(Copy, Clone)] enum AnonPipe {} const FOO: () = { union Foo { a: ChildStdin, b: (), } let x = unsafe { Foo { b: () }.a }; let x = &x.inner; }; fn main() {} </ins>


Question:
The following ICE's on stable, beta and nightly: <details<summaryBacktrace:</summary</detailsRunning a quick test in godbolt, the first occurrence of the ICE is in stable 1.25. Feel free to close if this is a dupe of
triage: P-medium. has fix in PR (thanks !). Assigning to latter and removing nomination label.

if let hir::ExprKind::Index(ref base, ref index) = e.kind { let mut tables = self.fcx.tables.borrow_mut(); <del> // All valid indexing looks like this; might encounter non-valid indexes at this point if let ty::Ref(_, base_ty, _) = tables.expr_ty_adjusted(&base).kind { let index_ty = tables.expr_ty_adjusted(&index); </del> <ins> // All valid indexing looks like this; might encounter non-valid indexes at this point. let base_ty = tables.expr_ty_adjusted_opt(&base).map(|t| &t.kind); if base_ty.is_none() { // When encountering `return [0][0]` outside of a `fn` body we can encounter a base // that isn't in the type table. We assume more relevant errors have already been // emitted, so we delay an ICE if none have. (#64638) self.tcx().sess.delay_span_bug(e.span, &format!("bad base: `{:?}`", base)); } if let Some(ty::Ref(_, base_ty, _)) = base_ty { let index_ty = tables.expr_ty_adjusted_opt(&index).unwrap_or_else(|| { // When encountering `return [0][0]` outside of a `fn` body we would attempt // to access an unexistend index. We assume that more relevant errors will // already have been emitted, so we only gate on this with an ICE if no // error has been emitted. (#64638) self.tcx().sess.delay_span_bug( e.span, &format!("bad index {:?} for base: `{:?}`", index, base), ); self.fcx.tcx.types.err }); </ins> let index_ty = self.fcx.resolve_vars_if_possible(&index_ty); if base_ty.builtin_index().is_some() && index_ty == self.fcx.tcx.types.usize {


Question:
The following ICE's on stable, beta and nightly: <details<summaryBacktrace:</summary</detailsRunning a quick test in godbolt, the first occurrence of the ICE is in stable 1.25. Feel free to close if this is a dupe of
triage: P-medium. has fix in PR (thanks !). Assigning to latter and removing nomination label.

<ins> enum Bug { V1 = return [0][0] //~ERROR return statement outside of function body } fn main() {} </ins>


Question:
The following ICE's on stable, beta and nightly: <details<summaryBacktrace:</summary</detailsRunning a quick test in godbolt, the first occurrence of the ICE is in stable 1.25. Feel free to close if this is a dupe of
triage: P-medium. has fix in PR (thanks !). Assigning to latter and removing nomination label.

<ins> error[E0572]: return statement outside of function body --> $DIR/issue-64620.rs:2:10 | LL |     V1 = return [0][0] |          ^^^^^^^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0572`. </ins>


Question:
Internal compiler error when missing bound on struct. Reproducible on stable/beta/nightly on . Also, not sure if it already has it's own issue, but is causing an illegal instruction error when you run it with on this code as well, which is also reproducible on playground if you turn the backtrace setting on. I tried this code: () I expected to see this happen: Instead, this happened: rustc versions (from playground): <details<summaryBacktrace (note the SIGILL at the end)</summary<p</p</details
cc
triage: P-high, removing nomination label (has PR).

// ignore it.  We can't put it on the struct header anyway. RegionKind::ReLateBound(..) => false, <ins> // This can appear in `where Self: ` bounds (#64855): // //     struct Bar<T>(<Self as Foo>::Type) where Self: ; //     struct Baz<'a>(&'a Self) where Self: ; RegionKind::ReEmpty => false, </ins> // These regions don't appear in types from type declarations: <del> RegionKind::ReEmpty | RegionKind::ReErased </del> <ins> RegionKind::ReErased </ins> | RegionKind::ReClosureBound(..) | RegionKind::ReScope(..) | RegionKind::ReVar(..)


Question:
Internal compiler error when missing bound on struct. Reproducible on stable/beta/nightly on . Also, not sure if it already has it's own issue, but is causing an illegal instruction error when you run it with on this code as well, which is also reproducible on playground if you turn the backtrace setting on. I tried this code: () I expected to see this happen: Instead, this happened: rustc versions (from playground): <details<summaryBacktrace (note the SIGILL at the end)</summary<p</p</details
cc
triage: P-high, removing nomination label (has PR).

<ins> // check-pass pub struct Bar<'a>(&'a Self) where Self: ; fn main() {} </ins>


Question:
Internal compiler error when missing bound on struct. Reproducible on stable/beta/nightly on . Also, not sure if it already has it's own issue, but is causing an illegal instruction error when you run it with on this code as well, which is also reproducible on playground if you turn the backtrace setting on. I tried this code: () I expected to see this happen: Instead, this happened: rustc versions (from playground): <details<summaryBacktrace (note the SIGILL at the end)</summary<p</p</details
cc
triage: P-high, removing nomination label (has PR).

<ins> pub trait Foo { type Type; } pub struct Bar<T>(<Self as Foo>::Type) where Self: ; //~^ ERROR the trait bound `Bar<T>: Foo` is not satisfied fn main() {} </ins>


Question:
Internal compiler error when missing bound on struct. Reproducible on stable/beta/nightly on . Also, not sure if it already has it's own issue, but is causing an illegal instruction error when you run it with on this code as well, which is also reproducible on playground if you turn the backtrace setting on. I tried this code: () I expected to see this happen: Instead, this happened: rustc versions (from playground): <details<summaryBacktrace (note the SIGILL at the end)</summary<p</p</details
cc
triage: P-high, removing nomination label (has PR).

<ins> error[E0277]: the trait bound `Bar<T>: Foo` is not satisfied --> $DIR/issue-64855.rs:5:19 | LL | pub struct Bar<T>(<Self as Foo>::Type) where Self: ; |                   ^^^^^^^^^^^^^^^^^^^ the trait `Foo` is not implemented for `Bar<T>` error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>


Question:
This fails (as expected): However, the help message is wrong: It should suggest instead. Rust version: 1.38.0 (stable)
I would like to pick this up, in case nobody is working on it
go ahead!

use syntax::feature_gate::{GateIssue, emit_feature_err}; use syntax::source_map::{DUMMY_SP, original_sp}; use syntax::symbol::{kw, sym}; <ins> use syntax::util::parser::ExprPrecedence; </ins> use std::cell::{Cell, RefCell, Ref, RefMut}; use std::collections::hash_map::Entry;


Question:
This fails (as expected): However, the help message is wrong: It should suggest instead. Rust version: 1.38.0 (stable)
I would like to pick this up, in case nobody is working on it
go ahead!

let max_len = receiver.rfind(".").unwrap(); format!("{}{}", &receiver[..max_len], method_call) } else { <del> format!("{}{}", receiver, method_call) </del> <ins> if expr.precedence().order() < ExprPrecedence::MethodCall.order() { format!("({}){}", receiver, method_call) } else { format!("{}{}", receiver, method_call) } </ins> }; Some(if is_struct_pat_shorthand_field { format!("{}: {}", receiver, sugg)


Question:
This fails (as expected): However, the help message is wrong: It should suggest instead. Rust version: 1.38.0 (stable)
I would like to pick this up, in case nobody is working on it
go ahead!

|                                               ^^^^^^^^^^ |                                               | |                                               expected struct `std::vec::Vec`, found reference <del> |                                               help: try using a conversion method: `&[1, 2, 3].to_vec()` </del> <ins> |                                               help: try using a conversion method: `(&[1, 2, 3]).to_vec()` </ins> | = note: expected type `std::vec::Vec<usize>` found type `&[{integer}; 3]`


Question:
This fails (as expected): However, the help message is wrong: It should suggest instead. Rust version: 1.38.0 (stable)
I would like to pick this up, in case nobody is working on it
go ahead!

|             ^^^^^ |             | |             cyclic type of infinite size <del> |             help: try using a conversion method: `box x.to_string()` </del> <ins> |             help: try using a conversion method: `(box x).to_string()` </ins> error[E0055]: reached the recursion limit while auto-dereferencing `Foo` --> $DIR/infinite-autoderef.rs:25:5


Question:
This fails (as expected): However, the help message is wrong: It should suggest instead. Rust version: 1.38.0 (stable)
I would like to pick this up, in case nobody is working on it
go ahead!

x //~ ERROR mismatched types } <ins> fn f() -> String { 1+2 //~ ERROR mismatched types } fn g() -> String { -2 //~ ERROR mismatched types } </ins> fn main() {}


Question:
This fails (as expected): However, the help message is wrong: It should suggest instead. Rust version: 1.38.0 (stable)
I would like to pick this up, in case nobody is working on it
go ahead!

= note: expected type `X<X<_, std::string::String>, _>` found type `X<X<_, {integer}>, _>` <del> error: aborting due to 6 previous errors </del> <ins> error[E0308]: mismatched types --> $DIR/abridged.rs:54:5 | LL | fn f() -> String { |           ------ expected `std::string::String` because of return type LL |     1+2 |     ^^^ |     | |     expected struct `std::string::String`, found integer |     help: try using a conversion method: `(1+2).to_string()` | = note: expected type `std::string::String` found type `{integer}` error[E0308]: mismatched types --> $DIR/abridged.rs:59:5 | LL | fn g() -> String { |           ------ expected `std::string::String` because of return type LL |     -2 |     ^^ |     | |     expected struct `std::string::String`, found integer |     help: try using a conversion method: `(-2).to_string()` | = note: expected type `std::string::String` found type `{integer}` error: aborting due to 8 previous errors </ins> For more information about this error, try `rustc --explain E0308`.


Question:
This fails (as expected): However, the help message is wrong: It should suggest instead. Rust version: 1.38.0 (stable)
I would like to pick this up, in case nobody is working on it
go ahead!

|         ^^^^^ |         | |         cyclic type of infinite size <del> |         help: try using a conversion method: `box g.to_string()` </del> <ins> |         help: try using a conversion method: `(box g).to_string()` </ins> error: aborting due to previous error


Question:
This fails (as expected): However, the help message is wrong: It should suggest instead. Rust version: 1.38.0 (stable)
I would like to pick this up, in case nobody is working on it
go ahead!

|         ^^^^^ |         | |         cyclic type of infinite size <del> |         help: try using a conversion method: `box f.to_string()` </del> <ins> |         help: try using a conversion method: `(box f).to_string()` </ins> error: aborting due to previous error


Question:
This fails (as expected): However, the help message is wrong: It should suggest instead. Rust version: 1.38.0 (stable)
I would like to pick this up, in case nobody is working on it
go ahead!

|         ^^^^^ |         | |         cyclic type of infinite size <del> |         help: try using a conversion method: `box f.to_string()` </del> <ins> |         help: try using a conversion method: `(box f).to_string()` </ins> error[E0308]: mismatched types --> $DIR/coerce-suggestions.rs:21:9


Question:
This code: Errors on with this message:
cc
regression in
I'm still building a compiler with graphviz debugging enabled so I can have a closer look, but I have a theory. I believe the problem is that we are too conservative when marking locals as . Because we pessimistically assume that type is , we also assume that type can be mutated through a shared reference. Once a shared reference to it is taken, we assume that all qualifs that could apply to are applied to that local. We should special case zero-sized arrays here, so when the borrow of occurs, it is not marked as indirectly mutable. Perhaps we could assume that zero-sized arrays never actually as well? While this change would solve this particular issue, I believe that this won't solve the problem entirely. What if we take two references to the zero-sized type ()? While the local containing the ZST itself will not be marked as indirectly mutable, the local containing the first borrow will be, which diverges from the old analysis. We may need to base whether a is indirectly mutable on the analysis.

param_env: ty::ParamEnv<'tcx>, } <ins> impl<'tcx> TransferFunction<'_, '_, 'tcx> { /// Returns `true` if this borrow would allow mutation of the `borrowed_place`. fn borrow_allows_mutation( &self, kind: mir::BorrowKind, borrowed_place: &mir::Place<'tcx>, ) -> bool { let borrowed_ty = borrowed_place.ty(self.body, self.tcx).ty; // Zero-sized types cannot be mutated, since there is nothing inside to mutate. // // FIXME: For now, we only exempt arrays of length zero. We need to carefully // consider the effects before extending this to all ZSTs. if let ty::Array(_, len) = borrowed_ty.kind { if len.try_eval_usize(self.tcx, self.param_env) == Some(0) { return false; } } match kind { mir::BorrowKind::Mut { .. } => true, | mir::BorrowKind::Shared | mir::BorrowKind::Shallow | mir::BorrowKind::Unique => !borrowed_ty.is_freeze(self.tcx, self.param_env, DUMMY_SP), } } } </ins> impl<'tcx> Visitor<'tcx> for TransferFunction<'_, '_, 'tcx> { fn visit_rvalue( &mut self,


Question:
This code: Errors on with this message:
cc
regression in
I'm still building a compiler with graphviz debugging enabled so I can have a closer look, but I have a theory. I believe the problem is that we are too conservative when marking locals as . Because we pessimistically assume that type is , we also assume that type can be mutated through a shared reference. Once a shared reference to it is taken, we assume that all qualifs that could apply to are applied to that local. We should special case zero-sized arrays here, so when the borrow of occurs, it is not marked as indirectly mutable. Perhaps we could assume that zero-sized arrays never actually as well? While this change would solve this particular issue, I believe that this won't solve the problem entirely. What if we take two references to the zero-sized type ()? While the local containing the ZST itself will not be marked as indirectly mutable, the local containing the first borrow will be, which diverges from the old analysis. We may need to base whether a is indirectly mutable on the analysis.

location: Location, ) { if let mir::Rvalue::Ref(_, kind, ref borrowed_place) = *rvalue { <del> let is_mut = match kind { mir::BorrowKind::Mut { .. } => true, | mir::BorrowKind::Shared | mir::BorrowKind::Shallow | mir::BorrowKind::Unique => { !borrowed_place .ty(self.body, self.tcx) .ty .is_freeze(self.tcx, self.param_env, DUMMY_SP) } }; if is_mut { </del> <ins> if self.borrow_allows_mutation(kind, borrowed_place) { </ins> match borrowed_place.base { mir::PlaceBase::Local(borrowed_local) if !borrowed_place.is_indirect() => self.trans.gen(borrowed_local),


Question:
This code: Errors on with this message:
cc
regression in
I'm still building a compiler with graphviz debugging enabled so I can have a closer look, but I have a theory. I believe the problem is that we are too conservative when marking locals as . Because we pessimistically assume that type is , we also assume that type can be mutated through a shared reference. Once a shared reference to it is taken, we assume that all qualifs that could apply to are applied to that local. We should special case zero-sized arrays here, so when the borrow of occurs, it is not marked as indirectly mutable. Perhaps we could assume that zero-sized arrays never actually as well? While this change would solve this particular issue, I believe that this won't solve the problem entirely. What if we take two references to the zero-sized type ()? While the local containing the ZST itself will not be marked as indirectly mutable, the local containing the first borrow will be, which diverges from the old analysis. We may need to base whether a is indirectly mutable on the analysis.

item.tcx, item.body, item.def_id, <del> &[], </del> <ins> &item.tcx.get_attrs(item.def_id), </ins> &dead_unwinds, old_dataflow::IndirectlyMutableLocals::new(item.tcx, item.body, item.param_env), |_, local| old_dataflow::DebugFormatted::new(&local),


Question:
This code: Errors on with this message:
cc
regression in
I'm still building a compiler with graphviz debugging enabled so I can have a closer look, but I have a theory. I believe the problem is that we are too conservative when marking locals as . Because we pessimistically assume that type is , we also assume that type can be mutated through a shared reference. Once a shared reference to it is taken, we assume that all qualifs that could apply to are applied to that local. We should special case zero-sized arrays here, so when the borrow of occurs, it is not marked as indirectly mutable. Perhaps we could assume that zero-sized arrays never actually as well? While this change would solve this particular issue, I believe that this won't solve the problem entirely. What if we take two references to the zero-sized type ()? While the local containing the ZST itself will not be marked as indirectly mutable, the local containing the first borrow will be, which diverges from the old analysis. We may need to base whether a is indirectly mutable on the analysis.

<ins> // Several variants of #64945. // This struct is not important, we just use it to put `T` and `'a` in scope for our associated // consts. struct Generic<'a, T>(std::marker::PhantomData<&'a T>); impl<'a, T: 'static> Generic<'a, T> { const EMPTY_SLICE: &'a [T] = { let x: &'a [T] = &[]; x }; const EMPTY_SLICE_REF: &'a &'static [T] = { let x: &'static [T] = &[]; &x //~^ ERROR `x` does not live long enough }; } static mut INTERIOR_MUT_AND_DROP: &'static [std::cell::RefCell<Vec<i32>>] = { let x: &[_] = &[]; x }; static mut INTERIOR_MUT_AND_DROP_REF: &'static &'static [std::cell::RefCell<Vec<i32>>] = { let x: &[_] = &[]; &x //~^ ERROR `x` does not live long enough }; fn main() {} </ins>


Question:
This code: Errors on with this message:
cc
regression in
I'm still building a compiler with graphviz debugging enabled so I can have a closer look, but I have a theory. I believe the problem is that we are too conservative when marking locals as . Because we pessimistically assume that type is , we also assume that type can be mutated through a shared reference. Once a shared reference to it is taken, we assume that all qualifs that could apply to are applied to that local. We should special case zero-sized arrays here, so when the borrow of occurs, it is not marked as indirectly mutable. Perhaps we could assume that zero-sized arrays never actually as well? While this change would solve this particular issue, I believe that this won't solve the problem entirely. What if we take two references to the zero-sized type ()? While the local containing the ZST itself will not be marked as indirectly mutable, the local containing the first borrow will be, which diverges from the old analysis. We may need to base whether a is indirectly mutable on the analysis.

<ins> error[E0597]: `x` does not live long enough --> $DIR/generic-slice.rs:15:9 | LL | impl<'a, T: 'static> Generic<'a, T> { |      -- lifetime `'a` defined here ... LL |         &x |         ^^ |         | |         borrowed value does not live long enough |         using this value as a constant requires that `x` is borrowed for `'a` LL | LL |     }; |     - `x` dropped here while still borrowed error[E0597]: `x` does not live long enough --> $DIR/generic-slice.rs:27:5 | LL |     &x |     ^^ |     | |     borrowed value does not live long enough |     using this value as a static requires that `x` is borrowed for `'static` LL | LL | }; | - `x` dropped here while still borrowed error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0597`. </ins>


Question:
Currently rustdoc's keyboard shortcuts use <kbd<kbdTab</kbd</kbdto cycle between the tabs at the top of search results, and the arrow keys for moving through search results. It's much more common for <kbd<kbdTab</kbd</kbdand <kbd<kbdShift</kbd+ <kbdTab</kbd</kbdto be used for navigating a list, and you can autosupport this by adding es, I think those autoskip elements as well. It's pretty bad form to override <kbd<kbdTab</kbd</kbd. Perhaps we should use for this and use something else for switching the search result tabs?
I never navigated a list using tab. I didn't even know it was a thing. O.o Also, up and down arrows seem more accurate to me and this has been integrated. As a little "bonus", uses arrows as well to go through crates. However, we can talk about adding if you want?
tabindex won't work if we override tab, that's the problem this is a well-established pattern
Even with tabindex, we'll still have to bind 'enter' key I assume to change the current search tab, no? Also, we can't bind right and left arrows to do this so we're kinda limited to find replacements. The last option would be to add a setting to disable like you proposed in I guess? But we have other issues to answer on this other one.
No, if you're using tab navigation the enter key should automatically work to "click" the currently selected thing. The browser functionality around this is quite robust, let's not reinvent it.
TIL. One less thing to worry about. :)
Triage: not aware of any work here
After coming back to this issue after such a long time, I think we should keep the current behavior.
I still disagree. I haven't had the time to prototype this, but this is very much not following the norms for keyboard navigation which has accessibility implications.
I don't see how accessibility can be impacted by this. I assume they don't go through text content the same way and that changing how the interactions are done will change anything for them. In addition to that, when included in , adding more tabindex could be problematic depending on evolutions (we some tabindex there as well).
Firstly, keyboard accessibility is not only for the blind. People may prefer keyboards over mice for many accessibiltiy reasons. However, tab navigation is a huge part of accessibility for the blind in many cases. No, that's the point, we don't actually need to add tabindex, currently we're overriding tab defaults via JS which is almost always really bad. The tab defaults for the page are quite good already, what would happen is that you would tab through focus on the top tabs, and then through all of the links and summary short strings. We may potentially want to exclude the summary short strings from tab navigation, but other than that we wouldn't be doing special tabindex stuff.
The largest problem here is that the moment you tab into the "tabs", your keyboard navigation is stuck there forever. Overriding browser tabbing with JS isn't always a problem but this is like one of the biggest reasons it usually is.
Maybe we could use left/right arrows instead of tab for switching between 'In Names' and 'In Parameters'? I think that's more clear than tabs anyway.
My rough proposal is that we remove all JS that consumes <kbd<kbdTab</kbd</kbd, potentially use on the summary entries (and on the links, if necessary, but i don't think it will be). (Negative tab index = "do not tab-focus this". Zero tab index = "please tab focus this in document order", this does not interfere with any explicitly defined positive tab indices in ) We could also add arrow key navigation, but people also use arrow keys for editing typed search phrases so that's more complex. At the very least we need to get rid of the custom JS IMO.
Hmm, personally I think I'd prefer for left/right to switch the search tabs and have to use explicitly to bring the search bar into focus. I don't think we should get rid of keyboard shortcuts for tabbing without having some replacement, even if it's a few more keystrokes.
Oh sure, I meant that we should not be capturing left/right whilst focused on the search box. We can add that event listener to the search results area, that should be fine.
But then how do you move in the search input? ;) I don't see how the current behavior blocks that? You can still move through answers using up and down arrows. But I think I'm starting to understand your issue: it's the overload we in the JS, right? Then, with what would you replace it? Also, you can use and then use afterwards.
Nothing. The browser has acceptable default tab navigation behavior, though we can improve on it by applying some s if we want You only do this when focused on the search results area
Then I'm lost: how do you switch between the three tabs? But then you need to focus on the search results area, which is almost never the case as far as can I can tell. That doesn't sound like a great idea. :-/
Tab navigate to a different "tab" and hit space. You will after hitting tab a few times. This is how keyboard navigation usually works.
That seems very counter-intuitive. Even more considering that switching between elements using isn't that common. Which is exactly why I don't think this is a good idea here. It's much more complicated than the current behavior.
This is literally how keyboard navigation typically works on the web. There are norms for how to do this, many people use this to a fair amount, some people rely strongly on it. The current behavior tab-locks you which is a huge accessibility hazard. Furthermore, it's nonintuitive, it does not follow the typical model of tab-navigation on the web.
I'm only using keyboard on my computer and I never use tab to switch between elements and I also find current shortcuts good enough.
You can switch to the "default" behavior by simply pressing "esc". I don't see why it's a problem then.
Firstly, no, the escape key exits the search pane altogether. Secondly, keyboard users will not know to expect such a thing. No matter what, it is a problem that our webpages tablock by default. I can't believe that we're having a hard time coming to agreement on that, I would have expected accessibility to be valued here :/
Some citations: From We are currently not coordinated with the structure of the webpage, and we do not follow the visual flow. From We violate this by tablocking From From Tab navigation, which is primarily how you change focus, is changing the context of the page here.
mentioned that she had been having trouble with this as well and was happy to see that it was reported.
What you're reporting isn't about accessibility but about personal preference: not using a mouse is a choice in most cases. Even though I think the current behavior is completely fine, I suggested to replace with another key. I don't want to lose the possibility to navigate the docs only with the keyboard, which is currently possible. Having to focus on tabs' title to switch between them is an absolute non-sense.
Even if this is true, what about the cases that are not the "most" case? That would be things like accessibility. Which does matter.
They can completely use rustdoc without a mouse, which was the whole point of those bindings. Accessibility does matter, I just don't agree with the arguments used here to support this.
This ... is an aspect of accessibility. Accessibility is about making your software accessible to the most number of people as possible; this includes people who are used to interacting with the web via keyboard. Even if it's a choice, it might introduce a barrier to entry to deliberately not use the choice (what if you don't even have a mouse attached to your computer and need to find one?) I do not think we should start a discussion about specific disabilities here, but there can be situations where someone has strong reasons for doing this where it's not "just a choice", as well. Furthermore tab-locking is absolutely a problem for blind users since the tab key is a key part of how blind users interact with the web and software in general. It feels roughly equivalent to locking Feel free to introduce a different keyboard shortcut for them that doesn't use tabs. My recommendation, to make this take the least amount of effort and least amount of change, was to use the default focus behavior and do nothing else. We don't have to force users to use the default focus behavior to navigate the page, I just want that to work. Alternatives would be good too; I'm having a hard time coming up with alternatives because most keys are used during typing. Note that with some tweaks we can make it so that literally the first tab-out of the search box will go to the tabs. So the workflow would be "tab, then hit tab more times to select your 'tab', and space" Also my personal feeling is that the tabs are not that used as much so I'm personally okay not having this. I'll point out that you are calling the default accessibility guidelines of the web as nonsense. This is stuff that has had a lot of work and research put into it, by people who are experts on this topic. The focus model of the web isn't perfect, but it's way better than what we'll be able to come up with. No, they cannot, because these are not clear at all, and there are norms about this so that people don't need to learn bespoke keyboard combinations for each website, because they won't. That's way too much overhead to just use a website. just didn't use search because of this. The tab-locking made it worse so she would refresh the page (not knowing that Esc works) to exit the search since the tab lock wouldn't let her otherwise, and over time stopped. She was typing URLs for documentation items directly instead of using search, which is an illustration of how bad this failure is. I'm sure she can talk more about her experience, but it is absolutely unacceptable for the answer to an accessibility issue to be "they can theoretically use it" when it is not designed for people to practically do it, since there's no obvious way to learn. Help text is not going to help here either, because, again, keyboard navigation on the web is largely a matter of norms, so people will not look for information on how to correctly keyboard navigate, they will simply dismiss the website as broken. That's a huge failure.
You can completely use rustdoc without a mouse (I don't have one for example), this isn't the issue here in my opinion. Well, we still need to keep that in mind in such discussions. I have to admit it's a bit hard to read this when I had to fight to keep rustdoc usable even without JS. But I'm glad that it's now an important parameter of rustdoc and that I'm not the only one to think about it. :) Yes, it's my whole point: I don't mind removing the current tab-locking (even less if it improves experience for people with no mouse!), but it needs to be replaced by something else. You're getting out of scope here, please not give me intentions I don't have. What I said is that the rustdoc search works without keyboard and that if we wanted to not tab-lock anymore, I'm okay with it but we needed to replace it with another key to be able to keep the same behavior overall. I'd rather simply switch fully out of the instead of doing such hacks if possible. We just need to agree on another key to have the same results. I agree with that part, but then it's a complete different issue. You're using one person to back all the reasoning here, which isn't great. I'm sorry if had a bad experience with rustdoc. But one person had issue with rustdoc doesn't mean it's a failure. Once again, it'd be nice to consider that people spent a lot of time on rustdoc and that if they knew about this, they'd be very happy about trying to improve the situation. However, I repeat myself once again: I agree that tab-locking isn't the best and I agree we should replace it and not remove it.
You theoretically can, practically it is hard to discover this keyboard setup and it does not follow norms, so people will not use it. It is! The default focus behavior of the web! Which is what is used everywhere, including on Google Search, which also has search results and tabs. This isn't a hack! This is how focus works on the web by default! We would not even have to write code to support this, our page is laid out in a way that works well without any javascript! No, I also had the same problem here, I just am more comfortable with switching to a mouse for this. I'm highlighting Katie's experience because she hit the worst failure mode -- she stopped using search entirely. Thank you. I do not mind coming up with something better, but I do not want to block it on coming up with additional keyboard shortcuts, because I think this is hard. I want to remove this, and then consider coming up with something that can replace it, keeping in mind that tab-switching would be possible by default via the keyboard the same way it is on Google. I think tab-locking is very very bad and should be gotten rid of as soon as possible.
Honestly, the fact that Google works this way should be a strong signal that we should follow suit, since most people using keyboard navigation will be used to doing it the same way there.
Hi all, I was around when implemented the feature and I have grown quite fond of how it works because it is very intuitive for me. What would you do with the tab key when it is not bound to tabbing trough the results? After pressing escape, the tab is free anyways. Just because Google does something, feels like an ad-hominem argument. Unless you would like rustdoc to collect the most common searches and report them (for a subscription?) to the crate authors too? Can you elaborate on the No-JS idea? Because this is hard for me to imagine since the filtering is very powerful at the moment and I love the reverse search which I need in like 30% of my queries. Cheers, Stefan
a data point: i was wildly surprised to find that <kbdtab</kbdswitches between tabs, and it took me a while to work out that it only happens when the textfield has focus. i usually use vimium to navigate the search results, which works because the results are just (pairs of) links: ! you might notice that the tab titles don't get annotations, because they're just s, so they're not keyboard-accessible.
how many people are necessary? even if the accessibility point is not compelling for some reason, the current tab mechanic has a very surprising behavior: if you begin a search, then empty the box (backspace, or ctrl+a and then backspace), the docs page reverts to the crate documentation as if no search had been done, but focus is still locked to the search bar. the page is visually identical to having not done a search, where tab could cycle between elements. before seeing this issue, i had encountered this and assumed that simply had some flaky javascript, did not make time to investigate, and moved on. i thought it was a bug. to return to a mode where the tab key is useful again, you have to know to press . this means does a different thing for than it does by default on every browser: is a shortcut for "stop", which stops all connections. the escape key has an expected behavior. it will not occur to someone who primarily navigates the internet by keyboard to press the escape key. i would have the tab key to cycle through through tabs and continue to the "in names" content, from top to bottom. cycling from "In Return Types" to "In Names" is an extremely narrow repurposing of tab (and shift+tab, to go backwards in tab order) command.
Then that is a problem we should address! Well, you can't get this page if you don't have javascript enabled, so in that sense, it wouldn't improve anything. :laughing: And it's exactly what I suggest by replacing instead of removing. The default web behavior exists but requires multiple actions. We can do better than that (like we currently do for example). Because the page is much simpler and I think the comparison is a bit out of context here. For reference, I was commenting on this: and I misunderstood what you meant. But that still makes more interactions than the current behavior (one), which is why I want a replacement and not a removal. And again, without javascript, you can't have the search results page. And I'm sorry about that. Which is why we're currently discussing about fixing it.
1. The whole point here is about prioritization. Until recently, I was mostly alone working on this. suggested this new feature, I thought it was nice and would improve everyone's life. Now I realize it didn't, I'm sorry about it but I still want to be able to switch tabs without losing focus on the search bar. We just need to agree on a key to do so and then it's done. Please all remember that it's mostly about priority. I don't voluntarily want to make people rustdoc's experience bad. If something doesn't feel right to you, well, it's simply because I ignored it could be used this way. Could you open a separate issue about this please?
will do. another point: in current versions of chrome, without vimium installed, pressing <kbdesc</kbddoes not release focus from the text field, it cancels the search altogether. so as far as i can see, if you don't use vimium, there's no way to recover the usual behaviour of <kbdtab</kbdonce you've done a search.
Browsers by default use the tab key for focus, which is an important accessibility property. It would just use the default behavior, which lets you switch through "tabs" and the search results This was an argument about norms: When people interact with the web, there are norms as to how things work. You can expect to find a search box at the top or top right of the page. You can expect to find a contact us at the bottom. Nobody is going to learn a billion minute things about how to use a particular website, a lot of this is based on norms. If you follow norms, you do not need to educate your users on how to use your website, which is exactly the problem we have here. Furthermore, the fact that Google -- an organization large enough to have accessibility teams to actually do the research on this -- picked the default behavior on their main website, is a pretty large signal. But okay, Bing has similar behavior, except focus starts on the first search entry, and you can shift-tab to get back to the "tabs". This is also easy behavior to replicate with a little javascript. Wikipedia doesn't have "tabs" but it has options at the top of the search and it works the same way. Oh no i'm not saying we remove all the JS here, I'm just saying that if we remove the JS around the tab key the default behavior is actually quite okay.
I meant no further custom JS. I understood what you meant. That is more interactions, but what i'm saying is that -- we are not losing the ability to do this, it's just harder (but following web norms, so nobody has to learn them!!), and given that we are currently violating many accessibility guidelines I would like to remove this behavior as soon as possible (there was less urgency for me when I filed this because I had not noticed the tablocking), and perhaps introduce new behavior later if possible. I'm having trouble imagining a good option for new behavior. The best I can think of is using the up/down arrow keys for this, which isn't super intuitive.
up/down is already used to go through items in the current tab, so we'll need another one haha. tab was very convenient for that... Well anyway, let's just pick a key, whichever the one we take and I'll open a PR so we can move on.
Just got an idea for the key: ctrl (or shift) + up/down would go through tabs up/down alone go through items in the list How does that sound?
It's voluntary (just realized it). The search page results is supposed to be switched into/out quickly by using escape or focusing on the search bar. We should really add all the rustdoc interactions into the help... I'll do that once we've settled down here.
My expectation is that arrow keys are for scrolling and tab is for selecting. It took me some time to get used to rustdoc doing things differently.
shift + up/down should be a non-option: shift+up will select the text being searched for. why must the list of tabs be cyclic? is going from the third tab to first tab in one keystroke a common task? i do not understand why tab cannot move focus from the third tab to the first item in the selected tab of results
that seems great! It seems a little unintuitive to me but that is fine, I don't think tab-switching is a particularly common operation. If you're okay with people learning the key combos I'm all for it.
I think I can explain this, wants a way to go through search results without having to defocus the search field, so that you can keep typing
Not if you in a input field. And that problem will be solved when we'll stop tab-locking. ;) Good point, ctrl+arrows then! That's a completely different behavior. But since we won't have tab-lock anymore, it'll now be possible so I guess it's all good? You'll have the choice between using rustdoc events through the search input or you can simply use the normal events by unfocusing the search input. Exactly! Great! I'll send the PR shortly then. We really need to improve the help popup.
ah, so pressing enter to (say) select an alternate tab would be out of the question since it would defocus? i can see that
Hello! Pardon the late response. As mentioned above, I would like to reiterate that is not only a conventional choice for navigating through lists such as this, but also a specified best practice for web accessibility. The W3C Working Groups's Authoring Practices says . I will try not to rehash the accessibility discussion above, but I will say that I do not own a mouse. Regardless of whether or not that is "by choice" due to a disability, this means that the tablocking behavior makes the generated documentation difficult for me to use. In many situations, rather than using the search feature, I often opt to manually type the URL's myself to navigate to a given type. While today I am a Rust engineer by trade, until very recently I worked as a front-end engineer, often focusing on improving the accessibility features of existing websites. The behavior that is requesting is not a matter of preference, it is considered an industry-wide best practice. I do not believe that citing other websites' conformance to this is an ad-hominem argument, it is reasonable supporting evidence of this position.
I use vimium for navigation and browser use. I find the rust docs to be very amenable to use of a keyboard with vimium.
Could you and implement it? Since you seem more knowledgeable in this area.
I mean, we were suggesting switching to the default behavior of the browser, so there's nothing new to implement, just code to use. I'm happy to do this or implement Guillaume's proposed keyboard shortcuts but it seems like he's already working on it? If not, happy to do this myself. There's a follow-up I'd like to experiment with which I'll implement, but I'll do that once we resolve this
Arf, another issue? :-/
While I appreciate the invitation to do so, I have very little familiarity with the internals of , and unfortunately very little bandwidth to contribute as of late. I do want to make a note of appreciation for all of the work that goes into maintaining this project, but I should disclaim that I was offering a comment describing my experience from the perspective of (a) a user of the Rust documentation impacted by keyboard accessibility, and (b) an engineer that has some previous experience with web accessibility guidelines and standards.
Nothing pressing, I just have ideas for how we can be even better here and want to experiment. I'll open PRs if I find something that works well

}); if (e.which === 38) { // up <del> if (!actives[currentTab].length || !actives[currentTab][0].previousElementSibling) { return; </del> <ins> if (e.ctrlKey) { // Going through result tabs. printTab(currentTab > 0 ? currentTab - 1 : 2); } else { if (!actives[currentTab].length || !actives[currentTab][0].previousElementSibling) { return; } addClass(actives[currentTab][0].previousElementSibling, "highlighted"); removeClass(actives[currentTab][0], "highlighted"); </ins> } <del> addClass(actives[currentTab][0].previousElementSibling, "highlighted"); removeClass(actives[currentTab][0], "highlighted"); </del> e.preventDefault(); } else if (e.which === 40) { // down <del> if (!actives[currentTab].length) { </del> <ins> if (e.ctrlKey) { // Going through result tabs. printTab(currentTab > 1 ? 0 : currentTab + 1); } else if (!actives[currentTab].length) { </ins> var results = document.getElementById("results").childNodes; if (results.length > 0) { var res = results[currentTab].getElementsByClassName("result");


Question:
Currently rustdoc's keyboard shortcuts use <kbd<kbdTab</kbd</kbdto cycle between the tabs at the top of search results, and the arrow keys for moving through search results. It's much more common for <kbd<kbdTab</kbd</kbdand <kbd<kbdShift</kbd+ <kbdTab</kbd</kbdto be used for navigating a list, and you can autosupport this by adding es, I think those autoskip elements as well. It's pretty bad form to override <kbd<kbdTab</kbd</kbd. Perhaps we should use for this and use something else for switching the search result tabs?
I never navigated a list using tab. I didn't even know it was a thing. O.o Also, up and down arrows seem more accurate to me and this has been integrated. As a little "bonus", uses arrows as well to go through crates. However, we can talk about adding if you want?
tabindex won't work if we override tab, that's the problem this is a well-established pattern
Even with tabindex, we'll still have to bind 'enter' key I assume to change the current search tab, no? Also, we can't bind right and left arrows to do this so we're kinda limited to find replacements. The last option would be to add a setting to disable like you proposed in I guess? But we have other issues to answer on this other one.
No, if you're using tab navigation the enter key should automatically work to "click" the currently selected thing. The browser functionality around this is quite robust, let's not reinvent it.
TIL. One less thing to worry about. :)
Triage: not aware of any work here
After coming back to this issue after such a long time, I think we should keep the current behavior.
I still disagree. I haven't had the time to prototype this, but this is very much not following the norms for keyboard navigation which has accessibility implications.
I don't see how accessibility can be impacted by this. I assume they don't go through text content the same way and that changing how the interactions are done will change anything for them. In addition to that, when included in , adding more tabindex could be problematic depending on evolutions (we some tabindex there as well).
Firstly, keyboard accessibility is not only for the blind. People may prefer keyboards over mice for many accessibiltiy reasons. However, tab navigation is a huge part of accessibility for the blind in many cases. No, that's the point, we don't actually need to add tabindex, currently we're overriding tab defaults via JS which is almost always really bad. The tab defaults for the page are quite good already, what would happen is that you would tab through focus on the top tabs, and then through all of the links and summary short strings. We may potentially want to exclude the summary short strings from tab navigation, but other than that we wouldn't be doing special tabindex stuff.
The largest problem here is that the moment you tab into the "tabs", your keyboard navigation is stuck there forever. Overriding browser tabbing with JS isn't always a problem but this is like one of the biggest reasons it usually is.
Maybe we could use left/right arrows instead of tab for switching between 'In Names' and 'In Parameters'? I think that's more clear than tabs anyway.
My rough proposal is that we remove all JS that consumes <kbd<kbdTab</kbd</kbd, potentially use on the summary entries (and on the links, if necessary, but i don't think it will be). (Negative tab index = "do not tab-focus this". Zero tab index = "please tab focus this in document order", this does not interfere with any explicitly defined positive tab indices in ) We could also add arrow key navigation, but people also use arrow keys for editing typed search phrases so that's more complex. At the very least we need to get rid of the custom JS IMO.
Hmm, personally I think I'd prefer for left/right to switch the search tabs and have to use explicitly to bring the search bar into focus. I don't think we should get rid of keyboard shortcuts for tabbing without having some replacement, even if it's a few more keystrokes.
Oh sure, I meant that we should not be capturing left/right whilst focused on the search box. We can add that event listener to the search results area, that should be fine.
But then how do you move in the search input? ;) I don't see how the current behavior blocks that? You can still move through answers using up and down arrows. But I think I'm starting to understand your issue: it's the overload we in the JS, right? Then, with what would you replace it? Also, you can use and then use afterwards.
Nothing. The browser has acceptable default tab navigation behavior, though we can improve on it by applying some s if we want You only do this when focused on the search results area
Then I'm lost: how do you switch between the three tabs? But then you need to focus on the search results area, which is almost never the case as far as can I can tell. That doesn't sound like a great idea. :-/
Tab navigate to a different "tab" and hit space. You will after hitting tab a few times. This is how keyboard navigation usually works.
That seems very counter-intuitive. Even more considering that switching between elements using isn't that common. Which is exactly why I don't think this is a good idea here. It's much more complicated than the current behavior.
This is literally how keyboard navigation typically works on the web. There are norms for how to do this, many people use this to a fair amount, some people rely strongly on it. The current behavior tab-locks you which is a huge accessibility hazard. Furthermore, it's nonintuitive, it does not follow the typical model of tab-navigation on the web.
I'm only using keyboard on my computer and I never use tab to switch between elements and I also find current shortcuts good enough.
You can switch to the "default" behavior by simply pressing "esc". I don't see why it's a problem then.
Firstly, no, the escape key exits the search pane altogether. Secondly, keyboard users will not know to expect such a thing. No matter what, it is a problem that our webpages tablock by default. I can't believe that we're having a hard time coming to agreement on that, I would have expected accessibility to be valued here :/
Some citations: From We are currently not coordinated with the structure of the webpage, and we do not follow the visual flow. From We violate this by tablocking From From Tab navigation, which is primarily how you change focus, is changing the context of the page here.
mentioned that she had been having trouble with this as well and was happy to see that it was reported.
What you're reporting isn't about accessibility but about personal preference: not using a mouse is a choice in most cases. Even though I think the current behavior is completely fine, I suggested to replace with another key. I don't want to lose the possibility to navigate the docs only with the keyboard, which is currently possible. Having to focus on tabs' title to switch between them is an absolute non-sense.
Even if this is true, what about the cases that are not the "most" case? That would be things like accessibility. Which does matter.
They can completely use rustdoc without a mouse, which was the whole point of those bindings. Accessibility does matter, I just don't agree with the arguments used here to support this.
This ... is an aspect of accessibility. Accessibility is about making your software accessible to the most number of people as possible; this includes people who are used to interacting with the web via keyboard. Even if it's a choice, it might introduce a barrier to entry to deliberately not use the choice (what if you don't even have a mouse attached to your computer and need to find one?) I do not think we should start a discussion about specific disabilities here, but there can be situations where someone has strong reasons for doing this where it's not "just a choice", as well. Furthermore tab-locking is absolutely a problem for blind users since the tab key is a key part of how blind users interact with the web and software in general. It feels roughly equivalent to locking Feel free to introduce a different keyboard shortcut for them that doesn't use tabs. My recommendation, to make this take the least amount of effort and least amount of change, was to use the default focus behavior and do nothing else. We don't have to force users to use the default focus behavior to navigate the page, I just want that to work. Alternatives would be good too; I'm having a hard time coming up with alternatives because most keys are used during typing. Note that with some tweaks we can make it so that literally the first tab-out of the search box will go to the tabs. So the workflow would be "tab, then hit tab more times to select your 'tab', and space" Also my personal feeling is that the tabs are not that used as much so I'm personally okay not having this. I'll point out that you are calling the default accessibility guidelines of the web as nonsense. This is stuff that has had a lot of work and research put into it, by people who are experts on this topic. The focus model of the web isn't perfect, but it's way better than what we'll be able to come up with. No, they cannot, because these are not clear at all, and there are norms about this so that people don't need to learn bespoke keyboard combinations for each website, because they won't. That's way too much overhead to just use a website. just didn't use search because of this. The tab-locking made it worse so she would refresh the page (not knowing that Esc works) to exit the search since the tab lock wouldn't let her otherwise, and over time stopped. She was typing URLs for documentation items directly instead of using search, which is an illustration of how bad this failure is. I'm sure she can talk more about her experience, but it is absolutely unacceptable for the answer to an accessibility issue to be "they can theoretically use it" when it is not designed for people to practically do it, since there's no obvious way to learn. Help text is not going to help here either, because, again, keyboard navigation on the web is largely a matter of norms, so people will not look for information on how to correctly keyboard navigate, they will simply dismiss the website as broken. That's a huge failure.
You can completely use rustdoc without a mouse (I don't have one for example), this isn't the issue here in my opinion. Well, we still need to keep that in mind in such discussions. I have to admit it's a bit hard to read this when I had to fight to keep rustdoc usable even without JS. But I'm glad that it's now an important parameter of rustdoc and that I'm not the only one to think about it. :) Yes, it's my whole point: I don't mind removing the current tab-locking (even less if it improves experience for people with no mouse!), but it needs to be replaced by something else. You're getting out of scope here, please not give me intentions I don't have. What I said is that the rustdoc search works without keyboard and that if we wanted to not tab-lock anymore, I'm okay with it but we needed to replace it with another key to be able to keep the same behavior overall. I'd rather simply switch fully out of the instead of doing such hacks if possible. We just need to agree on another key to have the same results. I agree with that part, but then it's a complete different issue. You're using one person to back all the reasoning here, which isn't great. I'm sorry if had a bad experience with rustdoc. But one person had issue with rustdoc doesn't mean it's a failure. Once again, it'd be nice to consider that people spent a lot of time on rustdoc and that if they knew about this, they'd be very happy about trying to improve the situation. However, I repeat myself once again: I agree that tab-locking isn't the best and I agree we should replace it and not remove it.
You theoretically can, practically it is hard to discover this keyboard setup and it does not follow norms, so people will not use it. It is! The default focus behavior of the web! Which is what is used everywhere, including on Google Search, which also has search results and tabs. This isn't a hack! This is how focus works on the web by default! We would not even have to write code to support this, our page is laid out in a way that works well without any javascript! No, I also had the same problem here, I just am more comfortable with switching to a mouse for this. I'm highlighting Katie's experience because she hit the worst failure mode -- she stopped using search entirely. Thank you. I do not mind coming up with something better, but I do not want to block it on coming up with additional keyboard shortcuts, because I think this is hard. I want to remove this, and then consider coming up with something that can replace it, keeping in mind that tab-switching would be possible by default via the keyboard the same way it is on Google. I think tab-locking is very very bad and should be gotten rid of as soon as possible.
Honestly, the fact that Google works this way should be a strong signal that we should follow suit, since most people using keyboard navigation will be used to doing it the same way there.
Hi all, I was around when implemented the feature and I have grown quite fond of how it works because it is very intuitive for me. What would you do with the tab key when it is not bound to tabbing trough the results? After pressing escape, the tab is free anyways. Just because Google does something, feels like an ad-hominem argument. Unless you would like rustdoc to collect the most common searches and report them (for a subscription?) to the crate authors too? Can you elaborate on the No-JS idea? Because this is hard for me to imagine since the filtering is very powerful at the moment and I love the reverse search which I need in like 30% of my queries. Cheers, Stefan
a data point: i was wildly surprised to find that <kbdtab</kbdswitches between tabs, and it took me a while to work out that it only happens when the textfield has focus. i usually use vimium to navigate the search results, which works because the results are just (pairs of) links: ! you might notice that the tab titles don't get annotations, because they're just s, so they're not keyboard-accessible.
how many people are necessary? even if the accessibility point is not compelling for some reason, the current tab mechanic has a very surprising behavior: if you begin a search, then empty the box (backspace, or ctrl+a and then backspace), the docs page reverts to the crate documentation as if no search had been done, but focus is still locked to the search bar. the page is visually identical to having not done a search, where tab could cycle between elements. before seeing this issue, i had encountered this and assumed that simply had some flaky javascript, did not make time to investigate, and moved on. i thought it was a bug. to return to a mode where the tab key is useful again, you have to know to press . this means does a different thing for than it does by default on every browser: is a shortcut for "stop", which stops all connections. the escape key has an expected behavior. it will not occur to someone who primarily navigates the internet by keyboard to press the escape key. i would have the tab key to cycle through through tabs and continue to the "in names" content, from top to bottom. cycling from "In Return Types" to "In Names" is an extremely narrow repurposing of tab (and shift+tab, to go backwards in tab order) command.
Then that is a problem we should address! Well, you can't get this page if you don't have javascript enabled, so in that sense, it wouldn't improve anything. :laughing: And it's exactly what I suggest by replacing instead of removing. The default web behavior exists but requires multiple actions. We can do better than that (like we currently do for example). Because the page is much simpler and I think the comparison is a bit out of context here. For reference, I was commenting on this: and I misunderstood what you meant. But that still makes more interactions than the current behavior (one), which is why I want a replacement and not a removal. And again, without javascript, you can't have the search results page. And I'm sorry about that. Which is why we're currently discussing about fixing it.
1. The whole point here is about prioritization. Until recently, I was mostly alone working on this. suggested this new feature, I thought it was nice and would improve everyone's life. Now I realize it didn't, I'm sorry about it but I still want to be able to switch tabs without losing focus on the search bar. We just need to agree on a key to do so and then it's done. Please all remember that it's mostly about priority. I don't voluntarily want to make people rustdoc's experience bad. If something doesn't feel right to you, well, it's simply because I ignored it could be used this way. Could you open a separate issue about this please?
will do. another point: in current versions of chrome, without vimium installed, pressing <kbdesc</kbddoes not release focus from the text field, it cancels the search altogether. so as far as i can see, if you don't use vimium, there's no way to recover the usual behaviour of <kbdtab</kbdonce you've done a search.
Browsers by default use the tab key for focus, which is an important accessibility property. It would just use the default behavior, which lets you switch through "tabs" and the search results This was an argument about norms: When people interact with the web, there are norms as to how things work. You can expect to find a search box at the top or top right of the page. You can expect to find a contact us at the bottom. Nobody is going to learn a billion minute things about how to use a particular website, a lot of this is based on norms. If you follow norms, you do not need to educate your users on how to use your website, which is exactly the problem we have here. Furthermore, the fact that Google -- an organization large enough to have accessibility teams to actually do the research on this -- picked the default behavior on their main website, is a pretty large signal. But okay, Bing has similar behavior, except focus starts on the first search entry, and you can shift-tab to get back to the "tabs". This is also easy behavior to replicate with a little javascript. Wikipedia doesn't have "tabs" but it has options at the top of the search and it works the same way. Oh no i'm not saying we remove all the JS here, I'm just saying that if we remove the JS around the tab key the default behavior is actually quite okay.
I meant no further custom JS. I understood what you meant. That is more interactions, but what i'm saying is that -- we are not losing the ability to do this, it's just harder (but following web norms, so nobody has to learn them!!), and given that we are currently violating many accessibility guidelines I would like to remove this behavior as soon as possible (there was less urgency for me when I filed this because I had not noticed the tablocking), and perhaps introduce new behavior later if possible. I'm having trouble imagining a good option for new behavior. The best I can think of is using the up/down arrow keys for this, which isn't super intuitive.
up/down is already used to go through items in the current tab, so we'll need another one haha. tab was very convenient for that... Well anyway, let's just pick a key, whichever the one we take and I'll open a PR so we can move on.
Just got an idea for the key: ctrl (or shift) + up/down would go through tabs up/down alone go through items in the list How does that sound?
It's voluntary (just realized it). The search page results is supposed to be switched into/out quickly by using escape or focusing on the search bar. We should really add all the rustdoc interactions into the help... I'll do that once we've settled down here.
My expectation is that arrow keys are for scrolling and tab is for selecting. It took me some time to get used to rustdoc doing things differently.
shift + up/down should be a non-option: shift+up will select the text being searched for. why must the list of tabs be cyclic? is going from the third tab to first tab in one keystroke a common task? i do not understand why tab cannot move focus from the third tab to the first item in the selected tab of results
that seems great! It seems a little unintuitive to me but that is fine, I don't think tab-switching is a particularly common operation. If you're okay with people learning the key combos I'm all for it.
I think I can explain this, wants a way to go through search results without having to defocus the search field, so that you can keep typing
Not if you in a input field. And that problem will be solved when we'll stop tab-locking. ;) Good point, ctrl+arrows then! That's a completely different behavior. But since we won't have tab-lock anymore, it'll now be possible so I guess it's all good? You'll have the choice between using rustdoc events through the search input or you can simply use the normal events by unfocusing the search input. Exactly! Great! I'll send the PR shortly then. We really need to improve the help popup.
ah, so pressing enter to (say) select an alternate tab would be out of the question since it would defocus? i can see that
Hello! Pardon the late response. As mentioned above, I would like to reiterate that is not only a conventional choice for navigating through lists such as this, but also a specified best practice for web accessibility. The W3C Working Groups's Authoring Practices says . I will try not to rehash the accessibility discussion above, but I will say that I do not own a mouse. Regardless of whether or not that is "by choice" due to a disability, this means that the tablocking behavior makes the generated documentation difficult for me to use. In many situations, rather than using the search feature, I often opt to manually type the URL's myself to navigate to a given type. While today I am a Rust engineer by trade, until very recently I worked as a front-end engineer, often focusing on improving the accessibility features of existing websites. The behavior that is requesting is not a matter of preference, it is considered an industry-wide best practice. I do not believe that citing other websites' conformance to this is an ad-hominem argument, it is reasonable supporting evidence of this position.
I use vimium for navigation and browser use. I find the rust docs to be very amenable to use of a keyboard with vimium.
Could you and implement it? Since you seem more knowledgeable in this area.
I mean, we were suggesting switching to the default behavior of the browser, so there's nothing new to implement, just code to use. I'm happy to do this or implement Guillaume's proposed keyboard shortcuts but it seems like he's already working on it? If not, happy to do this myself. There's a follow-up I'd like to experiment with which I'll implement, but I'll do that once we resolve this
Arf, another issue? :-/
While I appreciate the invitation to do so, I have very little familiarity with the internals of , and unfortunately very little bandwidth to contribute as of late. I do want to make a note of appreciation for all of the work that goes into maintaining this project, but I should disclaim that I was offering a comment describing my experience from the perspective of (a) a user of the Rust documentation impacted by keyboard accessibility, and (b) an engineer that has some previous experience with web accessibility guidelines and standards.
Nothing pressing, I just have ideas for how we can be even better here and want to experiment. I'll open PRs if I find something that works well

document.location.href = actives[currentTab][0].getElementsByTagName("a")[0].href; } <del> } else if (e.which === 9) { // tab if (e.shiftKey) { printTab(currentTab > 0 ? currentTab - 1 : 2); } else { printTab(currentTab > 1 ? 0 : currentTab + 1); } e.preventDefault(); </del> } else if (e.which === 16) { // shift // Does nothing, it's just to avoid losing "focus" on the highlighted element. } else if (actives[currentTab].length > 0) {