Question:
removed from to make it : We can't do these checks at compile-time, since , for example, involves ptr-int cast to check the alignment: So, as the FIXME suggests, we should enable the checks only at runtime. Recently intrinsic , it allows for exactly this use case - running different code in CTFE and runtime. cc and (it seems like use of requires approval of all of the above teams) label +T-lang +T-libs +A-const-eval +A-const-fn <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Did you intend to nominate this for lang, or for libs?
kinda both: lang: for whether constevalselect is ok in general libs: whether we should start using it in stable const fn
As the assigned reviewer on , and per some of the discussion in today's T-libs meeting, it feels like it would be good to have a more thorough writeup from or someone else on wg-const-eval about what is being asked here. In particular, "lang: for whether constevalselect is ok in general" seems like a question best asked with a considerable amount of context lacking in this issue, perhaps even RFC-like text targeted at the T-lang audience. While I'm not on T-lang, I definitely couldn't make a decision without that document on what the requirements for its usage should be, and this currently doesn't place it into that context. It also seems like the question is better suited to a tracking issue (or perhaps ideally the PR adding it, rather than this issue), but that's a separate question. I imagine a similar level of context would be helpful on the libs side as well, but again, not on that team either.
Thanks for the very kind way of informing me that I was writing useless comments again. I should know better, I do know better, but idk... Anyway: The intrinsic (initially considered as a solution to , but also useful in several other situations), allows calling one of two different functions, where the function is chosen depending on whether we are const evaluating or not. This allows you to write code that behaves differently between runtime and compile-time, and we have no way of checking whether that happened. You are not allowed to use the intrinsic to actually do that though. Both code paths should behave exactly the same, but you may make the const-eval path slower or otherwise different so that it can actually be const evaluated, without losing runtime performance. Notable examples of where it would be ok to use them as far as is concerned: implementing SIMD or platform intrinsics, where the const-eval part is just a slow, pure-Rust version of the same logic skipping pointer alignment or other pointer math checks that are going to get checked by the const eval machinery anyway unsure yet: avoiding debug! and dbg! statements at compile-time (or having a different mechanism entirely for reporting them) There are no plans to expose such behaviour to users at present, this is solely for libstd/libcore implementations. The intrinsic itself (from a runtime perspective) is a trivial type-safe function and completely written in safe Rust code. Its sole magicness comes from being a lang-item that const evaluation intercepts and then chooses to behave differently on. The intrinsic is documented at Do we want to use such behaviour in an easily accessible way in std? Up to now we hid each such case behind a custom intrinsic for just that specific case. Now we have a generic mean to do so. Furthermore, but not relevant this issue, we could in the future, instead of implementing intrinsics like in CTFE wrap it in and have const path execute a regular checked division. Similar changes may simplify the CTFE machinery by transferring some of its logic into libcore Assuming T-lang has no concerns, are you willing to stabilize some const fns that are impossible to stabilize without this. The main concern is that if we ever want to back out of , doing so may require significant work in the CTFE machinery (per function using ) in order to actually remove .
Correction: the const eval machinery does not do pointer alignment checks (Cc ). But if those checks are optional anyway (as is the case here, since these used to be debug assertions), then that is okay.
Note that this does not really save code, since Miri still needs to implement the intrinsics (it will run the run-time path, not the compile-time path). So I am not sure I like this proposal -- having the intrinsic shared between CTFE and Miri gives a lot of coverage to the Miri core engine intrinsic implementation that we would not otherwise get. These comments would probably better fit some consteval_select tracking issue though?
We discussed this in today's meeting. We don't have any issue with adding these checks to or . Also, as general guidance, nobody in the lang team meeting felt that non-observable uses of in this style need direct lang team review. We'd like to see such usages CCed to for review, and cases that wg-const-eval thinks are fine (such as the three "invisible" cases in comment above) seem fine and entirely in the libs domain.
We discussed your question in the libs meeting just now. We're happy with 'low risk' usages of this intrinsic in the standard library, even in stable functions. What counts as 'low risk' we'll leave up to since y'all can best judge what the alternative would look like if would have to be removed.

pub fn copy_nonoverlapping<T>(src: *const T, dst: *mut T, count: usize); } <del> // FIXME: Perform these checks only at run time /*if cfg!(debug_assertions) && !(is_aligned_and_not_null(src) && is_aligned_and_not_null(dst) && is_nonoverlapping(src, dst, count)) { // Not panicking to keep codegen impact smaller. abort(); }*/ </del> <ins> #[cfg(debug_assertions)] fn runtime_check<T>(src: *const T, dst: *mut T, count: usize) { if !is_aligned_and_not_null(src) || !is_aligned_and_not_null(dst) || !is_nonoverlapping(src, dst, count) { // Not panicking to keep codegen impact smaller. abort(); } } #[cfg(debug_assertions)] const fn compiletime_check<T>(_src: *const T, _dst: *mut T, _count: usize) {} #[cfg(debug_assertions)] // SAFETY: runtime debug-assertions are a best-effort basis; it's fine to // not do them during compile time unsafe { const_eval_select((src, dst, count), compiletime_check, runtime_check); } </ins> // SAFETY: the safety contract for `copy_nonoverlapping` must be // upheld by the caller.


Question:
removed from to make it : We can't do these checks at compile-time, since , for example, involves ptr-int cast to check the alignment: So, as the FIXME suggests, we should enable the checks only at runtime. Recently intrinsic , it allows for exactly this use case - running different code in CTFE and runtime. cc and (it seems like use of requires approval of all of the above teams) label +T-lang +T-libs +A-const-eval +A-const-fn <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Did you intend to nominate this for lang, or for libs?
kinda both: lang: for whether constevalselect is ok in general libs: whether we should start using it in stable const fn
As the assigned reviewer on , and per some of the discussion in today's T-libs meeting, it feels like it would be good to have a more thorough writeup from or someone else on wg-const-eval about what is being asked here. In particular, "lang: for whether constevalselect is ok in general" seems like a question best asked with a considerable amount of context lacking in this issue, perhaps even RFC-like text targeted at the T-lang audience. While I'm not on T-lang, I definitely couldn't make a decision without that document on what the requirements for its usage should be, and this currently doesn't place it into that context. It also seems like the question is better suited to a tracking issue (or perhaps ideally the PR adding it, rather than this issue), but that's a separate question. I imagine a similar level of context would be helpful on the libs side as well, but again, not on that team either.
Thanks for the very kind way of informing me that I was writing useless comments again. I should know better, I do know better, but idk... Anyway: The intrinsic (initially considered as a solution to , but also useful in several other situations), allows calling one of two different functions, where the function is chosen depending on whether we are const evaluating or not. This allows you to write code that behaves differently between runtime and compile-time, and we have no way of checking whether that happened. You are not allowed to use the intrinsic to actually do that though. Both code paths should behave exactly the same, but you may make the const-eval path slower or otherwise different so that it can actually be const evaluated, without losing runtime performance. Notable examples of where it would be ok to use them as far as is concerned: implementing SIMD or platform intrinsics, where the const-eval part is just a slow, pure-Rust version of the same logic skipping pointer alignment or other pointer math checks that are going to get checked by the const eval machinery anyway unsure yet: avoiding debug! and dbg! statements at compile-time (or having a different mechanism entirely for reporting them) There are no plans to expose such behaviour to users at present, this is solely for libstd/libcore implementations. The intrinsic itself (from a runtime perspective) is a trivial type-safe function and completely written in safe Rust code. Its sole magicness comes from being a lang-item that const evaluation intercepts and then chooses to behave differently on. The intrinsic is documented at Do we want to use such behaviour in an easily accessible way in std? Up to now we hid each such case behind a custom intrinsic for just that specific case. Now we have a generic mean to do so. Furthermore, but not relevant this issue, we could in the future, instead of implementing intrinsics like in CTFE wrap it in and have const path execute a regular checked division. Similar changes may simplify the CTFE machinery by transferring some of its logic into libcore Assuming T-lang has no concerns, are you willing to stabilize some const fns that are impossible to stabilize without this. The main concern is that if we ever want to back out of , doing so may require significant work in the CTFE machinery (per function using ) in order to actually remove .
Correction: the const eval machinery does not do pointer alignment checks (Cc ). But if those checks are optional anyway (as is the case here, since these used to be debug assertions), then that is okay.
Note that this does not really save code, since Miri still needs to implement the intrinsics (it will run the run-time path, not the compile-time path). So I am not sure I like this proposal -- having the intrinsic shared between CTFE and Miri gives a lot of coverage to the Miri core engine intrinsic implementation that we would not otherwise get. These comments would probably better fit some consteval_select tracking issue though?
We discussed this in today's meeting. We don't have any issue with adding these checks to or . Also, as general guidance, nobody in the lang team meeting felt that non-observable uses of in this style need direct lang team review. We'd like to see such usages CCed to for review, and cases that wg-const-eval thinks are fine (such as the three "invisible" cases in comment above) seem fine and entirely in the libs domain.
We discussed your question in the libs meeting just now. We're happy with 'low risk' usages of this intrinsic in the standard library, even in stable functions. What counts as 'low risk' we'll leave up to since y'all can best judge what the alternative would look like if would have to be removed.

fn copy<T>(src: *const T, dst: *mut T, count: usize); } <del> // FIXME: Perform these checks only at run time /*if cfg!(debug_assertions) && !(is_aligned_and_not_null(src) && is_aligned_and_not_null(dst)) { // Not panicking to keep codegen impact smaller. abort(); }*/ </del> <ins> #[cfg(debug_assertions)] fn runtime_check<T>(src: *const T, dst: *mut T) { if !is_aligned_and_not_null(src) || !is_aligned_and_not_null(dst) { // Not panicking to keep codegen impact smaller. abort(); } } #[cfg(debug_assertions)] const fn compiletime_check<T>(_src: *const T, _dst: *mut T) {} #[cfg(debug_assertions)] // SAFETY: runtime debug-assertions are a best-effort basis; it's fine to // not do them during compile time unsafe { const_eval_select((src, dst), compiletime_check, runtime_check); } </ins> // SAFETY: the safety contract for `copy` must be upheld by the caller. unsafe { copy(src, dst, count) }


