Question: let incr_comp_session_dir: PathBuf = sess.incr_comp_session_dir().clone(); <del> if sess.has_errors() { </del> <ins> if sess.has_errors_or_delayed_span_bugs() { </ins> // If there have been any errors during compilation, we don't want to // publish this session directory. Rather, we'll just delete it.

When compiling a testcase (e.g. the last snippet in on the current nightly, or any of the other examples in that issue on older compilers) with (or Cargo which does that by default), only the initial run will ICE. Subsequent runs will succeed without an ICE, in the absence of any regular errors. However, changing the relevant code (e.g. adding a space) can cause the query that calls to be recomputed and bring the ICE back. IIUC, incremental compilation stores diagnostics and replays them on subsequent runs, but that appears to not apply to ICEs. cc
It looks like without incremental we output artifacts (like ). Do we do this in case of errors too? It seems bad to produce artifacts after an ICE.
Nominating and proposing P-high (mostly because of potential annoyance factor). This should possibly also be labeled I-unsound under the assumption that under the general case of this issue, we might produce artifacts under subsequent runs that may produce UB traces. (However, it is probable that the user will notice the ICE at some other point in time and therefore discard the artifact.)
The current expected behavior of the compiler is to not save any incremental state if an error occurs. may slip through the cracks here.
In that case, it seems to me like it's a matter of recording the fact that we did a (which we already do, ) and then have this mean "there was an error" in terms of "should we save incremental state?".
Yep, the following check should also take into account: While we are at it, we could also add a similar check to and , as not to waste time producing values that will then be discarded anyway:
I'd like to start contributing to rustc and I wanted to ask if this is a good issue to start on (I have read the rustc book)
Sure, this is a decently good issue to start on and should be pretty interesting in terms of learning the infrastructure. If you get stuck, need help, and want to talk synchronously you can hop into https://rust- and we'll try to help out.
fixes this issue. It would still be good to have a test case for it.
I have started to write the code making this test possible, I'll open a PR shortly


Question: if (InstrProfileOutput) { Options.InstrProfileOutput = InstrProfileOutput; } <ins> // cargo run tests in multhreading mode by default // so use atomics for coverage counters Options.Atomic = true; </ins> MPM.addPass(InstrProfiling(Options, false)); } );

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I have a large-ish project with ~6000 testcases, and for a long time now, code coverage has been hit-or-miss. The issue is that some of the test cases don't seem to get their data included in the files, and so don't show up as having an effect on coverage. The unrecorded tests seem to be essentially random, but with thousands of tests, single-digit-percentage failures are noticed on every test run. It's been annoying. So I finally sat down to try and reduce to a simplest error, but it still takes multiple files, so is difficult to include inline in a GitHub issue. The tree: When I run a test via: which shows 2 tests run: Then report on that particular function via: Most of the time, I see the correct result: But sometimes (about 1 in 170 times), I see this: It seems to be related to having multiple source files; I could not get similar behavior with only a . I've seen the problem appear on both MacOS (Mohave) and on Windows (in Windows Subsystem for Linux 2) The two-source-file tree mentioned up above (including the script I run to repeat the test until a failure happens), is on a bug-report branch here: This really feels like whichever thread is controlling writes to the file is missing messages. Queue overrun maybe? (I haven't looked.) <!-- 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. --:
label A-code-coverage
I see you are using the placeholder for the profile file, which talks about locking and merging these files at runtime. Maybe adding the PID placeholder as well might avoid conflicts here. Can you give that a try?
Gave it a try; still exhibits the same behavior.
is definitely an indication to "please merge"; and doesn't do that, but is really about processes, not threads. I suspect whatever is doing the merging of thread data is what's got the issue here. (Though I get the same effect when I tell the test runner to just use one thread, as well.)


Question: if (InstrProfileOutput) { Options.InstrProfileOutput = InstrProfileOutput; } <ins> // cargo run tests in multhreading mode by default // so use atomics for coverage counters Options.Atomic = true; </ins> MPM.addPass(InstrProfiling(Options, false)); } );

Just learned that the option of is not the same thing as (which sends that flag to the test-runner). Adding to my harness removes the intermittent results. Not closing this issue, though. Rust is supposed to be "fearless concurrency" so this should work correctly even if the test runner is using multiple threads.
Still reproducible with I used such script to run against , because of I can not find : at step 854, coverage changed from 4 to 2.
This is in cargo-binutils.
I created bug against upstream llvm/llvm-project
Looks like this is not llvm bug. There is bool flag , that is by default, and depend on it llvm generates different code: So if set it to true via option , then C++ variant of test is unable to reproduce problem. So is any way to set via rustc command line?
or another atomic-counter flag may work, but I have not tested it yet.
I can not see how any of this options can reach here . So I create PR to set to by default.
Looks like should also works. where


Question: <del> Subproject commit 99faef833f890fe89f1a959d89b951954118828b </del> <ins> Subproject commit e9da96eb452aa65e79e2342be700544afe509440 </ins>

At various points, rustc may use to get a backtrace of the current thread such as if or similar functions are called. On Windows, this results in attempting to load the hardcoded path of rustc's PDB which, on normal user machines, never exists. Normally, this is fine and we just simply don't have debug symbols, but in some environments like build systems such as , filesystem accesses are monitored to enable fine-grained caching. If we try to load rustc's PDB in this environment, it will trigger build system errors: Since these paths won't generally resolve (unless you build rustc from source with debuginfo yourself), it would be nice to provide a way to turn this behavior off.
Modifying this to focus specifically on the behavior of as trying to load PDBs during an ICE isn't actually problematic for the stated use case.


Question: ty::TypeScheme { ty: ty, generics: ty_generics } } hir::ItemTy(ref t, ref generics) => { <del> let ty_generics = ty_generics_for_type_or_impl(ccx, generics); </del> <ins> let ty_generics = ty_generics_for_type(ccx, generics); </ins> let ty = ccx.icx(generics).to_ty(&ExplicitRscope, &t); ty::TypeScheme { ty: ty, generics: ty_generics } } hir::ItemEnum(ref ei, ref generics) => { <del> let ty_generics = ty_generics_for_type_or_impl(ccx, generics); </del> <ins> let ty_generics = ty_generics_for_type(ccx, generics); </ins> let substs = mk_item_substs(ccx, &ty_generics); let def = convert_enum_def(tcx, it, ei); let t = tcx.mk_enum(def, tcx.mk_substs(substs)); ty::TypeScheme { ty: t, generics: ty_generics } } hir::ItemStruct(ref si, ref generics) => { <del> let ty_generics = ty_generics_for_type_or_impl(ccx, generics); </del> <ins> let ty_generics = ty_generics_for_type(ccx, generics); </ins> let substs = mk_item_substs(ccx, &ty_generics); let def = convert_struct_def(tcx, it, si); let t = tcx.mk_struct(def, tcx.mk_substs(substs));

If I understand correctly, type parameter defaults have no effect in the block . Just like in PR , this should have a warning and then an error. Example cc
Argh, I guess I failed to cover those?
Nominating for triage.
triage: P-high


Question: <ins> error: character literal may only contain one codepoint --> $DIR/issue-64732.rs:3:17 | LL |     let _foo = b'hello0'; |                 ^^^^^^^^^ help: if you meant to write a byte string literal, use double quotes | LL |     let _foo = b"hello0"; |                 ^^^^^^^^^ error: character literal may only contain one codepoint --> $DIR/issue-64732.rs:6:16 | LL |     let _bar = 'hello'; |                ^^^^^^^ help: if you meant to write a `str` literal, use double quotes | LL |     let _bar = "hello"; |                ^^^^^^^ error: aborting due to 2 previous errors </ins>

When creating a byte literal with single quotes, like , The error message says: But following the directions would not give us a literal, it would give a literal.
This should be easy to fix, by replacing the message with: when the literal is prefixed by . You may need to see work out which call is originating from (in ) to pass information about the nature of the literal.
Can I work on this?
go ahead! :) Let me know if you have any questions.
Hi, I have been doing some work in this issue, cause this is the first time I'm sending PR to rust, can you give me some feedback. Thanks!


Question: // aux-build:sepcomp_lib.rs // compile-flags: -C lto // no-prefer-dynamic <ins> // ignore-android FIXME #18800 </ins> extern crate sepcomp_lib; use sepcomp_lib::a::one;

The test run-pass/sepcomp-lib- can fail on android apparently due to the fact that a pthread shim dependency is present in libstd (as part of librust_builtin), but it stripped out early. It may be possible to work around this by moving the dependency into liballoc instead, but a more thorough examination is needed.
cc
The problem here on android was as follows: jemalloc requires the symbol, which android does not provide. jemalloc is also statically linked to liballoc We provide a dummy definition of in , which is assembled into and is statically linked to . When building with LTO, we remove all rust-generated code from an rlib (it's all in the LTO object), but we still link the rlib. When linking, we pass libstd's rlib first, then liballoc's rlib on the command line. The linker detects that we're not using any symbols from the libstd's rlib by the time its reached on the command line (scans from left-to-right) because we actually aren't using any symbols from or any other objects in the archive. The linker then strips from the linkage step, which then later yields an unresolved reference. The solution here is to break apart to be less of a conglomerate and instead link specific symbols to specific libraries wherever necessary. For example all of the time-related functionality should be a lib linked directly to , not to . In this example we need to link the symbol directly to , not to , because is not the one that needs it. Just some general cleanup, most things should still work as advertised!
Triage: this test is still ignored on android, but I don't know what is nowadays.
! So I guess this can be closed, but should we check if the affected test was actually fixed?
Yeah I think this is all taken care of, so closing.


Question: path.push(id); } let path = ast::Path { <del> span: mk_sp(lo, self.span.hi), </del> <ins> span: mk_sp(path_lo, self.span.hi), </ins> global: false, segments: path.move_iter().map(|identifier| { ast::PathSegment {

For 'use' items of the form . [I don't see how to assign this to myself, but I have a patch which I will make into a PR soon]


Question: --lldb-python $$(CFG_LLDB_PYTHON)  --gdb-version="$(CFG_GDB_VERSION)"  --lldb-version="$(CFG_LLDB_VERSION)"  <ins> --llvm-version="$$(LLVM_VERSION_$(3))"  </ins> --android-cross-path=$(CFG_ARM_LINUX_ANDROIDEABI_NDK)  --adb-path=$(CFG_ADB)  --adb-test-dir=$(CFG_ADB_TEST_DIR)

I believe this is due to travis using system llvm which misses the fix backported in . cc
Can we do anything about this?
Our best bet is to add a for tests, I think (alternative is to drop support for LLVM pre 3.9, which would be a shame, even if its buggy in certain cases). Implementation of such directive could be implemented by injecting an environment variable or some such (done ) and checking for that in
There's no need to set an extra environment variable, just check if is set (or if you're boring :wink: )
but… but… what if people have on their own systems too?
cc
no we do not have existing infrastructure for this. I'd prefer to avoid as that's not the relevant piece here, but rather something like or . Distros or anyone else building with an older LLVM are likely to hit this and we'd need a solution for them as well. That being said I think it's fine to temporarily disable the test until we get that. There's basically a 0% chance of us regressing that test as it's just an LLVM bug, and they already have a regression test upstream as well.
Another option would be to create a base Docker image (publishing it to Docker Hub) that is just and the appropriate steps to build whatever version of LLVM we want.
We currently advertise ourselves as supporting LLVM 3.7+, and Travis is kinda our test for that, so I'd prefer to not pull that forward just yet (but instead just fix this)
For the record, I downgraded our LLVM version in a botched rebase and only this test stopped it at bors. Hopefully, someone would have noticed the absence of a fix, but you can't count of that.
touche!


Question: <ins> // Regression test of #43913. // run-rustfix #![feature(trait_alias)] #![allow(bare_trait_objects, dead_code)] type Strings = Iterator<Item=String>; struct Struct<S: Strings>(S); //~^ ERROR: expected trait, found type alias `Strings` fn main() {} </ins>

I managed to reproduce the problem with this snippet: The compiler yells E0404 at me, but fair enough I always ask it to a bit more about it :) However this time, it only says this: This is confusing because the snippet above doesn't involve the keyword so I didn't understand initially what I was doing wrong, then I read the error message again: I first tried this, and it worked, but having to repeat the whole syntax everywhere wasn't too compelling, hence the alias: The compiler error message makes it very clear that I can't alias a trait, but the E0404 explanation doesn't mention it at all. I hope the description could also include this use case as I've seen sometimes EXXXX explanations go over several facets of the same problem. That won't help me, but maybe others that may trip on the same problem. I would have submitted a pull request for the docs myself, but I have no idea why you can't use type aliases for traits so I can't it ;) I'm using stable Rust 1.19.0 (on Fedora).
One more thing, even though the compiler lets me create an alias for a trait, I don't know when I can use such an alias. Maybe this should be explained too.
Current output (in nightly):
Current output: No structured suggestion for the nightly feature (should be and the feature flag).


Question: buffer: String, } <ins> impl core::fmt::Write for Buffer { #[inline] fn write_str(&mut self, s: &str) -> fmt::Result { self.buffer.write_str(s) } #[inline] fn write_char(&mut self, c: char) -> fmt::Result { self.buffer.write_char(c) } #[inline] fn write_fmt(self: &mut Self, args: fmt::Arguments<'_>) -> fmt::Result { self.buffer.write_fmt(args) } } </ins> impl Buffer { crate fn empty_from(v: &Buffer) -> Buffer { Buffer { for_html: v.for_html, buffer: String::new() }

A further performance improvement here would be to make sure that impls , in which case we could use rather than , avoiding the allocation of a temporary here. internally seems to just hold a and it has and methods already, so perhaps it would make sense to implement that trait? I'm not sure how big/relevant the performance improvement would be. Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Since implementers get a generated for them by Askama's macro, the simpler way to get the meat of this change would probably be to call
claim Let me take a stab at it :)


Question: <ins> // compile-pass // edition:2018 // // Tests that we properly handle StorageDead/StorageLives for temporaries // created in async loop bodies. #![feature(async_await)] async fn bar() -> Option<()> { Some(()) } async fn listen() { while let Some(_) = bar().await { String::new(); } } fn main() { listen(); } </ins>

Attempting to shim futures-preview Stream to a tokio futures 0.1 Stream results in ICE when done this way. Most minimal example I can give
Minimized:
The ICE goes away if you assign (or whatever type you create in the loop body) to a variable. Looking at the generated MIR, it seems that we never emit / statements for the temporary created by the statement, leading later analysis to incorrectly conclude that it lives across a yield point.
I believe this will be fixed by
This is indeed fixed-- I've opened with a regression test.


Question: enum Enum1 { Variant1(isize), <del> Variant2 //~ ERROR: variant is never used </del> <ins> Variant2 //~ ERROR: variant is never constructed </ins> } enum Enum2 { Variant3(bool), #[allow(dead_code)] Variant4(isize), <del> Variant5 { _x: isize }, //~ ERROR: variant is never used: `Variant5` Variant6(isize), //~ ERROR: variant is never used: `Variant6` </del> <ins> Variant5 { _x: isize }, //~ ERROR: variant is never constructed: `Variant5` Variant6(isize), //~ ERROR: variant is never constructed: `Variant6` </ins> _Variant7, }

I was changing some code from integer constants to a proper enum and was greeted by the following warning: The warning sounded weird to me because I was pattern-matching on that damn variant in various places of the code; but I was pointed out to the fact that I wasn't actually creating that value. Maybe the warning should be rewritten to explicitly mention value creation? Cc
cc that looks like your thing
duplicate of
Yup! Closing in favor of that.


Question: <ins> // Copyright 2014 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. // Test that type IDs correctly account for higher-rank lifetimes // Also acts as a regression test for an ICE (issue #19791) #![feature(unboxed_closures)] use std::intrinsics::TypeId; fn main() { // Bare fns { let a = TypeId::of::<fn(&'static int, &'static int)>(); let b = TypeId::of::<for<'a> fn(&'static int, &'a int)>(); let c = TypeId::of::<for<'a, 'b> fn(&'a int, &'b int)>(); let d = TypeId::of::<for<'a, 'b> fn(&'b int, &'a int)>(); assert!(a != b); assert!(a != c); assert!(a != d); assert!(b != c); assert!(b != d); assert_eq!(c, d); // Make sure De Bruijn indices are handled correctly let e = TypeId::of::<for<'a> fn(fn(&'a int) -> &'a int)>(); let f = TypeId::of::<fn(for<'a> fn(&'a int) -> &'a int)>(); assert!(e != f); } // Stack closures { let a = TypeId::of::<|&'static int, &'static int|>(); let b = TypeId::of::<for<'a> |&'static int, &'a int|>(); let c = TypeId::of::<for<'a, 'b> |&'a int, &'b int|>(); let d = TypeId::of::<for<'a, 'b> |&'b int, &'a int|>(); assert!(a != b); assert!(a != c); assert!(a != d); assert!(b != c); assert!(b != d); assert_eq!(c, d); // Make sure De Bruijn indices are handled correctly let e = TypeId::of::<for<'a> |(|&'a int| -> &'a int)|>(); let f = TypeId::of::<|for<'a> |&'a int| -> &'a int|>(); assert!(e != f); } // Boxed unboxed closures { let a = TypeId::of::<Box<Fn(&'static int, &'static int)>>(); let b = TypeId::of::<Box<for<'a> Fn(&'static int, &'a int)>>(); let c = TypeId::of::<Box<for<'a, 'b> Fn(&'a int, &'b int)>>(); let d = TypeId::of::<Box<for<'a, 'b> Fn(&'b int, &'a int)>>(); assert!(a != b); assert!(a != c); assert!(a != d); assert!(b != c); assert!(b != d); assert_eq!(c, d); // Make sure De Bruijn indices are handled correctly let e = TypeId::of::<Box<for<'a> Fn(Box<Fn(&'a int) -> &'a int>)>>(); let f = TypeId::of::<Box<Fn(Box<for<'a> Fn(&'a int) -> &'a int>)>>(); assert!(e != f); } // Raw unboxed closures // Note that every unboxed closure has its own anonymous type, // so no two IDs should equal each other, even when compatible { let a = id(|&: _: &int, _: &int| {}); let b = id(|&: _: &int, _: &int| {}); assert!(a != b); } fn id<T:'static>(_: T) -> TypeId { TypeId::of::<T>() } } </ins>

Backtrace:
Well, this is interesting. It's broken all the way back to 0.10. I think it's been a bug in the type id implementation since it first landed. Here's a smaller test case:
is there a particular reason explicitly checks that all regions it encounters are ? Trans doesn't seem to go out of its way to erase late-bound regions in fn type signatures, which results in this ICE. I could add a call to in trans to fix this, but it would be cheaper to just ignore regions during hashing.
Ended up catching me
It seems we actually want to take late-bound regions into account when hashing. For example, the following should hold:


Question:
if !non_trait.is_empty() { let render_mode = match what { AssocItemRender::All => {  write!(w, "
Methods
")?;   write!(w, "
 Methods
 ")?;  RenderMode::Normal } AssocItemRender::DerefFor { trait_, type_, deref_mut_ } => {  write!(w, "
Methods from  {}<Target = {}>
", trait_, type_)?;   write!(w, "
 Methods from {}<Target = {}>
 ", trait_, type_)?;  RenderMode::ForDeref { mut_: deref_mut_ } } };

A page like has many things that could be useful to link to. These should be possible to link to by clicking on: [x] The header [x] 's on a page. [x] at the top On it's hit or miss: [x] Examples [x] Associated Types [x] Required Methods [x] Implementors On [x] Provided Methods I don't have any big use cases but when I want to link to these for something like this bug I can't link to any specific line. I gotta say go to vec page, scroll 75% to bottom. Squint hard to see it.
Just ran into this today; I'd really like to have links from the impls in the Implementors section to the source containing the impl.
Triage: we always need more links....
Update: Headers written in docs and (most) auto-generated headers are either fully hyperlinked or have a "section marker" symbol that shows up on hover. Major auto-generated page headers have links in the top of the sidebar of the page. Impl blocks do not have hyperlinks (yet); that's
Since got merged and closed out , that was the last major request on this issue, so i'll close this out. If you think of something else that needs a hyperlinked header, feel free to open a new issue or reopen this one.


Question: <del> Subproject commit 7799d03de85bcc1a7437f65d4f7adfbb267d2acb </del> <ins> Subproject commit 79d659e5699fbf7db5b4819e9a442fb3f550472a </ins>

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


Question: _ => {} } } <ins> // Similar to operators, indexing is always assumed to be overloaded // Here, correct cases where an indexing expression can be simplified // to use builtin indexing because the index type is known to be // usize-ish fn fix_index_builtin_expr(&mut self, e: &hir::Expr) { if let hir::ExprIndex(ref base, ref index) = e.node { let mut tables = self.fcx.tables.borrow_mut(); match tables.expr_ty_adjusted(&base).sty { // All valid indexing looks like this ty::TyRef(_, ty::TypeAndMut { ty: ref base_ty, .. }) => { let index_ty = tables.expr_ty_adjusted(&index); let index_ty = self.fcx.resolve_type_vars_if_possible(&index_ty); if base_ty.builtin_index().is_some() && index_ty == self.fcx.tcx.types.usize { // Remove the method call record tables.type_dependent_defs_mut().remove(e.hir_id); tables.node_substs_mut().remove(e.hir_id); tables.adjustments_mut().get_mut(base.hir_id).map(|a| { // Discard the need for a mutable borrow match a.pop() { // Extra adjustment made when indexing causes a drop // of size information - we need to get rid of it // Since this is "after" the other adjustment to be // discarded, we do an extra `pop()` Some(Adjustment { kind: Adjust::Unsize, .. }) => { // So the borrow discard actually happens here a.pop(); }, _ => {} } }); } }, // Might encounter non-valid indexes at this point, so there // has to be a fall-through _ => {}, } } } </ins> } /////////////////////////////////////////////////////////////////////////// // Impl of Visitor for Resolver //

Hello, today we've found some weird behaviour of array indexing. Here is the Code snippet: The question is, why is the indexing operator behaves depending on whether we evaluate in place or not.
Highly related question :
Moreover, does not compile too.
points to this being a difference in how builtin indexing works vs overloaded indexing. My cleaned up version of the transcript: Highly related to , which will cause these types of situations to occur more frequently.
As a workaround, you can write an explicit type of which will then allow builtin indexing to happen:


Question: _ => {} } } <ins> // Similar to operators, indexing is always assumed to be overloaded // Here, correct cases where an indexing expression can be simplified // to use builtin indexing because the index type is known to be // usize-ish fn fix_index_builtin_expr(&mut self, e: &hir::Expr) { if let hir::ExprIndex(ref base, ref index) = e.node { let mut tables = self.fcx.tables.borrow_mut(); match tables.expr_ty_adjusted(&base).sty { // All valid indexing looks like this ty::TyRef(_, ty::TypeAndMut { ty: ref base_ty, .. }) => { let index_ty = tables.expr_ty_adjusted(&index); let index_ty = self.fcx.resolve_type_vars_if_possible(&index_ty); if base_ty.builtin_index().is_some() && index_ty == self.fcx.tcx.types.usize { // Remove the method call record tables.type_dependent_defs_mut().remove(e.hir_id); tables.node_substs_mut().remove(e.hir_id); tables.adjustments_mut().get_mut(base.hir_id).map(|a| { // Discard the need for a mutable borrow match a.pop() { // Extra adjustment made when indexing causes a drop // of size information - we need to get rid of it // Since this is "after" the other adjustment to be // discarded, we do an extra `pop()` Some(Adjustment { kind: Adjust::Unsize, .. }) => { // So the borrow discard actually happens here a.pop(); }, _ => {} } }); } }, // Might encounter non-valid indexes at this point, so there // has to be a fall-through _ => {}, } } } </ins> } /////////////////////////////////////////////////////////////////////////// // Impl of Visitor for Resolver //

It appears that when it's not obvious the index type is , we fall back to overloaded indexing: Fails in constant checking, : And also with the new MIR-based constant checker, :


Question: Err(err) } <ins> /// Try to recover from an unbraced const argument whose first token [could begin a type][ty]. /// /// [ty]: token::Token::can_begin_type pub(crate) fn recover_unbraced_const_arg_that_can_begin_ty( &mut self, mut snapshot: SnapshotParser<'a>, ) -> Option<P<ast::Expr>> { match snapshot.parse_expr_res(Restrictions::CONST_EXPR, None) { // Since we don't know the exact reason why we failed to parse the type or the // expression, employ a simple heuristic to weed out some pathological cases. Ok(expr) if let token::Comma | token::Gt = snapshot.token.kind => { self.restore_snapshot(snapshot); Some(expr) } Ok(_) => None, Err(err) => { err.cancel(); None } } } </ins> /// Creates a dummy const argument, and reports that the expression must be enclosed in braces pub fn dummy_const_arg_needs_braces( &self,

<!-- 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. --This is a much abbreviated version of the code from my experiments with adding a shuffle API to the stdsimd repo, it probably needs further reduction but I wanted to file this before I forgot: I expected to see this happen: it works, provides a useful error, or even just ICEs. Instead, this happened: I got a request to input a type instead! And no, that doesn't work either if you put it in, because instead you get: : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The fix is Due to parsing ambiguities generic arguments currently need to be put into braces, unless they are really simple (like or ), is not simple enough.
Oh, cool! That does compile! I knew about that but wasn't sure if that was the problem because I thought that was just for expressions? I guess that's technically an array expression? That is none of the errors I was presented with, though, which makes this a diagnostics problem I suppose?
I believe diagnostic for const generic (example taken from ) needs to be improved too before release, at least I thought that can be used instead, if one didn't know about then they need to search it up.
Arrays as const parameters still have bad error messages. same with tuples
claim


Question: referent_ty: Ty<'tcx>) -> Rc<ty::TraitRef<'tcx>> { <ins> // We can only make objects from sized types. let sized_obligation = traits::obligation_for_builtin_bound( fcx.tcx(), traits::ObligationCause::new(span, traits::ObjectSized), referent_ty, ty::BoundSized); match sized_obligation { Ok(sized_obligation) => { fcx.register_obligation(sized_obligation); } Err(ErrorReported) => { } } </ins> // This is just for better error reporting. Kinda goofy. The object type stuff // needs some refactoring so there is a more convenient type to pass around. let object_trait_ty =

cc
cc too, presumably a consequence of the trait reform/new vtable lookup code
Hmm, yes. Probably we can fix this by just...allowing it to skolemize an open existential type. I just didn't expect this to ever happen.
actually, while debugging this I remembered that it is not possible to make an object out of an unsized type. We need to add a check for this I guess!
Explanation from PR: In the general case, at least, it is not possible to make an object out of an unsized type. This is because the object type would have to store the fat pointer information for the self value and the vtable -- meaning it'd have to be a fat pointer with three words -- but for the compiler to know that the object requires three words, it would have to know the self-type of the object (is self a thin or fat pointer?), which of course it doesn't.


Question: ))), ) } <del> ty::CoroutineClosure(did, _args) => { // FIXME(async_closures): Recover the proper error signature let inputs = tcx .closure_user_provided_sig(did.expect_local()) .value .skip_binder() .inputs(); let err = Ty::new_error(tcx, guar); (inputs.iter().map(|_| err).collect(), err, None) </del> <ins> ty::CoroutineClosure(did, args) => { let args = args.as_coroutine_closure(); let sig = tcx.liberate_late_bound_regions( def_id.to_def_id(), args.coroutine_closure_sig(), ); let self_ty = match args.kind() { ty::ClosureKind::Fn => { Ty::new_imm_ref(tcx, tcx.lifetimes.re_erased, closure_ty) } ty::ClosureKind::FnMut => { Ty::new_mut_ref(tcx, tcx.lifetimes.re_erased, closure_ty) } ty::ClosureKind::FnOnce => closure_ty, }; ( [self_ty].into_iter().chain(sig.tupled_inputs_ty.tuple_fields()).collect(), sig.to_coroutine( tcx, args.parent_args(), args.kind_ty(), tcx.coroutine_for_closure(*did), Ty::new_error(tcx, guar), ), None, ) </ins> } ty::Error(_) => (vec![closure_ty, closure_ty], closure_ty, None), kind => {

<!-- ICE: Rustc '-Zvalidate-mir -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: unexpected body ty: {type error} phase Runtime(PostCleanup)', 'error: internal compiler error: unexpected body ty: {type error} phase Runtime(PostCleanup)' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [mirdropselaboratedandconstchecked] elaborating drops for [analysis] running analysis passes on this crate --
cc :D (note you'll need which was merged 10 minutes ago ^^ )


Question: ))), ) } <del> ty::CoroutineClosure(did, _args) => { // FIXME(async_closures): Recover the proper error signature let inputs = tcx .closure_user_provided_sig(did.expect_local()) .value .skip_binder() .inputs(); let err = Ty::new_error(tcx, guar); (inputs.iter().map(|_| err).collect(), err, None) </del> <ins> ty::CoroutineClosure(did, args) => { let args = args.as_coroutine_closure(); let sig = tcx.liberate_late_bound_regions( def_id.to_def_id(), args.coroutine_closure_sig(), ); let self_ty = match args.kind() { ty::ClosureKind::Fn => { Ty::new_imm_ref(tcx, tcx.lifetimes.re_erased, closure_ty) } ty::ClosureKind::FnMut => { Ty::new_mut_ref(tcx, tcx.lifetimes.re_erased, closure_ty) } ty::ClosureKind::FnOnce => closure_ty, }; ( [self_ty].into_iter().chain(sig.tupled_inputs_ty.tuple_fields()).collect(), sig.to_coroutine( tcx, args.parent_args(), args.kind_ty(), tcx.coroutine_for_closure(*did), Ty::new_error(tcx, guar), ), None, ) </ins> } ty::Error(_) => (vec![closure_ty, closure_ty], closure_ty, None), kind => {

<!-- ICE: Rustc '--edition=2021 -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: impossible case reached', 'error: internal compiler error: impossible case reached' File: --auto-reduced (treereduce-rust): <details<summary<strongoriginal code</strong</summary<poriginal: </p</detailsVersion information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [mirconst] preparing for borrow checking [mirpromoted] promoting constants in MIR for [mir_borrowck] borrow-checking [analysis] running analysis passes on this crate --
cc


Question: pub is_cleanup: bool, } <del> #[derive(Clone, Debug, RustcEncodable, RustcDecodable, HashStable)] pub struct Terminator<'tcx> { pub source_info: SourceInfo, pub kind: TerminatorKind<'tcx>, } #[derive(Clone, RustcEncodable, RustcDecodable, HashStable, PartialEq)] pub enum TerminatorKind<'tcx> { /// Block should have one successor in the graph; we jump there. Goto { target: BasicBlock }, /// Operand evaluates to an integer; jump depending on its value /// to one of the targets, and otherwise fallback to `otherwise`. SwitchInt { /// The discriminant value being tested. discr: Operand<'tcx>, /// The type of value being tested. /// This is always the same as the type of `discr`. /// FIXME: remove this redundant information. Currently, it is relied on by pretty-printing. switch_ty: Ty<'tcx>, /// Possible values. The locations to branch to in each case /// are found in the corresponding indices from the `targets` vector. values: Cow<'tcx, [u128]>, /// Possible branch sites. The last element of this vector is used /// for the otherwise branch, so targets.len() == values.len() + 1 /// should hold. // // This invariant is quite non-obvious and also could be improved. // One way to make this invariant is to have something like this instead: // // branches: Vec<(ConstInt, BasicBlock)>, // otherwise: Option<BasicBlock> // exhaustive if None // // However we’ve decided to keep this as-is until we figure a case // where some other approach seems to be strictly better than other. targets: Vec<BasicBlock>, }, /// Indicates that the landing pad is finished and unwinding should /// continue. Emitted by `build::scope::diverge_cleanup`. Resume, /// Indicates that the landing pad is finished and that the process /// should abort. Used to prevent unwinding for foreign items. Abort, /// Indicates a normal return. The return place should have /// been filled in before this executes. This can occur multiple times /// in different basic blocks. Return, /// Indicates a terminator that can never be reached. Unreachable, /// Drop the `Place`. Drop { place: Place<'tcx>, target: BasicBlock, unwind: Option<BasicBlock> }, /// Drop the `Place` and assign the new value over it. This ensures /// that the assignment to `P` occurs *even if* the destructor for /// place unwinds. Its semantics are best explained by the /// elaboration: /// /// ``` /// BB0 { ///   DropAndReplace(P <- V, goto BB1, unwind BB2) /// } /// ``` /// /// becomes /// /// ``` /// BB0 { ///   Drop(P, goto BB1, unwind BB2) /// } /// BB1 { ///   // P is now uninitialized ///   P <- V /// } /// BB2 { ///   // P is now uninitialized -- its dtor panicked ///   P <- V /// } /// ``` DropAndReplace { place: Place<'tcx>, value: Operand<'tcx>, target: BasicBlock, unwind: Option<BasicBlock>, }, /// Block ends with a call of a converging function. Call { /// The function that’s being called. func: Operand<'tcx>, /// Arguments the function is called with. /// These are owned by the callee, which is free to modify them. /// This allows the memory occupied by "by-value" arguments to be /// reused across function calls without duplicating the contents. args: Vec<Operand<'tcx>>, /// Destination for the return value. If some, the call is converging. destination: Option<(Place<'tcx>, BasicBlock)>, /// Cleanups to be done if the call unwinds. cleanup: Option<BasicBlock>, /// `true` if this is from a call in HIR rather than from an overloaded /// operator. True for overloaded function call. from_hir_call: bool, /// This `Span` is the span of the function, without the dot and receiver /// (e.g. `foo(a, b)` in `x.foo(a, b)` fn_span: Span, }, /// Jump to the target if the condition has the expected value, /// otherwise panic with a message and a cleanup target. Assert { cond: Operand<'tcx>, expected: bool, msg: AssertMessage<'tcx>, target: BasicBlock, cleanup: Option<BasicBlock>, }, /// A suspend point. Yield { /// The value to return. value: Operand<'tcx>, /// Where to resume to. resume: BasicBlock, /// The place to store the resume argument in. resume_arg: Place<'tcx>, /// Cleanup to be done if the generator is dropped at this suspend point. drop: Option<BasicBlock>, }, /// Indicates the end of the dropping of a generator. GeneratorDrop, /// A block where control flow only ever takes one real path, but borrowck /// needs to be more conservative. FalseEdge { /// The target normal control flow will take. real_target: BasicBlock, /// A block control flow could conceptually jump to, but won't in /// practice. imaginary_target: BasicBlock, }, /// A terminator for blocks that only take one path in reality, but where we /// reserve the right to unwind in borrowck, even if it won't happen in practice. /// This can arise in infinite loops with no function calls for example. FalseUnwind { /// The target normal control flow will take. real_target: BasicBlock, /// The imaginary cleanup block link. This particular path will never be taken /// in practice, but in order to avoid fragility we want to always /// consider it in borrowck. We don't want to accept programs which /// pass borrowck only when `panic=abort` or some assertions are disabled /// due to release vs. debug mode builds. This needs to be an `Option` because /// of the `remove_noop_landing_pads` and `no_landing_pads` passes. unwind: Option<BasicBlock>, }, /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly, with placeholders. template: &'tcx [InlineAsmTemplatePiece], /// The operands for the inline assembly, as `Operand`s or `Place`s. operands: Vec<InlineAsmOperand<'tcx>>, /// Miscellaneous options for the inline assembly. options: InlineAsmOptions, /// Source spans for each line of the inline assembly code. These are /// used to map assembler errors back to the line in the source code. line_spans: &'tcx [Span], /// Destination block after the inline assembly returns, unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option<BasicBlock>, }, } </del> /// Information about an assertion failure. #[derive(Clone, RustcEncodable, RustcDecodable, HashStable, PartialEq)] pub enum AssertKind<O> {

