Question: // appears to be the most interesting point to report to the // user via an even more ad-hoc guess. categorized_path.sort_by(|p0, p1| p0.category.cmp(&p1.category)); <del> debug!("`: sorted_path={:#?}", categorized_path); </del> <ins> debug!("best_blame_constraint: sorted_path={:#?}", categorized_path); </ins> categorized_path.remove(0) }

<!-- 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. --code from glacier <!-- 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 --
This one also crashes beta and stable release channel.
Huh, why was this not detected earlier if it was tracked in glacier as fixed?
If you add a annotation to the trait bound on , then it no longer ICEs. Here's the code: Output: And if you add the two feature attributes the above messages ask you to enable, it still does not ICE, but correctly errors with "evaluation of constant value failed." Based on some debugging which I , I think this ICE has to do with the lifetime in the bound , although I'm not exactly sure how. I am new to the Rust compiler, and I just chose this issue because it seemed like a good first issue to work on, so I will read the (thanks to for sharing this) and try to further debug this.
If you plan to work on this issue, I recommend claiming it so other people know that and don't start working on it too. You can claim the issue by commenting with . More details about how to use rustbot are . You may also want to read the of the guide.
claim


Question: <ins> // test for trait methods with `doc(hidden)`. #![crate_name = "foo"] // @has foo/trait.Trait.html // @!has - '//*[@id="associatedtype.Foo"]' 'type Foo' // @has - '//*[@id="associatedtype.Bar"]' 'type Bar' // @!has - '//*[@id="tymethod.f"]' 'fn f()' // @has - '//*[@id="tymethod.g"]' 'fn g()' pub trait Trait { #[doc(hidden)] type Foo; type Bar; #[doc(hidden)] fn f(); fn g(); } // @has foo/struct.S.html // @!has - '//*[@id="associatedtype.Foo"]' 'type Foo' // @has - '//*[@id="associatedtype.Bar"]' 'type Bar' // @!has - '//*[@id="method.f"]' 'fn f()' // @has - '//*[@id="method.g"]' 'fn g()' pub struct S; impl Trait for S { type Foo = (); type Bar = (); fn f() {} fn g() {} } </ins>

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: Rustdoc does not show in the documentation for . Instead, this happened: ! Since is properly hidden in the documentation for , the link for is broken. : Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Mentoring instructions: when generating trait impls and is not passed, skip all methods where the method in the original trait was hidden. See for a similar change - the relevant code is in .
claim


Question: <ins> //@ revisions: enable-backchain disable-backchain //@ assembly-output: emit-asm //@ compile-flags: -O --crate-type=lib --target=s390x-unknown-linux-gnu //@ needs-llvm-components: systemz //@[enable-backchain] compile-flags: -Ctarget-feature=+backchain //@[disable-backchain] compile-flags: -Ctarget-feature=-backchain #![feature(no_core, lang_items)] #![no_std] #![no_core] #[lang = "sized"] trait Sized {} extern "C" { fn extern_func(); } // CHECK-LABEL: test_backchain #[no_mangle] extern "C" fn test_backchain() -> i32 { // Here we try to match if backchain register is saved to the parameter area (stored in r15/sp) // And also if a new parameter area (160 bytes) is allocated for the upcoming function call // enable-backchain: lgr [[REG1:.*]], %r15 // enable-backchain-NEXT: aghi %r15, -160 // enable-backchain: stg [[REG1]], 0(%r15) // disable-backchain: aghi %r15, -160 // disable-backchain-NOT: stg %r{{.*}}, 0(%r15) unsafe { extern_func(); } // enable-backchain-NEXT: brasl %r{{.*}}, extern_func@PLT // disable-backchain: brasl %r{{.*}}, extern_func@PLT // Make sure that the expected return value is written into %r2 (return register): // enable-backchain-NEXT: lghi %r2, 1 // disable-backchain: lghi %r2, 0 #[cfg(target_feature = "backchain")] { 1 } #[cfg(not(target_feature = "backchain"))] { 0 } // CHECK: br %r{{.*}} } </ins>