Question:
removed from to make it : We can't do these checks at compile-time, since , for example, involves ptr-int cast to check the alignment: So, as the FIXME suggests, we should enable the checks only at runtime. Recently intrinsic , it allows for exactly this use case - running different code in CTFE and runtime. cc and (it seems like use of requires approval of all of the above teams) label +T-lang +T-libs +A-const-eval +A-const-fn <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Did you intend to nominate this for lang, or for libs?
kinda both: lang: for whether constevalselect is ok in general libs: whether we should start using it in stable const fn
As the assigned reviewer on , and per some of the discussion in today's T-libs meeting, it feels like it would be good to have a more thorough writeup from or someone else on wg-const-eval about what is being asked here. In particular, "lang: for whether constevalselect is ok in general" seems like a question best asked with a considerable amount of context lacking in this issue, perhaps even RFC-like text targeted at the T-lang audience. While I'm not on T-lang, I definitely couldn't make a decision without that document on what the requirements for its usage should be, and this currently doesn't place it into that context. It also seems like the question is better suited to a tracking issue (or perhaps ideally the PR adding it, rather than this issue), but that's a separate question. I imagine a similar level of context would be helpful on the libs side as well, but again, not on that team either.
Thanks for the very kind way of informing me that I was writing useless comments again. I should know better, I do know better, but idk... Anyway: The intrinsic (initially considered as a solution to , but also useful in several other situations), allows calling one of two different functions, where the function is chosen depending on whether we are const evaluating or not. This allows you to write code that behaves differently between runtime and compile-time, and we have no way of checking whether that happened. You are not allowed to use the intrinsic to actually do that though. Both code paths should behave exactly the same, but you may make the const-eval path slower or otherwise different so that it can actually be const evaluated, without losing runtime performance. Notable examples of where it would be ok to use them as far as is concerned: implementing SIMD or platform intrinsics, where the const-eval part is just a slow, pure-Rust version of the same logic skipping pointer alignment or other pointer math checks that are going to get checked by the const eval machinery anyway unsure yet: avoiding debug! and dbg! statements at compile-time (or having a different mechanism entirely for reporting them) There are no plans to expose such behaviour to users at present, this is solely for libstd/libcore implementations. The intrinsic itself (from a runtime perspective) is a trivial type-safe function and completely written in safe Rust code. Its sole magicness comes from being a lang-item that const evaluation intercepts and then chooses to behave differently on. The intrinsic is documented at Do we want to use such behaviour in an easily accessible way in std? Up to now we hid each such case behind a custom intrinsic for just that specific case. Now we have a generic mean to do so. Furthermore, but not relevant this issue, we could in the future, instead of implementing intrinsics like in CTFE wrap it in and have const path execute a regular checked division. Similar changes may simplify the CTFE machinery by transferring some of its logic into libcore Assuming T-lang has no concerns, are you willing to stabilize some const fns that are impossible to stabilize without this. The main concern is that if we ever want to back out of , doing so may require significant work in the CTFE machinery (per function using ) in order to actually remove .
Correction: the const eval machinery does not do pointer alignment checks (Cc ). But if those checks are optional anyway (as is the case here, since these used to be debug assertions), then that is okay.
Note that this does not really save code, since Miri still needs to implement the intrinsics (it will run the run-time path, not the compile-time path). So I am not sure I like this proposal -- having the intrinsic shared between CTFE and Miri gives a lot of coverage to the Miri core engine intrinsic implementation that we would not otherwise get. These comments would probably better fit some consteval_select tracking issue though?
We discussed this in today's meeting. We don't have any issue with adding these checks to or . Also, as general guidance, nobody in the lang team meeting felt that non-observable uses of in this style need direct lang team review. We'd like to see such usages CCed to for review, and cases that wg-const-eval thinks are fine (such as the three "invisible" cases in comment above) seem fine and entirely in the libs domain.
We discussed your question in the libs meeting just now. We're happy with 'low risk' usages of this intrinsic in the standard library, even in stable functions. What counts as 'low risk' we'll leave up to since y'all can best judge what the alternative would look like if would have to be removed.

#![feature(const_caller_location)] #![feature(const_cell_into_inner)] #![feature(const_discriminant)] <del> #![cfg_attr(not(bootstrap), feature(const_eval_select))] </del> <ins> #![feature(const_eval_select)] </ins> #![feature(const_float_bits_conv)] #![feature(const_float_classify)] #![feature(const_fmt_arguments_new)]


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: Also checked beta and nightly at : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This does not panic on 1.55. Also, it panics on 1.56 regardless of which edition is used. label regression-from-stable-to-stable
searched nightlies: from nightly-2021-07-23 to nightly-2021-11-02 regressed nightly: nightly-2021-09-26 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsFrom this rollup, looks relevant, and it landed in 1.56 via backport.
claim
Assigning priority as in the prioritization working group.

// Save the index of all fields regardless of their visibility in case // of error recovery. self.write_field_index(expr.hir_id, index); <ins> let adjustments = self.adjust_steps(&autoderef); </ins> if field.vis.is_accessible_from(def_scope, self.tcx) { <del> let adjustments = self.adjust_steps(&autoderef); </del> self.apply_adjustments(base, adjustments); self.register_predicates(autoderef.into_obligations()); self.tcx.check_stability(field.did, Some(expr.hir_id), expr.span, None); return field_ty; } <del> private_candidate = Some((base_def.did, field_ty)); </del> <ins> private_candidate = Some((adjustments, base_def.did, field_ty)); </ins> } } ty::Tuple(tys) => {


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: Also checked beta and nightly at : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This does not panic on 1.55. Also, it panics on 1.56 regardless of which edition is used. label regression-from-stable-to-stable
searched nightlies: from nightly-2021-07-23 to nightly-2021-11-02 regressed nightly: nightly-2021-09-26 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsFrom this rollup, looks relevant, and it landed in 1.56 via backport.
claim
Assigning priority as in the prioritization working group.

} self.structurally_resolved_type(autoderef.span(), autoderef.final_ty(false)); <del> if let Some((did, field_ty)) = private_candidate { </del> <ins> if let Some((adjustments, did, field_ty)) = private_candidate { // (#90483) apply adjustments to avoid ExprUseVisitor from // creating erroneous projection. self.apply_adjustments(base, adjustments); </ins> self.ban_private_field_access(expr, expr_t, field, did); return field_ty; }


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: Also checked beta and nightly at : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This does not panic on 1.55. Also, it panics on 1.56 regardless of which edition is used. label regression-from-stable-to-stable
searched nightlies: from nightly-2021-07-23 to nightly-2021-11-02 regressed nightly: nightly-2021-09-26 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsFrom this rollup, looks relevant, and it landed in 1.56 via backport.
claim
Assigning priority as in the prioritization working group.

<ins> // edition:2021 mod m { pub struct S { foo: i32 } impl S { pub fn foo(&self) -> i32 { 42 } } } fn bar(s: &m::S) { || s.foo() + s.foo; //~ ERROR E0616 } fn main() {} </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: Also checked beta and nightly at : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This does not panic on 1.55. Also, it panics on 1.56 regardless of which edition is used. label regression-from-stable-to-stable
searched nightlies: from nightly-2021-07-23 to nightly-2021-11-02 regressed nightly: nightly-2021-09-26 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsFrom this rollup, looks relevant, and it landed in 1.56 via backport.
claim
Assigning priority as in the prioritization working group.

<ins> error[E0616]: field `foo` of struct `S` is private --> $DIR/issue-90483-inaccessible-field-adjustment.rs:11:18 | LL |   || s.foo() + s.foo; |                  ^^^ private field | help: a method `foo` also exists, call it with parentheses | LL |   || s.foo() + s.foo(); |                     ++ error: aborting due to previous error For more information about this error, try `rustc --explain E0616`. </ins>


Question:
Tracking issue: . The assembler directive allows to treat data as instructions. This allows to generate CPU instructions that are otherwise not possible using assembler commands. It is platform specific and mostly relevant for RISC-V platforms, but I could also find uses for it on MIPS targets as well. More generally speaking, any solution that allows me to produce custom machine code instructions without a performance overhead will be okay for me. The current best workaround is to write the assembler code externally and then link to it. However, this adds the overhead of a function call that cannot be inlined due to the FFI boundary, so this is not acceptable in the long term. See also for some more discussion of my problem.
This will likely work automatically once LLVM supports it. A commit has recently landed () but is not yet in any released version.
label +A-inline-assembly +F-asm
I tried building rust+cargo from source with cherry-picked. Sadly it did not make the error message go away. A good way to check is to use on a minimal example instead. Turns out that I somehow wasn't.
Okay, it actually does work. What is the procedure around Rust's LLVM dependency? How often is it bumped? Is this a candidate for cherry-picking onto rust-llvm?
LLVM procedure is at https://rustc-dev- I think this is a candidate for cherry-picking but someone needs to do the work.

<del> Subproject commit 01c8b654f9a01371414d1fd69cba38b289510a9e </del> <ins> Subproject commit 2b9078f4afae82f60c5ac0fdb4af42d269e2f2f3 </ins>


Question:
I tried : This should compile and work, but instead it ICEs. It doesn't ICE if I remove the generic parameter from or use <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details
Seems related to

//! `RETURN_PLACE` the MIR arguments) are always fully normalized (and //! contain revealed `impl Trait` values). <ins> use crate::type_check::constraint_conversion::ConstraintConversion; </ins> use rustc_index::vec::Idx; use rustc_infer::infer::LateBoundRegionConversionTime; use rustc_middle::mir::*; <del> use rustc_middle::traits::ObligationCause; use rustc_middle::ty::{self, Ty}; </del> <ins> use rustc_middle::ty::Ty; </ins> use rustc_span::Span; <del> use rustc_trait_selection::traits::query::normalize::AtExt; </del> <ins> use rustc_span::DUMMY_SP; use rustc_trait_selection::traits::query::type_op::{self, TypeOp}; use rustc_trait_selection::traits::query::Fallible; use type_op::TypeOpOutput; </ins> use crate::universal_regions::UniversalRegions;


Question:
I tried : This should compile and work, but instead it ICEs. It doesn't ICE if I remove the generic parameter from or use <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details
Seems related to

let (&normalized_output_ty, normalized_input_tys) = normalized_inputs_and_output.split_last().unwrap(); <ins> debug!(?normalized_output_ty); debug!(?normalized_input_tys); </ins> let mir_def_id = body.source.def_id().expect_local(); // If the user explicitly annotated the input types, extract


Question:
I tried : This should compile and work, but instead it ICEs. It doesn't ICE if I remove the generic parameter from or use <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details
Seems related to

.delay_span_bug(body.span, "found more normalized_input_ty than local_decls"); break; } // In MIR, argument N is stored in local N+1. let local = Local::new(argument_index + 1); let mir_input_ty = body.local_decls[local].ty; let mir_input_span = body.local_decls[local].source_info.span; self.equate_normalized_input_or_output( normalized_input_ty,


Question:
I tried : This should compile and work, but instead it ICEs. It doesn't ICE if I remove the generic parameter from or use <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details
Seems related to

// If the user explicitly annotated the input types, enforce those. let user_provided_input_ty = self.normalize(user_provided_input_ty, Locations::All(mir_input_span)); self.equate_normalized_input_or_output( user_provided_input_ty, mir_input_ty,


Question:
I tried : This should compile and work, but instead it ICEs. It doesn't ICE if I remove the generic parameter from or use <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details
Seems related to

// `rustc_traits::normalize_after_erasing_regions`. Ideally, we'd // like to normalize *before* inserting into `local_decls`, but // doing so ends up causing some other trouble. <del> let b = match self .infcx .at(&ObligationCause::dummy(), ty::ParamEnv::empty()) .normalize(b) { Ok(n) => { debug!("equate_inputs_and_outputs: {:?}", n); if n.obligations.iter().all(|o| { matches!( o.predicate.kind().skip_binder(), ty::PredicateKind::RegionOutlives(_) | ty::PredicateKind::TypeOutlives(_) ) }) { n.value } else { b } } </del> <ins> let b = match self.normalize_and_add_constraints(b) { Ok(n) => n, </ins> Err(_) => { debug!("equate_inputs_and_outputs: NoSolution"); b } }; // Note: if we have to introduce new placeholders during normalization above, then we won't have // added those universes to the universe info, which we would want in `relate_tys`. if let Err(terr) =


Question:
I tried : This should compile and work, but instead it ICEs. It doesn't ICE if I remove the generic parameter from or use <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details
Seems related to

} } } <ins> pub(crate) fn normalize_and_add_constraints(&mut self, t: Ty<'tcx>) -> Fallible<Ty<'tcx>> { let TypeOpOutput { output: norm_ty, constraints, .. } = self.param_env.and(type_op::normalize::Normalize::new(t)).fully_perform(self.infcx)?; debug!("{:?} normalized to {:?}", t, norm_ty); for data in constraints.into_iter().collect::<Vec<_>>() { ConstraintConversion::new( self.infcx, &self.borrowck_context.universal_regions, &self.region_bound_pairs, Some(self.implicit_region_bound), self.param_env, Locations::All(DUMMY_SP), ConstraintCategory::Internal, &mut self.borrowck_context.constraints, ) .convert_all(&*data); } Ok(norm_ty) } </ins> }