moved the file to over 3k LOC, but I didn't fix it there and instead just annotated the file so tidy ignores it. We should probably split the mir types into separate submodules by the way they are used in MIR. I think we can start by pulling out e.g. terminators and all their sub-types to a submodule <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim Will be interested in picking this up


Question: }; (respan(self.prev_span, Constness::NotConst), unsafety, abi) }; <del> self.expect_keyword(keywords::Fn)?; </del> <ins> if !self.eat_keyword(keywords::Fn) { // It is possible for `expect_one_of` to recover given the contents of // `self.expected_tokens`, therefore, do not use `self.unexpected()` which doesn't // account for this. if !self.expect_one_of(&[], &[])? { unreachable!() } } </ins> Ok((constness, unsafety, asyncness, abi)) }

I got an internal compiler error while compiling some code with a syntax error. The error is in the final line of the match statement in the function parse. () Errors:
triage: P-high. (Unnominating since there doesn't seem to be much else to discuss)
Assigning myself to look into and fix.
:
this ICE only happens for already broken code, I don't believe this is P-high.


Question: <ins> // build-pass pub trait Foo { type FooAssoc; } pub struct Bar<F: Foo> { id: F::FooAssoc } pub struct Baz; impl Foo for Baz { type FooAssoc = usize; } static mut MY_FOO: Bar<Baz> = Bar { id: 0 }; fn main() {} </ins>

These two code snippets should functionally be doing the same thing, but the type checker seems to think one has a destructor. The difference seems to be in the reliance on an associated type. complains that cannot be declared a mutable static because it has a desctructor: While this, unsurprisingly, works: Here are links to non-compiling/compiling examples on non-working: working:
( expressed interest in working on this, I will mentor.)
Triage: still relevant.
I'm still interested in helping to fix this. you mentioned at one point that you had a hunch for where the problem was. Perhaps a pointer would be enough to get the ball rolling?
Hmm. So, the error is emitted by the "constant qualification" code, which walks the MIR for generating a constant value and looks for things that should be disallowed. One of those things is the creation of a struct which has a destructor. This code is in . I think where I would start is trying to insert some to track out exactly what is happening. My guess would be that we are walking down , but I'm actually not sure. cc author of the code in question
It might be the type contents, if we use them for "needs drop". Aren't they conservative wrt projections?
that was my first assumption, that it was something like that. When I was poking about in the code I didn't see the place where we branch into that, but maybe I just wasn't reading very carefully.
which references . cc This could at least try to normalize projections, which would fix the problem here. Btw we can now remove "type contents" and replace it with two cached flags ( & needs-drop).
This doesn't seem to be an issue anymore. Running the provided "non-working" code doesn't trigger a compiler error.
Indeed, this not longer seems to be an issue. Happy to close the issue :)
Should we add a regression test first?


Question: <del> #![feature(fn_traits, unboxed_closures)] fn test<F: for<'x> FnOnce<(&'x str,)>>(_: F) {} struct Compose<F,G>(F,G); impl<T,F,G> FnOnce<(T,)> for Compose<F,G> where F: FnOnce<(T,)>, G: FnOnce<(F::Output,)> { type Output = G::Output; extern "rust-call" fn call_once(self, (x,): (T,)) -> G::Output { (self.1)((self.0)(x)) } } struct Str<'a>(&'a str); fn mk_str<'a>(s: &'a str) -> Str<'a> { Str(s) } fn main() { let _: for<'a> fn(&'a str) -> Str<'a> = mk_str; // expected concrete lifetime, found bound lifetime parameter 'a let _: for<'a> fn(&'a str) -> Str<'a> = Str; //~^ ERROR: mismatched types test(|_: &str| {}); test(mk_str); // expected concrete lifetime, found bound lifetime parameter 'x test(Str); //~ ERROR: type mismatch in function arguments test(Compose(|_: &str| {}, |_| {})); test(Compose(mk_str, |_| {})); // internal compiler error: cannot relate bound region: //   ReLateBound(DebruijnIndex { depth: 2 }, //     BrNamed(DefId { krate: 0, node: DefIndex(6) => test::'x }, 'x(65))) //<= ReSkolemized(0, //     BrNamed(DefId { krate: 0, node: DefIndex(6) => test::'x }, 'x(65))) test(Compose(Str, |_| {})); } </del>

Reproduction branch: When applying the change from the last commit I get a panic in my code during the call to . <details<summaryBacktrace</summary</details
Cannot reproduce on my linux. Can you provide a small ? Is that possible? Maybe without all the externals :/
I can reproduce a very similar problem (appears to involve the same origin and failing assertion of ) compiling rust-lang/regex with and compiler flags: For me, setting to 2 or greater is required to present this failure. <details<summarybacktrace</summary<code<preRUSTBACKTRACE=1 cargo build Compiling regex v1.1.2 (/home/kent/rust/regex) thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32', 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::beginpanic 7: syntax::sourcemap::SourceMap::bytepostofilecharpos 8: syntax::sourcemap::SourceMap::lookupcharpos 9: <rustccodegenssa::mir::FunctionCx<'a, 'tcx, Bx::scopemetadataforloc 10: <rustccodegenssa::mir::FunctionCx<'a, 'tcx,


Question: <del> #![feature(fn_traits, unboxed_closures)] fn test<F: for<'x> FnOnce<(&'x str,)>>(_: F) {} struct Compose<F,G>(F,G); impl<T,F,G> FnOnce<(T,)> for Compose<F,G> where F: FnOnce<(T,)>, G: FnOnce<(F::Output,)> { type Output = G::Output; extern "rust-call" fn call_once(self, (x,): (T,)) -> G::Output { (self.1)((self.0)(x)) } } struct Str<'a>(&'a str); fn mk_str<'a>(s: &'a str) -> Str<'a> { Str(s) } fn main() { let _: for<'a> fn(&'a str) -> Str<'a> = mk_str; // expected concrete lifetime, found bound lifetime parameter 'a let _: for<'a> fn(&'a str) -> Str<'a> = Str; //~^ ERROR: mismatched types test(|_: &str| {}); test(mk_str); // expected concrete lifetime, found bound lifetime parameter 'x test(Str); //~ ERROR: type mismatch in function arguments test(Compose(|_: &str| {}, |_| {})); test(Compose(mk_str, |_| {})); // internal compiler error: cannot relate bound region: //   ReLateBound(DebruijnIndex { depth: 2 }, //     BrNamed(DefId { krate: 0, node: DefIndex(6) => test::'x }, 'x(65))) //<= ReSkolemized(0, //     BrNamed(DefId { krate: 0, node: DefIndex(6) => test::'x }, 'x(65))) test(Compose(Str, |_| {})); } </del>

Bx::debugloc 11: rustccodegenssa::mir::codegenmir 12: rustccodegenssa::base::codegeninstance 13: rustccodegenssa::monoitem::MonoItemExt::define 14: rustccodegenllvm::base::compilecodegenunit::modulecodegen 15: rustc::depgraph::graph::DepGraph::withtask 16: rustccodegenllvm::base::compilecodegenunit 17: rustccodegenssa::base::codegencrate 18: <rustccodegenllvm::LlvmCodegenBackend as rustccodegenutils::codegenbackend::CodegenBackend::codegencrate 19: rustc::util::common::time 20: rustcdriver::driver::phase4codegen 21: rustcdriver::driver::compileinput::{{closure}} 22: <std::thread::local::LocalKey<T::with 23: rustc::ty::context::TyCtxt::createandenter 24: rustcdriver::driver::compileinput 25: rustcdriver::runcompilerwithpool 26: <scopedtls::ScopedKey<T::set 27: rustcdriver::runcompiler 28: syntax::withglobals 29: rustmaybecatchpanic at 30: <F as alloc::boxed::FnBox<A::callbox 31: std::sys::unix::thread::Thread::new::threadstart at at at 32: <unknown33: clone query stack during panic: 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-26) running on x86_64-unknown-linux-gnu note: compiler flags: -Z mir-opt-level=2 -C debuginfo=2 -C incremental --crate-type lib </pre</code</details
With the help of , I've found a tiny test that reproduces this crash on Linux and Mac:
Got another one: <details</detailsHappens when compiling regex tests with and calling on every span found in the mir of the functions needing codegen.
According to glaicer, the ICE from this example has been gone.
can you confirm that your example does not crash on nightly anymore?