introduced what I think is a logic error: is now always on s390x targets, even if the feature gate is not set. I verified this with Miri, which shares the logic with rustc so it should be a correct test. This should print when built without (as the feature seems off-by-default), but prints instead: Cc
I believe this is intended. is an always-available code-generation option in LLVM disguised as a target feature. Also, enabling for a single function is useless due to how IBM Z's mechanism works.
By "always available" you mean that there is no difference between and ? But then why would one set this feature?
There are differences between the code generated with or without attribute. Still, unlike other processors, this is a platform-specific (potential) unwinding mechanism that does not require additional processor features when you don't have DWARF information or don't want to use it (profilers on IBM Z systems may use it).
The point of is to reflect whether the feature is enabled. It doesn't matter whether it could be enabled or anything like that. For example, is false unless you are building with . It's not about whether static builds are "available" (that's not even a meaningful question), it's about the flags used to build this code. Maybe you are confusing with . Those are not the same thing. If this is not actually a target feature, then it is not clear that we want this to be a target feature in Rust. Though I guess is (unfortunately) precedent here. What happens when I mix code built with and without ? Does anything go wrong?
No, it just means you won't be able to perform unwinding actions based purely on backchain information.
If you want to know how Clang passes attribute in this situation, you can take a look at this Godbolt playground: In this example, is specified (see ), so the compiler needs to generate backchain-enabled code.
Okay, thanks. I don't fully understand the consequences of that -- if this makes Rust panic catching go wrong, that still seems bad -- but :shrug: whatever. The point of the issue is that the behavior of is wrong. Are you still arguing against that or have my examples above been convincing?


Question: <ins> //@ revisions: enable-backchain disable-backchain //@ assembly-output: emit-asm //@ compile-flags: -O --crate-type=lib --target=s390x-unknown-linux-gnu //@ needs-llvm-components: systemz //@[enable-backchain] compile-flags: -Ctarget-feature=+backchain //@[disable-backchain] compile-flags: -Ctarget-feature=-backchain #![feature(no_core, lang_items)] #![no_std] #![no_core] #[lang = "sized"] trait Sized {} extern "C" { fn extern_func(); } // CHECK-LABEL: test_backchain #[no_mangle] extern "C" fn test_backchain() -> i32 { // Here we try to match if backchain register is saved to the parameter area (stored in r15/sp) // And also if a new parameter area (160 bytes) is allocated for the upcoming function call // enable-backchain: lgr [[REG1:.*]], %r15 // enable-backchain-NEXT: aghi %r15, -160 // enable-backchain: stg [[REG1]], 0(%r15) // disable-backchain: aghi %r15, -160 // disable-backchain-NOT: stg %r{{.*}}, 0(%r15) unsafe { extern_func(); } // enable-backchain-NEXT: brasl %r{{.*}}, extern_func@PLT // disable-backchain: brasl %r{{.*}}, extern_func@PLT // Make sure that the expected return value is written into %r2 (return register): // enable-backchain-NEXT: lghi %r2, 1 // disable-backchain: lghi %r2, 0 #[cfg(target_feature = "backchain")] { 1 } #[cfg(not(target_feature = "backchain"))] { 0 } // CHECK: br %r{{.*}} } </ins>

It is currently inconsistent with how behaves, which is a similar kind of "target feature" that's really more like a boolean codegen toggle.
Hmm, I don't know what we should do here, if we need to fix this issue, how should we avoid passing the to in the current framework?
The logic that decides what to pass to LLVM and the logic that decides what is set in are completely independent. (That's fairly recent and might have happened after you implemented this feature.) I think all that needs to be done is change this to simply The feature will have been to in . But better add a test for this to be sure.
Yes, I believe the change was done after I . I will try to implement this change then.


Question: use syntax::ast; use syntax::source_map::Spanned; use syntax::ptr::P; <ins> use syntax::util::lev_distance::find_best_match_for_name; </ins> use syntax_pos::Span; impl<'a, 'gcx, 'tcx> FnCtxt<'a, 'gcx, 'tcx> {

With a single typo in a match arm, we generate three separate errors: We should collect all these errors into a single diagnostic:
could you share sample code to exactly reproduce above diagnostic?
I will raise another PR to address the case where we are unnecessarily throwing .


Question: <ins> error[E0384]: cannot assign twice to immutable variable `a` --> $DIR/tainted-promoteds.rs:7:5 | LL |     let a = 0; |         - |         | |         first assignment to `a` |         help: consider making this binding mutable: `mut a` LL |     a = &0 * &1 * &2 * &3; |     ^^^^^^^^^^^^^^^^^^^^^ cannot assign twice to immutable variable error: aborting due to previous error For more information about this error, try `rustc --explain E0384`. </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: for attr in &data.attrs { match attr.style { crate::AttrStyle::Outer => { <del> assert!( inner_attrs.len() == 0, "Found outer attribute {:?} after inner attrs {:?}", attr, inner_attrs ); </del> outer_attrs.push(attr); } crate::AttrStyle::Inner => {

<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --I encountered an ICE while incorrectly inserting a outer attribute above deriving or inside of a proc-macro. This did not happen with any other derive I tried. <!-- 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
can you please also provide the configuration to reproduce an for your issue? thanks
Sure, sorry for forgetting, here is the mcve: But incase you dont want to see the entire project the for the macro was just: And the of the project to use the macro (and trigger the ICE) was:
Cool, thank you! Here's the result of a bisection: seems to point to PR cc searched nightlies: from nightly-2021-01-01 to nightly-2021-08-11 regressed nightly: nightly-2021-04-12 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium


Question: // option. This file may not be copied, modified, or distributed // except according to those terms. <del> // compile-flags:--no-defaults --passes "collapse-docs" --passes "unindent-comments" </del> <ins> // compile-flags:--no-defaults --passes collapse-docs --passes unindent-comments </ins> // @has issue_15347/fn.foo.html #[doc(hidden)]

Rustdoc defaults to only documented things that are public, i.e. things that the user of a library would care about. This is a good default, but rustdoc can also be useful to people working on large crates by documenting these crates themselves. In that case, it’s preferable to also include private types, fields, functions, and methods. was about this use case, and was closed with this solution: We just tried this on . It’s better than before, but has the unexpected side effect that every item (including non- and the implicit prelude) and every (including the implicit ) is documented under “Reexports”. It can get pretty noisy: ! They’re technically part of the crate, but don’t provide useful information. Could rustdoc split up the pass into one that strips private and , and one for everything else?


Question: E0495, // cannot infer an appropriate lifetime due to conflicting requirements E0496, // .. name `..` shadows a .. name that is already in scope E0498, // malformed plugin attribute <ins> E0514, // metadata version mismatch </ins> }

When trying to update uutils/coreutils to HEAD, I got this ICE: Version: code:
apparently, this happens as a side effect of the build process. i had built with stable, then tried to build with nightly, giving incorrect metadata


Question: } fn build_free<'tcx>(tcx: &ty::ctxt<'tcx>, <del> cfg: &mut CFG<'tcx>, </del> unit_temp: Lvalue<'tcx>, data: &FreeData<'tcx>, <del> target: BasicBlock) -> BasicBlock { </del> <ins> target: BasicBlock) -> Terminator<'tcx> { </ins> let free_func = tcx.lang_items.box_free_fn() .expect("box_free language item is missing"); let substs = tcx.mk_substs(Substs::new( VecPerParamSpace::new(vec![], vec![], vec![data.item_ty]), VecPerParamSpace::new(vec![], vec![], vec![]) )); <del> let block = cfg.start_new_cleanup_block(); cfg.terminate(block, Terminator::Call { </del> <ins> Terminator::Call { </ins> func: Operand::Constant(Constant { span: data.span, ty: tcx.lookup_item_type(free_func).ty.subst(tcx, substs),

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: LL |     type Bar<'a>: Deref<Target = <Self>::Bar<'a, Target = Self>>; |                                              +++ <del> error: aborting due to previous error </del> <ins> error[E0229]: associated type bindings are not allowed here --> $DIR/issue-85347.rs:3:46 | LL |     type Bar<'a>: Deref<Target = <Self>::Bar<Target = Self>>; |                                              ^^^^^^^^^^^^^ associated type not allowed here error: aborting due to 2 previous errors </ins> <del> For more information about this error, try `rustc --explain E0107`. </del> <ins> Some errors have detailed explanations: E0107, E0229. For more information about an error, try `rustc --explain E0107`. </ins>

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


Question: fn in_call( cx: &ConstCx<'_, 'tcx>, callee: &Operand<'tcx>, <del> _args: &[Operand<'tcx>], </del> <ins> args: &[Operand<'tcx>], </ins> _return_ty: Ty<'tcx>, ) -> bool { if cx.mode == Mode::Fn {

While attempting to build the current bobbin-sdk under Ubuntu 18.04 using rust 1.34.0-nightly ( 2019-02-26) I get a panic in rustc.
cc
Minimal repro: you need both the , a method call , and a method call on the result of that in order to trigger promotion. It seems like is promoted to make a for the call to
Ok, so promotion is indeed screwing up. The MIR is promoting the argument.
triage: P-high. Looks under control.
Just to confirm, this has not made it out to the nightly, correct? As of today I am still seeing the same error when attempting to build bobbin-hz as part of bobbin-sdk.
No, is still open, I'll bump its priority


Question: fn in_call( cx: &ConstCx<'_, 'tcx>, callee: &Operand<'tcx>, <del> _args: &[Operand<'tcx>], </del> <ins> args: &[Operand<'tcx>], </ins> _return_ty: Ty<'tcx>, ) -> bool { if cx.mode == Mode::Fn {

ICE when compiling bash parity-ethereum git:(master) cargo build Compiling ethcore-miner v1.12.0 () thread 'rustc' panicked at 'index out of bounds: the len is 2 but the index is 3', stack backtrace: 0: std::sys::unix::backtrace::tracing::imp::unwindbacktrace at 1: std::syscommon::backtrace::print at 2: std::panicking::defaulthook::{{closure}} at at 3: std::panicking::defaulthook at 4: rustc::util::common::panichook 5: std::panicking::rustpanicwithhook at 6: std::panicking::continuepanicfmt at 7: rustbeginunwind at 8: core::panicking::panicfmt at 9: core::panicking::panicboundscheck at 10: <rustctarget::abi::TyLayout<'a, Ty::field 11: rustcmir::interpret::operand::<impl rustcmir::interpret::evalcontext::EvalContext<'a, 'mir, 'tcx, M::operandfield 12: rustcmir::interpret::operand::<impl rustcmir::interpret::evalcontext::EvalContext<'a, 'mir, 'tcx, M::evalplacetoop 13: rustcmir::interpret::step::<impl rustcmir::interpret::evalcontext::EvalContext<'a, 'mir, 'tcx, M::run 14: rustcmir::consteval::evalbodyusingecx 15: rustcmir::consteval::constevalrawprovider 16: rustc::ty::query::querycompute::constevalraw 17: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcxfor rustc::ty::query::queries::constevalraw<'tcx::compute 18: rustc::depgraph::graph::DepGraph::withtaskimpl 19: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx,


Question: fn in_call( cx: &ConstCx<'_, 'tcx>, callee: &Operand<'tcx>, <del> _args: &[Operand<'tcx>], </del> <ins> args: &[Operand<'tcx>], </ins> _return_ty: Ty<'tcx>, ) -> bool { if cx.mode == Mode::Fn {

'tcx::getquery 20: rustcmir::consteval::constevalprovider 21: rustc::ty::query::querycompute::consteval 22: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcxfor rustc::ty::query::queries::consteval<'tcx::compute 23: rustc::depgraph::graph::DepGraph::withtaskimpl 24: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx::getquery 25: rustcmir::consteval::constevalprovider 26: rustc::ty::query::querycompute::consteval 27: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcxfor rustc::ty::query::queries::consteval<'tcx::compute 28: rustc::depgraph::graph::DepGraph::withtaskimpl 29: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx::getquery 30: rustcmir::monomorphize::collector::collectitemsrec 31: rustcmir::monomorphize::collector::collectcratemonoitems::{{closure}} 32: rustc::util::common::time 33: rustcmir::monomorphize::collector::collectcratemonoitems 34: rustc::util::common::time 35: rustcmir::monomorphize::partitioning::collectandpartitionmonoitems 36: rustc::ty::query::querycompute::collectandpartitionmonoitems 37: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcxfor rustc::ty::query::queries::collectandpartitionmonoitems<'tcx::compute 38: rustc::depgraph::graph::DepGraph::withtaskimpl 39: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx,


Question: fn in_call( cx: &ConstCx<'_, 'tcx>, callee: &Operand<'tcx>, <del> _args: &[Operand<'tcx>], </del> <ins> args: &[Operand<'tcx>], </ins> _return_ty: Ty<'tcx>, ) -> bool { if cx.mode == Mode::Fn {

'tcx::getquery 40: rustccodegenssa::back::symbolexport::exportedsymbolsproviderlocal 41: rustc::ty::query::querycompute::exportedsymbols 42: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcxfor rustc::ty::query::queries::exportedsymbols<'tcx::compute 43: rustc::depgraph::graph::DepGraph::withtaskimpl 44: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx,


Question: fn in_call( cx: &ConstCx<'_, 'tcx>, callee: &Operand<'tcx>, <del> _args: &[Operand<'tcx>], </del> <ins> args: &[Operand<'tcx>], </ins> _return_ty: Ty<'tcx>, ) -> bool { if cx.mode == Mode::Fn {

'tcx::getquery 45: rustcmetadata::encoder::encodemetadata 46: rustcmetadata::cstoreimpl::<impl rustc::middle::cstore::CrateStore for rustcmetadata::cstore::CStore::encodemetadata 47: rustc::ty::context::TyCtxt::encodemetadata 48: rustccodegenllvm::base::writemetadata 49: rustc::util::common::time 50: rustccodegenssa::base::codegencrate 51: <rustccodegenllvm::LlvmCodegenBackend as rustccodegenutils::codegenbackend::CodegenBackend::codegencrate 52: rustc::util::common::time 53: rustcdriver::driver::phase4codegen 54: rustcdriver::driver::compileinput::{{closure}} 55: <std::thread::local::LocalKey<T::with 56: rustc::ty::context::TyCtxt::createandenter 57: rustcdriver::driver::compileinput 58: rustcdriver::runcompilerwithpool 59: <scopedtls::ScopedKey<T::set 60: rustcdriver::runcompiler 61: syntax::withglobals 62: rustmaybecatchpanic at 63: <F as alloc::boxed::FnBox<A::callbox 64: std::sys::unix::thread::Thread::new::threadstart at at at 65: startthread 66: _clone query stack during panic: [constevalraw] const-evaluating [consteval] const-evaluating + checking [consteval] const-evaluating + checking [collectandpartitionmonoitems] collectandpartitionmonoitems [exportedsymbols] exportedsymbols end of query stack error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: rustc 1.34.0-nightly ( 2019-02-21) running on x8664-unknown-linux-gnu note: compiler flags: -C debuginfo=2 -C incremental --crate-type lib note: some of the compiler flags provided by cargo are hidden error: Could not compile . warning: build failed, waiting for other jobs to finish... error: build failed
cc
Is this a regression?


Question: fn in_call( cx: &ConstCx<'_, 'tcx>, callee: &Operand<'tcx>, <del> _args: &[Operand<'tcx>], </del> <ins> args: &[Operand<'tcx>], </ins> _return_ty: Ty<'tcx>, ) -> bool { if cx.mode == Mode::Fn {

Did it work with a previous nightly? I'm currently looking through function (the ICE is during the evaluation of a promoted inside that function), but I can't find any promoteds :confused:
I can't debug this right now, because a debugging compiler fails even earlier:
So apparently still causes the ICE, but only inside the crate. If I try to create an MCVE everything compiles just fine... Very confusing.
triage: P-high. Looks to be in good hands.
Thanks, I can verify that it is fixed in


Question: } fn is_try_block(&self) -> bool { <del> self.token.is_keyword(kw::Try) && self.look_ahead(1, |t| *t == token::OpenDelim(token::Brace)) && self.token.uninterpolated_span().rust_2018() && // Prevent `while try {} {}`, `if try {} {} else {}`, etc. !self.restrictions.contains(Restrictions::NO_STRUCT_LITERAL) </del> <ins> self.token.is_keyword(kw::Try) && self.look_ahead(1, |t| *t == token::OpenDelim(token::Brace)) && self.token.uninterpolated_span().rust_2018() </ins> } /// Parses an `async move? {...}` expression.

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


Question: } fn is_try_block(&self) -> bool { <del> self.token.is_keyword(kw::Try) && self.look_ahead(1, |t| *t == token::OpenDelim(token::Brace)) && self.token.uninterpolated_span().rust_2018() && // Prevent `while try {} {}`, `if try {} {} else {}`, etc. !self.restrictions.contains(Restrictions::NO_STRUCT_LITERAL) </del> <ins> self.token.is_keyword(kw::Try) && self.look_ahead(1, |t| *t == token::OpenDelim(token::Brace)) && self.token.uninterpolated_span().rust_2018() </ins> } /// Parses an `async move? {...}` expression.

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


Question: [submodule "src/llvm-project"] path = src/llvm-project url = https://github.com/rust-lang/llvm-project.git <del> branch = rustc/16.0-2023-03-06 </del> <ins> branch = rustc/16.0-2023-04-05 </ins> [submodule "src/doc/embedded-book"] path = src/doc/embedded-book url = https://github.com/rust-embedded/book.git

Hi, Building in release mode with a freshly updated nightly fails with a SIGSEGV (or STATUSACCESSVIOLATION on Windows). This doesn't occur on or , or when building with any profile that has . I stumbled upon this while trying to measure the performance impact of , which branches from at and suffers from the same issue. I don't know why, but the problem only appears on (that I'm aware of): fails, while any other crate within the same repo works (provided they don't depend on )? : The same issue arises with the same version of nightly on Windows. <details<summaryBacktrace</summary<p</p</details
Could you check which nightly and PR caused this regression with ?
Additionally, are you able to get a backtrace with a debugger?
Sure, I'll run the bisect tomorrow morning (CET). I'll try, but if the builds don't already have debug symbols, I'm not sure how to have x.py spit them out. No need to reply if they're already in there, but if they aren't, instructions would be appreciated :)
We do ship debug symbols, they may be in a rustup component instead of shipped by default. rustc-dev, I believe?
Thanks, I'll check that out in roughly 8 hours :)
We do always ship symbols in the same binary, but we never ship debuginfo.
Preliminary reduction for :
Minimized:
Upstream fix:
Thank you so much for taking the issue, I did try bisecting, but you had located the issue by the time I made any progress :)


Question: /// # Examples /// /// ``` <del> /// # #![feature(duration_as_u128)] </del> /// use std::time::Duration; /// /// let duration = Duration::new(5, 730023852); /// assert_eq!(duration.as_millis(), 5730); /// ``` <del> #[unstable(feature = "duration_as_u128", issue = "50202")] </del> <ins> #[stable(feature = "duration_as_u128", since = "1.33.0")] </ins> #[inline] pub const fn as_millis(&self) -> u128 { self.secs as u128 * MILLIS_PER_SEC as u128 + (self.nanos / NANOS_PER_MILLI) as u128

Duration has historically lacked a way to get the actual number of nanoseconds it contained as a normal Rust type because u64 was of insufficient range, and f64 of insufficient precision. The u128 type solves both issues, so I propose adding an as_nanos function to expose the capability. CC:
I still don't understand why Duration is not allowed to be negative. It bugs me that the SystemTime difference returns a Result<Duration,Errorand returns and error if the time from is after the time to. To me, it should just return a negative Duration (Yes, the System Clock can go backwards). I find it odd that Duration does not support a negative amount.
I think it's about the way you think of . If it's a span of time (like described in the documentation) or an interval, then it must be positive. If it's the distance between two time points, it's negative. You're probably thinking of a distance instead of an interval. That's not necessarily a bad thing, but it's different from what the type is today, and it will never change due to compatibility concerns.
Here is what I take issue with: And....DING! DING! DING! know what, now that I've typed out that code, I can't think of any justifiable reason I would actually want that, so, once again, the thoughtfulness of Rust shows itself. You and the designers of Duration were correct. Negative Duration doesn't make sense (even though it feels like it should).
You can use if you want to measure a duration.
Yes, I'm aware. I guess I think there should be another thing called ClockTimeDifference (that can be neg/pos) and there should be methods on SystemTime that don't return Result<Duration,Error, but, instead return ClockTimeDifference. It could be as simple as:
It can, but the return type of will never change, so it's up to you (or a crate) to implement that.
This is the tracking issue for a feature that adds several specific methods to Duration, not a place to debate general concerns about the Duration type. Your discussion is probably better suited for the site.
Why can't as_millis return an i64?
large durations won't fit into that type.
Pardon my ignorance, but why is this unstable?


Question: /// # Examples /// /// ``` <del> /// # #![feature(duration_as_u128)] </del> /// use std::time::Duration; /// /// let duration = Duration::new(5, 730023852); /// assert_eq!(duration.as_millis(), 5730); /// ``` <del> #[unstable(feature = "duration_as_u128", issue = "50202")] </del> <ins> #[stable(feature = "duration_as_u128", since = "1.33.0")] </ins> #[inline] pub const fn as_millis(&self) -> u128 { self.secs as u128 * MILLIS_PER_SEC as u128 + (self.nanos / NANOS_PER_MILLI) as u128

For my usecase, I probably don't need more than a , and I really only need millis (though the code I'm porting happens to use microseconds). I'd rather have a , but I'm just not sure what to do here for my code which I'm trying to keep as close to fully stable as possible (I want it to be as portable and safe as I can make it). I know (I think?) I can use , but I'd rather not lose the precision and I think I can always use for all my platforms.
is there any reason not to move forward with stabilization on this? correctly observes that it has been unstable for quite a while
The stability of u128 was the blocker previously, but that's now no longer a problem. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
I couldn’t find all the details in this issue, grepping through the code shows that this tracking issue is for:
This may be a stupid question, but is available on all platforms that Rust supports?
:bell: This is now entering its final comment period, as per the . :bell:
Yep, it should be available on all platforms.
The final comment period, with a disposition to merge, as per the , is now complete.
Now that final comment period has ended, can these methods be stabilized?
Yes, the next step is a stabilization PR.
Awesome! I've made a PR for stabilization here: Please let me know if it needs any adjustments. I can't wait for this to land! :tada:


Question: <ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // Issue 46112: An extern crate pub reexporting libcore was causing // paths rooted from `std` to be misrendered in the diagnostic output. // ignore-windows // aux-build:xcrate_issue_46112_rexport_core.rs extern crate xcrate_issue_46112_rexport_core; fn test(r: Result<Option<()>, &'static str>) { } fn main() { test(Ok(())); } //~^ mismatched types </ins>

On nightly rustc (cargo) I get misleading expected type errors. If a crate has the same(?) type it is displayed instead of the std type. I tried this code: I expected to see this happen: (stable rust) Instead, this happened: (nightly) :
Confirming - broken on nightly (1.23), good on beta.
bisected across nightlys: bug was injected between and
Skimming output from , there are a number of different potential culprits. Rather than guess and "point fingers" right now, I'll just continue bisecting within that commit range.
This is recent enough that we should be able to run bisect-rust on it (cc
it is cc .
I'm a little surprised that this would be caused by that PR. I can push a revert but would like to first test locally to make sure that revert that PR will fix this.
I have misread 's statement. Your PR is not at fault, sorry. I'm doing another search further back to find the causing PR.
I tried it locally in the meantime and I can confirm it is not :)
Okay so the bug dates as far back as from September 2nd which is as close to the limit as I dare to go. So to the people in control, please, prolong the limit :).
suggests that the bug was introduced much more recently (11-08 to 11-09). Maybe the bisection script was wrong?
I should probably have read the original issue more closely :). sorry for pinging you! It seems to be cc
In particular, I have bisected it down to the commit: I have been trying to further dissect that commit to figure out why it causes the change we observe here. My current hypothesis (that I have not yet managed to confirm) is that it has to do with how we seed the hashmap's hashers with randomized state. (This commit changes our behavior in certain scenarios.) If this hypothesis is actually true, though, then I would think that this represents either a bug in hashmap itself, or a bug in how the compiler is using the hashmap...
Hmm. Its something more subtle than a hashmap-related bug.


Question: <ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // Issue 46112: An extern crate pub reexporting libcore was causing // paths rooted from `std` to be misrendered in the diagnostic output. // ignore-windows // aux-build:xcrate_issue_46112_rexport_core.rs extern crate xcrate_issue_46112_rexport_core; fn test(r: Result<Option<()>, &'static str>) { } fn main() { test(Ok(())); } //~^ mismatched types </ins>

In particular, I can reproduce the old behavior on master by just linking in the old crate into (in addtion to linking in the one from ; doing this requires changing the name of the old ), without making any actual calls into the old crate. That, to me, seems very strange. I'm now trying to reduce down the size of the crate that I am linking in (while still causing this delta in behavior).
triage: P-high
I still get a non std types in erros when the path has the same length. That would be okay if it is somehow deterministic, but I get different type errors within the same file for the same types.
is that a regression from the stable channel? While I absolutely agree that a deterministic result would be better (and better stilll, a deterministic result that favored minimal-length paths rooted at ), I want to triage this appropriately.
Hmm I guess since is the person who filed the original ticket then it is reasonable to infer that they are indeed seeing the described regression compared to the stable channel.
gives me: seems to work now: Maybe this was some sort of partial compile cache issue? I haven't found a way to reproduce these mixed errors yet.
This looks like a duplicate of . That issue has some repro cases that affect the 1.22.1 stable compiler but not 1.21.0.
When I bisected the nightlies by hand on I ended up with a range (...) that does not include the commit identified here. Is it possible that the nondeterministic nature of the bug is also messing with our attempts to bisect? I wonder whether merely linking affects in the same way as it affected this issue.
Any evidence of this problem existing with the newest nightly?
All the cases I tried seem to have been fixed by and . Nicely done! I reported one follow-up in .


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

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


Question: verbose_help); } <ins> fn print_wall_help() { println!(" The flag `-Wall` does not exist in `rustc`. Most useful lints are enabled by default. Use `rustc -W help` to see all available lints. It's more common to put warning settings in the crate root using `#![warn(LINT_NAME)]` instead of using the command line flag directly. "); } </ins> fn describe_lints(sess: &Session, lint_store: &lint::LintStore, loaded_plugins: bool) { println!(" Available lint options:

It would be nice if turned on all warnings, like how other compilers work.
At least with and , doesn't turn on all the warnings. I don't think turning all on the warnings is ever going to be useful because lots are going to be very domain specific (ones like already are). clang has a fairly useless to turn on all warnings, and to turn on all those included by , and also many more that are considered to be useful. Rust already has all the warnings viewed as useful and not too subjective on by default.
Oh, wow! Thanks for the detailed, thoughtful response. I'll definitely look into each of those options.
(FWIW the warnings are listed in and are almost all on by default)
I think there should be a catch-all lint group, that objectively enables all lints. Whenever programmers decide subjectively to allow lints in some instances, they may then do that on a case-by-case basis. And if an implemented lint simply does not make sense at all then it should be improved/removed. The existing lint group apparently does not include all built-in lint groups, contrary to the output of (): can this issue be reopened?
Reopening. However, I think we shouldn't have any sort of "enable all lints" option; rustc's lints are already all intended to have no or very few false positives (and as such are enabled by default where that makes sense). Could you talk about which specific lints are missing from the default warnings built-in list? I'm not personally aware of any. I'm also somewhat concerned that a or similar option would be confusing to some extent because "all" wouldn't include clippy lints (and probably can't, or at least not easily -- though I don't know the details here).
Issue triage: no longer prints , so that was fixed at some point. (it now prints ) I think it might be useful to have a message explaining why doesn't exist, point the user toward to see all available errors, and suggest adding a for a more thorough lint check. This would help beginners coming from other languages to 1) understand that most useful warnings are turned on by default, 2) tell the user that exists, and 3) show the user that warnings can be controlled from inside the source code, rather than the command line. If there's interest in doing this, I could make a PR.


Question: Command::new("mkdir").arg("./").output().unwrap() }; <del> assert!(status.code() == Some(1)); </del> <ins> assert!(status.code().is_some()); assert!(status.code() != Some(0)); </ins> assert_eq!(stdout, Vec::new()); assert!(!stderr.is_empty()); } #[test] <del> #[cfg_attr(any(target_os = "vxworks", target_os = "android"), ignore)] </del> <ins> #[cfg_attr(any(target_os = "vxworks"), ignore)] </ins> fn test_finish_once() { let mut prog = if cfg!(target_os = "windows") { Command::new("cmd").args(&["/C", "exit 1"]).spawn().unwrap() } else { <del> Command::new("false").spawn().unwrap() </del> <ins> shell_cmd().arg("-c").arg("false").spawn().unwrap() </ins> }; assert!(prog.wait().unwrap().code() == Some(1)); } #[test] <del> #[cfg_attr(any(target_os = "vxworks", target_os = "android"), ignore)] </del> <ins> #[cfg_attr(any(target_os = "vxworks"), ignore)] </ins> fn test_finish_twice() { let mut prog = if cfg!(target_os = "windows") { Command::new("cmd").args(&["/C", "exit 1"]).spawn().unwrap() } else { <del> Command::new("false").spawn().unwrap() </del> <ins> shell_cmd().arg("-c").arg("false").spawn().unwrap() </ins> }; assert!(prog.wait().unwrap().code() == Some(1)); assert!(prog.wait().unwrap().code() == Some(1)); } #[test] <del> #[cfg_attr(any(target_os = "vxworks", target_os = "android"), ignore)] </del> <ins> #[cfg_attr(any(target_os = "vxworks"), ignore)] </ins> fn test_wait_with_output_once() { let prog = if cfg!(target_os = "windows") { Command::new("cmd").args(&["/C", "echo hello"]).stdout(Stdio::piped()).spawn().unwrap() } else { <del> Command::new("echo").arg("hello").stdout(Stdio::piped()).spawn().unwrap() </del> <ins> shell_cmd().arg("-c").arg("echo hello").stdout(Stdio::piped()).spawn().unwrap() </ins> }; let Output { status, stdout, stderr } = prog.wait_with_output().unwrap();

To enable test on android bot and test/run-pass/rtio- It looks to me RtioProcess does not work properly on android.
logs are
Hm this may be an FFI issue with libuv. I realized during my uv rewrite that libuv is giving us an int64t exit status and we think it's a cint. Once lands this may be fixed.
Hmm, this issue number has propagated to several more tests that are cfg-disabled on android. (Some of which are now failing when I mixed in a Boehm/BDW conservative GC into the runtime, in particular .)
Also, has landed, so it would be good to determine if these tests now work on Android.
Triage: I have no idea how to test this, but a lot has changed in a year (especially the removal of green & libuv), so these may be magically fixed; if someone can check.
Triage: is gone, but all these tests in are still ignored for android.
I tried to run these tests with but they all failed with , which seems suspect (at least for the tests that invoke , , , etc.). Is there a better way to test? I have an android device available.


Question: expanded_cache: FxHashMap::default(), primary_def_id: Some(def_id), found_recursion: false, <ins> found_any_recursion: false, </ins> check_recursion: true, tcx: self, };

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


Question: expanded_cache: FxHashMap::default(), primary_def_id: Some(def_id), found_recursion: false, <ins> found_any_recursion: false, </ins> check_recursion: true, tcx: self, };

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


Question: Box::new(MaybeUninit::uninit()) } <del> // FIXME: add a test for a bigger box. Currently broken, see // https://github.com/rust-lang/rust/issues/58201. </del> <ins> // https://github.com/rust-lang/rust/issues/58201 #[no_mangle] pub fn box_uninitialized2() -> Box<MaybeUninit<[usize; 1024 * 1024]>> { // CHECK-LABEL: @box_uninitialized2 // CHECK-NOT: store // CHECK-NOT: alloca // CHECK-NOT: memcpy // CHECK-NOT: memset Box::new(MaybeUninit::uninit()) } </ins> // Hide the `allocalign` attribute in the declaration of __rust_alloc // from the CHECK-NOT above, and also verify the attributes got set reasonably.

The following code generates some really awful LLVM IR: The same happens with . Cc who made me write these tests, and
Feels like an LLVM limitation to me. It should be replacing the with a (or a of poison when that becomes available).
For reference: LLVM is capable of optimizing a memcpy of undef alloca away, this just runs into the usual limitation that all of memcpyopt doesn't work across BBs.
This is such a long-standing issue. Seems like it might be wise to have someone working on fixing this.
Someone has already worked on this, see It's a bit hard to track, but unfortunately this got reverted again (multiple times). I suspect that this is only going to get really resolved once memcpyopt moves to memssa -- which someone has also worked on in the past (), but which never really went anywhere.
The alloca and memcpy are no longer present on nightly, as a result of .
The FIXME in the test is still there, needs a test.


Question: use rustc_hir as hir; use rustc_hir::def::{DefKind, Res}; use rustc_hir::def_id::{DefId, DefIdMap, LocalDefId, LocalDefIdSet}; <del> use rustc_hir::intravisit::{walk_item, Visitor}; </del> <ins> use rustc_hir::intravisit::{walk_body, walk_item, Visitor}; </ins> use rustc_hir::{Node, CRATE_HIR_ID}; use rustc_middle::hir::nested_filter; use rustc_middle::ty::TyCtxt;

<!-- 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. --Consider the following code is local to and inaccessible, and should not be documented. Instead, rustdoc currently documents the module at the same level as . <!-- 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. --: </details
cc does this have to do with those changes you made to item collection?
Very likely. I won't be able to fix it until next week though. EDIT: I suspect it broke from
I just realized that this is broken on stable, too, so I think the cause may be older than that?
Oh. I'm at least happy to realize that I didn't break it recently. Thanks for the report. Will fix it monday.


Question: <ins> error[E0308]: mismatched types --> $DIR/bad-type-in-vec-push.rs:11:17 | LL |     vector.sort(); |     ------ here the type of `vector` is inferred to be `Vec<_>` LL |     result.push(vector); |            ---- ^^^^^^ expected integer, found struct `Vec` |            | |            arguments to this method are incorrect | = note: expected type `{integer}` found struct `Vec<_>` note: associated function defined here --> $SRC_DIR/alloc/src/vec/mod.rs:LL:COL error[E0308]: mismatched types --> $DIR/bad-type-in-vec-push.rs:18:12 | LL |     x.push(""); |       ---- ^^ expected integer, found `&str` |       | |       arguments to this method are incorrect | note: associated function defined here --> $SRC_DIR/alloc/src/vec/mod.rs:LL:COL error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0308`. </ins>

I tried this code on nightly: I expected to see this happen: compiler does not panic. Instead, this happened: compiler panics and suggests I open a bug report. I initially posted to , but says this is a different issue, despite panicking on the same line in . (Though I'm realizing now that might be the proximal cause but not very related to the root cause.) : <details<summaryPanic message</summary<p</p</detailsThanks all for maintaining Rust, by the way.
Thanks!
searched nightlies: from nightly-2022-12-01 to nightly-2023-01-21 regressed nightly: nightly-2023-01-07 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
It's , i'll fix it unless someone beats me to it since I'm busy this weekend
Hi it's Justin from Commure :wave:. I found a compiler panic you made :grinning:
sorry for causing you trouble


Question: } fn run(self, builder: &Builder<'_>) { <del> // This gets called by `promote-release` // (https://github.com/rust-lang/rust-central-station/tree/master/promote-release). </del> let mut cmd = builder.tool_cmd(Tool::BuildManifest); if builder.config.dry_run { return;

Seems like no nightly was released today. That might be related to Unfortunately I don't think I have access to the logs. Cc
Logs are missing on the server, let me start a manual release...
Well that is odd. You wouldn't know what commit is is using? ( file in the tarball, if I recall correctly.)
Is there a way for me to download the "dist" artifacts for better testing? Right now I am manually grabbing a bunch of files from https://s3-us-west- (and we only get dir listing for alt builds there it seems so I am using those). That's not very convenient at all.
Apparently not all commits are pushed to toolstate ( vs ), for example the latest one () is missing in toolstate .
Reverting the cause in the meantime --
Alternatively we could land which will just skip of the toolstate is not found. That installs a toolchain based on these artifacts, but I don't think it gives me access to the tarballs. FTR, for now I did So we are only committing when the toolstate changed? Ouch. That kills my entire approach :(
It should print the URLs it's downloading though, and you can use to avoid it actually downloading stuff.


Question: impl ErrorIndex { pub fn command(builder: &Builder<'_>) -> Command { <del> // This uses stage-1 to match the behavior of building rustdoc. // Error-index-generator links with the rustdoc library, so we want to // use the same librustdoc to avoid building rustdoc twice (and to // avoid building the compiler an extra time). This uses // saturating_sub to deal with building with stage 0. (Using stage 0 // isn't recommended, since it will fail if any new error index tests // use new syntax, but it should work otherwise.) let compiler = builder.compiler(builder.top_stage.saturating_sub(1), builder.config.build); </del> <ins> // Error-index-generator links with the rustdoc library, so we need to add `rustc_lib_paths` // for rustc_private and libLLVM.so, and `sysroot_lib` for libstd, etc. let host = builder.config.build; let compiler = builder.compiler_for(builder.top_stage, host, host); </ins> let mut cmd = Command::new(builder.ensure(ErrorIndex { compiler })); <del> add_dylib_path( vec![ PathBuf::from(&builder.sysroot_libdir(compiler, compiler.host)), builder.rustc_libdir(compiler), ], &mut cmd, ); </del> <ins> let mut dylib_paths = builder.rustc_lib_paths(compiler); dylib_paths.push(PathBuf::from(&builder.sysroot_libdir(compiler, compiler.host))); add_dylib_path(dylib_paths, &mut cmd); </ins> cmd } }

Steps: Checkout commit Have in . In particular, this implies Run Output (on the second run):
cc
For what it’s worth is just what I happened to get after running today. I mentioned it in case something changes later, it’s a coincidence that that commit happens to be related to downloading LLVM from Rust CI.
I think this is a duplicate of
That issue is closed, and its final comment points to this issue.
I just hit this on the following sequence. Do a fresh clone of Run Select option (b) "compiler: Contribute to the compiler itself" Run The build finished like so:
IMO the proper fix for this is to remove error-index's dependency on rustdoc, either by moving the relevant code out into a library that doesn't use rustc_private, or by duplicating the code altogether. There are other ways to solve this but they'll be more complicated and take longer to compile for no real benefit.
by making it invoke rustdoc-the-binary (through ), rather than using rustdoc-the-library.
you should be able to work around this by adding --stage 2 I think.
Thanks, that worked
I think you're right that the binary will be easier - parsing the markdown requires parsing doctests so that it can generate the "Run" button, and parsing doctests requires all of .


Question: <ins> #![feature(doc_alias)] #![feature(trait_alias)] pub struct Foo; pub trait Bar { const BAZ: u8; } impl Bar for Foo { #[doc(alias = "CONST_BAZ")] //~ ERROR const BAZ: u8 = 0; } impl Foo { #[doc(alias = "CONST_FOO")] // ok! pub const FOO: u8 = 0; pub fn bar() -> u8 { Self::FOO } } </ins>

Now that has been merged, only a few checks remain to be in order to stabilize this feature. First, we need to actually perform those checks in the compiler directly instead of rustdoc. You mentioned other checks too ? This issue is part of .
We should reject on items that don't actually appear in the search index such as blocks and s.
Ok, makes sense! Last question: I remember you telling that you'd prefer this check in rustc directly instead of rustdoc. I can move things there, just wanted to check one last time before doing it.
Yeah, rustc validates some attributes in and it might make sense to validate the attribute there as well.
Since has been merged, we can close this issue.
We're still not rejecting on associated s in trait impls like:
Ok! Putting on hold then!


Question: fn test1() { let a: i32 = "foo"; //~^ ERROR: mismatched types <ins> let b: i32 = "f'oo"; //~^ ERROR: mismatched types </ins> } fn test2() {

This is minimized from the dramatic forum thread . The following code is fine in nightly-2018-04-12 but breaks with nightly-2018-04-15. Oddly, lots of minor perturbations make it succeed. For example remove the two characters and it works. Or remove the single quote in the string and it works.
Alrighty-roo. As everything these days with hygiene, there's a couple of bugs here. With this one though I think only two! Everything has to do here with basically. AKA anything that runs through that falls off The usual reasons we think you fall off the "happy path" are due to things like inner attributes, , macro expansion, etc. None of that's present here! It should be the case that above can be losslessly converted to a based on what we've cached. Turns out though had a bug in it (surprise surprise!). There we're using to compare the resulting two token streams which eventually bottoms out in . As it turns out this isn't quite what we want! The implementation is structural, but the token stream we get when stringifying is slightly different than what we parsed. Here in the example you're using the literal string , but rustc stringifies this token as . Similarly if you replaced the string with something like it'll be stringified as . This means that the tokens are not literally byte-for-byte equal, which means we fall off the happy path! tl;dr the token stream of is not equivalent to the token stream . This causes us to fall off the happy path and used a stringified token stream. OK so in the case above we're falling off the happy path when we didn't expect to, but even still there's some weird bad hygiene behavior when we're not on the happy path. There's still something to fix! It turns out that there's also a regression due to (found via bisection). Before that PR this example would compile just fine, afterwards though it's hitting this error. can you help diagnose this and see what's going on? The reduced test case I have right now is: (note the inner attribute on to force using a non-cached token stream)
I've posted a fix for the "happy path" at will actually fix example above.


Question: fn test1() { let a: i32 = "foo"; //~^ ERROR: mismatched types <ins> let b: i32 = "f'oo"; //~^ ERROR: mismatched types </ins> } fn test2() {

That PR does not, however, fix the regression from which is still reproducible with the example I gisted.
Any idea why my repro case above is fixed if you remove the tokens? It seems like should fall off the happy path just as much.
If you remove the tokens we're still on the stringification path (aka not the happy path). For whatever reason though the hygiene bug goes away. That's likely caused from a subtelty introduced in (or at least so I'm hoping). I don't know much about , so I'm hoping will be able to look at this and know what's going on!
I don't know much about , so I'm hoping will be able to look at this and know what's going on! I'll investigate.
is the commit causing the regression. Further investigation is in progress.
An issue recently popped up on Rocket () that appears to be identical to this one and is not resolved in any recent nightly. It's possible that the root cause is , however.


Question: fn after_krate(&mut self) -> Result<(), Error> { debug!("Done with crate"); <del> debug!("Adding Primitive impls"); for primitive in Rc::clone(&self.cache).primitive_locations.values() { self.get_impls(*primitive); } </del> let e = ExternalCrate { crate_num: LOCAL_CRATE }; let index = (*self.index).clone().into_inner(); debug!("Constructing Output");

Generated rustdoc JSON for every one of dozens of crates I've looked at seems to contain unexpected inlined items that look like an block and its contents. I expected to see this happen: rustdoc JSON file contains only the items defined or re-exported by the corresponding crate. Instead, this happened: the rustdoc JSON file contains items like this: In this example, is and here are the names of the items contained in that impl (also part of the rustdoc JSON): Similarly, you can find items from : Invocation for generating rustdoc JSON: : You can find a variety of pre-generated rustdoc JSON files with this issue here: Briefly discussed in Zulip: https://rust- I'll have to work around this behavior to shield , which uses the same codebase as the playground link above. I can hold off on updating the playground for, say, another week, but at some point I'll need to upgrade it to include my workaround which means those items will cease being shown. label +T-rustdoc +A-rustdoc-json
Possibly duplicate of
Might be! Definitely at least some overlap, not entirely sure if duplicate. Do you mind if I ship the workaround for this in cargo-semver-checks and the playground, which will hide these items from our lints and from queries in the playground?
Yeah, it's easy enough to reproduce in raw json, I'm not worried about the repro breaking.


Question: <del> // Copyright 2014-2015 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. //! Scoped thread-local storage //! //! This module provides the ability to generate *scoped* thread-local //! variables. In this sense, scoped indicates that thread local storage //! actually stores a reference to a value, and this reference is only placed //! in storage for a scoped amount of time. //! //! There are no restrictions on what types can be placed into a scoped //! variable, but all scoped variables are initialized to the equivalent of //! null. Scoped thread local storage is useful when a value is present for a known //! period of time and it is not required to relinquish ownership of the //! contents. //! //! # Examples //! //! ``` //! # #![feature(scoped_tls)] //! scoped_thread_local!(static FOO: u32); //! //! // Initially each scoped slot is empty. //! assert!(!FOO.is_set()); //! //! // When inserting a value, the value is only in place for the duration //! // of the closure specified. //! FOO.set(&1, || { //!     FOO.with(|slot| { //!         assert_eq!(*slot, 1); //!     }); //! }); //! ``` #![unstable(feature = "thread_local_internals")] use prelude::v1::*; // macro hygiene sure would be nice, wouldn't it? #[doc(hidden)] pub mod __impl { pub use super::imp::KeyInner; pub use sys_common::thread_local::INIT as OS_INIT; } /// Type representing a thread local storage key corresponding to a reference /// to the type parameter `T`. /// /// Keys are statically allocated and can contain a reference to an instance of /// type `T` scoped to a particular lifetime. Keys provides two methods, `set` /// and `with`, both of which currently use closures to control the scope of /// their contents. #[unstable(feature = "scoped_tls", reason = "scoped TLS has yet to have wide enough use to fully consider  stabilizing its interface")] pub struct ScopedKey<T> { #[doc(hidden)] pub inner: __impl::KeyInner<T> } /// Declare a new scoped thread local storage key. /// /// This macro declares a `static` item on which methods are used to get and /// set the value stored within. #[macro_export] #[allow_internal_unstable] macro_rules! scoped_thread_local { (static $name:ident: $t:ty) => ( __scoped_thread_local_inner!(static $name: $t); ); (pub static $name:ident: $t:ty) => ( __scoped_thread_local_inner!(pub static $name: $t); ); } #[macro_export] #[doc(hidden)] #[allow_internal_unstable] macro_rules! __scoped_thread_local_inner { (static $name:ident: $t:ty) => ( #[cfg_attr(not(any(windows, target_os = "android", target_os = "ios", target_os = "openbsd", target_arch = "aarch64")), thread_local)] static $name: ::std::thread::ScopedKey<$t> = __scoped_thread_local_inner!($t); ); (pub static $name:ident: $t:ty) => ( #[cfg_attr(not(any(windows, target_os = "android", target_os = "ios", target_os = "openbsd", target_arch = "aarch64")), thread_local)] pub static $name: ::std::thread::ScopedKey<$t> = __scoped_thread_local_inner!($t); ); ($t:ty) => ({ use std::thread::ScopedKey as __Key; #[cfg(not(any(windows, target_os = "android", target_os = "ios", target_os = "openbsd", target_arch = "aarch64")))] const _INIT: __Key<$t> = __Key { inner: ::std::thread::__scoped::KeyInner { inner: ::std::cell::UnsafeCell { value: 0 as *mut _ }, } }; #[cfg(any(windows, target_os = "android", target_os = "ios", target_os = "openbsd", target_arch = "aarch64"))] const _INIT: __Key<$t> = __Key { inner: ::std::thread::__scoped::KeyInner { inner: ::std::thread::__scoped::OS_INIT, marker: ::std::marker::PhantomData::<::std::cell::Cell<$t>>, } }; _INIT }) } #[unstable(feature = "scoped_tls", reason = "scoped TLS has yet to have wide enough use to fully consider  stabilizing its interface")] impl<T> ScopedKey<T> { /// Insert a value into this scoped thread local storage slot for a /// duration of a closure. /// /// While `cb` is running, the value `t` will be returned by `get` unless /// this function is called recursively inside of `cb`. /// /// Upon return, this function will restore the previous value, if any /// was available. /// /// # Examples /// /// ``` /// # #![feature(scoped_tls)] /// scoped_thread_local!(static FOO: u32); /// /// FOO.set(&100, || { ///     let val = FOO.with(|v| *v); ///     assert_eq!(val, 100); /// ///     // set can be called recursively ///     FOO.set(&101, || { ///         // ... ///     }); /// ///     // Recursive calls restore the previous value. ///     let val = FOO.with(|v| *v); ///     assert_eq!(val, 100); /// }); /// ``` pub fn set<R, F>(&'static self, t: &T, cb: F) -> R where F: FnOnce() -> R, { struct Reset<'a, T: 'a> { key: &'a __impl::KeyInner<T>, val: *mut T, } #[unsafe_destructor] impl<'a, T> Drop for Reset<'a, T> { fn drop(&mut self) { unsafe { self.key.set(self.val) } } } let prev = unsafe { let prev = self.inner.get(); self.inner.set(t as *const T as *mut T); prev }; let _reset = Reset { key: &self.inner, val: prev }; cb() } /// Get a value out of this scoped variable. /// /// This function takes a closure which receives the value of this /// variable. /// /// # Panics /// /// This function will panic if `set` has not previously been called. /// /// # Examples /// /// ```no_run /// # #![feature(scoped_tls)] /// scoped_thread_local!(static FOO: u32); /// /// FOO.with(|slot| { ///     // work with `slot` /// }); /// ``` pub fn with<R, F>(&'static self, cb: F) -> R where F: FnOnce(&T) -> R { unsafe { let ptr = self.inner.get(); assert!(!ptr.is_null(), "cannot access a scoped thread local  variable without calling `set` first"); cb(&*ptr) } } /// Test whether this TLS key has been `set` for the current thread. pub fn is_set(&'static self) -> bool { unsafe { !self.inner.get().is_null() } } } #[cfg(not(any(windows, target_os = "android", target_os = "ios", target_os = "openbsd", target_arch = "aarch64")))] mod imp { use std::cell::UnsafeCell; #[doc(hidden)] pub struct KeyInner<T> { pub inner: UnsafeCell<*mut T> } unsafe impl<T> ::marker::Sync for KeyInner<T> { } #[doc(hidden)] impl<T> KeyInner<T> { #[doc(hidden)] pub unsafe fn set(&self, ptr: *mut T) { *self.inner.get() = ptr; } #[doc(hidden)] pub unsafe fn get(&self) -> *mut T { *self.inner.get() } } } #[cfg(any(windows, target_os = "android", target_os = "ios", target_os = "openbsd", target_arch = "aarch64"))] mod imp { use marker; use std::cell::Cell; use sys_common::thread_local::StaticKey as OsStaticKey; #[doc(hidden)] pub struct KeyInner<T> { pub inner: OsStaticKey, pub marker: marker::PhantomData<Cell<T>>, } unsafe impl<T> ::marker::Sync for KeyInner<T> { } #[doc(hidden)] impl<T> KeyInner<T> { #[doc(hidden)] pub unsafe fn set(&self, ptr: *mut T) { self.inner.set(ptr as *mut _) } #[doc(hidden)] pub unsafe fn get(&self) -> *mut T { self.inner.get() as *mut _ } } } #[cfg(test)] mod tests { use cell::Cell; use prelude::v1::*; scoped_thread_local!(static FOO: u32); #[test] fn smoke() { scoped_thread_local!(static BAR: u32); assert!(!BAR.is_set()); BAR.set(&1, || { assert!(BAR.is_set()); BAR.with(|slot| { assert_eq!(*slot, 1); }); }); assert!(!BAR.is_set()); } #[test] fn cell_allowed() { scoped_thread_local!(static BAR: Cell<u32>); BAR.set(&Cell::new(1), || { BAR.with(|slot| { assert_eq!(slot.get(), 1); }); }); } #[test] fn scope_item_allowed() { assert!(!FOO.is_set()); FOO.set(&1, || { assert!(FOO.is_set()); FOO.with(|slot| { assert_eq!(*slot, 1); }); }); assert!(!FOO.is_set()); } } </del>

I have no idea what's causing this, but on the current nightly, this fails: with "use of unstable library feature 'threadlocalinternals'." Enabling the feature works, but this should be a stable function. Interestingly, tweaking the works: I wonder if it's because there is a (private) sub-module called which has a module-wide marker. Version info:
This change was introduced just recently: I reproduced the problem without using anything thread-related: Commands: Output: If I remove the attribute from the module, the code gives me the error. I mark as stable, then the code compiles. If I instead remove the function, I get the bar error. cc
With merged, is this fixed?
The exact issue at hand has been resolved, but the underlying issue remains. Specifically a module and free-function of the same name but different stability level will cause problems.
Also hit by this; still affecting the nightly for osx right now, but hopefully the next build will include the fix.
Stability is an internal detail. This is unlikely to impact out-of-tree code.


Question: <ins> use core::fmt; </ins> use core::iter::FusedIterator; <ins> use core::marker::PhantomData; use core::mem::{self, MaybeUninit}; </ins> use core::ptr::{self, NonNull}; <del> use core::{fmt, mem}; </del> use crate::alloc::{Allocator, Global}; <del> use super::{count, Iter, VecDeque}; </del> <ins> use super::{count, wrap_index, VecDeque}; </ins> /// A draining iterator over the elements of a `VecDeque`. ///

liballoc's fails when run in Miri. The error occurs in the call: is called with a as argument. contains contains a shared reference to a slice; that slice is thus marked as "must not be mutated for the entire duration of this function call". calls calls calls calls , which eventually drops the . calls to re-arrange stuff (I have not fully understood this yet), and in some cases this will end up writing to memory that the slice in points to. I am not sure what the best way to fix this is. We have to fix holding (indirectly) a shared reference to something that it'll mutate during its . The mutation is likely there for a reason, so I guess the shared reference has to go. (FWIW, this shared reference already caused other trouble, but that was fixed by ) Cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
yeah I guess just change it to and toss in a PhantomData for the borrow. shrug
You mean, change this in as well? Sure, that should work. In principle this reduces the precision of compiler analyses on .
ahh misread. maybe would just not use Iter then. depends on what the impl looks like now
But the first thing it does is which should exhaust the such that its is an empty slice. I suppose its pointer will still be somewhere in the deque's memory, but with length 0 it can't actually read anything. Is that not good enough to appease Miri?
No. This code still matches the pattern There is no notion of "exhausting" or "consuming" a shared reference. When you create a shared reference with a certain lifetime, you promise that until that lifetime ends, no mutation happens. here is mutable so you can change what the slice points to, but that has no effect at all on the guarantees that have been made about the value that was initially passed to . Now, lifetimes are an entirely static concept, so for Stacked Borrows a "lifetime" generally is "until the pointer is used for the last time".


Question: <ins> use core::fmt; </ins> use core::iter::FusedIterator; <ins> use core::marker::PhantomData; use core::mem::{self, MaybeUninit}; </ins> use core::ptr::{self, NonNull}; <del> use core::{fmt, mem}; </del> use crate::alloc::{Allocator, Global}; <del> use super::{count, Iter, VecDeque}; </del> <ins> use super::{count, wrap_index, VecDeque}; </ins> /// A draining iterator over the elements of a `VecDeque`. ///

However, for the special case of a reference being passed to a function, Stacked Borrows asserts that the "lifetime" will last at least as long as the function the reference is pointed to. (This is enforced by the "barriers" explained .) This is extremely useful for optimizations.
forward to . I wouldn't want to copy those.
Oh, I also didn't realize that doesn't actually shrink down to an empty slice -- it only updates its indexes. It would otherwise have to use two slices for the wrapped head and tail. So that full shared reference does still exist after the iterator is exhausted. (This also raises the validity question of having references to uninitialized data.) Could we base on instead? We could arrange to work through that mutable reference too, so there's no question of mutable aliasing.
That might work. However, must not access in that case -- that would be in conflict with the unique reference in .
Hmm, does need to be covariant over ? I guess would break that.
Actually this idea of "consuming a shared ref" is far from unique to ... the following code also errors in Miri:
As I understand it, Miri and stacked borrows should be "more powerful" than the Rust borrow checker, right? So, is this an example where Miri does not match what Rust allows or is this a bug in Rust that could lead to undefined behaviour in safe code? ()
-- I believe is admitting that example as something that should be allowed. But this issue with involves raw pointers, which rustc doesn't check at all, so miri is in uncharted waters here.
This is up for us all to decide. I can't tell you. ;) Not necessary. I have argued that / are problematic long before Stacked Borrows. The lifetimes there are, strictly speaking, wrong. I think it would be reasonable to rule that they have to use raw pointers.
FWIW here is a stand-alone version of the testcase to reproduce this with Miri (but it needs access to some private internals):
See for the issue about whether Stacked Borrows should allow such code or not. For now, with , Miri accepts this code again. So I am going to close the issue here. It still represents an interesting data point to inform what Stacked Borrows rules should be.


Question: <ins> use core::fmt; </ins> use core::iter::FusedIterator; <ins> use core::marker::PhantomData; use core::mem::{self, MaybeUninit}; </ins> use core::ptr::{self, NonNull}; <del> use core::{fmt, mem}; </del> use crate::alloc::{Allocator, Global}; <del> use super::{count, Iter, VecDeque}; </del> <ins> use super::{count, wrap_index, VecDeque}; </ins> /// A draining iterator over the elements of a `VecDeque`. ///

nods wisely just gotta stand still long enough for the spec to bend around you
;-) I don't think the decision is made either way, but for now with several counterexamples in libstd, it is not helpful for Miri to complain about this. Plus, this matches what we formalized in Coq; the basic optimizations that we considered so far are all fine with this change.
See there actually is a bug here right now, because we do emit for passed to a function. So what Miri found is actually UB in the LLVM IR that we are generating right now. Reopening for now, but maybe it makes more sense to treat this as a duplicate of
Smaller reproduction that I found in (a now closed dupe of this issue) that doesn't rely on VecDeque internals, that fails now with
re-enables the part of Stacked Borrows that got disabled (in parts) to work around the issue, before I knew that we actually have here and are risking real miscompilations.
claim


Question: use std::collections::BTreeMap; use std::env; <del> use std::fs; </del> <ins> use std::fs::{self, File}; </ins> use std::io::{self, Read, Write}; use std::path::{PathBuf, Path}; use std::process::{Command, Stdio}; <ins> use std::collections::HashMap; </ins> static HOSTS: &[&str] = &[ "aarch64-unknown-linux-gnu",

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


Question: use std::collections::BTreeMap; use std::env; <del> use std::fs; </del> <ins> use std::fs::{self, File}; </ins> use std::io::{self, Read, Write}; use std::path::{PathBuf, Path}; use std::process::{Command, Stdio}; <ins> use std::collections::HashMap; </ins> static HOSTS: &[&str] = &[ "aarch64-unknown-linux-gnu",

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


Question: use std::collections::BTreeMap; use std::env; <del> use std::fs; </del> <ins> use std::fs::{self, File}; </ins> use std::io::{self, Read, Write}; use std::path::{PathBuf, Path}; use std::process::{Command, Stdio}; <ins> use std::collections::HashMap; </ins> static HOSTS: &[&str] = &[ "aarch64-unknown-linux-gnu",

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


Question: pub mod fun_treemap; pub mod list; pub mod priority_queue; <del> pub mod rope; </del> pub mod smallintmap; pub mod sort;

In commit I had to disable one of the rope tests. The purpose of that commit was to fix up a bug in the way operator [] works on strings. In particular it used to let you index up to and including the trailing null; now it considers access to the null byte an index overrun and fails. I tried to figure out exactly what was going on in the rope code for quite a while, and tried adjusting a number of obvious-looking things, but to no avail. I'm not really good with boundary-case arithmetic (are any of us?) and the rope module is a maze of such arithmetic. Sharper minds requested to find the bug. Meanwhile I marked the rope test in question () as ignored. The others seem to work.
Paging
I'll take a look.
There is some discussion on IRC that maybe we should just pitch the rope code as it exists now.
agreed. The code is pretty outdated and the work required to modernize it would probably be similar to the work needed to just re-write it. When I was looking through it, it seemed to be doing some very strange things that I don't think are even close to being safe, so there's that too.


Question: [`std::env`]: https://doc.rust-lang.org/stable/std/env/index.html#functions [strikethrough]: https://github.github.com/gfm/#strikethrough-extension- [tables]: https://github.github.com/gfm/#tables-extension- <ins> [task list extension]: https://github.github.com/gfm/#task-list-items-extension- </ins>

These include: The reasoning for all of these extensions is that they all have wide use not just in GitHub, but in many applications of Markdown.
I'm not sure if automatically creating links from bare domain names is a good idea, so if there's an option to disable that specifically I'd suggest it. The rest all seems fine to me.
Just like said for Autolinks. I'm also not sure to see the point of the task list one. However, adding strikethrough would be nice.
Tasklist would be useful for things like this: [x] Implemented thing [x] Some other implemented thing [ ] Unimplemented thing [ ] Some other unimplemented thing or possibly in the crate root [x] Webhooks [x] Websockets [ ] Websites [ ] Other
Another noteworthy extension to implement is . This would prevent the following tags from being used for safety reasons: - - - - -
We decided in not to add this. Instead rustdoc will now suggest to turn raw links into automatic links (). So I think the only thing left is adding task list parsing.


Question: } else { // `sret` parameter thus one less integer register available arg.make_indirect(); <ins> // NOTE(eddyb) return is handled first, so no registers // should've been used yet. assert_eq!(int_regs, MAX_INT_REGS); </ins> int_regs -= 1; } } Ok(ref cls) => { // split into sized chunks passed individually <del> int_regs -= needed_int; sse_regs -= needed_sse; </del> if arg.layout.is_aggregate() { let size = arg.layout.size; arg.cast_to(cast_target(cls, size))

We encountered this with WebRender, where we exposed a method in Rust to the Gecko, and the last parameters supplied appeared random on the Rust side. I made a reduced test case adapted from it that you can grab at: It is a very simple test case where the C++ program puts all the parameters on the stack, prints the expected values of some of them, and calls the Rust method. The Rust method prints the values it received. We have enough parameters to fill up the registers used in the calling convention, and once we get to pushing things on the stack, it goes wrong. You can see from the output that they mismatch. ./build- && ./run- outputs c++ expect width=7 height=8 c++ expect slice=9 10 11 12 c++ expect outset=13. 13. 13. 13. c++ expect repeat h=0 v=0 got rust image 6 width 7 height 8 got rust slice SideOffsets { top: 9, right: 10, bottom: 11, left: 12 } got rust outset LayoutGeometry { top: 0.0, left: 0.0, width: 0.0, height: 0.0 } got rust repeat h=26 v=58 Note that the earlier parameters are correct, but the last 3 (outset, repeat h and repeat v) are all incorrect.
Is there an upstream issue in WebRender you can link? What platform is this happening on?
The Gecko side integrating with WebRender was disabled, and I have been working to re-enable this in You can find the code in question at: I intend to just work around this using structs for the moment as part of the aforementioned bug.
We're seeing this on all of our x64 platforms (win, mac, linux; all using clang). It looks like a pretty clear bug in our sysv callee ABI for x64 when there are lots of arguments.
<details<summaryrustc callee llvm-ir </summary</details<details<summaryclang caller llvm-ir </summary</detailsJust the signatures:
Note to self: can go negative from scalar integer arguments after the 6 integer registers have been exhausted and then is always true. Will try to fix soon (also I wonder if this is a stable-to-stable regression from years ago?).


Question: } else { // `sret` parameter thus one less integer register available arg.make_indirect(); <ins> // NOTE(eddyb) return is handled first, so no registers // should've been used yet. assert_eq!(int_regs, MAX_INT_REGS); </ins> int_regs -= 1; } } Ok(ref cls) => { // split into sized chunks passed individually <del> int_regs -= needed_int; sse_regs -= needed_sse; </del> if arg.layout.is_aggregate() { let size = arg.layout.size; arg.cast_to(cast_target(cls, size))

Looks like this was working circa 1.0, but has been broken at least since 1.12. Oof.
Do you need this fixed on beta as well, btw?
it would certainly be great if you uplifted this, but we have to work around it for the next few weeks anyway


Question: Err(CharTryFromError(())) } else { // SAFETY: checked that it's a legal unicode value <del> Ok(unsafe { from_u32_unchecked(i) }) </del> <ins> Ok(unsafe { transmute(i) }) </ins> } } }

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: Err(CharTryFromError(())) } else { // SAFETY: checked that it's a legal unicode value <del> Ok(unsafe { from_u32_unchecked(i) }) </del> <ins> Ok(unsafe { transmute(i) }) </ins> } } }

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: } fn run_ui_cargo(config: &mut compiletest::Config) { <ins> if cargo::is_rustc_test_suite() { return; } </ins> fn run_tests( config: &compiletest::Config, filter: &Option<String>,

The following sample crashed rustc: Removing the , or unwrapping the (leaving only ), or replacing the predicate (leaving ), solves the crash. Reproduced on Windows 64-bit, Fedora 32-bit, Ubuntu 64-bit. Full crash log (thanks to ) @ Short crash message:
Fixed pending
Fixed in


Question: } fn run_ui_cargo(config: &mut compiletest::Config) { <ins> if cargo::is_rustc_test_suite() { return; } </ins> fn run_tests( config: &compiletest::Config, filter: &Option<String>,

While I was playing with the new rustc 0.6, I encountered an internal compiler error The source code is here: Compiler version is 0.6, built with gcc, on OS X 10.7.5
If you run rustc under gdb and break on , could you paste the backtrace here?
OK. Here is the backtrace:
Looks like stack exhaustion to me. What happens if you remove ?
The code compiles with no problem when I wrap the rest of the code with mod block. Like:
This yields a proper error message now; closing.


Question: } fn run_ui_cargo(config: &mut compiletest::Config) { <ins> if cargo::is_rustc_test_suite() { return; } </ins> fn run_tests( config: &compiletest::Config, filter: &Option<String>,

When you download the 0.6 tarball and execute ./configure && make, a download occurs. and a wget info dump appears. It would be really awesome if this piece was integrated with the tarball. Not all environments are friendly to downloading arbitrary code off the net. E.g., I might be in a SCIF[1] and experimenting with Rust on a machine disconnected from the public net. Or I might be on a laptop working in a no-wifi area. :-/ (I know this is probably a real low priority issue, but it IS a (usually minor) hassle) [1]
Please note that you can avoid that if you already have a (compatible) locally installed rust compiler. Check the --local-rust and --local-rust-root parameters for ./configure. Also, I'm against bundling binaries in source tarballs. They are target-dependent and bundling all of them will make the released archive quite large. Downloading an external bootstrapper is a minor issue for downstream packagers too, though. See
far-future
Yeah, you can also just populate the directory in your builddir with an appropriate snapshot tarball. There's not much else we can do here. Putting binaries in a source tarball feels even worse, to me. Closing as I don't expect we're going to much change the requirements here and have several workable workarounds.


Question: } fn run_ui_cargo(config: &mut compiletest::Config) { <ins> if cargo::is_rustc_test_suite() { return; } </ins> fn run_tests( config: &compiletest::Config, filter: &Option<String>,

As seen in , LLVM has lots of places where it will insert calls to libm directly, not switching stacks. One of places that I recall seeing this before is the translation of the instruction. Rust has floating point modulus and presumably it is doing it in the red zone.
We can solve this with an lang item.
Is this an issue with calls to compiler-rt too? Or are they compiled in some special way to avoid the issue?
Nominating for milestone 5, production-ready
, , and are also all generated. As far as I can tell, we can't prevent it from generating these by altering the IR we output.
We can possibly be selective about when we emit memcpy/memmov, second guessing LLVM (like, never for big things)
accepted for production-ready milestone
Closing due to segmented stacks being gone (stack switches no longer a thing)


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

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