Question:
I tried : This should compile and work, but instead it ICEs. It doesn't ICE if I remove the generic parameter from or use <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details
Seems related to

} struct BorrowCheckContext<'a, 'tcx> { <del> universal_regions: &'a UniversalRegions<'tcx>, </del> <ins> pub(crate) universal_regions: &'a UniversalRegions<'tcx>, </ins> location_table: &'a LocationTable, all_facts: &'a mut Option<AllFacts>, borrow_set: &'a BorrowSet<'tcx>, <del> constraints: &'a mut MirTypeckRegionConstraints<'tcx>, </del> <ins> pub(crate) constraints: &'a mut MirTypeckRegionConstraints<'tcx>, </ins> upvars: &'a [Upvar<'tcx>], }


Question:
I tried : This should compile and work, but instead it ICEs. It doesn't ICE if I remove the generic parameter from or use <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details
Seems related to

self.relate_types(sup, ty::Variance::Contravariant, sub, locations, category) } <ins> #[instrument(skip(self, category), level = "debug")] </ins> fn eq_types( &mut self, expected: Ty<'tcx>,


Question:
I tried : This should compile and work, but instead it ICEs. It doesn't ICE if I remove the generic parameter from or use <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details
Seems related to

<ins> // check-pass #![feature(generic_associated_types)] use std::marker::PhantomData; trait Family: Sized { type Item<'a>; fn apply_all<F>(&self, f: F) where F: FamilyItemFn<Self> { } } struct Array<T>(PhantomData<T>); impl<T: 'static> Family for Array<T> { type Item<'a> = &'a T; } trait FamilyItemFn<T: Family> { fn apply(&self, item: T::Item<'_>); } impl<T, F> FamilyItemFn<T> for F where T: Family, for<'a> F: Fn(T::Item<'a>) { fn apply(&self, item: T::Item<'_>) { (*self)(item); } } fn process<T: 'static>(array: Array<T>) { // Works array.apply_all(|x: &T| { }); // ICE: NoSolution array.apply_all(|x: <Array<T> as Family>::Item<'_>| { }); } fn main() {} </ins>


Question:
I tried : This should compile and work, but instead it ICEs. It doesn't ICE if I remove the generic parameter from or use <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details
Seems related to

<ins> //check-pass #![feature(generic_associated_types)] trait Yokeable<'a>: 'static { type Output: 'a; } trait IsCovariant<'a> {} struct Yoke<Y: for<'a> Yokeable<'a>> { data: Y, } impl<Y: for<'a> Yokeable<'a>> Yoke<Y> { fn project<Y2: for<'a> Yokeable<'a>>(&self, _f: for<'a> fn(<Y as Yokeable<'a>>::Output, &'a ()) -> <Y2 as Yokeable<'a>>::Output) -> Yoke<Y2> { unimplemented!() } } fn _upcast<Y>(x: Yoke<Y>) -> Yoke<Box<dyn IsCovariant<'static> + 'static>> where Y: for<'a> Yokeable<'a>, for<'a> <Y as Yokeable<'a>>::Output: IsCovariant<'a> { x.project(|data, _| { Box::new(data) }) } impl<'a> Yokeable<'a> for Box<dyn IsCovariant<'static> + 'static> { type Output = Box<dyn IsCovariant<'a> + 'a>; } fn main() {} </ins>


Question:
I tried this code: I expected to see this happen: The documentation is empty. Instead, this happened: ! <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: rustdoc 1.58.0-nightly ( 2021-11-12) cc I suspect this is related to one of your recent changes to visibility.
This does appear to have been . I'm not entirely sure how to fix this. Basically, what's happening here is that the query is checking if the use statement is accessible from its parent module. It is, because the parent module of the top level of the module is itself. Before this, it would have been documented if you did a , but not with just . The new behavior is more consistent, and better in that sense, but perhaps not ideal. Do you have an idea on how you'd like this to work?
Some additional thoughts: If we want to stick to the "visible from parent module" thing, the simplest way to do that would be to add a check for whether is the top level module. Of course, I'd also have to add a check for the visibility being actually public... sighs. Might need to break this into a seperate thing. I guess the problem I'm struggling with after thinking about all of this is that I don't fully understand the justification for all of this logic. Why is it that we want to show some imports but not others? If these were structs, we'd just show all of them, regardless of their visibility. That said, if this really is the behavior we want, it shouldn't be hard to implement.
I think we should inline neither nor bare (pretty sure I said so on the PR, but I guess I forgot to check for a test case). Because the structs are only visible from the module where they're defined. The use statements aren't intended to be used from elsewhere in the crate.
I think I explained this poorly above. We generally don't inline either or bare . Not doing so is the intended behavior from the PR. Because of how I implemented it, the top of the crate ended up being an inadvertent exception, and we didn't have any tests that covered the top of the crate as opposed to lower level modules. It's an easy fix if we want it not to be an exception, I was just trying to make sure we had a clear philosophical reason for wanting things to be the way we were trying to have them be. (In other words, I was double-checking that the behavior the PR was supposed to create is really what we want before submitting a PR to do that.) It sounds like it is, so I'll get working on a bugfix. I feel like I'm expressing myself rather unclearly at the moment. If there's anything I need to clear up about this explanation, please feel free to let me know.
Oh oops, I missed this bit. Yes, I think this should be consistent with the submodules of the crate.
I agree, that sounds like the right behavior to me.
Quick update: I've got a substantive patch, but it's taking a while to get the tests to a point where I'm satisfied with them.
My PR is up! Also, I'm going to assign this as a , per the discussion in of the prioritization working group.

let inline_attr = attrs.lists(sym::doc).get_word_attr(sym::inline); let pub_underscore = visibility.is_public() && name == kw::Underscore; let current_mod = cx.tcx.parent_module_from_def_id(import.def_id); <ins> // The parent of the module in which this import resides. This // is the same as `current_mod` if that's already the top // level module. </ins> let parent_mod = cx.tcx.parent_module_from_def_id(current_mod); <ins> // This checks if the import can be seen from a higher level module. // In other words, it checks if the visibility is the equivalent of // `pub(super)` or higher. If the current module is the top level // module, there isn't really a parent module, which makes the results // meaningless. In this case, we make sure the answer is `false`. let is_visible_from_parent_mod = visibility.is_accessible_from(parent_mod.to_def_id(), cx.tcx) && !current_mod.is_top_level_module(); </ins> if pub_underscore { if let Some(ref inline) = inline_attr { rustc_errors::struct_span_err!(