Question: <del> #![feature(fn_traits, unboxed_closures)] fn test<F: for<'x> FnOnce<(&'x str,)>>(_: F) {} struct Compose<F,G>(F,G); impl<T,F,G> FnOnce<(T,)> for Compose<F,G> where F: FnOnce<(T,)>, G: FnOnce<(F::Output,)> { type Output = G::Output; extern "rust-call" fn call_once(self, (x,): (T,)) -> G::Output { (self.1)((self.0)(x)) } } struct Str<'a>(&'a str); fn mk_str<'a>(s: &'a str) -> Str<'a> { Str(s) } fn main() { let _: for<'a> fn(&'a str) -> Str<'a> = mk_str; // expected concrete lifetime, found bound lifetime parameter 'a let _: for<'a> fn(&'a str) -> Str<'a> = Str; //~^ ERROR: mismatched types test(|_: &str| {}); test(mk_str); // expected concrete lifetime, found bound lifetime parameter 'x test(Str); //~ ERROR: type mismatch in function arguments test(Compose(|_: &str| {}, |_| {})); test(Compose(mk_str, |_| {})); // internal compiler error: cannot relate bound region: //   ReLateBound(DebruijnIndex { depth: 2 }, //     BrNamed(DefId { krate: 0, node: DefIndex(6) => test::'x }, 'x(65))) //<= ReSkolemized(0, //     BrNamed(DefId { krate: 0, node: DefIndex(6) => test::'x }, 'x(65))) test(Compose(Str, |_| {})); } </del>

