Question: <ins> error[E0261]: use of undeclared lifetime name `'a` --> $DIR/ice-unexpected-inference-var-122549.rs:5:70 | LL |     fn const_chunks_exact<const N: usize>(&self) -> ConstChunksExact<'a, T, { N }>; |                                                                      ^^ undeclared lifetime | help: consider introducing lifetime `'a` here | LL |     fn const_chunks_exact<'a, const N: usize>(&self) -> ConstChunksExact<'a, T, { N }>; |                           +++ help: consider introducing lifetime `'a` here | LL | trait ConstChunksExactTrait<'a, T> { |                             +++ error[E0261]: use of undeclared lifetime name `'a` --> $DIR/ice-unexpected-inference-var-122549.rs:11:34 | LL | struct ConstChunksExact<'rem, T: 'a, const N: usize> {} |                         -        ^^ undeclared lifetime |                         | |                         help: consider introducing lifetime `'a` here: `'a,` error[E0046]: not all trait items implemented, missing: `const_chunks_exact` --> $DIR/ice-unexpected-inference-var-122549.rs:9:1 | LL |     fn const_chunks_exact<const N: usize>(&self) -> ConstChunksExact<'a, T, { N }>; |     ------------------------------------------------------------------------------- `const_chunks_exact` from trait ... LL | impl<T> ConstChunksExactTrait<T> for [T] {} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ missing `const_chunks_exact` in implementation error[E0392]: lifetime parameter `'rem` is never used --> $DIR/ice-unexpected-inference-var-122549.rs:11:25 | LL | struct ConstChunksExact<'rem, T: 'a, const N: usize> {} |                         ^^^^ unused lifetime parameter | = help: consider removing `'rem`, referring to it in a field, or using a marker such as `PhantomData` error[E0392]: type parameter `T` is never used --> $DIR/ice-unexpected-inference-var-122549.rs:11:31 | LL | struct ConstChunksExact<'rem, T: 'a, const N: usize> {} |                               ^ unused type parameter | = help: consider removing `T`, referring to it in a field, or using a marker such as `PhantomData` error[E0207]: the const parameter `N` is not constrained by the impl trait, self type, or predicates --> $DIR/ice-unexpected-inference-var-122549.rs:15:13 | LL | impl<'a, T, const N: usize> Iterator for ConstChunksExact<'a, T, {}> { |             ^^^^^^^^^^^^^^ unconstrained const parameter | = note: expressions using a const parameter must map each value to a distinct output value = note: proving the result of expressions other than the parameter are unique is not supported error[E0308]: mismatched types --> $DIR/ice-unexpected-inference-var-122549.rs:15:66 | LL | impl<'a, T, const N: usize> Iterator for ConstChunksExact<'a, T, {}> { |                                                                  ^^ expected `usize`, found `()` error: aborting due to 7 previous errors Some errors have detailed explanations: E0046, E0207, E0261, E0308, E0392. For more information about an error, try `rustc --explain E0046`. </ins>

<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'unexpected inference var std::option::Option<&'?16 [i32; ?0c: usize]'', 'thread 'rustc' panicked at 'unexpected inference var std::option::Option<&'?16 [i32; ?0c: usize]'' File: --snippet, probably from Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<perror[E0261]: use of undeclared lifetime name -- | 2 | fn constchunksexact<const N: usize(&self) -ConstChunksExact<'a, T, { N }; | ^^ undeclared lifetime | help: consider introducing lifetime here | 2 | fn constchunksexact<'a, const N: usize(&self) -ConstChunksExact<'a, T, { N }; | +++ help: consider introducing lifetime here | 1 | trait ConstChunksExactTrait<'a, T{ | +++ error[E0261]: use of undeclared lifetime name -- | 7 | struct ConstChunksExact<'rem, T: 'a, const N: usize{} | - ^^ undeclared lifetime | help: consider introducing lifetime here: error[E0046]: not all trait items implemented, missing: -- | 2 | fn constchunks_exact<const N: usize(&self) -ConstChunksExact<'a, T, { N }; |
from trait . 5 | impl<TConstChunksExactTrait<Tfor [T] {} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ missing in implementation error[E0392]: lifetime parameter is never used -- | 7 | struct ConstChunksExact<'rem, T: 'a, const N: usize{} | ^^^^ unused lifetime parameter | = help: consider removing , referring to it in a field, or using a marker such as error[E0392]: type parameter is never used -- | 7 | struct ConstChunksExact<'rem, T: 'a, const N: usize{} | ^ unused type parameter | = help: consider removing , referring to it in a field, or using a marker such as error[E0207]: the const parameter is not constrained by the impl trait, self type, or predicates -- | 9 | impl<'a, T,


Question: <ins> error[E0261]: use of undeclared lifetime name `'a` --> $DIR/ice-unexpected-inference-var-122549.rs:5:70 | LL |     fn const_chunks_exact<const N: usize>(&self) -> ConstChunksExact<'a, T, { N }>; |                                                                      ^^ undeclared lifetime | help: consider introducing lifetime `'a` here | LL |     fn const_chunks_exact<'a, const N: usize>(&self) -> ConstChunksExact<'a, T, { N }>; |                           +++ help: consider introducing lifetime `'a` here | LL | trait ConstChunksExactTrait<'a, T> { |                             +++ error[E0261]: use of undeclared lifetime name `'a` --> $DIR/ice-unexpected-inference-var-122549.rs:11:34 | LL | struct ConstChunksExact<'rem, T: 'a, const N: usize> {} |                         -        ^^ undeclared lifetime |                         | |                         help: consider introducing lifetime `'a` here: `'a,` error[E0046]: not all trait items implemented, missing: `const_chunks_exact` --> $DIR/ice-unexpected-inference-var-122549.rs:9:1 | LL |     fn const_chunks_exact<const N: usize>(&self) -> ConstChunksExact<'a, T, { N }>; |     ------------------------------------------------------------------------------- `const_chunks_exact` from trait ... LL | impl<T> ConstChunksExactTrait<T> for [T] {} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ missing `const_chunks_exact` in implementation error[E0392]: lifetime parameter `'rem` is never used --> $DIR/ice-unexpected-inference-var-122549.rs:11:25 | LL | struct ConstChunksExact<'rem, T: 'a, const N: usize> {} |                         ^^^^ unused lifetime parameter | = help: consider removing `'rem`, referring to it in a field, or using a marker such as `PhantomData` error[E0392]: type parameter `T` is never used --> $DIR/ice-unexpected-inference-var-122549.rs:11:31 | LL | struct ConstChunksExact<'rem, T: 'a, const N: usize> {} |                               ^ unused type parameter | = help: consider removing `T`, referring to it in a field, or using a marker such as `PhantomData` error[E0207]: the const parameter `N` is not constrained by the impl trait, self type, or predicates --> $DIR/ice-unexpected-inference-var-122549.rs:15:13 | LL | impl<'a, T, const N: usize> Iterator for ConstChunksExact<'a, T, {}> { |             ^^^^^^^^^^^^^^ unconstrained const parameter | = note: expressions using a const parameter must map each value to a distinct output value = note: proving the result of expressions other than the parameter are unique is not supported error[E0308]: mismatched types --> $DIR/ice-unexpected-inference-var-122549.rs:15:66 | LL | impl<'a, T, const N: usize> Iterator for ConstChunksExact<'a, T, {}> { |                                                                  ^^ expected `usize`, found `()` error: aborting due to 7 previous errors Some errors have detailed explanations: E0046, E0207, E0261, E0308, E0392. For more information about an error, try `rustc --explain E0046`. </ins>

const N: usizeIterator for ConstChunksExact<'a, T, {}{ | ^^^^^^^^^^^^^^ unconstrained const parameter | = note: expressions using a const parameter must map each value to a distinct output value = note: proving the result of expressions other than the parameter are unique is not supported error[E0308]: mismatched types -- | 9 | impl<'a, T, const N: usizeIterator for ConstChunksExact<'a, T, {}{ | ^^ expected , found thread 'rustc' panicked at unexpected inference var std::option::Option<&'?16 [i32;


Question: <ins> error[E0261]: use of undeclared lifetime name `'a` --> $DIR/ice-unexpected-inference-var-122549.rs:5:70 | LL |     fn const_chunks_exact<const N: usize>(&self) -> ConstChunksExact<'a, T, { N }>; |                                                                      ^^ undeclared lifetime | help: consider introducing lifetime `'a` here | LL |     fn const_chunks_exact<'a, const N: usize>(&self) -> ConstChunksExact<'a, T, { N }>; |                           +++ help: consider introducing lifetime `'a` here | LL | trait ConstChunksExactTrait<'a, T> { |                             +++ error[E0261]: use of undeclared lifetime name `'a` --> $DIR/ice-unexpected-inference-var-122549.rs:11:34 | LL | struct ConstChunksExact<'rem, T: 'a, const N: usize> {} |                         -        ^^ undeclared lifetime |                         | |                         help: consider introducing lifetime `'a` here: `'a,` error[E0046]: not all trait items implemented, missing: `const_chunks_exact` --> $DIR/ice-unexpected-inference-var-122549.rs:9:1 | LL |     fn const_chunks_exact<const N: usize>(&self) -> ConstChunksExact<'a, T, { N }>; |     ------------------------------------------------------------------------------- `const_chunks_exact` from trait ... LL | impl<T> ConstChunksExactTrait<T> for [T] {} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ missing `const_chunks_exact` in implementation error[E0392]: lifetime parameter `'rem` is never used --> $DIR/ice-unexpected-inference-var-122549.rs:11:25 | LL | struct ConstChunksExact<'rem, T: 'a, const N: usize> {} |                         ^^^^ unused lifetime parameter | = help: consider removing `'rem`, referring to it in a field, or using a marker such as `PhantomData` error[E0392]: type parameter `T` is never used --> $DIR/ice-unexpected-inference-var-122549.rs:11:31 | LL | struct ConstChunksExact<'rem, T: 'a, const N: usize> {} |                               ^ unused type parameter | = help: consider removing `T`, referring to it in a field, or using a marker such as `PhantomData` error[E0207]: the const parameter `N` is not constrained by the impl trait, self type, or predicates --> $DIR/ice-unexpected-inference-var-122549.rs:15:13 | LL | impl<'a, T, const N: usize> Iterator for ConstChunksExact<'a, T, {}> { |             ^^^^^^^^^^^^^^ unconstrained const parameter | = note: expressions using a const parameter must map each value to a distinct output value = note: proving the result of expressions other than the parameter are unique is not supported error[E0308]: mismatched types --> $DIR/ice-unexpected-inference-var-122549.rs:15:66 | LL | impl<'a, T, const N: usize> Iterator for ConstChunksExact<'a, T, {}> { |                                                                  ^^ expected `usize`, found `()` error: aborting due to 7 previous errors Some errors have detailed explanations: E0046, E0207, E0261, E0308, E0392. For more information about an error, try `rustc --explain E0046`. </ins>

?0c: usize]stack backtrace: 0: 0x7ff8073a4912 - std::backtracers::backtrace::libunwind::trace::h2da6c6ec1776ed1b at 1: 0x7ff8073a4912 - std::backtracers::backtrace::traceunsynchronized::h0cb696e9cf0107ba at 2: 0x7ff8073a4912 - std::syscommon::backtrace::printfmt::hfb11ed7a7d38a028 at 3: 0x7ff8073a4912 - <std::syscommon::backtrace::print::DisplayBacktrace as core::fmt::Display::fmt::h1048d052a888b26c at 4: 0x7ff8073f5c8c - core::fmt::rt::Argument::fmt::hcf8265a03a389e34 at 5: 0x7ff8073f5c8c - core::fmt::write::hd12c3a84e62e1cec at 6: 0x7ff80739980f - std::io::Write::writefmt::h236993be0d5d91de at 7: 0x7ff8073a46e4 - std::syscommon::backtrace::print::he44e9b7b149d34c3 at 8: 0x7ff8073a46e4 - std::syscommon::backtrace::print::h6f8e8e3b9f052551 at 9: 0x7ff8073a73eb - std::panicking::defaulthook::{{closure}}::h321d04c9179dccca 10: 0x7ff8073a7143 - std::panicking::defaulthook::hd949d1362c2e5565 at 11: 0x7ff803fa68ef - std[]::panicking::updatehook::<alloc[]::boxed::Box<rustcdriverimpl[]::installicehook::{closure}::{closure} 12: 0x7ff8073a7b50 - <alloc::boxed::Box<F,


Question: <ins> error[E0261]: use of undeclared lifetime name `'a` --> $DIR/ice-unexpected-inference-var-122549.rs:5:70 | LL |     fn const_chunks_exact<const N: usize>(&self) -> ConstChunksExact<'a, T, { N }>; |                                                                      ^^ undeclared lifetime | help: consider introducing lifetime `'a` here | LL |     fn const_chunks_exact<'a, const N: usize>(&self) -> ConstChunksExact<'a, T, { N }>; |                           +++ help: consider introducing lifetime `'a` here | LL | trait ConstChunksExactTrait<'a, T> { |                             +++ error[E0261]: use of undeclared lifetime name `'a` --> $DIR/ice-unexpected-inference-var-122549.rs:11:34 | LL | struct ConstChunksExact<'rem, T: 'a, const N: usize> {} |                         -        ^^ undeclared lifetime |                         | |                         help: consider introducing lifetime `'a` here: `'a,` error[E0046]: not all trait items implemented, missing: `const_chunks_exact` --> $DIR/ice-unexpected-inference-var-122549.rs:9:1 | LL |     fn const_chunks_exact<const N: usize>(&self) -> ConstChunksExact<'a, T, { N }>; |     ------------------------------------------------------------------------------- `const_chunks_exact` from trait ... LL | impl<T> ConstChunksExactTrait<T> for [T] {} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ missing `const_chunks_exact` in implementation error[E0392]: lifetime parameter `'rem` is never used --> $DIR/ice-unexpected-inference-var-122549.rs:11:25 | LL | struct ConstChunksExact<'rem, T: 'a, const N: usize> {} |                         ^^^^ unused lifetime parameter | = help: consider removing `'rem`, referring to it in a field, or using a marker such as `PhantomData` error[E0392]: type parameter `T` is never used --> $DIR/ice-unexpected-inference-var-122549.rs:11:31 | LL | struct ConstChunksExact<'rem, T: 'a, const N: usize> {} |                               ^ unused type parameter | = help: consider removing `T`, referring to it in a field, or using a marker such as `PhantomData` error[E0207]: the const parameter `N` is not constrained by the impl trait, self type, or predicates --> $DIR/ice-unexpected-inference-var-122549.rs:15:13 | LL | impl<'a, T, const N: usize> Iterator for ConstChunksExact<'a, T, {}> { |             ^^^^^^^^^^^^^^ unconstrained const parameter | = note: expressions using a const parameter must map each value to a distinct output value = note: proving the result of expressions other than the parameter are unique is not supported error[E0308]: mismatched types --> $DIR/ice-unexpected-inference-var-122549.rs:15:66 | LL | impl<'a, T, const N: usize> Iterator for ConstChunksExact<'a, T, {}> { |                                                                  ^^ expected `usize`, found `()` error: aborting due to 7 previous errors Some errors have detailed explanations: E0046, E0207, E0261, E0308, E0392. For more information about an error, try `rustc --explain E0046`. </ins>

Aas core::ops::function::Fn<Args::call::h4f6c988be7bdee68 at 13: 0x7ff8073a7b50 - std::panicking::rustpanicwithhook::hb71de646be3b3469 at 14: 0x7ff8073a7892 - std::panicking::beginpanichandler::{{closure}}::hbca15a8a0a3dee72 at 15: 0x7ff8073a4de6 - std::syscommon::backtrace::rustendshortbacktrace::h885125d06f4d13f0 at 16: 0x7ff8073a75c4 - rustbeginunwind at 17: 0x7ff8073f21a5 - core::panicking::panicfmt::ha3facef8c988a935 at 18: 0x7ff80529d0a8 - <rustcborrowck[]::typecheck::relatetys::NllTypeRelating as rustcmiddle[]::ty::relate::TypeRelation::tys 19: 0x7ff80608d936 - <rustcborrowck[]::typecheck::TypeChecker::typeckmir 20: 0x7ff802afa5fa - rustcborrowck[]::typecheck::typecheck 21: 0x7ff802b34257 - rustcborrowck[]::nll::computeregions 22: 0x7ff80601edc1 - rustcborrowck[]::domirborrowck 23: 0x7ff806011128 - rustcborrowck[]::mirborrowck 24: 0x7ff806010c17 - rustcqueryimpl[]::plumbing::rustbeginshortbacktrace::<rustcqueryimpl[]::queryimpl::mirborrowck::dynamicquery::{closure}::{closure}, rustcmiddle[]::query::erase::Erased<[u8; 8usize]25: 0x7ff80540ff2e - rustcquerysystem[]::query::plumbing::tryexecutequery::<rustcqueryimpl[]::DynamicConfig<rustcquerysystem[]::query::caches::VecCache<rustcspan[]::defid::LocalDefId,


Question: <ins> error[E0261]: use of undeclared lifetime name `'a` --> $DIR/ice-unexpected-inference-var-122549.rs:5:70 | LL |     fn const_chunks_exact<const N: usize>(&self) -> ConstChunksExact<'a, T, { N }>; |                                                                      ^^ undeclared lifetime | help: consider introducing lifetime `'a` here | LL |     fn const_chunks_exact<'a, const N: usize>(&self) -> ConstChunksExact<'a, T, { N }>; |                           +++ help: consider introducing lifetime `'a` here | LL | trait ConstChunksExactTrait<'a, T> { |                             +++ error[E0261]: use of undeclared lifetime name `'a` --> $DIR/ice-unexpected-inference-var-122549.rs:11:34 | LL | struct ConstChunksExact<'rem, T: 'a, const N: usize> {} |                         -        ^^ undeclared lifetime |                         | |                         help: consider introducing lifetime `'a` here: `'a,` error[E0046]: not all trait items implemented, missing: `const_chunks_exact` --> $DIR/ice-unexpected-inference-var-122549.rs:9:1 | LL |     fn const_chunks_exact<const N: usize>(&self) -> ConstChunksExact<'a, T, { N }>; |     ------------------------------------------------------------------------------- `const_chunks_exact` from trait ... LL | impl<T> ConstChunksExactTrait<T> for [T] {} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ missing `const_chunks_exact` in implementation error[E0392]: lifetime parameter `'rem` is never used --> $DIR/ice-unexpected-inference-var-122549.rs:11:25 | LL | struct ConstChunksExact<'rem, T: 'a, const N: usize> {} |                         ^^^^ unused lifetime parameter | = help: consider removing `'rem`, referring to it in a field, or using a marker such as `PhantomData` error[E0392]: type parameter `T` is never used --> $DIR/ice-unexpected-inference-var-122549.rs:11:31 | LL | struct ConstChunksExact<'rem, T: 'a, const N: usize> {} |                               ^ unused type parameter | = help: consider removing `T`, referring to it in a field, or using a marker such as `PhantomData` error[E0207]: the const parameter `N` is not constrained by the impl trait, self type, or predicates --> $DIR/ice-unexpected-inference-var-122549.rs:15:13 | LL | impl<'a, T, const N: usize> Iterator for ConstChunksExact<'a, T, {}> { |             ^^^^^^^^^^^^^^ unconstrained const parameter | = note: expressions using a const parameter must map each value to a distinct output value = note: proving the result of expressions other than the parameter are unique is not supported error[E0308]: mismatched types --> $DIR/ice-unexpected-inference-var-122549.rs:15:66 | LL | impl<'a, T, const N: usize> Iterator for ConstChunksExact<'a, T, {}> { |                                                                  ^^ expected `usize`, found `()` error: aborting due to 7 previous errors Some errors have detailed explanations: E0046, E0207, E0261, E0308, E0392. For more information about an error, try `rustc --explain E0046`. </ins>

rustcmiddle[]::query::erase::Erased<[u8; 8usize], false, false, false, rustcqueryimpl[]::plumbing::QueryCtxt, false26: 0x7ff80540fa4c - rustcqueryimpl[]::queryimpl::mirborrowck::getquerynonincr::rustendshortbacktrace 27: 0x7ff80599919e - rustcinterface[]::passes::analysis 28: 0x7ff805998425 - rustcqueryimpl[]::plumbing::rustbeginshortbacktrace::<rustcqueryimpl[]::queryimpl::analysis::dynamicquery::{closure}::{closure}, rustcmiddle[]::query::erase::Erased<[u8; 1usize]29: 0x7ff806006165 - rustcquerysystem[]::query::plumbing::tryexecutequery::<rustcqueryimpl[]::DynamicConfig<rustcquerysystem[]::query::caches::SingleCache<rustcmiddle[]::query::erase::Erased<[u8; 1usize], false, false, false, rustcqueryimpl[]::plumbing::QueryCtxt, false30: 0x7ff806005ec9 - rustcqueryimpl[]::queryimpl::analysis::getquerynonincr::rustendshortbacktrace 31: 0x7ff805d5e284 - rustcinterface[]::interface::runcompiler::<core[]::result::Result<(), rustcspan[]::ErrorGuaranteed, rustcdriverimpl[]::runcompiler::{closure}::{closure} 32: 0x7ff806223805 - std[]::syscommon::backtrace::rustbeginshortbacktrace::<rustcinterface[]::util::runinthreadwithglobals<rustcinterface[]::util::runinthreadpoolwithglobals<rustcinterface[]::interface::runcompiler<core[]::result::Result<(), rustcspan[]::ErrorGuaranteed, rustcdriverimpl[]::runcompiler::{closure}::{closure}, core[]::result::Result<(), rustcspan[]::ErrorGuaranteed::{closure}, core[]::result::Result<(), rustcspan[]::ErrorGuaranteed::{closure}::{closure}, core[]::result::Result<(),


Question: <ins> error[E0261]: use of undeclared lifetime name `'a` --> $DIR/ice-unexpected-inference-var-122549.rs:5:70 | LL |     fn const_chunks_exact<const N: usize>(&self) -> ConstChunksExact<'a, T, { N }>; |                                                                      ^^ undeclared lifetime | help: consider introducing lifetime `'a` here | LL |     fn const_chunks_exact<'a, const N: usize>(&self) -> ConstChunksExact<'a, T, { N }>; |                           +++ help: consider introducing lifetime `'a` here | LL | trait ConstChunksExactTrait<'a, T> { |                             +++ error[E0261]: use of undeclared lifetime name `'a` --> $DIR/ice-unexpected-inference-var-122549.rs:11:34 | LL | struct ConstChunksExact<'rem, T: 'a, const N: usize> {} |                         -        ^^ undeclared lifetime |                         | |                         help: consider introducing lifetime `'a` here: `'a,` error[E0046]: not all trait items implemented, missing: `const_chunks_exact` --> $DIR/ice-unexpected-inference-var-122549.rs:9:1 | LL |     fn const_chunks_exact<const N: usize>(&self) -> ConstChunksExact<'a, T, { N }>; |     ------------------------------------------------------------------------------- `const_chunks_exact` from trait ... LL | impl<T> ConstChunksExactTrait<T> for [T] {} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ missing `const_chunks_exact` in implementation error[E0392]: lifetime parameter `'rem` is never used --> $DIR/ice-unexpected-inference-var-122549.rs:11:25 | LL | struct ConstChunksExact<'rem, T: 'a, const N: usize> {} |                         ^^^^ unused lifetime parameter | = help: consider removing `'rem`, referring to it in a field, or using a marker such as `PhantomData` error[E0392]: type parameter `T` is never used --> $DIR/ice-unexpected-inference-var-122549.rs:11:31 | LL | struct ConstChunksExact<'rem, T: 'a, const N: usize> {} |                               ^ unused type parameter | = help: consider removing `T`, referring to it in a field, or using a marker such as `PhantomData` error[E0207]: the const parameter `N` is not constrained by the impl trait, self type, or predicates --> $DIR/ice-unexpected-inference-var-122549.rs:15:13 | LL | impl<'a, T, const N: usize> Iterator for ConstChunksExact<'a, T, {}> { |             ^^^^^^^^^^^^^^ unconstrained const parameter | = note: expressions using a const parameter must map each value to a distinct output value = note: proving the result of expressions other than the parameter are unique is not supported error[E0308]: mismatched types --> $DIR/ice-unexpected-inference-var-122549.rs:15:66 | LL | impl<'a, T, const N: usize> Iterator for ConstChunksExact<'a, T, {}> { |                                                                  ^^ expected `usize`, found `()` error: aborting due to 7 previous errors Some errors have detailed explanations: E0046, E0207, E0261, E0308, E0392. For more information about an error, try `rustc --explain E0046`. </ins>

rustcspan[]::ErrorGuaranteed33: 0x7ff806223632 - <<std[]::thread::Builder::spawnunchecked<rustcinterface[]::util::runinthreadwithglobals<rustcinterface[]::util::runinthreadpoolwithglobals<rustcinterface[]::interface::runcompiler<core[]::result::Result<(), rustcspan[]::ErrorGuaranteed, rustcdriverimpl[]::runcompiler::{closure}::{closure}, core[]::result::Result<(), rustcspan[]::ErrorGuaranteed::{closure}, core[]::result::Result<(), rustcspan[]::ErrorGuaranteed::{closure}::{closure}, core[]::result::Result<(), rustcspan[]::ErrorGuaranteed::{closure} as core[]::ops::function::FnOnce<()::callonce::{shim:vtable} 34: 0x7ff8073b11e5 - <alloc::boxed::Box<F,Aas core::ops::function::FnOnce<Args::callonce::hab5d072bb143d8fe at 35: 0x7ff8073b11e5 - <alloc::boxed::Box<F,Aas core::ops::function::FnOnce<Args::callonce::he1f566ad483a8fda at 36: 0x7ff8073b11e5 - std::sys::pal::unix::thread::Thread::new::threadstart::h23d47a8da771b95c at 37: 0x7ff800ea955a - <unknown38: 0x7ff800f26a3c - <unknown39: 0x0 - <unknownerror: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: rustc 1.78.0-nightly ( 2024-03-15) running on x8664-unknown-linux-gnu query stack during panic: [mirborrowck] borrow-checking [analysis] running analysis passes on this crate end of query stack error: aborting due to 7 previous errors Some errors have detailed explanations: E0046, E0207, E0261, E0308, E0392. For more information about an error, try .


Question: <ins> error[E0261]: use of undeclared lifetime name `'a` --> $DIR/ice-unexpected-inference-var-122549.rs:5:70 | LL |     fn const_chunks_exact<const N: usize>(&self) -> ConstChunksExact<'a, T, { N }>; |                                                                      ^^ undeclared lifetime | help: consider introducing lifetime `'a` here | LL |     fn const_chunks_exact<'a, const N: usize>(&self) -> ConstChunksExact<'a, T, { N }>; |                           +++ help: consider introducing lifetime `'a` here | LL | trait ConstChunksExactTrait<'a, T> { |                             +++ error[E0261]: use of undeclared lifetime name `'a` --> $DIR/ice-unexpected-inference-var-122549.rs:11:34 | LL | struct ConstChunksExact<'rem, T: 'a, const N: usize> {} |                         -        ^^ undeclared lifetime |                         | |                         help: consider introducing lifetime `'a` here: `'a,` error[E0046]: not all trait items implemented, missing: `const_chunks_exact` --> $DIR/ice-unexpected-inference-var-122549.rs:9:1 | LL |     fn const_chunks_exact<const N: usize>(&self) -> ConstChunksExact<'a, T, { N }>; |     ------------------------------------------------------------------------------- `const_chunks_exact` from trait ... LL | impl<T> ConstChunksExactTrait<T> for [T] {} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ missing `const_chunks_exact` in implementation error[E0392]: lifetime parameter `'rem` is never used --> $DIR/ice-unexpected-inference-var-122549.rs:11:25 | LL | struct ConstChunksExact<'rem, T: 'a, const N: usize> {} |                         ^^^^ unused lifetime parameter | = help: consider removing `'rem`, referring to it in a field, or using a marker such as `PhantomData` error[E0392]: type parameter `T` is never used --> $DIR/ice-unexpected-inference-var-122549.rs:11:31 | LL | struct ConstChunksExact<'rem, T: 'a, const N: usize> {} |                               ^ unused type parameter | = help: consider removing `T`, referring to it in a field, or using a marker such as `PhantomData` error[E0207]: the const parameter `N` is not constrained by the impl trait, self type, or predicates --> $DIR/ice-unexpected-inference-var-122549.rs:15:13 | LL | impl<'a, T, const N: usize> Iterator for ConstChunksExact<'a, T, {}> { |             ^^^^^^^^^^^^^^ unconstrained const parameter | = note: expressions using a const parameter must map each value to a distinct output value = note: proving the result of expressions other than the parameter are unique is not supported error[E0308]: mismatched types --> $DIR/ice-unexpected-inference-var-122549.rs:15:66 | LL | impl<'a, T, const N: usize> Iterator for ConstChunksExact<'a, T, {}> { |                                                                  ^^ expected `usize`, found `()` error: aborting due to 7 previous errors Some errors have detailed explanations: E0046, E0207, E0261, E0308, E0392. For more information about an error, try `rustc --explain E0046`. </ins>

</p</details<!-- query stack: 5 | impl<TConstChunksExactTrait<Tfor [T] {} [mirborrowck] borrow-checking [analysis] running analysis passes on this crate --
cc


Question: <ins> // Copyright 2016 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. pub struct Foo; macro_rules! reexport { () => { use Foo as Bar; } } reexport!(); fn main() { use Bar; fn f(_: Bar) {} } </ins>

Test case: Compiles successfully on , causes an ICE on . Diff contains only , CC Found while trying to minimize , but filed separately since the error message is different and this one has a small test case.
Do you have a backtrace?
Yes of course. Sorry I forgot to include it: rust error: internal compiler error: attempted .defid() on invalid def: Err note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: run with for a backtrace thread 'rustc' panicked at 'Box<Any',


Question: <ins> // Copyright 2016 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. pub struct Foo; macro_rules! reexport { () => { use Foo as Bar; } } reexport!(); fn main() { use Bar; fn f(_: Bar) {} } </ins>

stack backtrace: 1: 0x7fc35e73fdf3 - std::sys::imp::backtrace::tracing::imp::write::hdfa3e34b856f69a3 2: 0x7fc35e74e5dd - std::panicking::defaulthook::{{closure}}::h20f8c1082e0ce86e 3: 0x7fc35e74e17b - std::panicking::defaulthook::hd31552ac08c2a241 4: 0x7fc35e74ea68 - std::panicking::rustpanicwithhook::h73969d230a072c1a 5: 0x7fc357eda667 - std::panicking::beginpanic::hb89a2261f4776ce3 6: 0x7fc357eef99f - rustcerrors::Handler::bug::h13b3b29154320abd 7: 0x7fc35bab053a - rustc::session::optspanbugfmt::{{closure}}::hfea18dd68f59976d 8: 0x7fc35baafff7 - rustc::session::optspanbugfmt::h7d370a0810dbdbbd 9: 0x7fc35baafce2 - rustc::session::bugfmt::hcde5f50c54004a4f 10: 0x7fc35b984552 - rustc::hir::def::Def::defid::h728c22aafbe84efc 11: 0x7fc35c6ddb3a - rustcprivacy::ObsoleteVisiblePrivateTypesVisitor::pathisprivatetype::h24756a49a68d1da9 12: 0x7fc35c6d53db - rustc::hir::intravisit::walkty::h64b13c0c45b7a09a 13: 0x7fc35c6d49ba - rustc::hir::intravisit::Visitor::visitfn::ha8ad665c42b1d643 14: 0x7fc35c6de7cf - <rustcprivacy::ObsoleteVisiblePrivateTypesVisitor<'a,


Question: <ins> // Copyright 2016 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. pub struct Foo; macro_rules! reexport { () => { use Foo as Bar; } } reexport!(); fn main() { use Bar; fn f(_: Bar) {} } </ins>

'tcxas rustc::hir::intravisit::Visitor<'tcx::visititem::hae9f32c7942ccca1 15: 0x7fc35c6deab5 - <rustcprivacy::ObsoleteVisiblePrivateTypesVisitor<'a, 'tcxas rustc::hir::intravisit::Visitor<'tcx::visititem::hae9f32c7942ccca1 16: 0x7fc35c6e1b7a - rustcprivacy::checkcrate::h5ba75e3c4ebe0690 17: 0x7fc35eaef747 - rustcdriver::driver::phase3runanalysispasses::{{closure}}::h388b9236cf305089 18: 0x7fc35ead66d6 - rustcdriver::driver::phase3runanalysispasses::h080c1a734c4f2909 19: 0x7fc35eac5425 - rustcdriver::driver::compileinput::hab55539b85c4ceed 20: 0x7fc35eb0ea51 - rustcdriver::runcompiler::h128b89b79f649304 21: 0x7fc35ea236fb - std::panicking::try::docall::h15bca94dda232804 22: 0x7fc35e757b06 - rustmaybecatchpanic 23: 0x7fc35ea44d01 - <F as alloc::boxed::FnBox<A::callbox::h8832766c4bda585b 24: 0x7fc35e74d470 - std::sys::imp::thread::Thread::new::threadstart::h7d03d727f96da002 25: 0x7fc357684453 - startthread 26: 0x7fc35e4147de - GI__clone 27: 0x0 - <unknown
triage: P-high Seems bad. Assigning to based on bisection.
Fixed in .


Question: <ins> // Copyright 2016 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. pub struct Foo; macro_rules! reexport { () => { use Foo as Bar; } } reexport!(); fn main() { use Bar; fn f(_: Bar) {} } </ins>

Servo compiles with rustc 2016-12-18, but not with 2016-12-21. Diff: The crate fails to build with: The method being called here is: Its return type is which is . This call is in another impl of the same method of the same trait: Adding an explicit type annotation works around this error, but only to uncover another very similar one, then another. The third one was in code generated by serde’s , so I gave up that approach. So far I haven’t managed to reduce a test case smaller than "most of Servo", sorry. I’m suspicious of (which is part of ) because it’s commit message mentions inference. I’m not building a compiler to confirm.
CC
Also fails in , so is not to blame. New diff: I don’t have another guess, and doing a full bisect would take a very long time…
I can't find the cause in that range, at least nothing changed in the compiler AFAICT. Can you try (the commit before larger rollup)?
Expanding the macro: (Even simplifying it, this is not using ) gives:
Alright, that matches what I've seen from What about a couple more steps of bisecting? Or maybe compiling this crate with the "servo" feature off (which, AFAICT, turns off all the macros 1.1 - they might be responsible).
Swapping the order of the two arms: Changing the pattern to : Hacking to not use the stable version of the compiler (so effectively disabling the feature and enabling the one) also gives the same error.
New range, based on manual bisect: good, bad. Diff: , which leaves only in-between. CC Also found more clues. More context for the code where the error happens: is a module generated by a macro, that contains re-exports of other modules: If I add a similar not in a macro: or if I change the original code to use the real path without going through a , this seems to work around this issue completely. … only to uncover another one:
Found another ICE, I don’t know if it’s related: .


Question: <ins> // Copyright 2016 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. pub struct Foo; macro_rules! reexport { () => { use Foo as Bar; } } reexport!(); fn main() { use Bar; fn f(_: Bar) {} } </ins>

Found a smaller test case for the inference issue: rust fn main() {} pub mod a { pub struct FontFamily; impl FontFamily { pub fn tocss(&self) -::std::fmt::Result { Ok(()) } } } macrorules! reexport { () ={ mod b { pub use a; } } } reexport!(); pub mod c { use b::a::FontFamily; struct FontFace { family: FontFamily } impl FontFace { pub fn tocss(&self) -::std::fmt::Result { try!(()); Ok(()) } } }
That "other ICE" is actually a direct observation of the bug, whereas this inference issue is some weird side-effect of the way we handle errors that don't stop compilation.
never mind, apparently it fails locally
triage: P-high Seems bad. Assigning to based on bisection.
Does this affect beta ()?
At the moment the latest successful nightly build is 3 days old. I don’t know how often playpen’s nigthly is updated. merged 2 days ago. (This is the rollup PR that merged , which introduced this issue if I did my manual bisecting correctly.) As far as I can tell no, is not reachable from and so beta is not affected.
Fixed in .


Question: #[deprecated(since(b), note = "a")] //~ ERROR incorrect meta item fn f6() { } <ins> #[deprecated(note = b"test")] //~ ERROR literal in `deprecated` value must be a string fn f7() { } #[deprecated("test")] //~ ERROR item in `deprecated` must be a key/value pair fn f8() { } </ins> } #[deprecated(since = "a", note = "b")]

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


Question: let a_kind = &a.kind; let b_kind = &b.kind; <del> let compare_layouts = |a, b| -> bool { let a_layout = &cx.layout_of(a).unwrap().layout.abi; let b_layout = &cx.layout_of(b).unwrap().layout.abi; debug!("{:?} == {:?} = {}", a_layout, b_layout, a_layout == b_layout); a_layout == b_layout </del> <ins> let compare_layouts = |a, b| -> Result<bool, LayoutError<'tcx>> { debug!("compare_layouts({:?}, {:?})", a, b); let a_layout = &cx.layout_of(a)?.layout.abi; let b_layout = &cx.layout_of(b)?.layout.abi; debug!( "comparing layouts: {:?} == {:?} = {}", a_layout, b_layout, a_layout == b_layout ); Ok(a_layout == b_layout) </ins> }; #[allow(rustc::usage_of_ty_tykind)]

<!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc for ClashingExternDeclarations in backtrace.
claim
Thank you for fixing it! There is nothing better than software with only a few open issues.
Not a problem! Thank you for the report, and especially for taking the time to make a minimal example :)


Question: /// Copied from String::push /// This does **not** include the WTF-8 concatenation check. fn push_code_point_unchecked(&mut self, code_point: CodePoint) { <del> let c = unsafe { char::from_u32_unchecked(code_point.value) }; </del> let mut bytes = [0; 4]; <del> let bytes = c.encode_utf8(&mut bytes).as_bytes(); </del> <ins> let bytes = char::encode_utf8_raw(code_point.value, &mut bytes); </ins> self.bytes.extend_from_slice(bytes) }

The following program causes UB: Miri says: The problem is this code: This calls unless the new code point is in , but what about surrogates in ? This code is unchanged since its introduction in I am not sure what the intended safety contract of is. That method is not marked but clearly should be -- it calls . So my guess is the safety precondition is that must not be part of a surrogate pair, but the thing is, calls it without actually ensuring that condition. The condition it does ensure is that the codepoint is not in , but that does not help.
is excluded from Unicode scalar values a.k.a. , but it’s fine as a Unicode code point. I think this bug is not in the contract of (which is private anyway) but in its implementation, namely going through . The fix is to either duplicate the logic of into , or (to avoid duplication) move that logic to a new function in libcore that takes a parameter and that is called by both and . This function would need to be public because is in a different crate, but it should be prema-unstable and .
I would classify the priority of this bug as low. Although this call to is UB, I expect Miri checking for it explicitly is the only case where that has any consequence in today’s implementation: behaves as expected (for the purpose of WTF-8) in the surrogate range and does not exploit this UB The "layout" of in rustc excludes values beyond but not surrogates:
By the way, the docs at feel insufficient: Which values are invalid? Similarly, and say that represents Unicode Scalar values, but I couldn’t find it documented anywhere that constructing an out of range is Undefined Behavior rather than "merely" a logic bug. Is this specified elsewhere? What is the closest we have to a written down normative resource that specifies what is or isn’t UB in the the Rust language? (For APIs I assume this is the responsibility of their respective doc-comments.)
I agree the impact is low, but it's not just Miri -- this blocks , which is how I discovered the problem. That would be
But then what is "unchecked" about it? Elsewhere in that file the code is careful not to construct a from a without checking for surrogates: That made me assume the author was aware that surrogates in are UB.


Question: /// Copied from String::push /// This does **not** include the WTF-8 concatenation check. fn push_code_point_unchecked(&mut self, code_point: CodePoint) { <del> let c = unsafe { char::from_u32_unchecked(code_point.value) }; </del> let mut bytes = [0; 4]; <del> let bytes = c.encode_utf8(&mut bytes).as_bytes(); </del> <ins> let bytes = char::encode_utf8_raw(code_point.value, &mut bytes); </ins> self.bytes.extend_from_slice(bytes) }

The type contains a (generalized-UTF-8-encoded) sequence of code point (including potentially surrogates) that doesn’t form a surrogate pair. doesn’t check for surrogate pairs. is a public method that is documented as returning a scalar value, therefore excluding all surrogates. Ok I looked into it, there are three different people involved. The original code in 2014 was YOLO Later in 2014, moved to duplicating logic instead. In 2015, PR which first imported WTF-8 support in libstd deduplicated that logic by adding a function that takes . (I knew that approach sounded familiar…) In 2016, PR changed the signature of and in passing removed . It made use + instead, presumably in the middle of updating many callers other.
Okay, so the fix would be to revert the part of that removed ?
That or copy into . I find them both not great, so meh.
Even with that done, there's still UB in another testcase: This is converting something to a before calling -- so probably the same issue as the above, just for a different encoding.


Question: #![feature(iter_is_partitioned)] #![feature(iter_order_by)] #![feature(cmp_min_max_by)] <del> #![feature(slice_from_raw_parts)] </del> #![feature(const_slice_from_raw_parts)] #![feature(const_raw_ptr_deref)]

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


Question: _ => unreachable!(), }; <del> color | (bits & 0x8) // copy the hi-intensity bit </del> <ins> color | (u32::from(bits) & 0x8) // copy the hi-intensity bit </ins> } impl<T: Write + Send + 'static> WinConsole<T> {

does not emit color output when running under a tmux session with set correctly to (supported by the latest versions of ncurses) even with when is set to . On the machine in question (macOS) the term file for is installed and returns the following: Per cargo should be invoking rustc with the flag, and indeed, returns 'Option color given more than once. Executing also does not produce color output, but does.
I have a similar bug on Archlinux. I used to get colored output on this system, but that recently stopped working for rustc. (Cargo is still fine for me.) If I add in and run in , I get Result::unwrap()Err/lib/terminfo/x/xterm-256colorncursesNEWS file does mention a new (incompatible) file format with a different magic number: Could rustc switch to whatever Cargo uses for colored terminal output?
A work-around for my machine was temporarily downgrading the packages, and copying the old file to .
Yes rustc should be able to switch at any time
Thanks for the workaround!
Changing from to also seems to work as a temporary workaround. (note: this may affect other terminal applications)
Another work-around if you're using sh: This sets to a possibly incorrect value, but limits its impact to only the output of a command.
That worked for me as well. I had no colour with . I downgraded to , which was what I had in , and now I have colour again.
I have a similar issue: In my regular terminal emulator (not tmux), there are no colors from rustc (as executed with ), colors from cargo itself are working fine. The default setting for there is: . The problem is fixed by setting to . Inside tmux however, colors work just fine, there seems to be by default.
Colors are fixed in the latest nightly (thanks to o/)
This is fixed for me in today’s nigthly, presumably by
With the current nightly I still have no colors with and have to use as a work around. What might still be broken?
Terminal colors are still broken with . however, does use colors, so there's clearly still a discrepancy between how and use termcolor
It works fine for me with ncurses 6.1, even rustup has colors again since the last version .


Question: _ => unreachable!(), }; <del> color | (bits & 0x8) // copy the hi-intensity bit </del> <ins> color | (u32::from(bits) & 0x8) // copy the hi-intensity bit </ins> } impl<T: Write + Send + 'static> WinConsole<T> {

I’d like to note though that things like destroy this for some reason (even if is set). It took me some time to figure that out
I'm using ncurses 6.1 on Fedora 28 and everything appears to be working fine except for test colors. In mentioned that a bit tricky due to how the build works, but we can always tackle that later. What is the barrier to migrating libtest from to ? For now, it's leaving my test output looking like this. !
I have an in-progress patch for libtest but I ran into I'm guessing that's the build issue that is referring to. I don't know how linking libtest works, but I'm happy to try to fix the build if someone can point me in the right direction.


Question: --> $DIR/auxiliary/dummy_lib.rs:2:1 | 2   + #[derive(Debug)] <del> 3   | #[path = "auxiliary/dummy_lib.rs"] </del> <ins> 3   | pub struct Dummy; </ins> | error: aborting due to previous error

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I have the following code, split into two files: This code, as expected, produces , shown below. However, the help message at the bottom of the error appears to be referencing line 2 in , while displaying the filename , thus suggesting we add the annotation to a comment in . It should instead point to the in . <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
The issue is that in , the span we use to look up the file/line mapper is the primary span of the message, i.e. the error in


Question: fn build_sidebar_items(&self, m: &clean::Module) -> BTreeMap<String, Vec<NameDoc>> { // BTreeMap instead of HashMap to get a sorted output let mut map: BTreeMap<_, Vec<_>> = BTreeMap::new(); <ins> let mut inserted: FxHashMap<ItemType, FxHashSet<Symbol>> = FxHashMap::default(); </ins> for item in &m.items { if item.is_stripped() { continue;

Hey! Ran into what appears to be a bug - crate's exported macros each appear twice in the left sidebar: ! Toolchain versions (per log): rustc 1.60.0-nightly ( 2022-02-09), docsrs 0.6.0 ( 2022-02-01) Please let me know if I can provide additional info.
Thank you for the report! This is definitely not an issue with itself, but with rustdoc. is this known? Should a rustdoc issue be created?
Not known afaik. Please do file an issue (or transfer this one)!
Seems similar to
Thanks for transferring the issue. One difference between this and - both macros are exported using a wildcard in crate root (not rename):
Well, just another reexport issue. It's common around here. :laughing: I'll try to take a look in the next days.
This is what I have on currently nightly: ! So I guess it's fixed?
Trying locally with the latest nightly (, more current than that of issue open) I get the same initial landing page for but if I click on one of the macros listed (e.g. "drill down") duplicates still appear on the sidebar: ! So the tiny bug is still there, just deeper/hidden on the latest nightly?
Ah indeed! I can also reproduce it now. Will take another look tomorrow then.


Question: self.diverge_cleanup(); let scope = self.scopes.pop().unwrap(); assert_eq!(scope.extent, extent); <del> build_scope_drops(block, &scope, &self.scopes[..], &mut self.cfg) </del> <ins> build_scope_drops(&mut self.cfg, &scope, &self.scopes[..], block) </ins> }

This generates the following (broken) MIR: As you can see, is dropped but never written to (AFAIK this should be OK because of zeroing) but the boxes are never freed.
cc
EDIT: I wasn’t looking closely enough, it is indeed broken.
This is a problem on latest master ()


Question: COPY host-x86_64/dist-various-2/build-fuchsia-toolchain.sh /tmp/ RUN /tmp/build-fuchsia-toolchain.sh COPY host-x86_64/dist-various-2/build-solaris-toolchain.sh /tmp/ <del> RUN /tmp/build-solaris-toolchain.sh x86_64  amd64   solaris-i386 RUN /tmp/build-solaris-toolchain.sh sparcv9 sparcv9 solaris-sparc </del> <ins> RUN /tmp/build-solaris-toolchain.sh x86_64  amd64   solaris-i386  pc # Build deprecated target 'x86_64-sun-solaris2.10' until removed RUN /tmp/build-solaris-toolchain.sh x86_64  amd64   solaris-i386  sun RUN /tmp/build-solaris-toolchain.sh sparcv9 sparcv9 solaris-sparc sun </ins> COPY host-x86_64/dist-various-2/build-x86_64-fortanix-unknown-sgx-toolchain.sh /tmp/ RUN /tmp/build-x86_64-fortanix-unknown-sgx-toolchain.sh

removed the alias of to , but as far as I can tell did not remove the target itself. After inquiring on Zulip, it was pointed out that the target was demoted to tier three, meaning builds are no longer provided. It appears this was done with no discussion, warning, or even a mention in the release notes. Given that the target hasn't been around for that long (I think? feel free to tell me I'm wrong), I think this change should be reverted. My CI unexpectedly failed after being unable to download the target, and the only solution that wouldn't involve a notable increase in complexity of the CI script is to outright remove the checks for Solaris/Illumos — a let loss for everyone. cc
I think my feeling right now is that we should likely re-enable the sun-solaris target alongside the pc-solaris, I don't think that should be a major problem for CI times or similar. I will see if we can do this in time for 1.52.1, but if it ends up being harder than expected, I think it's likely that either a) we'll push it out to a 1.52.2 release later in the cycle, or simply leave it to 1.53. For the time being, tagging as 1.53.
I will note that the change itself is fine, of course, it's the suddenness and unexpectedness of it that caught me by surprise.
I think it is likely true that we'll eventually drop the sun target, but it does seem like we should communicate that change better at least. Certainly the newly merged target tier policy suggests just that:
It is not clear to me what the impact of was. In particular, the produced target was not changed in , but I guess the target definition is sort of for pc... I think I am not sufficiently confident in moving in a particular direction here - and a full revert does not seem quite right either - so I will likely say this should be left for at least 1.52.2 or 1.53.0. cc as well, who reviewed
Removal of the older target was certainly not my intent; if that happened due to , I am sorry. Both and are there and both targets are usable when compiling with , but I guess that change to one of files might have resulted in artifacts necessary for no longer being available.


Question: COPY host-x86_64/dist-various-2/build-fuchsia-toolchain.sh /tmp/ RUN /tmp/build-fuchsia-toolchain.sh COPY host-x86_64/dist-various-2/build-solaris-toolchain.sh /tmp/ <del> RUN /tmp/build-solaris-toolchain.sh x86_64  amd64   solaris-i386 RUN /tmp/build-solaris-toolchain.sh sparcv9 sparcv9 solaris-sparc </del> <ins> RUN /tmp/build-solaris-toolchain.sh x86_64  amd64   solaris-i386  pc # Build deprecated target 'x86_64-sun-solaris2.10' until removed RUN /tmp/build-solaris-toolchain.sh x86_64  amd64   solaris-i386  sun RUN /tmp/build-solaris-toolchain.sh sparcv9 sparcv9 solaris-sparc sun </ins> COPY host-x86_64/dist-various-2/build-x86_64-fortanix-unknown-sgx-toolchain.sh /tmp/ RUN /tmp/build-x86_64-fortanix-unknown-sgx-toolchain.sh

I created , which I believe should bring back the ability to the old target.
Reopening to track the illumos target work. I'm not sure it's a release blocker, but would like to not lose sight.
The remaining bug in this issue -- the change in the compiler used to build illumos to be based on a -pc- triple, not -sun- here is not a release blocker.
Realistically I don't think there's anything actionable here, so I'm going to go ahead and close this.


Question: } } <del> fn frame_address(f: &fn(++x: *u8)) { </del> <ins> fn frame_address(f: &fn(x: *u8)) { </ins> unsafe { rusti::frame_address(f) }

This function still takes its argument by explicit .
also,
I'm doing this, just waiting for tests.
Done, pending
Fixed in


Question: fn check_bounds_on_type_parameters(cx: &mut Context, e: &Expr) { let method_map = cx.tcx.method_map.borrow(); <del> let method = method_map.find(&typeck::MethodCall::expr(e.id)); </del> <ins> let method_call = typeck::MethodCall::expr(e.id); let method = method_map.find(&method_call); </ins> // Find the values that were provided (if any) let item_substs = cx.tcx.item_substs.borrow();

Example: This should be fixed by code in .
Nominating for 1.0, P-backcompat-lang.
Assigning 1.0, P-backcompat-lang


Question: assert!(first.maybe_empty); first.add_all(subfirst); <del> if subfirst.maybe_empty || seq_rep.op == quoted::KleeneOp::ZeroOrMore { </del> <ins> if subfirst.maybe_empty || seq_rep.op == quoted::KleeneOp::ZeroOrMore || seq_rep.op == quoted::KleeneOp::ZeroOrOne { </ins> // continue scanning for more first // tokens, but also make sure we // restore empty-tracking state

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


Question: } } <del> macro_rules! range_impl { </del> <ins> macro_rules! range_exact_iter_impl { </ins> ($($t:ty)*) => ($( #[stable(feature = "rust1", since = "1.0.0")] <del> impl Iterator for ::ops::Range<$t> { type Item = $t; </del> <ins> impl ExactSizeIterator for ::ops::Range<$t> { </ins> #[inline] <del> fn next(&mut self) -> Option<$t> { if self.start < self.end { let result = self.start; self.start += 1; return Some(result); } return None; } #[inline] fn size_hint(&self) -> (usize, Option<usize>) { </del> <ins> fn len(&self) -> usize { </ins> debug_assert!(self.end >= self.start); <del> let hint = (self.end - self.start) as usize; (hint, Some(hint)) </del> <ins> (self.end - self.start) as usize </ins> } } <del> #[stable(feature = "rust1", since = "1.0.0")] impl ExactSizeIterator for ::ops::Range<$t> {} </del> )*) } <del> macro_rules! range_impl_no_hint { ($($t:ty)*) => ($( #[stable(feature = "rust1", since = "1.0.0")] impl Iterator for ::ops::Range<$t> { type Item = $t; #[inline] fn next(&mut self) -> Option<$t> { if self.start < self.end { let result = self.start; self.start += 1; return Some(result); } </del> <ins> #[stable(feature = "rust1", since = "1.0.0")] impl<A: Int> Iterator for ::ops::Range<A> { type Item = A; </ins> <del> return None; } </del> <ins> #[inline] fn next(&mut self) -> Option<A> { if self.start < self.end { let result = self.start; self.start = self.start + Int::one(); Some(result) } else { None </ins> } <del> )*) } macro_rules! range_other_impls { ($($t:ty)*) => ($( #[stable(feature = "rust1", since = "1.0.0")] impl DoubleEndedIterator for ::ops::Range<$t> { #[inline] fn next_back(&mut self) -> Option<$t> { if self.start < self.end { self.end -= 1; return Some(self.end); } </del> <ins> } </ins> <del> return None; } } </del> <ins> #[inline] fn size_hint(&self) -> (usize, Option<usize>) { debug_assert!(self.end >= self.start); let hint = (self.end - self.start).to_uint(); (hint.unwrap_or(0), hint) } } </ins> <del> #[stable(feature = "rust1", since = "1.0.0")] impl Iterator for ::ops::RangeFrom<$t> { type Item = $t; </del> <ins> range_exact_iter_impl!(usize u8 u16 u32 isize i8 i16 i32); #[cfg(target_pointer_width = "64")] range_exact_iter_impl!(u64 i64); </ins> <del> #[inline] fn next(&mut self) -> Option<$t> { let result = self.start; self.start += 1; debug_assert!(result < self.start); return Some(result); } </del> <ins> #[stable(feature = "rust1", since = "1.0.0")] impl<A: Int> DoubleEndedIterator for ::ops::Range<A> { #[inline] fn next_back(&mut self) -> Option<A> { if self.start < self.end { self.end = self.end - Int::one(); Some(self.end) } else { None </ins> } <del> )*) </del> <ins> } </ins> } <del> range_impl!(usize u8 u16 u32 isize i8 i16 i32); #[cfg(target_pointer_width = "64")] range_impl!(u64 i64); #[cfg(target_pointer_width = "32")] range_impl_no_hint!(u64 i64); </del> <ins> #[stable(feature = "rust1", since = "1.0.0")] impl<A: Int> Iterator for ::ops::RangeFrom<A> { type Item = A; </ins> <del> range_other_impls!(usize u8 u16 u32 u64 isize i8 i16 i32 i64); </del> <ins> #[inline] fn next(&mut self) -> Option<A> { let result = self.start; self.start = self.start + Int::one(); debug_assert!(result < self.start); Some(result) } } </ins> /// An iterator that repeats an element endlessly #[derive(Clone)]

cc
I think you have a PR that improves type inference in some cases where closures are involved (?), do you know if by chance that fixes this as well?
This is not closure specific:
This must be duo to . It seems to enforce the numeric fallback rule a bit too eagerly.
Another example from IRC is that type checked while didn't. Rather interesting.
edwardw, not just that, type inference regressed slightly at the time of the range stabilization PR.
also related
Have a partial fix by deferring numeric fallback, but it seems to hit now.
OK, so I spent some time digging into this. I don't think that deferring numeric fallback is necessarily the solution. sorry if I kept disappearing on IRC, I had to put my head down and study the log to see what was happening. So what seems to happen is that we correctly come up with the constraint: However, we are unable to make the connection between and . The reason is that the new has separate impls for each of the numeric types, whereas the old had only impl for a type . When we process the projections, we first try to resolve (without considering the output type ), and we get ambiguity, because there are many impls that could apply. Unfortunately this all seems a bit right to me. Basically we're trying to infer the type of the range from the output type, which is the reverse direction inference is supposed to go. When we used a blanket impl, we were able to resolve this because there was only one impl for . Probably the best fix is to go back to that, actually, but this is an interesting quandry. I'll have to think about it a bit.
To be clear, the example I was digging into was
Also, to put it another way: having a single blanket impl allows us to draw the connection that when you iterate over , you get . With the current setup of many distinct impls, that is not known to be true.
After some discussion with on RFC, I just wanted to clarify a few things (I myself was a touch confused too). the impl is probably the easiest way to fix this in the short term. , to some extent, this limitation is an artifact of how trait matching is implemented. That is, we intentionally do not take output bindings into account when selecting traits.


Question: } } <del> macro_rules! range_impl { </del> <ins> macro_rules! range_exact_iter_impl { </ins> ($($t:ty)*) => ($( #[stable(feature = "rust1", since = "1.0.0")] <del> impl Iterator for ::ops::Range<$t> { type Item = $t; </del> <ins> impl ExactSizeIterator for ::ops::Range<$t> { </ins> #[inline] <del> fn next(&mut self) -> Option<$t> { if self.start < self.end { let result = self.start; self.start += 1; return Some(result); } return None; } #[inline] fn size_hint(&self) -> (usize, Option<usize>) { </del> <ins> fn len(&self) -> usize { </ins> debug_assert!(self.end >= self.start); <del> let hint = (self.end - self.start) as usize; (hint, Some(hint)) </del> <ins> (self.end - self.start) as usize </ins> } } <del> #[stable(feature = "rust1", since = "1.0.0")] impl ExactSizeIterator for ::ops::Range<$t> {} </del> )*) } <del> macro_rules! range_impl_no_hint { ($($t:ty)*) => ($( #[stable(feature = "rust1", since = "1.0.0")] impl Iterator for ::ops::Range<$t> { type Item = $t; #[inline] fn next(&mut self) -> Option<$t> { if self.start < self.end { let result = self.start; self.start += 1; return Some(result); } </del> <ins> #[stable(feature = "rust1", since = "1.0.0")] impl<A: Int> Iterator for ::ops::Range<A> { type Item = A; </ins> <del> return None; } </del> <ins> #[inline] fn next(&mut self) -> Option<A> { if self.start < self.end { let result = self.start; self.start = self.start + Int::one(); Some(result) } else { None </ins> } <del> )*) } macro_rules! range_other_impls { ($($t:ty)*) => ($( #[stable(feature = "rust1", since = "1.0.0")] impl DoubleEndedIterator for ::ops::Range<$t> { #[inline] fn next_back(&mut self) -> Option<$t> { if self.start < self.end { self.end -= 1; return Some(self.end); } </del> <ins> } </ins> <del> return None; } } </del> <ins> #[inline] fn size_hint(&self) -> (usize, Option<usize>) { debug_assert!(self.end >= self.start); let hint = (self.end - self.start).to_uint(); (hint.unwrap_or(0), hint) } } </ins> <del> #[stable(feature = "rust1", since = "1.0.0")] impl Iterator for ::ops::RangeFrom<$t> { type Item = $t; </del> <ins> range_exact_iter_impl!(usize u8 u16 u32 isize i8 i16 i32); #[cfg(target_pointer_width = "64")] range_exact_iter_impl!(u64 i64); </ins> <del> #[inline] fn next(&mut self) -> Option<$t> { let result = self.start; self.start += 1; debug_assert!(result < self.start); return Some(result); } </del> <ins> #[stable(feature = "rust1", since = "1.0.0")] impl<A: Int> DoubleEndedIterator for ::ops::Range<A> { #[inline] fn next_back(&mut self) -> Option<A> { if self.start < self.end { self.end = self.end - Int::one(); Some(self.end) } else { None </ins> } <del> )*) </del> <ins> } </ins> } <del> range_impl!(usize u8 u16 u32 isize i8 i16 i32); #[cfg(target_pointer_width = "64")] range_impl!(u64 i64); #[cfg(target_pointer_width = "32")] range_impl_no_hint!(u64 i64); </del> <ins> #[stable(feature = "rust1", since = "1.0.0")] impl<A: Int> Iterator for ::ops::RangeFrom<A> { type Item = A; </ins> <del> range_other_impls!(usize u8 u16 u32 u64 isize i8 i16 i32 i64); </del> <ins> #[inline] fn next(&mut self) -> Option<A> { let result = self.start; self.start = self.start + Int::one(); debug_assert!(result < self.start); Some(result) } } </ins> /// An iterator that repeats an element endlessly #[derive(Clone)]

However, it doesn't have to be this way, but it'd take some work to massage the trait matching infrastructure, since impl selection doesn't presently have access to output binding information, that'd have to be propagated inward. It might be interesting to try and address this in a more wholistic way (i.e., something that accounts for the full set of facts that are registered). particular, the important constraint that we MUST maintain is that, during trans, given the input types, we can derive the output type. But it's permissible for us to use the output type to derive the input type during type checking, since once inference is done, we then have the input types to supply during trans so that we can rederive the output.
The fix is very simple then. Thanks for helping diagnose the problem and pointing to the right direction.


Question: } } <del> macro_rules! range_impl { </del> <ins> macro_rules! range_exact_iter_impl { </ins> ($($t:ty)*) => ($( #[stable(feature = "rust1", since = "1.0.0")] <del> impl Iterator for ::ops::Range<$t> { type Item = $t; </del> <ins> impl ExactSizeIterator for ::ops::Range<$t> { </ins> #[inline] <del> fn next(&mut self) -> Option<$t> { if self.start < self.end { let result = self.start; self.start += 1; return Some(result); } return None; } #[inline] fn size_hint(&self) -> (usize, Option<usize>) { </del> <ins> fn len(&self) -> usize { </ins> debug_assert!(self.end >= self.start); <del> let hint = (self.end - self.start) as usize; (hint, Some(hint)) </del> <ins> (self.end - self.start) as usize </ins> } } <del> #[stable(feature = "rust1", since = "1.0.0")] impl ExactSizeIterator for ::ops::Range<$t> {} </del> )*) } <del> macro_rules! range_impl_no_hint { ($($t:ty)*) => ($( #[stable(feature = "rust1", since = "1.0.0")] impl Iterator for ::ops::Range<$t> { type Item = $t; #[inline] fn next(&mut self) -> Option<$t> { if self.start < self.end { let result = self.start; self.start += 1; return Some(result); } </del> <ins> #[stable(feature = "rust1", since = "1.0.0")] impl<A: Int> Iterator for ::ops::Range<A> { type Item = A; </ins> <del> return None; } </del> <ins> #[inline] fn next(&mut self) -> Option<A> { if self.start < self.end { let result = self.start; self.start = self.start + Int::one(); Some(result) } else { None </ins> } <del> )*) } macro_rules! range_other_impls { ($($t:ty)*) => ($( #[stable(feature = "rust1", since = "1.0.0")] impl DoubleEndedIterator for ::ops::Range<$t> { #[inline] fn next_back(&mut self) -> Option<$t> { if self.start < self.end { self.end -= 1; return Some(self.end); } </del> <ins> } </ins> <del> return None; } } </del> <ins> #[inline] fn size_hint(&self) -> (usize, Option<usize>) { debug_assert!(self.end >= self.start); let hint = (self.end - self.start).to_uint(); (hint.unwrap_or(0), hint) } } </ins> <del> #[stable(feature = "rust1", since = "1.0.0")] impl Iterator for ::ops::RangeFrom<$t> { type Item = $t; </del> <ins> range_exact_iter_impl!(usize u8 u16 u32 isize i8 i16 i32); #[cfg(target_pointer_width = "64")] range_exact_iter_impl!(u64 i64); </ins> <del> #[inline] fn next(&mut self) -> Option<$t> { let result = self.start; self.start += 1; debug_assert!(result < self.start); return Some(result); } </del> <ins> #[stable(feature = "rust1", since = "1.0.0")] impl<A: Int> DoubleEndedIterator for ::ops::Range<A> { #[inline] fn next_back(&mut self) -> Option<A> { if self.start < self.end { self.end = self.end - Int::one(); Some(self.end) } else { None </ins> } <del> )*) </del> <ins> } </ins> } <del> range_impl!(usize u8 u16 u32 isize i8 i16 i32); #[cfg(target_pointer_width = "64")] range_impl!(u64 i64); #[cfg(target_pointer_width = "32")] range_impl_no_hint!(u64 i64); </del> <ins> #[stable(feature = "rust1", since = "1.0.0")] impl<A: Int> Iterator for ::ops::RangeFrom<A> { type Item = A; </ins> <del> range_other_impls!(usize u8 u16 u32 u64 isize i8 i16 i32 i64); </del> <ins> #[inline] fn next(&mut self) -> Option<A> { let result = self.start; self.start = self.start + Int::one(); debug_assert!(result < self.start); Some(result) } } </ins> /// An iterator that repeats an element endlessly #[derive(Clone)]

This code compiled fine before 1.0.0-nightly ( 2015-01-23 16:08:14 +0000): But with that version, it now gives this error:
changing to should work, I stumbled upon the same thing and the doc seems to be updated: (see at the very bottom) EDIT: Maybe worth noting that these work:
That's just a workaround to a bug (not sure if that was implied). should fall back to being as per the existence of the integer fallback.
I don't necessarily expect this to work. Fallback comes late in the process, once all constraints are known, but (like method dispatch) requires the type being cast to be known immediately.
It's plausible we could make it work since we know that the type is integral (I imagine that's how it ever worked, not sure what would have changed that, though it might have been something I did). It occurs to me though that this is somewhat forward-hostile to the idea of integer literals ever being used for anything other than plain ints (but enabling such a feature may well wind up requiring opt-in anyway).
(Though really it's sort of silly that requires the type to be known immediately, so I guess fixing that would be another way to ease the forward compat fears.)
I thought this was a feature because it's saying that it doesn't know if it's or for example. Would it assume it's signed only if it contains negative numbers in the range? EDIT3: what said makes sense: EDIT2: ignore the following, my bad But I might be missing something because this doesn't output anything from : EDIT: just realized -1u32 is too big so the following makes sense: There's no output from , unless using


Question: <ins> pub trait Bar<S> {} pub trait Qux<T> {} pub trait Foo<T, S> { fn bar() where T: Bar<S>, { } } pub struct Concrete; impl<S> Foo<(), S> for Concrete {} impl<T, S> Bar<S> for T where S: Qux<T> {} impl<T, S> Qux<T> for S where T: Bar<S> {} </ins>

<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see this happen: Rustdoc compiles the documentation as for older toolchains (stable, < nightly-2022-08-10) or as it is happening for / Instead, this happened: Rustdoc reports an compiler error <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: nightly-2022-08-09 : : points to as merge that introduced this regression which is a roll-up PR. and are included there and seems to be rustdoc releated. Pinging and as authors of these PR's. <!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-nightly -regression-untriaged --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think the bug is coming from cc EDIT: also, would be quite useful to have a minimum code that we can use as a regression test.
Reducing compiler errors coming from diesel is quite hard and takes a lot of time. Diesel is already part of the rust compiler tests-suite, although in an older version. So it might be easier to just update this version to a current diesel version.
This is due to my PR. claim
is not documented inside the compiler so it wouldn't be very helpful unfortunately. Also, I didn't ask you specifically, just thought it might be useful to say it, so don't worry if you don't have time for it. :wink: Thanks !
The corresponding test code is here: I think it did not catch this issue as it uses an older diesel version (and it does not enable the corresponding feature flag).
I minimized this: And fix PR incoming.
This apparently was not fixed.
I can confirm that this is fixed for . Thank you all for the fast fix :tada:


Question: <ins> // revisions: current next //[next] compile-flags: -Znext-solver // check-pass #![feature(non_lifetime_binders)] //~^ WARN the feature `non_lifetime_binders` is incomplete trait Id { type Output: ?Sized; } impl<T: ?Sized> Id for T { type Output = T; } trait Everyone {} impl<T: ?Sized> Everyone for T {} fn hello() where for<T> <T as Id>::Output: Everyone {} fn main() { hello(); } </ins>

<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --minimal project with full compiler output can be found here cargo 1.77.0-nightly ( 2024-01-09) : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details


Question: let associated_trait = tcx.impl_trait_ref(did).map(ty::EarlyBinder::skip_binder); <ins> // Do not inline compiler-internal items unless we're a compiler-internal crate. let is_compiler_internal = |did| { tcx.lookup_stability(did) .is_some_and(|stab| stab.is_unstable() && stab.feature == sym::rustc_private) }; let document_compiler_internal = is_compiler_internal(LOCAL_CRATE.as_def_id()); let is_directly_public = |cx: &mut DocContext<'_>, did| { cx.cache.effective_visibilities.is_directly_public(tcx, did) && (document_compiler_internal || !is_compiler_internal(did)) }; </ins> // Only inline impl if the implemented trait is // reachable in rustdoc generated documentation if !did.is_local() && let Some(traitref) = associated_trait <ins> && !is_directly_public(cx, traitref.def_id) </ins> { <del> let did = traitref.def_id; if !cx.cache.effective_visibilities.is_directly_public(tcx, did) { return; } if !tcx.features().rustc_private && !cx.render_options.force_unstable_if_unmarked { if let Some(stab) = tcx.lookup_stability(did) && stab.is_unstable() && stab.feature == sym::rustc_private { return; } } </del> <ins> return; </ins> } let impl_item = match did.as_local() {

for example lists implementations of in , which aren't visible anyway and the links are also broken.
Not present in the docs for 1.77.2, regression?
cc getting multiple reports of this:
I believe this regressed in (
This was closed but it's still happening on current stable docs, in various traits, Debug being the one that seems the worst: ! !
What page are you looking at? I do not see those implementations on
stable docs, not nightly I understand this was reported the day 1.78.0 was released and 1.79.0 isn't due for a few weeks more, but I feel it should be possible to apply the fix to the current stable docs at least as published on rust- in the meantime
The stable docs are tied to the release, so we would have to make a new release to update them. The fix for this is in 1.80, and will reach stable on July 25.
There's no way to backport it internally? That's unfortunate. I was hoping it would land for 1.79.0 at least
Closing then.
This can in fact be beta backported.
And it was in
Good to know, thank you


Question: <ins> // Regression test for issue #110856, where a borrowck error for a MIR tainted // all promoteds within. This in turn generated a spurious "erroneous constant // used" note when trying to evaluate a promoted. pub fn f() -> u32 { let a = 0; a = &0 * &1 * &2 * &3; //~^ ERROR: cannot assign twice to immutable variable a } fn main() {} </ins>

I tried : I expected to see this happen: an error about not being able to move out of a slice Instead, this happened: the error and a bunch of Fails on , works fine on
It also applies to way simpler code like:
searched nightlies: from nightly-2023-04-01 to nightly-2023-04-26 regressed nightly: nightly-2023-04-22 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </detailsHost triple: x8664-unknown-linux-gnu Reproduce with: </details Intestingly, the same day also contained two PRs but I have bisected this twice (with manual promt) and const prop lint really does seem to be the cause: commit[0] 2023-04-20: Auto merge of - m-ou-se:fmt-lang-items, r=jyn514 commit[1] 2023-04-20: Auto merge of - m-ou-se:flatten-format-args, r=oli-obk
WG-prioritization assigning priority (). label -I-prioritize +P-medium


Question: <ins> // build-pass // // (this is deliberately *not* check-pass; I have confirmed that the bug in // question does not replicate when one uses `cargo check` alone.) pub enum Void {} enum UninhabitedUnivariant { _Variant(Void), } enum UninhabitedMultivariant2 { _Variant(Void), _Warriont(Void), } enum UninhabitedMultivariant3 { _Variant(Void), _Warriont(Void), _Worrynot(Void), } #[repr(C)] enum UninhabitedUnivariantC { _Variant(Void), } #[repr(i32)] enum UninhabitedUnivariant32 { _Variant(Void), } fn main() { let _seed: UninhabitedUnivariant = None.unwrap(); match _seed { UninhabitedUnivariant::_Variant(_x) => {} } let _seed: UninhabitedMultivariant2 = None.unwrap(); match _seed { UninhabitedMultivariant2::_Variant(_x) => {} UninhabitedMultivariant2::_Warriont(_x) => {} } let _seed: UninhabitedMultivariant2 = None.unwrap(); match _seed { UninhabitedMultivariant2::_Variant(_x) => {} _ => {} } let _seed: UninhabitedMultivariant2 = None.unwrap(); match _seed { UninhabitedMultivariant2::_Warriont(_x) => {} _ => {} } let _seed: UninhabitedMultivariant3 = None.unwrap(); match _seed { UninhabitedMultivariant3::_Variant(_x) => {} UninhabitedMultivariant3::_Warriont(_x) => {} UninhabitedMultivariant3::_Worrynot(_x) => {} } let _seed: UninhabitedMultivariant3 = None.unwrap(); match _seed { UninhabitedMultivariant3::_Variant(_x) => {} _ => {} } let _seed: UninhabitedMultivariant3 = None.unwrap(); match _seed { UninhabitedMultivariant3::_Warriont(_x) => {} _ => {} } let _seed: UninhabitedMultivariant3 = None.unwrap(); match _seed { UninhabitedMultivariant3::_Worrynot(_x) => {} _ => {} } let _seed: UninhabitedUnivariantC = None.unwrap(); match _seed { UninhabitedUnivariantC::_Variant(_x) => {} } let _seed: UninhabitedUnivariant32 = None.unwrap(); match _seed { UninhabitedUnivariant32::_Variant(_x) => {} } } </ins>

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


Question: [[package]] name = "rustfmt-nightly" <del> version = "0.1.9" </del> <ins> version = "0.2.1" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "diff 0.1.10 (registry+https://github.com/rust-lang/crates.io-index)",

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


Question: all(target_vendor = "fortanix", target_env = "sgx"), feature(slice_index_methods, coerce_unsized, sgx_platform) )] <ins> #![cfg_attr(windows, feature(round_char_boundary))] </ins> // // Language features: #![feature(alloc_error_handler)]

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


Question: all(target_vendor = "fortanix", target_env = "sgx"), feature(slice_index_methods, coerce_unsized, sgx_platform) )] <ins> #![cfg_attr(windows, feature(round_char_boundary))] </ins> // // Language features: #![feature(alloc_error_handler)]

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


Question: <ins> #[no_mangle] pub extern "C" fn hello() { println!("Hello world!"); } #[no_mangle] pub extern "C" fn number() -> u32 { 42 } </ins>

<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried to build using a simple then . I expected to see this happen: linking success. Instead, this happened: MSVC link returns LNK2005 and fails to the static library. It most recently worked on: 1.77.2 <!-- Provide the version you are using that has the regression. --: This is caused by both and When creating stdlibs, each MR causes the Rust compiler to add an export of ; one comes from api-ms-win-core-synch-l1-2-0.dll and the other from This error will not be found until one consumes the Rust-generated library. I am filing this report to consolidate the ones in and <!-- Did the compiler crash? If so, please provide a backtrace. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details modify labels: +regression-from-stable-to-stable -regression-untriaged
cc
Using for a rust staticlib seems weird to me but cc
The purpose is to allow reexporting a subset of symbols on MSVC. This can be achieved with partial linking elsewhere, but this is not doable on Windows. I wrote about a specific application here:
Sorry, I'm confused, are you trying to create a dynamic or static library? The article that you linked to talks about static libraries, but the backtrace in the OP shows that you are creating a dynamic library.
Both: I'm using the Rust-produced static library through , plus a module definition file, to create a dynamic library. This is because (apart from size considerations) GNOME's gobject-introspection needs a shared library, and Meson will only accept targets that are generated by itself. Further context is here:
In this particular case, because of the imports present in the stdlib, linking something against the Rust-produced static librsvg is enough to trigger the issue.
I am still struggling to understand why is needed, at least for MSVC.


Question: <ins> #[no_mangle] pub extern "C" fn hello() { println!("Hello world!"); } #[no_mangle] pub extern "C" fn number() -> u32 { 42 } </ins>

So the DLL is created here: is used so that the DLL includes every single object in the staticlib, even if it's unneeded or indeed causes conflicts. But then is used to add a which presumably defines what actually gets exported from the DLL. What I'm not understanding is what would be different if, for MSVC, it just linked normally without ? I.e. using instead.
On MSVC, static linking doesn't let you reexport dependencies' symbols automatically, they're subject to DCE. . However, PE-COFF static libraries don't support symbol visibility, so the is there to make all Rust symbols private and keep only the librsvg ones. See e.g. and for consequences of not blocking out symbols like .
Sure but the should work regardless of if is used or not because using the export will force the linker to go looking for the symbol(s) listed in the file. E.g. as a test I have the following static lib (using to make symbols easier to find): Which I compile into a static lib using: rustc -O --crate-type=staticlib And I have the following file: Which for simplicity I compile via rustc but I'm using an empty file and also raw linker arguments: rustc -O --crate-type=cdylib -C link-args=" " This compiles and if I see the two functions I wanted: No std symbols are exported.
Independent of whether whole-archive is necessary for this specific use case, we should support linking rust staticlibs with whole-archive, even if because of the fact that not linking with whole-archive can mask linker errors, which will later show up when any change to the cgu partitioning is made, which often causes people to report a regression even though their crate is at fault.
If I repeat the above using even in this simple case I get a bunch of errors, not just : I'm not really sure if rustc can currently guarantee that whole archive will work without doing some of the work of a linker. Which sounds like a new feature and not specific to MSVC.
All duplicate symbol errors for are caused by That it works without is by accident and likely to break in case of cgu partitioning changes.


Question: <ins> #[no_mangle] pub extern "C" fn hello() { println!("Hello world!"); } #[no_mangle] pub extern "C" fn number() -> u32 { 42 } </ins>

Sure, and then if I compile the static library with and use whole archive then I get a whole slew of errors, which I'll spoiler for length <details<summarylinker errors</summary</details
There are also some technical details in that kleisauke linked. windows-gnu is unaffected because it uses legacy import libraries format.
To get back to address case we could either: Filter symbols when building a staticlib Try using COMDAT in generated raw-dylibs (might not work in this situation)
Filter in what way?
When linking raw dylibs into a staticlib we could exclude the objects containing . Except for one.


Question: // ignore-tidy-linelength // ignore-lldb <del> // ignore-android: FIXME(#10381) </del> <ins> // ignore-android: FIXME(#24958) </ins> // compile-flags:-g

Triggers an LLVM assertion when targeting Android:
Something that works on any host (i.e. you needn’t compile libstd for android to repro):
As the error says, isn't a supported calling convention for the ARM target in LLVM. Not really much we can do from the rustc side unless we want to error early based on cc/target combinations. In any case, it should not crash.
I'm hitting this when I tried to run tests for 1.10.0 on arm64 (aarch64-unknown-linux-gnu). The build succeeds otherwise. I'm just adding and to for the time being.
Neither example crashes today. Closing, since I don't see any good opportunity for a test here (it'd have to be something like and that's probably not worth it). With (original example): Updated example:


Question: "codegen-units"); suite("check-incremental", "src/test/incremental", "incremental", "incremental"); <del> suite("check-ui", "src/test/ui", "ui", "ui"); </del> } if build.config.build.contains("msvc") {

Inlined from Another issue. If a struct has two different custom derives on it and the second one panics, the error span will point to the first one, not the one which panicked. Reproduction Script
was "Reproduction Script" supposed to be a link? I'm spinning this off from as I don't think it's going to block stabilization and/or closing that issue.
Reproduction script there is a summary tag
<details<summaryReproduction Script</summaryIn a crate called In another crate The error will highlight even though panicked. </details
This seems to be fixed now, so this issue can be closed.
I ran this as a test, and got the following output:


Question: candidates.vec.push(FnPointerCandidate); } } <ins> // Provide an impl for suitable functions, rejecting `#[target_feature]` functions (RFC 2396). ty::FnDef(def_id, _) => { if let ty::FnSig { unsafety: hir::Unsafety::Normal, abi: Abi::Rust, c_variadic: false, .. } = self_ty.fn_sig(self.tcx()).skip_binder() { if self.tcx().codegen_fn_attrs(def_id).target_features.is_empty() { candidates.vec.push(FnPointerCandidate); } } } </ins> _ => {} }

(Moved from with an PoC.) The following program () demonstrates how current implementation of allows using a targetfeature from safe code without ensuring it's actually available: This is unsound because it allows executing (e.g.) AVX instructions on CPUs that do not implement them, which is UB. It only works because "safe fns with targetfeatures" are erroneously considered to implement the FnOnce/FnMut/Fn traits.
Proposed resolution: It would probably be better to add the to functions implicitly during lowering to HIR. Implicit is already to functions in blocks in the same way. That would make the unsafety checker the only place (besides AST lowering) where they would be treated specially. Like, "yes, the function is unsafe, but we know that it's safe to call in this specific context, so the unsafe block can be omitted". The special coercion checks would no longer be necessary in that case.
Or perhaps the RFC should be revised to still require writing and only unsafety checker need to be enhanced to allow calling unsafe functions without unsafe blocks in the situations known to be safe. That would be even less magic, which is good, IMO. The ergonomic regression would be minor because would still be not required at call sites.
Good catch. Another option is that referencing, not calling, a target-feature function is unsafe, but I guess that is a bit inconsistent given that this already compiles (): In other words, accessing a safe target feature 1.1 function would be unsafe (unless the target feature is in scope), not just calling it. I think that this is what I would expect somehow, but I would expect it to apply uniformly to both safe and unsafe target feature functions (and that's not an option). The downside of this approach is that we don't know why the function was declared unsafe, not really -- was it only because of the target feature? Or were there additional requirements that would have made it unsafe?
For example, a whole bunch of functions take raw pointers and use them to access memory, so they need to be unsafe even if the respective target feature is enabled in the calling context.
The downside of this approach is that we don't know why the function was declared unsafe, not really -- was it only because of the target feature? Or were there additional requirements that would have made it unsafe? Ah, right, that's a good argument.