Question:
I tried this code: I expected to see this happen: The documentation is empty. Instead, this happened: ! <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: rustdoc 1.58.0-nightly ( 2021-11-12) cc I suspect this is related to one of your recent changes to visibility.
This does appear to have been . I'm not entirely sure how to fix this. Basically, what's happening here is that the query is checking if the use statement is accessible from its parent module. It is, because the parent module of the top level of the module is itself. Before this, it would have been documented if you did a , but not with just . The new behavior is more consistent, and better in that sense, but perhaps not ideal. Do you have an idea on how you'd like this to work?
Some additional thoughts: If we want to stick to the "visible from parent module" thing, the simplest way to do that would be to add a check for whether is the top level module. Of course, I'd also have to add a check for the visibility being actually public... sighs. Might need to break this into a seperate thing. I guess the problem I'm struggling with after thinking about all of this is that I don't fully understand the justification for all of this logic. Why is it that we want to show some imports but not others? If these were structs, we'd just show all of them, regardless of their visibility. That said, if this really is the behavior we want, it shouldn't be hard to implement.
I think we should inline neither nor bare (pretty sure I said so on the PR, but I guess I forgot to check for a test case). Because the structs are only visible from the module where they're defined. The use statements aren't intended to be used from elsewhere in the crate.
I think I explained this poorly above. We generally don't inline either or bare . Not doing so is the intended behavior from the PR. Because of how I implemented it, the top of the crate ended up being an inadvertent exception, and we didn't have any tests that covered the top of the crate as opposed to lower level modules. It's an easy fix if we want it not to be an exception, I was just trying to make sure we had a clear philosophical reason for wanting things to be the way we were trying to have them be. (In other words, I was double-checking that the behavior the PR was supposed to create is really what we want before submitting a PR to do that.) It sounds like it is, so I'll get working on a bugfix. I feel like I'm expressing myself rather unclearly at the moment. If there's anything I need to clear up about this explanation, please feel free to let me know.
Oh oops, I missed this bit. Yes, I think this should be consistent with the submodules of the crate.
I agree, that sounds like the right behavior to me.
Quick update: I've got a substantive patch, but it's taking a while to get the tests to a point where I'm satisfied with them.
My PR is up! Also, I'm going to assign this as a , per the discussion in of the prioritization working group.

// #[doc(no_inline)] attribute is present. // Don't inline doc(hidden) imports so they can be stripped at a later stage. let mut denied = !(visibility.is_public() <del> || (cx.render_options.document_private && visibility.is_accessible_from(parent_mod.to_def_id(), cx.tcx))) </del> <ins> || (cx.render_options.document_private && is_visible_from_parent_mod)) </ins> || pub_underscore || attrs.iter().any(|a| { a.has_name(sym::doc)


Question:
I tried this code: I expected to see this happen: The documentation is empty. Instead, this happened: ! <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: rustdoc 1.58.0-nightly ( 2021-11-12) cc I suspect this is related to one of your recent changes to visibility.
This does appear to have been . I'm not entirely sure how to fix this. Basically, what's happening here is that the query is checking if the use statement is accessible from its parent module. It is, because the parent module of the top level of the module is itself. Before this, it would have been documented if you did a , but not with just . The new behavior is more consistent, and better in that sense, but perhaps not ideal. Do you have an idea on how you'd like this to work?
Some additional thoughts: If we want to stick to the "visible from parent module" thing, the simplest way to do that would be to add a check for whether is the top level module. Of course, I'd also have to add a check for the visibility being actually public... sighs. Might need to break this into a seperate thing. I guess the problem I'm struggling with after thinking about all of this is that I don't fully understand the justification for all of this logic. Why is it that we want to show some imports but not others? If these were structs, we'd just show all of them, regardless of their visibility. That said, if this really is the behavior we want, it shouldn't be hard to implement.
I think we should inline neither nor bare (pretty sure I said so on the PR, but I guess I forgot to check for a test case). Because the structs are only visible from the module where they're defined. The use statements aren't intended to be used from elsewhere in the crate.
I think I explained this poorly above. We generally don't inline either or bare . Not doing so is the intended behavior from the PR. Because of how I implemented it, the top of the crate ended up being an inadvertent exception, and we didn't have any tests that covered the top of the crate as opposed to lower level modules. It's an easy fix if we want it not to be an exception, I was just trying to make sure we had a clear philosophical reason for wanting things to be the way we were trying to have them be. (In other words, I was double-checking that the behavior the PR was supposed to create is really what we want before submitting a PR to do that.) It sounds like it is, so I'll get working on a bugfix. I feel like I'm expressing myself rather unclearly at the moment. If there's anything I need to clear up about this explanation, please feel free to let me know.
Oh oops, I missed this bit. Yes, I think this should be consistent with the submodules of the crate.
I agree, that sounds like the right behavior to me.
Quick update: I've got a substantive patch, but it's taking a while to get the tests to a point where I'm satisfied with them.
My PR is up! Also, I'm going to assign this as a , per the discussion in of the prioritization working group.