Has been fixed in
is likely the part of the rollup fixing it.
Shouldn't a testcase be instead of closing this?
A similar crash that still happens:


Question: <del> #![feature(fn_traits, unboxed_closures)] fn test<F: for<'x> FnOnce<(&'x str,)>>(_: F) {} struct Compose<F,G>(F,G); impl<T,F,G> FnOnce<(T,)> for Compose<F,G> where F: FnOnce<(T,)>, G: FnOnce<(F::Output,)> { type Output = G::Output; extern "rust-call" fn call_once(self, (x,): (T,)) -> G::Output { (self.1)((self.0)(x)) } } struct Str<'a>(&'a str); fn mk_str<'a>(s: &'a str) -> Str<'a> { Str(s) } fn main() { let _: for<'a> fn(&'a str) -> Str<'a> = mk_str; // expected concrete lifetime, found bound lifetime parameter 'a let _: for<'a> fn(&'a str) -> Str<'a> = Str; //~^ ERROR: mismatched types test(|_: &str| {}); test(mk_str); // expected concrete lifetime, found bound lifetime parameter 'x test(Str); //~ ERROR: type mismatch in function arguments test(Compose(|_: &str| {}, |_| {})); test(Compose(mk_str, |_| {})); // internal compiler error: cannot relate bound region: //   ReLateBound(DebruijnIndex { depth: 2 }, //     BrNamed(DefId { krate: 0, node: DefIndex(6) => test::'x }, 'x(65))) //<= ReSkolemized(0, //     BrNamed(DefId { krate: 0, node: DefIndex(6) => test::'x }, 'x(65))) test(Compose(Str, |_| {})); } </del>

I realize it's kinda nonsensical, but here:
Why didn't WF catch this?
That's because only checks statics/constants.
Still reproducible with .
This ought to be a mostly easy fix. The problem is that the well formedness check, which ought to be rejected this code, is ignoring things in an : They fall through to this `` case: We would need to add support for the HIR item: which in turn has a number of items: which are defined here: presumably we want the to check that the types of are well-formed, roughly analogous to how we current check normal static items: (We probably want similar checks on foreign item fns, though?) One tricky part might be compatibility, we may need to turn this into a compatibility lint in case there is lots of broken code in the wild.
I am trying to fix this bug, and need help moving forward. function is modified to accept a and a , yet it doesn't report any additional errors and the ICE prevails. Test file: Commit: Should I create a pull request or is it too early?
Looks like suggestions are incomplete ( does not require ). Also, I left a comment on your commit about how you can avoid adding . I suspect the only reason regular s are required to be is they have an initializer (and that, not the type, requires ), i.e. for we have these errors:
Oddly, the PR that were previously posted to fix this (PR , following on PR ) was subsequently closed as inactive ... but the bug itself seems like it may have been resolved in the meantime?
I'm going to assume this was fixed. Tagging as E-needstest, but if someone wants to take the time, it'd be even better to bisect to where this was fixed, and see if a regression test for this was at that time.
Compiler no longer panics, tested with