&raw const $place } <ins> pub macro addr_of_crate($place:expr) { &raw const $place } pub macro addr_of_super($place:expr) { &raw const $place } </ins> pub macro addr_of_self($place:expr) { &raw const $place } <del> pub macro addr_of_crate($place:expr) { </del> <ins> pub macro addr_of_local($place:expr) { </ins> &raw const $place } pub struct Foo; <del> pub struct FooSelf; </del> pub struct FooCrate; <ins> pub struct FooSuper; pub struct FooSelf; pub struct FooLocal; </ins> pub enum Bar { Foo, } <del> pub enum BarSelf { Foo, } </del> pub enum BarCrate { Foo, } <ins> pub enum BarSuper { Foo, } pub enum BarSelf { Foo, } pub enum BarLocal { Foo, } </ins> pub fn foo() {} <del> pub fn foo_self() {} </del> pub fn foo_crate() {} <ins> pub fn foo_super() {} pub fn foo_self() {} pub fn foo_local() {} </ins> pub type Type = i32; <del> pub type TypeSelf = i32; </del> pub type TypeCrate = i32; <ins> pub type TypeSuper = i32; pub type TypeSelf = i32; pub type TypeLocal = i32; </ins> pub union Union { a: i8, b: i8, } <ins> pub union UnionCrate { a: i8, b: i8, } pub union UnionSuper { a: i8, b: i8, } </ins> pub union UnionSelf { a: i8, b: i8, } <del> pub union UnionCrate { </del> <ins> pub union UnionLocal { </ins> a: i8, b: i8, }


Question:
I tried this code: I expected to see this happen: The documentation is empty. Instead, this happened: ! <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: rustdoc 1.58.0-nightly ( 2021-11-12) cc I suspect this is related to one of your recent changes to visibility.
This does appear to have been . I'm not entirely sure how to fix this. Basically, what's happening here is that the query is checking if the use statement is accessible from its parent module. It is, because the parent module of the top level of the module is itself. Before this, it would have been documented if you did a , but not with just . The new behavior is more consistent, and better in that sense, but perhaps not ideal. Do you have an idea on how you'd like this to work?
Some additional thoughts: If we want to stick to the "visible from parent module" thing, the simplest way to do that would be to add a check for whether is the top level module. Of course, I'd also have to add a check for the visibility being actually public... sighs. Might need to break this into a seperate thing. I guess the problem I'm struggling with after thinking about all of this is that I don't fully understand the justification for all of this logic. Why is it that we want to show some imports but not others? If these were structs, we'd just show all of them, regardless of their visibility. That said, if this really is the behavior we want, it shouldn't be hard to implement.
I think we should inline neither nor bare (pretty sure I said so on the PR, but I guess I forgot to check for a test case). Because the structs are only visible from the module where they're defined. The use statements aren't intended to be used from elsewhere in the crate.
I think I explained this poorly above. We generally don't inline either or bare . Not doing so is the intended behavior from the PR. Because of how I implemented it, the top of the crate ended up being an inadvertent exception, and we didn't have any tests that covered the top of the crate as opposed to lower level modules. It's an easy fix if we want it not to be an exception, I was just trying to make sure we had a clear philosophical reason for wanting things to be the way we were trying to have them be. (In other words, I was double-checking that the behavior the PR was supposed to create is really what we want before submitting a PR to do that.) It sounds like it is, so I'll get working on a bugfix. I feel like I'm expressing myself rather unclearly at the moment. If there's anything I need to clear up about this explanation, please feel free to let me know.
Oh oops, I missed this bit. Yes, I think this should be consistent with the submodules of the crate.
I agree, that sounds like the right behavior to me.
Quick update: I've got a substantive patch, but it's taking a while to get the tests to a point where I'm satisfied with them.
My PR is up! Also, I'm going to assign this as a , per the discussion in of the prioritization working group.

// @has 'foo/macro.addr_of.html' '//*[@class="docblock item-decl"]' 'pub macro addr_of($place : expr) {' pub use reexports::addr_of; <del> // @has 'foo/macro.addr_of_crate.html' '//*[@class="docblock item-decl"]' 'pub(crate) macro addr_of_crate($place : expr) {' </del> <ins> // @!has 'foo/macro.addr_of_crate.html' </ins> pub(crate) use reexports::addr_of_crate; <del> // @has 'foo/macro.addr_of_self.html' '//*[@class="docblock item-decl"]' 'pub(crate) macro addr_of_self($place : expr) {' </del> <ins> // @!has 'foo/macro.addr_of_self.html' </ins> pub(self) use reexports::addr_of_self; <ins> // @!has 'foo/macro.addr_of_local.html' use reexports::addr_of_local; </ins> // @has 'foo/struct.Foo.html' '//*[@class="docblock item-decl"]' 'pub struct Foo;' pub use reexports::Foo; <del> // @has 'foo/struct.FooCrate.html' '//*[@class="docblock item-decl"]' 'pub(crate) struct FooCrate;' </del> <ins> // @!has 'foo/struct.FooCrate.html' </ins> pub(crate) use reexports::FooCrate; <del> // @has 'foo/struct.FooSelf.html' '//*[@class="docblock item-decl"]' 'pub(crate) struct FooSelf;' </del> <ins> // @!has 'foo/struct.FooSelf.html' </ins> pub(self) use reexports::FooSelf; <ins> // @!has 'foo/struct.FooLocal.html' use reexports::FooLocal; </ins> // @has 'foo/enum.Bar.html' '//*[@class="docblock item-decl"]' 'pub enum Bar {' pub use reexports::Bar; <del> // @has 'foo/enum.BarCrate.html' '//*[@class="docblock item-decl"]' 'pub(crate) enum BarCrate {' </del> <ins> // @!has 'foo/enum.BarCrate.html' </ins> pub(crate) use reexports::BarCrate; <del> // @has 'foo/enum.BarSelf.html' '//*[@class="docblock item-decl"]' 'pub(crate) enum BarSelf {' </del> <ins> // @!has 'foo/enum.BarSelf.html' </ins> pub(self) use reexports::BarSelf; <ins> // @!has 'foo/enum.BarLocal.html' use reexports::BarLocal; </ins> // @has 'foo/fn.foo.html' '//*[@class="rust fn"]' 'pub fn foo()' pub use reexports::foo; <del> // @has 'foo/fn.foo_crate.html' '//*[@class="rust fn"]' 'pub(crate) fn foo_crate()' </del> <ins> // @!has 'foo/fn.foo_crate.html' </ins> pub(crate) use reexports::foo_crate; <del> // @has 'foo/fn.foo_self.html' '//*[@class="rust fn"]' 'pub(crate) fn foo_self()' </del> <ins> // @!has 'foo/fn.foo_self.html' </ins> pub(self) use reexports::foo_self; <ins> // @!has 'foo/fn.foo_local.html' use reexports::foo_local; </ins> // @has 'foo/type.Type.html' '//*[@class="rust typedef"]' 'pub type Type =' pub use reexports::Type; <del> // @has 'foo/type.TypeCrate.html' '//*[@class="rust typedef"]' 'pub(crate) type TypeCrate =' </del> <ins> // @!has 'foo/type.TypeCrate.html' </ins> pub(crate) use reexports::TypeCrate; <del> // @has 'foo/type.TypeSelf.html' '//*[@class="rust typedef"]' 'pub(crate) type TypeSelf =' </del> <ins> // @!has 'foo/type.TypeSelf.html' </ins> pub(self) use reexports::TypeSelf; <ins> // @!has 'foo/type.TypeLocal.html' use reexports::TypeLocal; </ins> // @has 'foo/union.Union.html' '//*[@class="docblock item-decl"]' 'pub union Union {' pub use reexports::Union; <del> // @has 'foo/union.UnionCrate.html' '//*[@class="docblock item-decl"]' 'pub(crate) union UnionCrate {' </del> <ins> // @!has 'foo/union.UnionCrate.html' </ins> pub(crate) use reexports::UnionCrate; <del> // @has 'foo/union.UnionSelf.html' '//*[@class="docblock item-decl"]' 'pub(crate) union UnionSelf {' </del> <ins> // @!has 'foo/union.UnionSelf.html' </ins> pub(self) use reexports::UnionSelf; <ins> // @!has 'foo/union.UnionLocal.html' use reexports::UnionLocal; </ins> <del> pub mod foo { // @!has 'foo/foo/union.Union.html' use crate::reexports::Union; </del> <ins> pub mod outer { pub mod inner { // @has 'foo/outer/inner/macro.addr_of.html' '//*[@class="docblock item-decl"]' 'pub macro addr_of($place : expr) {' pub use reexports::addr_of; // @has 'foo/outer/inner/macro.addr_of_crate.html' '//*[@class="docblock item-decl"]' 'pub(crate) macro addr_of_crate($place : expr) {' pub(crate) use reexports::addr_of_crate; // @has 'foo/outer/inner/macro.addr_of_super.html' '//*[@class="docblock item-decl"]' 'pub(in outer) macro addr_of_super($place : expr) {' pub(super) use reexports::addr_of_super; // @!has 'foo/outer/inner/macro.addr_of_self.html' pub(self) use reexports::addr_of_self; // @!has 'foo/outer/inner/macro.addr_of_local.html' use reexports::addr_of_local; // @has 'foo/outer/inner/struct.Foo.html' '//*[@class="docblock item-decl"]' 'pub struct Foo;' pub use reexports::Foo; // @has 'foo/outer/inner/struct.FooCrate.html' '//*[@class="docblock item-decl"]' 'pub(crate) struct FooCrate;' pub(crate) use reexports::FooCrate; // @has 'foo/outer/inner/struct.FooSuper.html' '//*[@class="docblock item-decl"]' 'pub(in outer) struct FooSuper;' pub(super) use reexports::FooSuper; // @!has 'foo/outer/inner/struct.FooSelf.html' pub(self) use reexports::FooSelf; // @!has 'foo/outer/inner/struct.FooLocal.html' use reexports::FooLocal; // @has 'foo/outer/inner/enum.Bar.html' '//*[@class="docblock item-decl"]' 'pub enum Bar {' pub use reexports::Bar; // @has 'foo/outer/inner/enum.BarCrate.html' '//*[@class="docblock item-decl"]' 'pub(crate) enum BarCrate {' pub(crate) use reexports::BarCrate; // @has 'foo/outer/inner/enum.BarSuper.html' '//*[@class="docblock item-decl"]' 'pub(in outer) enum BarSuper {' pub(super) use reexports::BarSuper; // @!has 'foo/outer/inner/enum.BarSelf.html' pub(self) use reexports::BarSelf; // @!has 'foo/outer/inner/enum.BarLocal.html' use reexports::BarLocal; // @has 'foo/outer/inner/fn.foo.html' '//*[@class="rust fn"]' 'pub fn foo()' pub use reexports::foo; // @has 'foo/outer/inner/fn.foo_crate.html' '//*[@class="rust fn"]' 'pub(crate) fn foo_crate()' pub(crate) use reexports::foo_crate; // @has 'foo/outer/inner/fn.foo_super.html' '//*[@class="rust fn"]' 'pub(in outer) fn foo_super()' pub(super) use::reexports::foo_super; // @!has 'foo/outer/inner/fn.foo_self.html' pub(self) use reexports::foo_self; // @!has 'foo/outer/inner/fn.foo_local.html' use reexports::foo_local; // @has 'foo/outer/inner/type.Type.html' '//*[@class="rust typedef"]' 'pub type Type =' pub use reexports::Type; // @has 'foo/outer/inner/type.TypeCrate.html' '//*[@class="rust typedef"]' 'pub(crate) type TypeCrate =' pub(crate) use reexports::TypeCrate; // @has 'foo/outer/inner/type.TypeSuper.html' '//*[@class="rust typedef"]' 'pub(in outer) type TypeSuper =' pub(super) use reexports::TypeSuper; // @!has 'foo/outer/inner/type.TypeSelf.html' pub(self) use reexports::TypeSelf; // @!has 'foo/outer/inner/type.TypeLocal.html' use reexports::TypeLocal; // @has 'foo/outer/inner/union.Union.html' '//*[@class="docblock item-decl"]' 'pub union Union {' pub use reexports::Union; // @has 'foo/outer/inner/union.UnionCrate.html' '//*[@class="docblock item-decl"]' 'pub(crate) union UnionCrate {' pub(crate) use reexports::UnionCrate; // @has 'foo/outer/inner/union.UnionSuper.html' '//*[@class="docblock item-decl"]' 'pub(in outer) union UnionSuper {' pub(super) use reexports::UnionSuper; // @!has 'foo/outer/inner/union.UnionSelf.html' pub(self) use reexports::UnionSelf; // @!has 'foo/outer/inner/union.UnionLocal.html' use reexports::UnionLocal; } } mod re_re_exports { // @!has 'foo/re_re_exports/union.Union.html' use crate::reexports::Union; </ins> }


Question:
I tried this code: I expected to see this happen: The documentation is empty. Instead, this happened: ! <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: rustdoc 1.58.0-nightly ( 2021-11-12) cc I suspect this is related to one of your recent changes to visibility.
This does appear to have been . I'm not entirely sure how to fix this. Basically, what's happening here is that the query is checking if the use statement is accessible from its parent module. It is, because the parent module of the top level of the module is itself. Before this, it would have been documented if you did a , but not with just . The new behavior is more consistent, and better in that sense, but perhaps not ideal. Do you have an idea on how you'd like this to work?
Some additional thoughts: If we want to stick to the "visible from parent module" thing, the simplest way to do that would be to add a check for whether is the top level module. Of course, I'd also have to add a check for the visibility being actually public... sighs. Might need to break this into a seperate thing. I guess the problem I'm struggling with after thinking about all of this is that I don't fully understand the justification for all of this logic. Why is it that we want to show some imports but not others? If these were structs, we'd just show all of them, regardless of their visibility. That said, if this really is the behavior we want, it shouldn't be hard to implement.
I think we should inline neither nor bare (pretty sure I said so on the PR, but I guess I forgot to check for a test case). Because the structs are only visible from the module where they're defined. The use statements aren't intended to be used from elsewhere in the crate.
I think I explained this poorly above. We generally don't inline either or bare . Not doing so is the intended behavior from the PR. Because of how I implemented it, the top of the crate ended up being an inadvertent exception, and we didn't have any tests that covered the top of the crate as opposed to lower level modules. It's an easy fix if we want it not to be an exception, I was just trying to make sure we had a clear philosophical reason for wanting things to be the way we were trying to have them be. (In other words, I was double-checking that the behavior the PR was supposed to create is really what we want before submitting a PR to do that.) It sounds like it is, so I'll get working on a bugfix. I feel like I'm expressing myself rather unclearly at the moment. If there's anything I need to clear up about this explanation, please feel free to let me know.
Oh oops, I missed this bit. Yes, I think this should be consistent with the submodules of the crate.
I agree, that sounds like the right behavior to me.
Quick update: I've got a substantive patch, but it's taking a while to get the tests to a point where I'm satisfied with them.
My PR is up! Also, I'm going to assign this as a , per the discussion in of the prioritization working group.

pub(crate) use reexports::addr_of_crate; // @!has 'foo/macro.addr_of_self.html' pub(self) use reexports::addr_of_self; <ins> // @!has 'foo/macro.addr_of_local.html' use reexports::addr_of_local; </ins> // @has 'foo/struct.Foo.html' '//*[@class="docblock item-decl"]' 'pub struct Foo;' pub use reexports::Foo;


Question:
I tried this code: I expected to see this happen: The documentation is empty. Instead, this happened: ! <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: rustdoc 1.58.0-nightly ( 2021-11-12) cc I suspect this is related to one of your recent changes to visibility.
This does appear to have been . I'm not entirely sure how to fix this. Basically, what's happening here is that the query is checking if the use statement is accessible from its parent module. It is, because the parent module of the top level of the module is itself. Before this, it would have been documented if you did a , but not with just . The new behavior is more consistent, and better in that sense, but perhaps not ideal. Do you have an idea on how you'd like this to work?
Some additional thoughts: If we want to stick to the "visible from parent module" thing, the simplest way to do that would be to add a check for whether is the top level module. Of course, I'd also have to add a check for the visibility being actually public... sighs. Might need to break this into a seperate thing. I guess the problem I'm struggling with after thinking about all of this is that I don't fully understand the justification for all of this logic. Why is it that we want to show some imports but not others? If these were structs, we'd just show all of them, regardless of their visibility. That said, if this really is the behavior we want, it shouldn't be hard to implement.
I think we should inline neither nor bare (pretty sure I said so on the PR, but I guess I forgot to check for a test case). Because the structs are only visible from the module where they're defined. The use statements aren't intended to be used from elsewhere in the crate.
I think I explained this poorly above. We generally don't inline either or bare . Not doing so is the intended behavior from the PR. Because of how I implemented it, the top of the crate ended up being an inadvertent exception, and we didn't have any tests that covered the top of the crate as opposed to lower level modules. It's an easy fix if we want it not to be an exception, I was just trying to make sure we had a clear philosophical reason for wanting things to be the way we were trying to have them be. (In other words, I was double-checking that the behavior the PR was supposed to create is really what we want before submitting a PR to do that.) It sounds like it is, so I'll get working on a bugfix. I feel like I'm expressing myself rather unclearly at the moment. If there's anything I need to clear up about this explanation, please feel free to let me know.
Oh oops, I missed this bit. Yes, I think this should be consistent with the submodules of the crate.
I agree, that sounds like the right behavior to me.
Quick update: I've got a substantive patch, but it's taking a while to get the tests to a point where I'm satisfied with them.
My PR is up! Also, I'm going to assign this as a , per the discussion in of the prioritization working group.

pub(crate) use reexports::FooCrate; // @!has 'foo/struct.FooSelf.html' pub(self) use reexports::FooSelf; <ins> // @!has 'foo/struct.FooLocal.html' use reexports::FooLocal; </ins> // @has 'foo/enum.Bar.html' '//*[@class="docblock item-decl"]' 'pub enum Bar {' pub use reexports::Bar;


Question:
I tried this code: I expected to see this happen: The documentation is empty. Instead, this happened: ! <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: rustdoc 1.58.0-nightly ( 2021-11-12) cc I suspect this is related to one of your recent changes to visibility.
This does appear to have been . I'm not entirely sure how to fix this. Basically, what's happening here is that the query is checking if the use statement is accessible from its parent module. It is, because the parent module of the top level of the module is itself. Before this, it would have been documented if you did a , but not with just . The new behavior is more consistent, and better in that sense, but perhaps not ideal. Do you have an idea on how you'd like this to work?
Some additional thoughts: If we want to stick to the "visible from parent module" thing, the simplest way to do that would be to add a check for whether is the top level module. Of course, I'd also have to add a check for the visibility being actually public... sighs. Might need to break this into a seperate thing. I guess the problem I'm struggling with after thinking about all of this is that I don't fully understand the justification for all of this logic. Why is it that we want to show some imports but not others? If these were structs, we'd just show all of them, regardless of their visibility. That said, if this really is the behavior we want, it shouldn't be hard to implement.
I think we should inline neither nor bare (pretty sure I said so on the PR, but I guess I forgot to check for a test case). Because the structs are only visible from the module where they're defined. The use statements aren't intended to be used from elsewhere in the crate.
I think I explained this poorly above. We generally don't inline either or bare . Not doing so is the intended behavior from the PR. Because of how I implemented it, the top of the crate ended up being an inadvertent exception, and we didn't have any tests that covered the top of the crate as opposed to lower level modules. It's an easy fix if we want it not to be an exception, I was just trying to make sure we had a clear philosophical reason for wanting things to be the way we were trying to have them be. (In other words, I was double-checking that the behavior the PR was supposed to create is really what we want before submitting a PR to do that.) It sounds like it is, so I'll get working on a bugfix. I feel like I'm expressing myself rather unclearly at the moment. If there's anything I need to clear up about this explanation, please feel free to let me know.
Oh oops, I missed this bit. Yes, I think this should be consistent with the submodules of the crate.
I agree, that sounds like the right behavior to me.
Quick update: I've got a substantive patch, but it's taking a while to get the tests to a point where I'm satisfied with them.
My PR is up! Also, I'm going to assign this as a , per the discussion in of the prioritization working group.

pub(crate) use reexports::BarCrate; // @!has 'foo/enum.BarSelf.html' pub(self) use reexports::BarSelf; <ins> // @!has 'foo/enum.BarLocal.html' use reexports::BarLocal; </ins> // @has 'foo/fn.foo.html' '//*[@class="rust fn"]' 'pub fn foo()' pub use reexports::foo;


Question:
I tried this code: I expected to see this happen: The documentation is empty. Instead, this happened: ! <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: rustdoc 1.58.0-nightly ( 2021-11-12) cc I suspect this is related to one of your recent changes to visibility.
This does appear to have been . I'm not entirely sure how to fix this. Basically, what's happening here is that the query is checking if the use statement is accessible from its parent module. It is, because the parent module of the top level of the module is itself. Before this, it would have been documented if you did a , but not with just . The new behavior is more consistent, and better in that sense, but perhaps not ideal. Do you have an idea on how you'd like this to work?
Some additional thoughts: If we want to stick to the "visible from parent module" thing, the simplest way to do that would be to add a check for whether is the top level module. Of course, I'd also have to add a check for the visibility being actually public... sighs. Might need to break this into a seperate thing. I guess the problem I'm struggling with after thinking about all of this is that I don't fully understand the justification for all of this logic. Why is it that we want to show some imports but not others? If these were structs, we'd just show all of them, regardless of their visibility. That said, if this really is the behavior we want, it shouldn't be hard to implement.
I think we should inline neither nor bare (pretty sure I said so on the PR, but I guess I forgot to check for a test case). Because the structs are only visible from the module where they're defined. The use statements aren't intended to be used from elsewhere in the crate.
I think I explained this poorly above. We generally don't inline either or bare . Not doing so is the intended behavior from the PR. Because of how I implemented it, the top of the crate ended up being an inadvertent exception, and we didn't have any tests that covered the top of the crate as opposed to lower level modules. It's an easy fix if we want it not to be an exception, I was just trying to make sure we had a clear philosophical reason for wanting things to be the way we were trying to have them be. (In other words, I was double-checking that the behavior the PR was supposed to create is really what we want before submitting a PR to do that.) It sounds like it is, so I'll get working on a bugfix. I feel like I'm expressing myself rather unclearly at the moment. If there's anything I need to clear up about this explanation, please feel free to let me know.
Oh oops, I missed this bit. Yes, I think this should be consistent with the submodules of the crate.
I agree, that sounds like the right behavior to me.
Quick update: I've got a substantive patch, but it's taking a while to get the tests to a point where I'm satisfied with them.
My PR is up! Also, I'm going to assign this as a , per the discussion in of the prioritization working group.

pub(crate) use reexports::foo_crate; // @!has 'foo/fn.foo_self.html' pub(self) use reexports::foo_self; <ins> // @!has 'foo/fn.foo_local.html' use reexports::foo_local; </ins> // @has 'foo/type.Type.html' '//*[@class="rust typedef"]' 'pub type Type =' pub use reexports::Type;


Question:
I tried this code: I expected to see this happen: The documentation is empty. Instead, this happened: ! <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: rustdoc 1.58.0-nightly ( 2021-11-12) cc I suspect this is related to one of your recent changes to visibility.
This does appear to have been . I'm not entirely sure how to fix this. Basically, what's happening here is that the query is checking if the use statement is accessible from its parent module. It is, because the parent module of the top level of the module is itself. Before this, it would have been documented if you did a , but not with just . The new behavior is more consistent, and better in that sense, but perhaps not ideal. Do you have an idea on how you'd like this to work?
Some additional thoughts: If we want to stick to the "visible from parent module" thing, the simplest way to do that would be to add a check for whether is the top level module. Of course, I'd also have to add a check for the visibility being actually public... sighs. Might need to break this into a seperate thing. I guess the problem I'm struggling with after thinking about all of this is that I don't fully understand the justification for all of this logic. Why is it that we want to show some imports but not others? If these were structs, we'd just show all of them, regardless of their visibility. That said, if this really is the behavior we want, it shouldn't be hard to implement.
I think we should inline neither nor bare (pretty sure I said so on the PR, but I guess I forgot to check for a test case). Because the structs are only visible from the module where they're defined. The use statements aren't intended to be used from elsewhere in the crate.
I think I explained this poorly above. We generally don't inline either or bare . Not doing so is the intended behavior from the PR. Because of how I implemented it, the top of the crate ended up being an inadvertent exception, and we didn't have any tests that covered the top of the crate as opposed to lower level modules. It's an easy fix if we want it not to be an exception, I was just trying to make sure we had a clear philosophical reason for wanting things to be the way we were trying to have them be. (In other words, I was double-checking that the behavior the PR was supposed to create is really what we want before submitting a PR to do that.) It sounds like it is, so I'll get working on a bugfix. I feel like I'm expressing myself rather unclearly at the moment. If there's anything I need to clear up about this explanation, please feel free to let me know.
Oh oops, I missed this bit. Yes, I think this should be consistent with the submodules of the crate.
I agree, that sounds like the right behavior to me.
Quick update: I've got a substantive patch, but it's taking a while to get the tests to a point where I'm satisfied with them.
My PR is up! Also, I'm going to assign this as a , per the discussion in of the prioritization working group.

pub(crate) use reexports::TypeCrate; // @!has 'foo/type.TypeSelf.html' pub(self) use reexports::TypeSelf; <ins> // @!has 'foo/type.TypeLocal.html' use reexports::TypeLocal; </ins> // @has 'foo/union.Union.html' '//*[@class="docblock item-decl"]' 'pub union Union {' pub use reexports::Union;


Question:
I tried this code: I expected to see this happen: The documentation is empty. Instead, this happened: ! <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: rustdoc 1.58.0-nightly ( 2021-11-12) cc I suspect this is related to one of your recent changes to visibility.
This does appear to have been . I'm not entirely sure how to fix this. Basically, what's happening here is that the query is checking if the use statement is accessible from its parent module. It is, because the parent module of the top level of the module is itself. Before this, it would have been documented if you did a , but not with just . The new behavior is more consistent, and better in that sense, but perhaps not ideal. Do you have an idea on how you'd like this to work?
Some additional thoughts: If we want to stick to the "visible from parent module" thing, the simplest way to do that would be to add a check for whether is the top level module. Of course, I'd also have to add a check for the visibility being actually public... sighs. Might need to break this into a seperate thing. I guess the problem I'm struggling with after thinking about all of this is that I don't fully understand the justification for all of this logic. Why is it that we want to show some imports but not others? If these were structs, we'd just show all of them, regardless of their visibility. That said, if this really is the behavior we want, it shouldn't be hard to implement.
I think we should inline neither nor bare (pretty sure I said so on the PR, but I guess I forgot to check for a test case). Because the structs are only visible from the module where they're defined. The use statements aren't intended to be used from elsewhere in the crate.
I think I explained this poorly above. We generally don't inline either or bare . Not doing so is the intended behavior from the PR. Because of how I implemented it, the top of the crate ended up being an inadvertent exception, and we didn't have any tests that covered the top of the crate as opposed to lower level modules. It's an easy fix if we want it not to be an exception, I was just trying to make sure we had a clear philosophical reason for wanting things to be the way we were trying to have them be. (In other words, I was double-checking that the behavior the PR was supposed to create is really what we want before submitting a PR to do that.) It sounds like it is, so I'll get working on a bugfix. I feel like I'm expressing myself rather unclearly at the moment. If there's anything I need to clear up about this explanation, please feel free to let me know.
Oh oops, I missed this bit. Yes, I think this should be consistent with the submodules of the crate.
I agree, that sounds like the right behavior to me.
Quick update: I've got a substantive patch, but it's taking a while to get the tests to a point where I'm satisfied with them.
My PR is up! Also, I'm going to assign this as a , per the discussion in of the prioritization working group.

pub(crate) use reexports::UnionCrate; // @!has 'foo/union.UnionSelf.html' pub(self) use reexports::UnionSelf; <ins> // @!has 'foo/union.UnionLocal.html' use reexports::UnionLocal; pub mod outer { pub mod inner { // @has 'foo/outer/inner/macro.addr_of.html' '//*[@class="docblock item-decl"]' 'pub macro addr_of($place : expr) {' pub use reexports::addr_of; // @!has 'foo/outer/inner/macro.addr_of_crate.html' pub(crate) use reexports::addr_of_crate; // @!has 'foo/outer/inner/macro.addr_of_super.html' pub(super) use reexports::addr_of_super; // @!has 'foo/outer/inner/macro.addr_of_self.html' pub(self) use reexports::addr_of_self; // @!has 'foo/outer/inner/macro.addr_of_local.html' use reexports::addr_of_local; // @has 'foo/outer/inner/struct.Foo.html' '//*[@class="docblock item-decl"]' 'pub struct Foo;' pub use reexports::Foo; // @!has 'foo/outer/inner/struct.FooCrate.html' pub(crate) use reexports::FooCrate; // @!has 'foo/outer/inner/struct.FooSuper.html' pub(super) use reexports::FooSuper; // @!has 'foo/outer/inner/struct.FooSelf.html' pub(self) use reexports::FooSelf; // @!has 'foo/outer/inner/struct.FooLocal.html' use reexports::FooLocal; // @has 'foo/outer/inner/enum.Bar.html' '//*[@class="docblock item-decl"]' 'pub enum Bar {' pub use reexports::Bar; // @!has 'foo/outer/inner/enum.BarCrate.html' pub(crate) use reexports::BarCrate; // @!has 'foo/outer/inner/enum.BarSuper.html' pub(super) use reexports::BarSuper; // @!has 'foo/outer/inner/enum.BarSelf.html' pub(self) use reexports::BarSelf; // @!has 'foo/outer/inner/enum.BarLocal.html' use reexports::BarLocal; // @has 'foo/outer/inner/fn.foo.html' '//*[@class="rust fn"]' 'pub fn foo()' pub use reexports::foo; // @!has 'foo/outer/inner/fn.foo_crate.html' pub(crate) use reexports::foo_crate; // @!has 'foo/outer/inner/fn.foo_super.html' pub(super) use::reexports::foo_super; // @!has 'foo/outer/inner/fn.foo_self.html' pub(self) use reexports::foo_self; // @!has 'foo/outer/inner/fn.foo_local.html' use reexports::foo_local; // @has 'foo/outer/inner/type.Type.html' '//*[@class="rust typedef"]' 'pub type Type =' pub use reexports::Type; // @!has 'foo/outer/inner/type.TypeCrate.html' pub(crate) use reexports::TypeCrate; // @!has 'foo/outer/inner/type.TypeSuper.html' pub(super) use reexports::TypeSuper; // @!has 'foo/outer/inner/type.TypeSelf.html' pub(self) use reexports::TypeSelf; // @!has 'foo/outer/inner/type.TypeLocal.html' use reexports::TypeLocal; // @has 'foo/outer/inner/union.Union.html' '//*[@class="docblock item-decl"]' 'pub union Union {' pub use reexports::Union; // @!has 'foo/outer/inner/union.UnionCrate.html' pub(crate) use reexports::UnionCrate; // @!has 'foo/outer/inner/union.UnionSuper.html' pub(super) use reexports::UnionSuper; // @!has 'foo/outer/inner/union.UnionSelf.html' pub(self) use reexports::UnionSelf; // @!has 'foo/outer/inner/union.UnionLocal.html' use reexports::UnionLocal; } } </ins>


Question:
Source: It is worth noting that this code should not compile. This bug occurs in both beta and nightly. : <details<summary<strongBacktrace</strong</summary<p</p</details
No longer ICEs since

<ins> // check-pass pub trait Associate { type Associated; } pub struct Wrap<'a> { pub field: &'a i32, } pub trait Create<T> { fn create() -> Self; } pub fn oh_no<'a, T>() where Wrap<'a>: Associate, <Wrap<'a> as Associate>::Associated: Create<T>, { <Wrap<'a> as Associate>::Associated::create(); } pub fn main() {} </ins>


Question:
Source: It is worth noting that this code should not compile. This bug occurs in both beta and nightly. : <details<summary<strongBacktrace</strong</summary<p</p</details
No longer ICEs since

<ins> // check-pass #![feature(generic_associated_types)] trait Foo<T> { type Type<'a> where T: 'a; } impl<T> Foo<T> for () { type Type<'a> where T: 'a, = (); } fn foo<T>() { let _: for<'a> fn(<() as Foo<T>>::Type<'a>, &'a T) = |_, _| (); } pub fn main() {} </ins>


Question:
An enhancement request discussed here: (That thread also contains a hacky solution by Yandros). I propose to add a config like this: #[cfg(overflow_checks)] I would like to use it to enable/disable lines of code that perform safe unsafe "as" casts replacing them with casts when I compile with debug builds or with release builds compiled with "-C overflow-checks".
modify labels: C-enhancement
label A-attributes T-compiler
I’d also be interested in this.
Tracking issue:

(active, c_unwind, "1.52.0", Some(74990), None), /// Allows using C-variadics. (active, c_variadic, "1.34.0", Some(44930), None), <ins> /// Allows the use of `#[cfg(overflow_checks)` to check if integer overflow behaviour. (active, cfg_overflow_checks, "CURRENT_RUSTC_VERSION", Some(111466), None), </ins> /// Allows the use of `#[cfg(sanitize = "option")]`; set when -Zsanitizer is used. (active, cfg_sanitize, "1.41.0", Some(39699), None), /// Allows `cfg(target_abi = "...")`.


Question:
An enhancement request discussed here: (That thread also contains a hacky solution by Yandros). I propose to add a config like this: #[cfg(overflow_checks)] I would like to use it to enable/disable lines of code that perform safe unsafe "as" casts replacing them with casts when I compile with debug builds or with release builds compiled with "-C overflow-checks".
modify labels: C-enhancement
label A-attributes T-compiler
I’d also be interested in this.
Tracking issue:

/// `cfg(...)`'s that are feature gated. const GATED_CFGS: &[GatedCfg] = &[ // (name in cfg, feature, function to check if the feature is enabled) <ins> (sym::overflow_checks, sym::cfg_overflow_checks, cfg_fn!(cfg_overflow_checks)), </ins> (sym::target_abi, sym::cfg_target_abi, cfg_fn!(cfg_target_abi)), (sym::target_thread_local, sym::cfg_target_thread_local, cfg_fn!(cfg_target_thread_local)), (


Question:
An enhancement request discussed here: (That thread also contains a hacky solution by Yandros). I propose to add a config like this: #[cfg(overflow_checks)] I would like to use it to enable/disable lines of code that perform safe unsafe "as" casts replacing them with casts when I compile with debug builds or with release builds compiled with "-C overflow-checks".
modify labels: C-enhancement
label A-attributes T-compiler
I’d also be interested in this.
Tracking issue:

if sess.opts.debug_assertions { ret.insert((sym::debug_assertions, None)); } <ins> if sess.overflow_checks() { ret.insert((sym::overflow_checks, None)); } </ins> // JUSTIFICATION: before wrapper fn is available #[allow(rustc::bad_opt_access)] if sess.opts.crate_types.contains(&CrateType::ProcMacro) {


Question:
An enhancement request discussed here: (That thread also contains a hacky solution by Yandros). I propose to add a config like this: #[cfg(overflow_checks)] I would like to use it to enable/disable lines of code that perform safe unsafe "as" casts replacing them with casts when I compile with debug builds or with release builds compiled with "-C overflow-checks".
modify labels: C-enhancement
label A-attributes T-compiler
I’d also be interested in this.
Tracking issue:

sym::windows, sym::proc_macro, sym::debug_assertions, <ins> sym::overflow_checks, </ins> sym::target_thread_local, ] { self.expecteds.entry(name).or_insert_with(no_values);


Question:
An enhancement request discussed here: (That thread also contains a hacky solution by Yandros). I propose to add a config like this: #[cfg(overflow_checks)] I would like to use it to enable/disable lines of code that perform safe unsafe "as" casts replacing them with casts when I compile with debug builds or with release builds compiled with "-C overflow-checks".
modify labels: C-enhancement
label A-attributes T-compiler
I’d also be interested in this.
Tracking issue:

cfg_doctest, cfg_eval, cfg_hide, <ins> cfg_overflow_checks, </ins> cfg_panic, cfg_sanitize, cfg_target_abi,


Question:
An enhancement request discussed here: (That thread also contains a hacky solution by Yandros). I propose to add a config like this: #[cfg(overflow_checks)] I would like to use it to enable/disable lines of code that perform safe unsafe "as" casts replacing them with casts when I compile with debug builds or with release builds compiled with "-C overflow-checks".
modify labels: C-enhancement
label A-attributes T-compiler
I’d also be interested in this.
Tracking issue:

or_patterns, other, out, <ins> overflow_checks, </ins> overlapping_marker_traits, owned_box, packed,


Question:
An enhancement request discussed here: (That thread also contains a hacky solution by Yandros). I propose to add a config like this: #[cfg(overflow_checks)] I would like to use it to enable/disable lines of code that perform safe unsafe "as" casts replacing them with casts when I compile with debug builds or with release builds compiled with "-C overflow-checks".
modify labels: C-enhancement
label A-attributes T-compiler
I’d also be interested in this.
Tracking issue:

<ins> #![crate_type = "lib"] #[cfg(overflow_checks)] //~ ERROR `cfg(overflow_checks)` is experimental pub fn cast(v: i64)->u32{ todo!() } </ins>


Question:
An enhancement request discussed here: (That thread also contains a hacky solution by Yandros). I propose to add a config like this: #[cfg(overflow_checks)] I would like to use it to enable/disable lines of code that perform safe unsafe "as" casts replacing them with casts when I compile with debug builds or with release builds compiled with "-C overflow-checks".
modify labels: C-enhancement
label A-attributes T-compiler
I’d also be interested in this.
Tracking issue:

<ins> error[E0658]: `cfg(overflow_checks)` is experimental and subject to change --> $DIR/feature-gate-cfg_overflow_checks.rs:3:7 | LL | #[cfg(overflow_checks)] |       ^^^^^^^^^^^^^^^ | = note: see issue #111466 <https://github.com/rust-lang/rust/issues/111466> for more information = help: add `#![feature(cfg_overflow_checks)]` to the crate attributes to enable error: aborting due to previous error For more information about this error, try `rustc --explain E0658`. </ins>


Question:
An enhancement request discussed here: (That thread also contains a hacky solution by Yandros). I propose to add a config like this: #[cfg(overflow_checks)] I would like to use it to enable/disable lines of code that perform safe unsafe "as" casts replacing them with casts when I compile with debug builds or with release builds compiled with "-C overflow-checks".
modify labels: C-enhancement
label A-attributes T-compiler
I’d also be interested in this.
Tracking issue:

<ins> // run-pass // compile-flags: -C overflow_checks=true #![feature(cfg_overflow_checks)] fn main() { assert!(cfg!(overflow_checks)); assert!(compiles_differently()); } #[cfg(overflow_checks)] fn compiles_differently()->bool { true } #[cfg(not(overflow_checks))] fn compiles_differently()->bool { false } </ins>


Question:
An enhancement request discussed here: (That thread also contains a hacky solution by Yandros). I propose to add a config like this: #[cfg(overflow_checks)] I would like to use it to enable/disable lines of code that perform safe unsafe "as" casts replacing them with casts when I compile with debug builds or with release builds compiled with "-C overflow-checks".
modify labels: C-enhancement
label A-attributes T-compiler
I’d also be interested in this.
Tracking issue:

<ins> // run-pass // compile-flags: -C overflow_checks=false #![feature(cfg_overflow_checks)] fn main() { assert!(!cfg!(overflow_checks)); assert!(!compiles_differently()); } #[cfg(overflow_checks)] fn compiles_differently()->bool { true } #[cfg(not(overflow_checks))] fn compiles_differently()->bool { false } </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. -- <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Minimized a bit more:
It started ICE-ing in 1.41.0:
This compiles successfully without the bound. It also compiles if you change the bound to constrain the associated type:
I bisected it to be between and : I've tried to bisect between these commits, but I'm getting a compilation error in llvm.
It'll be , which changed the coherence rules to allow . The impl in this code is intentionally allowed under the new rules and should be fine, so it didn't really regress in that PR so much as it was newly permitted but likely surfaced a pre-existing bug. I tried to replicate this issue with a local trait but compiles successfully, so this does seem to involve the built-in trait and operator (the error message complains about the MIR statement which is a built-in index).
Further reduced to: , but not on 1.24.0 I agree with assessment:
So it could be considered a stable-to-stable regression? I don't how or who could add this label.
Yeah, I guess we could modify labels +regression-from-stable-to-stable although it's a regression from a very old stable
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium

// substitutions. use crate::check::FnCtxt; use hir::def_id::LocalDefId; use rustc_data_structures::fx::FxHashMap; use rustc_errors::ErrorGuaranteed;


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. -- <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Minimized a bit more:
It started ICE-ing in 1.41.0:
This compiles successfully without the bound. It also compiles if you change the bound to constrain the associated type:
I bisected it to be between and : I've tried to bisect between these commits, but I'm getting a compilation error in llvm.
It'll be , which changed the coherence rules to allow . The impl in this code is intentionally allowed under the new rules and should be fine, so it didn't really regress in that PR so much as it was newly permitted but likely surfaced a pre-existing bug. I tried to replicate this issue with a local trait but compiles successfully, so this does seem to involve the built-in trait and operator (the error message complains about the MIR statement which is a built-in index).
Further reduced to: , but not on 1.24.0 I agree with assessment:
So it could be considered a stable-to-stable regression? I don't how or who could add this label.
Yeah, I guess we could modify labels +regression-from-stable-to-stable although it's a regression from a very old stable
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium

use rustc_middle::ty::adjustment::{Adjust, Adjustment, PointerCast}; use rustc_middle::ty::fold::{TypeFoldable, TypeFolder, TypeSuperFoldable}; use rustc_middle::ty::visit::{TypeSuperVisitable, TypeVisitable}; <ins> use rustc_middle::ty::TypeckResults; </ins> use rustc_middle::ty::{self, ClosureSizeProfileData, Ty, TyCtxt}; use rustc_span::symbol::sym; use rustc_span::Span;


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. -- <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Minimized a bit more:
It started ICE-ing in 1.41.0:
This compiles successfully without the bound. It also compiles if you change the bound to constrain the associated type:
I bisected it to be between and : I've tried to bisect between these commits, but I'm getting a compilation error in llvm.
It'll be , which changed the coherence rules to allow . The impl in this code is intentionally allowed under the new rules and should be fine, so it didn't really regress in that PR so much as it was newly permitted but likely surfaced a pre-existing bug. I tried to replicate this issue with a local trait but compiles successfully, so this does seem to involve the built-in trait and operator (the error message complains about the MIR statement which is a built-in index).
Further reduced to: , but not on 1.24.0 I agree with assessment:
So it could be considered a stable-to-stable regression? I don't how or who could add this label.
Yeah, I guess we could modify labels +regression-from-stable-to-stable although it's a regression from a very old stable
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium

} } <ins> // (ouz-a 1005988): Normally `[T] : std::ops::Index<usize>` should be normalized // into [T] but currently `Where` clause stops the normalization process for it, // here we compare types of expr and base in a code without `Where` clause they would be equal // if they are not we don't modify the expr, hence we bypass the ICE fn is_builtin_index( &mut self, typeck_results: &TypeckResults<'tcx>, e: &hir::Expr<'_>, base_ty: Ty<'tcx>, index_ty: Ty<'tcx>, ) -> bool { if let Some(elem_ty) = base_ty.builtin_index() { let Some(exp_ty) = typeck_results.expr_ty_opt(e) else {return false;}; let resolved_exp_ty = self.resolve(exp_ty, &e.span); elem_ty == resolved_exp_ty && index_ty == self.fcx.tcx.types.usize } else { false } } </ins> // Similar to operators, indexing is always assumed to be overloaded // Here, correct cases where an indexing expression can be simplified // to use builtin indexing because the index type is known to be


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. -- <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Minimized a bit more:
It started ICE-ing in 1.41.0:
This compiles successfully without the bound. It also compiles if you change the bound to constrain the associated type:
I bisected it to be between and : I've tried to bisect between these commits, but I'm getting a compilation error in llvm.
It'll be , which changed the coherence rules to allow . The impl in this code is intentionally allowed under the new rules and should be fine, so it didn't really regress in that PR so much as it was newly permitted but likely surfaced a pre-existing bug. I tried to replicate this issue with a local trait but compiles successfully, so this does seem to involve the built-in trait and operator (the error message complains about the MIR statement which is a built-in index).
Further reduced to: , but not on 1.24.0 I agree with assessment:
So it could be considered a stable-to-stable regression? I don't how or who could add this label.
Yeah, I guess we could modify labels +regression-from-stable-to-stable although it's a regression from a very old stable
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium

) }); let index_ty = self.fcx.resolve_vars_if_possible(index_ty); <ins> let resolved_base_ty = self.resolve(*base_ty, &base.span); </ins> <del> if base_ty.builtin_index().is_some() && index_ty == self.fcx.tcx.types.usize { </del> <ins> if self.is_builtin_index(&typeck_results, e, resolved_base_ty, index_ty) { </ins> // Remove the method call record typeck_results.type_dependent_defs_mut().remove(e.hir_id); typeck_results.node_substs_mut().remove(e.hir_id);