Question: impl EntryKind { fn def_kind(&self) -> DefKind { match *self { <ins> EntryKind::AnonConst(..) => DefKind::AnonConst, </ins> EntryKind::Const(..) => DefKind::Const, EntryKind::AssocConst(..) => DefKind::AssocConst, EntryKind::ImmStatic

Currently with const generics you can create a "specialized" implementation, such as: Which has the following output: (playground link: ) However, when using such a type in another crate this causes a stack overflow in the compiler. For example, with the following code (full example: ): I would expect it to produce the same output as the playground link above, however it produces the following:
A bisect shows this stopped crashing after , marked as needing a test
I was still encountering this in my code with and after trying to minimize it seems that the original example is fixed but the stack overflow still occurs when the const expression in the has braces around it. After experimenting I found some more examples of what works and what doesn't: (see to try it) compiles and runs successfully while and (or ) crash the compiler with the same error as the original: :


Question: // These cases don't actually need a destination ExprKind::Assign { .. } | ExprKind::AssignOp { .. } <del> | ExprKind::Continue { .. } | ExprKind::Break { .. } | ExprKind::LlvmInlineAsm { .. } | ExprKind::Return { .. } => { </del> <ins> | ExprKind::LlvmInlineAsm { .. } => { </ins> unpack!(block = this.stmt_expr(block, expr, None)); this.cfg.push_assign_unit(block, source_info, destination, this.hir.tcx()); block.unit() } <ins> ExprKind::Continue { .. } | ExprKind::Break { .. } | ExprKind::Return { .. } => { unpack!(block = this.stmt_expr(block, expr, None)); // No assign, as these have type `!`. block.unit() } </ins> // Avoid creating a temporary ExprKind::VarRef { .. } | ExprKind::SelfRef

<!-- 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. --The code fails to pass <!-- 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. --Repo is at <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Oh that is interesting: is that expected? The other way around would make sense (assigning a into anything, really), but with a on the left, that seems odd? Or maybe the message just gets the sides wrong.
Yeah, that MIR looks really broken: Cc
This is probably due to this line: , and shouldn't have this, since they have type , not .
This is a super old issue going back all the way to the initial MIR implementation and I’m somewhat confident is documented somewhere, though I cannot find an issue for this. IIRC these invalid assignments only happen in unreachable basic blocks, so however wrong it looks in isolation, it is dead code and I think it never was a priority to fix either generation or the MIR validation we had back then for exactly that reason. Looks like is a new take on validation? Perhaps the easy fix would be to not validate unreachable blocks.


Question: call_locations, no_emit_shared: false, html_no_source, <del> force_unstable_if_unmarked, </del> }; Some((options, render_options)) }

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


Question: COPY host-x86_64/dist-x86_64-linux/build-binutils.sh /tmp/ RUN ./build-binutils.sh <del> # libssh2 (a dependency of Cargo) requires cmake 2.8.11 or higher but CentOS # only has 2.6.4, so build our own COPY host-x86_64/dist-x86_64-linux/build-cmake.sh /tmp/ RUN ./build-cmake.sh # Build a version of gcc capable of building LLVM 6 </del> <ins> # Need at least GCC 5.1 to compile LLVM nowadays </ins> COPY host-x86_64/dist-x86_64-linux/build-gcc.sh /tmp/ <del> RUN ./build-gcc.sh </del> <ins> RUN ./build-gcc.sh && apt-get remove -y gcc g++ </ins> <del> # CentOS 5.5 has Python 2.4 by default, but LLVM needs 2.7+ </del> <ins> # Debian 6 has Python 2.6 by default, but LLVM needs 2.7+ </ins> COPY host-x86_64/dist-x86_64-linux/build-python.sh /tmp/ RUN ./build-python.sh <del> # Now build LLVM+Clang 7, afterwards configuring further compilations to use the </del> <ins> # LLVM needs cmake 3.4.3 or higher, and is planning to raise to 3.13.4. COPY host-x86_64/dist-x86_64-linux/build-cmake.sh /tmp/ RUN ./build-cmake.sh # Now build LLVM+Clang, afterwards configuring further compilations to use the </ins> # clang/clang++ compilers. <del> COPY host-x86_64/dist-x86_64-linux/build-clang.sh host-x86_64/dist-x86_64-linux/llvm-project-centos.patch /tmp/ </del> <ins> COPY host-x86_64/dist-x86_64-linux/build-clang.sh /tmp/ </ins> RUN ./build-clang.sh ENV CC=clang CXX=clang++ <del> # Apparently CentOS 5.5 desn't have `git` in yum, but we're gonna need it for # cloning, so download and build it here. COPY host-x86_64/dist-x86_64-linux/build-git.sh /tmp/ RUN ./build-git.sh # for sanitizers, we need kernel headers files newer than the ones CentOS ships # with so we install newer ones here COPY host-x86_64/dist-x86_64-linux/build-headers.sh /tmp/ RUN ./build-headers.sh # OpenSSL requires a more recent version of perl # with so we install newer ones here COPY host-x86_64/dist-x86_64-linux/build-perl.sh /tmp/ RUN ./build-perl.sh </del> COPY scripts/sccache.sh /scripts/ RUN sh /scripts/sccache.sh

The docs currently claim that the minimum Linux kernel version for is 2.6.18 (released September 20th, 2006). This is because RHEL 5 used that kernel version. However, RHEL 5 entered ELS on March 31, 2017. Should we continue to support RHEL 5 for , or should we increase the minimum Linux Kernel version to 2.6.27 (2nd LTS) or 2.6.32 (RHEL 6, 3rd LTS)? . Even bumping the min-version to 2.6.27 would allow us to remove most of the Linux-specific hacks in . Example: .
Given that RHEL is the only reason we keep comically old kernel versions around, I would propose that Rust only support RHEL until Maintenance Support ends. This is (essentially) what we already did for RHEL 4. Rust never supported RHEL 4, and back when RHEL 5 still had maintenance support. It would be nice to get someone from Red Hat or a RHEL customer to comment. This policy would allow us to increment the minimum kernel from 2.6.18 to 2.6.32 (and remove a lot of Linux-specific hacks). Note that RHEL has a weird (and very long) support system for RHEL 4, 5, and 6 (sources: and ). It has 5 major steps: Full Support Normal support of the OS Maintenance Support 1 Bug/Security fixes Limited hardware refresh Maintenance Support 2 Bug/Security fixes The end of this phase is considered "Product retirement" Extended Life Cycle Support (ELS) Additional paid product from Red Hat Gives updates for a longer period of time No additional releases/images Extended Life Phase (ELP) No more updates Limited Technical Support End date not given by Red Hat Current status of RHEL versions: RHEL 4 Not supported by Rust Currently in ELP (no end date specified) ELS ended March 31, 2017 RHEL 5 Supported by Rust Currently in ELS Maintenance Support ended March 31, 2017 ELS ends November 30, 2020 RHEL 6 Supported by Rust Currently in Maintenance Support 2 Maintenance Support ends November 30, 2020
cc which I think they could be related.


Question: COPY host-x86_64/dist-x86_64-linux/build-binutils.sh /tmp/ RUN ./build-binutils.sh <del> # libssh2 (a dependency of Cargo) requires cmake 2.8.11 or higher but CentOS # only has 2.6.4, so build our own COPY host-x86_64/dist-x86_64-linux/build-cmake.sh /tmp/ RUN ./build-cmake.sh # Build a version of gcc capable of building LLVM 6 </del> <ins> # Need at least GCC 5.1 to compile LLVM nowadays </ins> COPY host-x86_64/dist-x86_64-linux/build-gcc.sh /tmp/ <del> RUN ./build-gcc.sh </del> <ins> RUN ./build-gcc.sh && apt-get remove -y gcc g++ </ins> <del> # CentOS 5.5 has Python 2.4 by default, but LLVM needs 2.7+ </del> <ins> # Debian 6 has Python 2.6 by default, but LLVM needs 2.7+ </ins> COPY host-x86_64/dist-x86_64-linux/build-python.sh /tmp/ RUN ./build-python.sh <del> # Now build LLVM+Clang 7, afterwards configuring further compilations to use the </del> <ins> # LLVM needs cmake 3.4.3 or higher, and is planning to raise to 3.13.4. COPY host-x86_64/dist-x86_64-linux/build-cmake.sh /tmp/ RUN ./build-cmake.sh # Now build LLVM+Clang, afterwards configuring further compilations to use the </ins> # clang/clang++ compilers. <del> COPY host-x86_64/dist-x86_64-linux/build-clang.sh host-x86_64/dist-x86_64-linux/llvm-project-centos.patch /tmp/ </del> <ins> COPY host-x86_64/dist-x86_64-linux/build-clang.sh /tmp/ </ins> RUN ./build-clang.sh ENV CC=clang CXX=clang++ <del> # Apparently CentOS 5.5 desn't have `git` in yum, but we're gonna need it for # cloning, so download and build it here. COPY host-x86_64/dist-x86_64-linux/build-git.sh /tmp/ RUN ./build-git.sh # for sanitizers, we need kernel headers files newer than the ones CentOS ships # with so we install newer ones here COPY host-x86_64/dist-x86_64-linux/build-headers.sh /tmp/ RUN ./build-headers.sh # OpenSSL requires a more recent version of perl # with so we install newer ones here COPY host-x86_64/dist-x86_64-linux/build-perl.sh /tmp/ RUN ./build-perl.sh </del> COPY scripts/sccache.sh /scripts/ RUN sh /scripts/sccache.sh

It also may be worth to drop support of Windows XP and Vista (especially considering that panics are broken on XP since June 2016, see: ). Previously it was discussed . cc
Besides , which other things would we be able to clean up?
Good question! There are 6 workarounds in for older Linux versions (that I could find). Increasing the minimum version to 2.6.32 (aka 3rd Kernel LTS, aka RHEL 6) would fix 5 of them. Code links are inline: (mentioned above, in 2.6.23) ( in 2.6.24, there is also the mention of a bug occuring on "some linux kernel at some point") to atomically set the flag on the pipe fds ( in 2.6.27) ( in 2.6.27) to permit use of ( in 2.6.28) ( in 4.5, not fixed by this proposal) As you can see, the workarounds fixed by this proposal all have a similar flavor.
I am Red Hat's maintainer for Rust on RHEL -- thanks for the cc. I try to keep an eye on new issues, but this one slipped past me. Red Hat only ships the Rust toolchain to customers for RHEL 7 and RHEL 8. If our customers would like to use Rust on older RHEL, they can do so via , and we'll support them in the same way we would for any other third-party software. Internally we do also build and use on RHEL 6, mostly because it's needed to ship Firefox updates. This is where it gets a little hairy, because each RHEL N is bootstrapped on RHEL N-1 and often kept that way -- meaning a lot of our RHEL 6 builders are still running on a RHEL 5 kernel. I would have to apply local workarounds if upstream Rust loses the ability to run on 2.6.18 kernels. We prefer to keep fixes upstream as much as possible, both for open sharing and to avoid bitrot. Is there much of a benefit to removing the current workarounds? I agree all of that code is annoying and cumbersome, but it's already written, and as far as I know it hasn't been a maintenance burden. Do you see otherwise?


Question: COPY host-x86_64/dist-x86_64-linux/build-binutils.sh /tmp/ RUN ./build-binutils.sh <del> # libssh2 (a dependency of Cargo) requires cmake 2.8.11 or higher but CentOS # only has 2.6.4, so build our own COPY host-x86_64/dist-x86_64-linux/build-cmake.sh /tmp/ RUN ./build-cmake.sh # Build a version of gcc capable of building LLVM 6 </del> <ins> # Need at least GCC 5.1 to compile LLVM nowadays </ins> COPY host-x86_64/dist-x86_64-linux/build-gcc.sh /tmp/ <del> RUN ./build-gcc.sh </del> <ins> RUN ./build-gcc.sh && apt-get remove -y gcc g++ </ins> <del> # CentOS 5.5 has Python 2.4 by default, but LLVM needs 2.7+ </del> <ins> # Debian 6 has Python 2.6 by default, but LLVM needs 2.7+ </ins> COPY host-x86_64/dist-x86_64-linux/build-python.sh /tmp/ RUN ./build-python.sh <del> # Now build LLVM+Clang 7, afterwards configuring further compilations to use the </del> <ins> # LLVM needs cmake 3.4.3 or higher, and is planning to raise to 3.13.4. COPY host-x86_64/dist-x86_64-linux/build-cmake.sh /tmp/ RUN ./build-cmake.sh # Now build LLVM+Clang, afterwards configuring further compilations to use the </ins> # clang/clang++ compilers. <del> COPY host-x86_64/dist-x86_64-linux/build-clang.sh host-x86_64/dist-x86_64-linux/llvm-project-centos.patch /tmp/ </del> <ins> COPY host-x86_64/dist-x86_64-linux/build-clang.sh /tmp/ </ins> RUN ./build-clang.sh ENV CC=clang CXX=clang++ <del> # Apparently CentOS 5.5 desn't have `git` in yum, but we're gonna need it for # cloning, so download and build it here. COPY host-x86_64/dist-x86_64-linux/build-git.sh /tmp/ RUN ./build-git.sh # for sanitizers, we need kernel headers files newer than the ones CentOS ships # with so we install newer ones here COPY host-x86_64/dist-x86_64-linux/build-headers.sh /tmp/ RUN ./build-headers.sh # OpenSSL requires a more recent version of perl # with so we install newer ones here COPY host-x86_64/dist-x86_64-linux/build-perl.sh /tmp/ RUN ./build-perl.sh </del> COPY scripts/sccache.sh /scripts/ RUN sh /scripts/sccache.sh

If there are any known issues with such Linux compatibility code, I am definitely willing to take assignment for fixing them.
(Not a Rust maintainer, but I'm a Rust user and maintain a lot of other OSS software so I have well-developed feelings around supporting Very Old Software :-)) Do you have any sense of on what timeline Rust would be able to drop support for 2.6.18 kernels without causing you pain? In general I don't think people mind supporting configurations that have users and are painful to work around, but needing to support them for forever is a bitter pill to swallow! Particularly as they get harder and harder to test over time (already I have no idea how to test on really old kernels besides building it myself). So if there was an estimate "we'd like to be able to support this until Q2 2020", even if it's not set in stone, I think that would be very helpful!
The other benefit would be that Rust wouldn't have to use CentOS 5 for CI, which means we don't have to patch LLVM (and Emscripten LLVM) to compile on those systems. Of course that's also fairly limited in scope.
As soon as we stop shipping Firefox and Thunderbird updates on RHEL 6, I won't need Rust there anymore. AFAIK this does correspond to the end of Maintenance Support, November 30, 2020. Then I'll be on to RHEL 7 builders as my minimum, probably still with some RHEL 6 2.6.32 kernels involved. It should be fine for me if we update CI to CentOS 6. This is mostly concerned with how the release binaries are linked to GLIBC symbol versions, which is all in userspace. It's a broader community question whether any other Rust users still care about running on RHEL or CentOS 5. (Small caveat - glibc support for a symbol can still return , .)
I noticed that Red Hat also has Extended Life Cycle Support (ELS) for RHEL 6 until June 30, 2024. Will you need RHEL 5 to work during this time? I don't know how ELS works with Firefox updates. Also, is there any reason RHEL 4 support wasn't an issue prior to March 31, 2017 (while RHEL 5 was still normally supported)?


Question: COPY host-x86_64/dist-x86_64-linux/build-binutils.sh /tmp/ RUN ./build-binutils.sh <del> # libssh2 (a dependency of Cargo) requires cmake 2.8.11 or higher but CentOS # only has 2.6.4, so build our own COPY host-x86_64/dist-x86_64-linux/build-cmake.sh /tmp/ RUN ./build-cmake.sh # Build a version of gcc capable of building LLVM 6 </del> <ins> # Need at least GCC 5.1 to compile LLVM nowadays </ins> COPY host-x86_64/dist-x86_64-linux/build-gcc.sh /tmp/ <del> RUN ./build-gcc.sh </del> <ins> RUN ./build-gcc.sh && apt-get remove -y gcc g++ </ins> <del> # CentOS 5.5 has Python 2.4 by default, but LLVM needs 2.7+ </del> <ins> # Debian 6 has Python 2.6 by default, but LLVM needs 2.7+ </ins> COPY host-x86_64/dist-x86_64-linux/build-python.sh /tmp/ RUN ./build-python.sh <del> # Now build LLVM+Clang 7, afterwards configuring further compilations to use the </del> <ins> # LLVM needs cmake 3.4.3 or higher, and is planning to raise to 3.13.4. COPY host-x86_64/dist-x86_64-linux/build-cmake.sh /tmp/ RUN ./build-cmake.sh # Now build LLVM+Clang, afterwards configuring further compilations to use the </ins> # clang/clang++ compilers. <del> COPY host-x86_64/dist-x86_64-linux/build-clang.sh host-x86_64/dist-x86_64-linux/llvm-project-centos.patch /tmp/ </del> <ins> COPY host-x86_64/dist-x86_64-linux/build-clang.sh /tmp/ </ins> RUN ./build-clang.sh ENV CC=clang CXX=clang++ <del> # Apparently CentOS 5.5 desn't have `git` in yum, but we're gonna need it for # cloning, so download and build it here. COPY host-x86_64/dist-x86_64-linux/build-git.sh /tmp/ RUN ./build-git.sh # for sanitizers, we need kernel headers files newer than the ones CentOS ships # with so we install newer ones here COPY host-x86_64/dist-x86_64-linux/build-headers.sh /tmp/ RUN ./build-headers.sh # OpenSSL requires a more recent version of perl # with so we install newer ones here COPY host-x86_64/dist-x86_64-linux/build-perl.sh /tmp/ RUN ./build-perl.sh </del> COPY scripts/sccache.sh /scripts/ RUN sh /scripts/sccache.sh

This issue came up for me when dealing with opening files in , see for more info. No single RHEL 5 issue is that bad, it's mainly just the sum of a bunch of tiny issues.
I'm not on that team, but AFAIK we don't ship Firefox updates for ELS. The last build I see for RHEL 5 was . Maybe there could be an exception for a severe security issue, but I really doubt we'd rebase to newer Firefox for that, which means Rust requirements won't change. New Firefox ESR versions do require a newer Rust toolchain too, which is generally why we have to keep up. Otherwise we could just freeze some older compat rustc while upstream moves on. Rust wasn't required until Firefox 52.
that makes perfect sense to me, thanks for clarifying. So the proposed policy would be: Support RHEL until RHEL is retired (i.e. ends normal support). This would mean: Supporting RHEL 5 (v2.6.18) until November 30, 2020 Supporting RHEL 6 (v2.6.32) until June 30, 2024 Supporting RHEL 7 (v3.10) until May, 2029 This is a much longer support tail than any other Linux distros (that I know of), so it would also be the effective minimum kernel version of , , and their dependencies. How does that sound to people? EDIT: The alternative to this would be Support RHEL until it is retired, taking the table above and incrementing the RHEL versions by 1. It would also mean being able to drop RHEL 5 support now.
Sure, that's ideal for me. :smile: As mentioned, is just needed for kernel support, as far as I'm concerned. Userspace concerns like GLIBC symbol versions can stick to currently supported for my needs.
Red Hat should backport the features we need (CLOEXEC and getrandom, in particular) to whatever kernels that it wants Rust to support. I don't know any good reason why they don't do so, other than it's cheaper to convince the whole world to keep supporting older kernel versions than it is to do the backports. We should change that dynamic.


Question: COPY host-x86_64/dist-x86_64-linux/build-binutils.sh /tmp/ RUN ./build-binutils.sh <del> # libssh2 (a dependency of Cargo) requires cmake 2.8.11 or higher but CentOS # only has 2.6.4, so build our own COPY host-x86_64/dist-x86_64-linux/build-cmake.sh /tmp/ RUN ./build-cmake.sh # Build a version of gcc capable of building LLVM 6 </del> <ins> # Need at least GCC 5.1 to compile LLVM nowadays </ins> COPY host-x86_64/dist-x86_64-linux/build-gcc.sh /tmp/ <del> RUN ./build-gcc.sh </del> <ins> RUN ./build-gcc.sh && apt-get remove -y gcc g++ </ins> <del> # CentOS 5.5 has Python 2.4 by default, but LLVM needs 2.7+ </del> <ins> # Debian 6 has Python 2.6 by default, but LLVM needs 2.7+ </ins> COPY host-x86_64/dist-x86_64-linux/build-python.sh /tmp/ RUN ./build-python.sh <del> # Now build LLVM+Clang 7, afterwards configuring further compilations to use the </del> <ins> # LLVM needs cmake 3.4.3 or higher, and is planning to raise to 3.13.4. COPY host-x86_64/dist-x86_64-linux/build-cmake.sh /tmp/ RUN ./build-cmake.sh # Now build LLVM+Clang, afterwards configuring further compilations to use the </ins> # clang/clang++ compilers. <del> COPY host-x86_64/dist-x86_64-linux/build-clang.sh host-x86_64/dist-x86_64-linux/llvm-project-centos.patch /tmp/ </del> <ins> COPY host-x86_64/dist-x86_64-linux/build-clang.sh /tmp/ </ins> RUN ./build-clang.sh ENV CC=clang CXX=clang++ <del> # Apparently CentOS 5.5 desn't have `git` in yum, but we're gonna need it for # cloning, so download and build it here. COPY host-x86_64/dist-x86_64-linux/build-git.sh /tmp/ RUN ./build-git.sh # for sanitizers, we need kernel headers files newer than the ones CentOS ships # with so we install newer ones here COPY host-x86_64/dist-x86_64-linux/build-headers.sh /tmp/ RUN ./build-headers.sh # OpenSSL requires a more recent version of perl # with so we install newer ones here COPY host-x86_64/dist-x86_64-linux/build-perl.sh /tmp/ RUN ./build-perl.sh </del> COPY scripts/sccache.sh /scripts/ RUN sh /scripts/sccache.sh

The alternative to this would be Support RHEL N until it is retired I think we should not officially support retired OS versions (well, maybe with some grace period), so I prefer this option. Supporting 14 year old kernels seems a bit too much to me. each RHEL N is bootstrapped on RHEL N-1 and often kept that way -- meaning a lot of our RHEL 6 builders are still running on a RHEL 5 kernel Is it possible to apply kernel patches to those builders to add support for functionality like CLOEXEC? Or build Firefox separately on RHEL 6?
I think it won't be fruitful for us to debate the merits of stable enterprise kernels, but no, this is not a possibility. An alternative take is "Red Hat should be responsible for the work in Rust to maintain the support they want" -- here I am, ready and willing. I definitely can't change those kernels. The ones that are stuck on N-1 are precisely to avoid rocking the boat, and backporting features is a big change. Some of our arches do eventually update the builders to their matching N kernel, but some don't, and I don't know all the reasons. If the workarounds are removed, then I will have to reapply them in our own builds. This assumes I keep using only our own binaries -- if I ever have to re-bootstrap from upstream binaries for stage0, I would also have to use some interception (like ) to hack in the workarounds. This is all possible, but much worse than the status quo of maintaining support here.
I think this sounds reasonable. We aren't going to be able to update these kernels, it's just a question of when we would drop support for these OSes. Especially given that we wont need RHEL 5 CI support, I think that leaving things as they are is fine. I opened this issue to verify two things: 1) That we weren't intending on supporting RHEL 5 "forever", and had a clear date when to drop support. 2) That someone from Red Hat actively cared about supporting these older kernels. It looks like both these things are true. We should remove RHEL 5 workarounds after November 30, 2020. This issue can be postponed until then.


Question: COPY host-x86_64/dist-x86_64-linux/build-binutils.sh /tmp/ RUN ./build-binutils.sh <del> # libssh2 (a dependency of Cargo) requires cmake 2.8.11 or higher but CentOS # only has 2.6.4, so build our own COPY host-x86_64/dist-x86_64-linux/build-cmake.sh /tmp/ RUN ./build-cmake.sh # Build a version of gcc capable of building LLVM 6 </del> <ins> # Need at least GCC 5.1 to compile LLVM nowadays </ins> COPY host-x86_64/dist-x86_64-linux/build-gcc.sh /tmp/ <del> RUN ./build-gcc.sh </del> <ins> RUN ./build-gcc.sh && apt-get remove -y gcc g++ </ins> <del> # CentOS 5.5 has Python 2.4 by default, but LLVM needs 2.7+ </del> <ins> # Debian 6 has Python 2.6 by default, but LLVM needs 2.7+ </ins> COPY host-x86_64/dist-x86_64-linux/build-python.sh /tmp/ RUN ./build-python.sh <del> # Now build LLVM+Clang 7, afterwards configuring further compilations to use the </del> <ins> # LLVM needs cmake 3.4.3 or higher, and is planning to raise to 3.13.4. COPY host-x86_64/dist-x86_64-linux/build-cmake.sh /tmp/ RUN ./build-cmake.sh # Now build LLVM+Clang, afterwards configuring further compilations to use the </ins> # clang/clang++ compilers. <del> COPY host-x86_64/dist-x86_64-linux/build-clang.sh host-x86_64/dist-x86_64-linux/llvm-project-centos.patch /tmp/ </del> <ins> COPY host-x86_64/dist-x86_64-linux/build-clang.sh /tmp/ </ins> RUN ./build-clang.sh ENV CC=clang CXX=clang++ <del> # Apparently CentOS 5.5 desn't have `git` in yum, but we're gonna need it for # cloning, so download and build it here. COPY host-x86_64/dist-x86_64-linux/build-git.sh /tmp/ RUN ./build-git.sh # for sanitizers, we need kernel headers files newer than the ones CentOS ships # with so we install newer ones here COPY host-x86_64/dist-x86_64-linux/build-headers.sh /tmp/ RUN ./build-headers.sh # OpenSSL requires a more recent version of perl # with so we install newer ones here COPY host-x86_64/dist-x86_64-linux/build-perl.sh /tmp/ RUN ./build-perl.sh </del> COPY scripts/sccache.sh /scripts/ RUN sh /scripts/sccache.sh

EDIT: For our use case in , we were able to add compatibility for RHEL 5 .
See for a recent case where supporting such ancient kernels required extra manual work ( to the 2 lines mentioned by above). I am not sure how often that comes up, but probably the hardest part is to even notice that it happens -- and even then those codepaths will likely linger untested.
Yes, but this will still be true in general. If the CI kernel is newer than whatever kernel baseline we choose, it will be possible for newer syscalls to pass undetected. I don't know if we have any control over that -- can we choose a particular VM image? So that leaves us with a stated policy of support. The more that developers are aware of such issues, the better, but I'm the one most likely to notice when my build actually fails. If I come back with a fix, I at least need the project to be receptive. I haven't been in the habit of building nightly on our RHEL6 builders, but maybe I should! Catching this early is better for everyone involved...
That seems reasonable. How quick is the Rust related bootstrapping? Could it be run automatically (or more frequently)? This is an interesting point. If I hadn't made that change, would have kept working on RHEL 5, it just would have leaked an FD. I'm not sure how we would even test for this sort of thing. This isn't a RHEL 5 specific concern, I just don't know how Rust tests these types of resource leak issues in general.
About 2 hours. Automation is harder, since I believe our build system needs my credentials, but I'll look into what is possible here. Yeah, that's a lot more subtle than an !


Question: return f.c; } <ins> struct quad_floats { float a; float b; float c; float d; }; float get_c_exhaust_sysv64_ints( void *a, void *b, void *c, void *d, void *e, void *f, // `f` used the last integer register, so `g` goes on the stack. // It also used to bring the "count of available integer registers" down to // `-1` which broke the next SSE-only aggregate argument (`h`) - see #62350. void *g, struct quad_floats h ) { return h.c; } </ins> // Calculates the average of `(x + y) / n` where x: i64, y: f64. There must be exactly n pairs // passed as variadic arguments. There are two versions of this function: the // variadic one, and the one that takes a `va_list`.

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: return f.c; } <ins> struct quad_floats { float a; float b; float c; float d; }; float get_c_exhaust_sysv64_ints( void *a, void *b, void *c, void *d, void *e, void *f, // `f` used the last integer register, so `g` goes on the stack. // It also used to bring the "count of available integer registers" down to // `-1` which broke the next SSE-only aggregate argument (`h`) - see #62350. void *g, struct quad_floats h ) { return h.c; } </ins> // Calculates the average of `(x + y) / n` where x: i64, y: f64. There must be exactly n pairs // passed as variadic arguments. There are two versions of this function: the // variadic one, and the one that takes a `va_list`.

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: "checksum quote 0.3.15 (registry+https://github.com/rust-lang/crates.io-index)" = "7a6e920b65c65f10b2ae65c831a81a073a89edd28c7cce89475bff467ab4167a" "checksum quote 0.6.12 (registry+https://github.com/rust-lang/crates.io-index)" = "faf4799c5d274f3868a4aae320a0a182cbd2baee377b378f080e16a23e9d80db" "checksum racer 2.1.23 (registry+https://github.com/rust-lang/crates.io-index)" = "94dbdea3d959d8f76a2e303b3eadf107fd76da886b231291e649168613d432fb" <del> "checksum rand 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)" = "552840b97013b1a26992c11eac34bdd778e464601a4c2054b5f0bff7c6761293" </del> "checksum rand 0.6.1 (registry+https://github.com/rust-lang/crates.io-index)" = "ae9d223d52ae411a33cf7e54ec6034ec165df296ccd23533d671a28252b6f66a" "checksum rand_chacha 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)" = "771b009e3a508cb67e8823dda454aaa5368c7bc1c16829fb77d3e980440dd34a" "checksum rand_core 0.3.0 (registry+https://github.com/rust-lang/crates.io-index)" = "0905b6b7079ec73b314d4c748701f6931eb79fd97c668caa3f1899b22b32c6db"

I noticed this scrolling by while "Building stage0 compiler artifacts" today: Optimistically flagging E-easy
I'd like to work on this, how can I fix? make rustc use one version(maybe v0.6.1)?
You will need to look into each dependency that depends on (by searching through ), check if they have a newer version that depends on new , and finally use to upgrade those crates.
Thanks! When I checked, it seems each rand version is used.
Yeah, it's natural that they are all used, and you could try to eliminate those crates using old by upgrading or refactoring. That said, there isn't much drawback with an older , so in that case this issue can be just closed.
Oh, I'm sorry, I misunderstood. Hmmm, I think we don't have to fix this quickly and this may be a catalyst for a newbie like me to contribute, so I leave this, okay?
but one could argue that it will lower the time to compile so it's worth to fix IMHO ;)
Uh, would it be better to fix?
Disclaimer: I'm not a core member, but IMHO this is worth fixing. Also scottmcm who is a core member opened this issue, so I guess you're good to go and fix that issue :)
Okay, I want to try to fix. For instance, depends on , how can I update or refactor this?
That's one thing you can't edit, because rand is a dependency of crossbeam-channel here, so the crate crossbeam-channel needs to update its dependecy (maybe it already did and you just need to update crossbeam-channel itself)?
For future reference, running  from is an easy way to identify the source of all duplicates.
Thanks ! I got this tree(). I updated , but is latest and depends on (). What should I do?
I'm not on compiler (or core), so don't take my word on this one :slightlysmilingface: It looks like upstream rayon needs 0.5, so you could consider making a PR to upgrade it to 0.6. (Maybe .) Also, it seems that , so they'd probably appreciate a PR to upgrade it to newer upstream.
Current rayon only uses rand as a dev-dependency, since rayon-rs/rayon.


Question: "checksum quote 0.3.15 (registry+https://github.com/rust-lang/crates.io-index)" = "7a6e920b65c65f10b2ae65c831a81a073a89edd28c7cce89475bff467ab4167a" "checksum quote 0.6.12 (registry+https://github.com/rust-lang/crates.io-index)" = "faf4799c5d274f3868a4aae320a0a182cbd2baee377b378f080e16a23e9d80db" "checksum racer 2.1.23 (registry+https://github.com/rust-lang/crates.io-index)" = "94dbdea3d959d8f76a2e303b3eadf107fd76da886b231291e649168613d432fb" <del> "checksum rand 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)" = "552840b97013b1a26992c11eac34bdd778e464601a4c2054b5f0bff7c6761293" </del> "checksum rand 0.6.1 (registry+https://github.com/rust-lang/crates.io-index)" = "ae9d223d52ae411a33cf7e54ec6034ec165df296ccd23533d671a28252b6f66a" "checksum rand_chacha 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)" = "771b009e3a508cb67e8823dda454aaa5368c7bc1c16829fb77d3e980440dd34a" "checksum rand_core 0.3.0 (registry+https://github.com/rust-lang/crates.io-index)" = "0905b6b7079ec73b314d4c748701f6931eb79fd97c668caa3f1899b22b32c6db"

That wouldn't show up in here at all, if rustc-rayon follows suit.
So the latest versions are and , but is used in this repository. They come from . Maybe those dependencies should be updated or made optional?
It looks like this was fixed in PR and merged by bors. Should this issue be closed now?
There are still 3 versions of rand in use:
will remove rand 0.5, I can get rid of 0.4 anytime but there are many PRs modifying right now.
Update: is used by , and (via ).
That's with -- only uses as a dev-dependency.
I didn't check now, but at some point was using an old version of a custom fork of .
has rebased since then, so it already reflects that dependency change.
I tried to fix a part of this in , but it didn't come out as planned. There is dependency and license whitelist that needs to be updated. I think just running leaves only one usage of via and (which can be updated). But then there is the licensing story, and it's not very clear to me which dependencies are used by the tools, and which by the compiler.
Last time I checked and were the only thing preventing of , otherwise I'd fix it already. We are working on removing it but it's blocked on releasing new version of .
I think goes away after a , so that one might be easy to fix. I don't know how dependencies are updated across the repository. Is it just that most of them are for the tools, not for and ? Does somebody run from time to time? And why does the license check fail on bors on my PR, but not on Travis or on my computer?
So released new version since. Correct, dependencies of everything that is created by are tracked by single . Dependencies are often updated separately as needed because upgrading everything at once is likely to break something and it's easier to find what is wrong when you change like 5 dependencies instead of 50. I think it should error when you run .
Also you can run the same image that found the error ( in this case) by using these steps


Question: <del> error: `#[doc(hidden)]` is ignored on trait impl items --> $DIR/unused-attr-doc-hidden.rs:29:5 | LL |     #[doc(hidden)] |     ^^^^^^^^^^^^^^ help: remove this attribute | note: the lint level is defined here --> $DIR/unused-attr-doc-hidden.rs:4:9 | LL | #![deny(unused_attributes)] |         ^^^^^^^^^^^^^^^^^ = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: whether the impl item is `doc(hidden)` or not entirely depends on the corresponding trait item error: `#[doc(hidden)]` is ignored on trait impl items --> $DIR/unused-attr-doc-hidden.rs:34:5 | LL |     #[doc(hidden)] |     ^^^^^^^^^^^^^^ help: remove this attribute | = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: whether the impl item is `doc(hidden)` or not entirely depends on the corresponding trait item error: `#[doc(hidden)]` is ignored on trait impl items --> $DIR/unused-attr-doc-hidden.rs:39:11 | LL |     #[doc(hidden, alias = "aka")] |           ^^^^^^-- |           | |           help: remove this attribute | = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: whether the impl item is `doc(hidden)` or not entirely depends on the corresponding trait item error: `#[doc(hidden)]` is ignored on trait impl items --> $DIR/unused-attr-doc-hidden.rs:44:27 | LL |     #[doc(alias = "this", hidden,)] |                           ^^^^^^- |                           | |                           help: remove this attribute | = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: whether the impl item is `doc(hidden)` or not entirely depends on the corresponding trait item error: `#[doc(hidden)]` is ignored on trait impl items --> $DIR/unused-attr-doc-hidden.rs:49:11 | LL |     #[doc(hidden, hidden)] |           ^^^^^^-- |           | |           help: remove this attribute | = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: whether the impl item is `doc(hidden)` or not entirely depends on the corresponding trait item error: `#[doc(hidden)]` is ignored on trait impl items --> $DIR/unused-attr-doc-hidden.rs:49:19 | LL |     #[doc(hidden, hidden)] |                   ^^^^^^ help: remove this attribute | = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: whether the impl item is `doc(hidden)` or not entirely depends on the corresponding trait item error: aborting due to 6 previous errors </del>

The warning by claims that on an impl item is ignored by rustdoc, but it isn't necessarily. The warning says: which is not true in the following repro: This warning is a false positive. Rustdoc does pay attention to this attribute. For the code above, the rendered documentation of and looks like: <table<tr<td<img src="https://user-" height="185"</td<td<img src="https://user-" height="300"</td</tr</tableAfter removing the supposedly unused attribute and rendering again, the "nasty uninteresting type" that we wanted not shown is going to get rendered on both pages: <table<tr<td<img src="https://user-" height="185"</td<td<img src="https://user-" height="300"</td</tr</table( :


Question: <del> error: `#[doc(hidden)]` is ignored on trait impl items --> $DIR/unused-attr-doc-hidden.rs:29:5 | LL |     #[doc(hidden)] |     ^^^^^^^^^^^^^^ help: remove this attribute | note: the lint level is defined here --> $DIR/unused-attr-doc-hidden.rs:4:9 | LL | #![deny(unused_attributes)] |         ^^^^^^^^^^^^^^^^^ = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: whether the impl item is `doc(hidden)` or not entirely depends on the corresponding trait item error: `#[doc(hidden)]` is ignored on trait impl items --> $DIR/unused-attr-doc-hidden.rs:34:5 | LL |     #[doc(hidden)] |     ^^^^^^^^^^^^^^ help: remove this attribute | = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: whether the impl item is `doc(hidden)` or not entirely depends on the corresponding trait item error: `#[doc(hidden)]` is ignored on trait impl items --> $DIR/unused-attr-doc-hidden.rs:39:11 | LL |     #[doc(hidden, alias = "aka")] |           ^^^^^^-- |           | |           help: remove this attribute | = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: whether the impl item is `doc(hidden)` or not entirely depends on the corresponding trait item error: `#[doc(hidden)]` is ignored on trait impl items --> $DIR/unused-attr-doc-hidden.rs:44:27 | LL |     #[doc(alias = "this", hidden,)] |                           ^^^^^^- |                           | |                           help: remove this attribute | = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: whether the impl item is `doc(hidden)` or not entirely depends on the corresponding trait item error: `#[doc(hidden)]` is ignored on trait impl items --> $DIR/unused-attr-doc-hidden.rs:49:11 | LL |     #[doc(hidden, hidden)] |           ^^^^^^-- |           | |           help: remove this attribute | = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: whether the impl item is `doc(hidden)` or not entirely depends on the corresponding trait item error: `#[doc(hidden)]` is ignored on trait impl items --> $DIR/unused-attr-doc-hidden.rs:49:19 | LL |     #[doc(hidden, hidden)] |                   ^^^^^^ help: remove this attribute | = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: whether the impl item is `doc(hidden)` or not entirely depends on the corresponding trait item error: aborting due to 6 previous errors </del>

Just wanted to add that this is also affecting , but in a different way: <img width="500" src="https://user-"The isn't there at all without the : <img width="500" src="https://user-"Based on the above, this isn't correct: it actually hides the entire thing, at least for associated constants.
In your case, it's inherent associated items being accidentally flagged which is which was meaning the most recent nightly should not have your issue anymore. Sorry for the inconvenience. The longer I look this lint, the less I like it.