Question: use crate::io; use crate::mem; <del> use crate::sync; </del> <ins> use crate::ptr; </ins> use crate::sys::c; <del> /// The kinds of HashMap RNG that may be available #[derive(Clone, Copy, Debug, PartialEq)] enum HashMapRng { Preferred, Fallback, } </del> pub fn hashmap_random_keys() -> (u64, u64) { <del> match get_hashmap_rng() { HashMapRng::Preferred => { preferred_rng().expect("couldn't generate random bytes with preferred RNG") } HashMapRng::Fallback => { fallback_rng().expect("couldn't generate random bytes with fallback RNG") } } } /// Returns the HashMap RNG that should be used /// /// Panics if they are both broken fn get_hashmap_rng() -> HashMapRng { // Assume that if the preferred RNG is broken the first time we use it, it likely means // that: the DLL has failed to load, there is no point to calling it over-and-over again, // and we should cache the result static VALUE: sync::OnceLock<HashMapRng> = sync::OnceLock::new(); *VALUE.get_or_init(choose_hashmap_rng) } /// Test whether we should use the preferred or fallback RNG /// /// If the preferred RNG is successful, we choose it. Otherwise, if the fallback RNG is successful, /// we choose that /// /// Panics if both the preferred and the fallback RNG are both non-functional fn choose_hashmap_rng() -> HashMapRng { let preferred_error = match preferred_rng() { Ok(_) => return HashMapRng::Preferred, Err(e) => e, }; match fallback_rng() { Ok(_) => return HashMapRng::Fallback, Err(fallback_error) => panic!( "preferred RNG broken: `{}`, fallback RNG broken: `{}`", preferred_error, fallback_error ), } } /// Generate random numbers using the preferred RNG function (BCryptGenRandom) fn preferred_rng() -> Result<(u64, u64), io::Error> { use crate::ptr; </del> let mut v = (0, 0); let ret = unsafe { c::BCryptGenRandom(

To be clear, we (at least at the moment) don't really support calling into libstd from initialization contexts like DllMain. We sometimes fix bugs from this it, but mostly on a best-effort basis, which depending on stuff like severity/impact/maintance burden/hackiness/the weather/etc, all of which is mostly judged on an ad-hoc basis. Even when we fix it, there's no guarantee it'd going to keep working in the future. Given that it's only broken on Win7[^1] and there doesn't seem to be a great approach that wouldn't make things worse outside of it (and/or for on newer windows), I'm inclined to just say... sorry, it's not really supported. Anyway, while things from libstd like HashMap (well, the it uses in particular) is unlikely to be viable in DllMain (at least on win7), I think things from liballoc should be fine (so long as your allocator supports it), so my recommendation might be to switch to using /, which shouldn't have this issue. Another option would be to use a different hasher that doesn't need randomness, but be careful about that. [^1]: It may be worth reconsidering if this happens on newer Windows as well. There are some... unpleasant approaches we could consider, but I don't think they're worth it for Win7 given how close to EOL it is, and the fact that we don't really support use from DllMain anyway.
I am loading an dll from DLL main for years now, and you just told me that Microsoft can screw me over at any time Well thanks for warning. I will keep doing that and hope Microsoft will never change that.
If you scroll down this page it has a list of things Microsoft says you should never do in DllMain:
This is what I was saying before about the stack trace not actually reflecting the changes -- but I also mentioned the bizarre coincidence that this hang bisects to exactly the same nightly as the one with the patch. I agree with keeping the revised changes in all cases and libstd support being a best-effort deal, but I'm guessing that something in how/what gets locked/attempted before the call into changes the state in some unsupported way that caused the bug to surface. I'd be curious what Application Verifier finds if you run it against a minimum repro.


Question: use crate::io; use crate::mem; <del> use crate::sync; </del> <ins> use crate::ptr; </ins> use crate::sys::c; <del> /// The kinds of HashMap RNG that may be available #[derive(Clone, Copy, Debug, PartialEq)] enum HashMapRng { Preferred, Fallback, } </del> pub fn hashmap_random_keys() -> (u64, u64) { <del> match get_hashmap_rng() { HashMapRng::Preferred => { preferred_rng().expect("couldn't generate random bytes with preferred RNG") } HashMapRng::Fallback => { fallback_rng().expect("couldn't generate random bytes with fallback RNG") } } } /// Returns the HashMap RNG that should be used /// /// Panics if they are both broken fn get_hashmap_rng() -> HashMapRng { // Assume that if the preferred RNG is broken the first time we use it, it likely means // that: the DLL has failed to load, there is no point to calling it over-and-over again, // and we should cache the result static VALUE: sync::OnceLock<HashMapRng> = sync::OnceLock::new(); *VALUE.get_or_init(choose_hashmap_rng) } /// Test whether we should use the preferred or fallback RNG /// /// If the preferred RNG is successful, we choose it. Otherwise, if the fallback RNG is successful, /// we choose that /// /// Panics if both the preferred and the fallback RNG are both non-functional fn choose_hashmap_rng() -> HashMapRng { let preferred_error = match preferred_rng() { Ok(_) => return HashMapRng::Preferred, Err(e) => e, }; match fallback_rng() { Ok(_) => return HashMapRng::Fallback, Err(fallback_error) => panic!( "preferred RNG broken: `{}`, fallback RNG broken: `{}`", preferred_error, fallback_error ), } } /// Generate random numbers using the preferred RNG function (BCryptGenRandom) fn preferred_rng() -> Result<(u64, u64), io::Error> { use crate::ptr; </del> let mut v = (0, 0); let ret = unsafe { c::BCryptGenRandom(

I tried Application Verifier, because I was wondering what it does. My code is in the dll, and it seems to not work for only dll, so I needed to enable the tests for the exe directly. did not catch anything. But what is bit more funny is that enabling causes the application to fail so early that none of my code is executed... (at least if I set it up correctly and understand what it is doing)


Question: <ins> #![allow(unreachable_code)] use std::marker::PhantomData; use std::ops::Deref; use std::sync::Arc; pub struct Guard<T> { _phantom: PhantomData<T>, } impl<T> Deref for Guard<T> { type Target = T; fn deref(&self) -> &T { unimplemented!() } } pub struct DirectDeref<T>(T); impl<T> Deref for DirectDeref<Arc<T>> { type Target = T; fn deref(&self) -> &T { unimplemented!() } } pub trait Access<T> { type Guard: Deref<Target = T>; fn load(&self) -> Self::Guard { unimplemented!() } } impl<T, A: Access<T>, P: Deref<Target = A>> Access<T> for P { //~^ NOTE: required for `Arc<ArcSwapAny<Arc<usize>>>` to implement `Access<_>` type Guard = A::Guard; } impl<T> Access<T> for ArcSwapAny<T> { //~^ NOTE: multiple `impl`s satisfying `ArcSwapAny<Arc<usize>>: Access<_>` found type Guard = Guard<T>; } impl<T> Access<T> for ArcSwapAny<Arc<T>> { type Guard = DirectDeref<Arc<T>>; } pub struct ArcSwapAny<T> { _phantom_arc: PhantomData<T>, } pub fn foo() { let s: Arc<ArcSwapAny<Arc<usize>>> = unimplemented!(); let guard: Guard<Arc<usize>> = s.load(); //~^ ERROR: type annotations needed //~| HELP: try using a fully qualified path to specify the expected types } fn main() {} </ins>

A code attached below used to compile with rustc 1.48 (stable) and stopped to work with 1.49 (stable). Two thing help to make the code compile: 1) comment out 2) explicitly deref . To compile code below one need to add to dependencies. Maybe this is due to some conflict between ArcSwap instance method and Access load method? I tried this code: I expected to see this happen: It should compile properly (it worked with rustc version 1.48 and earlier versions as well). Instead, this happened: I got compilation error It most recently worked on: Rust 1.48 :
searched nightlies: from nightly-2020-10-01 to nightly-2020-11-14 regressed nightly: nightly-2020-10-07 searched commits: from to regressed commit: () <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Assigning as discussed as part of the and removing .
:
The examples now print actionable feedback for the user, in the form of errors complaining about multiple applicable impl's. For example, the now prints: So I think this might just need a regression test. label: E-needs-test


Question: let mut slice = None; let mut prev_rest_span = None; <ins> // Lowers `$bm $ident @ ..` to `$bm $ident @ _`. let lower_rest_sub = |this: &mut Self, pat, bm, ident, sub| { let lower_sub = |this: &mut Self| Some(this.pat_wild_with_node_id_of(sub)); let node = this.lower_pat_ident(pat, bm, ident, lower_sub); this.pat_with_node_id_of(pat, node) }; </ins> let mut iter = pats.iter(); // Lower all the patterns until the first occurrence of a sub-slice pattern. for pat in iter.by_ref() {

The ICE only occurs when is used. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Nominating due to impending stabilization, even though stable doesn't ICE yet
Simplified:


Question: fn get_rendered_const(&self, id: DefIndex) -> String { match self.kind(id) { <del> EntryKind::Const(_, data) | EntryKind::AssocConst(_, _, data) => data.decode(self).0, </del> <ins> EntryKind::AnonConst(_, data) | EntryKind::Const(_, data) | EntryKind::AssocConst(_, _, data) => data.decode(self).0, </ins> _ => bug!(), } }

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: "checksum rls-vfs 0.4.4 (registry+https://github.com/rust-lang/crates.io-index)" = "ffd34691a510938bb67fe0444fb363103c73ffb31c121d1e16bc92d8945ea8ff" "checksum rustc-demangle 0.1.4 (registry+https://github.com/rust-lang/crates.io-index)" = "3058a43ada2c2d0b92b3ae38007a2d0fa5e9db971be260e0171408a4ff471c95" "checksum rustc-serialize 0.3.24 (registry+https://github.com/rust-lang/crates.io-index)" = "dcf128d1287d2ea9d80910b5f1120d0b8eede3fbf1abe91c40d39ea7d51e6fda" <del> "checksum rustfmt-nightly 0.1.9 (registry+https://github.com/rust-lang/crates.io-index)" = "6693f90ac7d0a2291aa309f5214f5f3ac1bd79961c11116fcf6d5545749bf2e7" </del> <ins> "checksum rustfmt-nightly 0.2.1 (registry+https://github.com/rust-lang/crates.io-index)" = "aa1ffc66e1e1786355f22e8a958a57bd67fbf9564f522f87f31de9586715f8f6" </ins> "checksum same-file 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)" = "d931a44fdaa43b8637009e7632a02adc4f2b2e0733c08caa4cf00e8da4a117a7" "checksum scoped-tls 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)" = "f417c22df063e9450888a7561788e9bd46d3bb3c1466435b4eccb903807f147d" "checksum scopeguard 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)" = "59a076157c1e2dc561d8de585151ee6965d910dd4dcb5dabb7ae3e83981a6c57"

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: let b = b.subst(cx.tcx, b_substs); debug!("Comparing {:?} and {:?}", a, b); <ins> // We can immediately rule out these types as structurally same if // their layouts differ. match compare_layouts(a, b) { Ok(false) => return false, _ => (), // otherwise, continue onto the full, fields comparison } </ins> // Grab a flattened representation of all fields. let a_fields = a_def.variants.iter().flat_map(|v| v.fields.iter()); let b_fields = b_def.variants.iter().flat_map(|v| v.fields.iter()); <del> compare_layouts(a, b) && a_fields.eq_by( </del> <ins> // Perform a structural comparison for each field. a_fields.eq_by( </ins> b_fields, |&ty::FieldDef { did: a_did, .. }, &ty::FieldDef { did: b_did, .. }| {

<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc for ClashingExternDeclarations in backtrace.
claim
Thank you for fixing it! There is nothing better than software with only a few open issues.
Not a problem! Thank you for the report, and especially for taking the time to make a minimal example :)


Question: <ins> #![feature(const_fn_trait_bound)] // Regression test related to issue 88434 const _CONST: &() = &f(&|_| {}); const fn f<F>(_: &F) where F: FnMut(&u8), { panic!() //~ ERROR evaluation of constant value failed } fn main() { } </ins>

<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --code from glacier <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This one also crashes beta and stable release channel.
Huh, why was this not detected earlier if it was tracked in glacier as fixed?
If you add a annotation to the trait bound on , then it no longer ICEs. Here's the code: Output: And if you add the two feature attributes the above messages ask you to enable, it still does not ICE, but correctly errors with "evaluation of constant value failed." Based on some debugging which I , I think this ICE has to do with the lifetime in the bound , although I'm not exactly sure how. I am new to the Rust compiler, and I just chose this issue because it seemed like a good first issue to work on, so I will read the (thanks to for sharing this) and try to further debug this.
If you plan to work on this issue, I recommend claiming it so other people know that and don't start working on it too. You can claim the issue by commenting with . More details about how to use rustbot are . You may also want to read the of the guide.
claim


Question: <ins> fn main() { format!("x7Ba}"); //~^ ERROR cannot find value `a` in this scope format!("x7Bax7D"); //~^ ERROR cannot find value `a` in this scope let a = 0; format!("x7Ba} {b}"); //~^ ERROR cannot find value `b` in this scope format!("x7Bax7D {b}"); //~^ ERROR cannot find value `b` in this scope format!("x7Ba} x7Bb}"); //~^ ERROR cannot find value `b` in this scope format!("x7Bax7D x7Bb}"); //~^ ERROR cannot find value `b` in this scope format!("x7Bax7D x7Bbx7D"); //~^ ERROR cannot find value `b` in this scope } </ins>

I tried this code: I expected to see this happen: a "no value found" error pointing at the token Instead, this happened: a "no value found" error pointing at the : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This doesn't seem to be an issue on stable, interestingly.
Yep, it works fine on 1.63.0, but has the problem on 1.65.0-beta.1 and the latest nightly.
claim


Question:
if !consts.is_empty() { write!(w, "
Associated Constants

 Associated Constants

 ")?; for t in &consts {

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: /// /// * `to_drop` must be [valid] for reads. /// <del> /// * `to_drop` must be properly aligned. See the example below for how to drop ///   an unaligned pointer. </del> <ins> /// * `to_drop` must be properly aligned. </ins> /// /// Additionally, if `T` is not [`Copy`], using the pointed-to value after /// calling `drop_in_place` can cause undefined behavior. Note that `*to_drop =

The docs for  state: And include an example which uses to copy the value from an unaligned pointer into an aligned one. However, the docs for  state: Either the docs for are wrong, and does not need to be aligned, or the example for invokes UB and should be updated to use
cc (It's also notable that the example in is wrong when it uses as is seen if you move the statement out of the block; we should fix that ASAP)
Good catch! What we'd really want is , I think... we don't want an intermediate value on the stack. Feel free to suggest code that we can use instead. We have several doctests that need They have been there since 1.0 and longer, probably. But nobody listens to me when I say that there is existing code that we need to support ASAP.
The example given is just using to put it on the stack anyway. If you're having to copy the value at all, there's really no reason to use at that point, since the only reason to use it instead of is to avoid the copy (which is optimized out in release mode anyway). I think we can probably just remove the unaligned example entirely and change the documentation to read: I think we should probably mention the caveat WRT the optimizer eliminating the copy (or can it even do that in this case? The docs mention that the drop glue generated for packed structs does this copy automatically, I'm curious if it's doing so in a way that is UB or if the copy is just the price you have to pay here. It's also worth noting that there's no way to an unsized value through an unaligned pointer, but I'm not sure that's worth bringing up at all in the docs, since there's no reasonable way to actually get that pointer in the first place.
Oh, good point. Yeah then you can basically just make it , right? I wonder why / ever got used here? Well but wouldn't it make sense for that text to come with an example? It cannot, because then it would be introducing alignment errors. Uh... yeah. With it could work. Doesn't seem like a reasonable thing to have either way?
Presumably because they wanted the example to continue to use Sure, we could -- it just wouldn't ever call the function being documented.


Question: /// /// * `to_drop` must be [valid] for reads. /// <del> /// * `to_drop` must be properly aligned. See the example below for how to drop ///   an unaligned pointer. </del> <ins> /// * `to_drop` must be properly aligned. </ins> /// /// Additionally, if `T` is not [`Copy`], using the pointed-to value after /// calling `drop_in_place` can cause undefined behavior. Note that `*to_drop =

Yes, it's just unrelated to dropping unaligned pointers since the only place you can reasonably copy them to is the stack. Unless you happen to already have an valid pointer of the proper size and alignment sitting around
I'm not actually sure unalgined DSTs are so unreasonable. For example, is only stopped by this rule: Which could be solved if we had e.g. a way to express "does not have drop glue" as a bound ( doesn't work for obvious reasons). In any case, I think "copy unaligned" functions make sense but we might want to consider multiple variants for src only / dest only / both unaligned. This can be expressed in LLVM IR though in a brief test I couldn't demonstrate that it currently makes a codegen difference (but I could only try on x86_64, where alignment rarely matters for codegen).
:rofl: fair. I guess all of this is basically saying an in-place drop of unaligned data is just not possible. Do an "out-of-place" drop instead.
Actually looks like the use of an unaligned pointer in the doctest just caused to fail to land. ;)
Proposed fix at


Question: resolver: &mut Resolver<'_>, krate: &ast::Crate, externs: Externs, <ins> document_private_items: bool, </ins> ) -> ResolverCaches { let mut loader = IntraLinkCrateLoader { resolver,

The ICE appears with and , but not . Beta: <details<summary<strongBacktrace</strong</summary<p</p</details
this is a regression affecting the release that is being prepared today.
I'll take a look.


Question: #[inline] fn next(&mut self) -> Option<T> { <del> self.iter.next().map(|elt| unsafe { ptr::read(elt) }) </del> <ins> if self.tail == self.head { return None; } let tail = self.tail; self.tail = wrap_index(self.tail.wrapping_add(1), self.ring.len()); // Safety: // - `self.tail` in a ring buffer is always a valid index. // - `self.head` and `self.tail` equality is checked above. unsafe { Some(ptr::read(self.ring.as_ptr().get_unchecked_mut(tail))) } </ins> } #[inline] fn size_hint(&self) -> (usize, Option<usize>) { <del> self.iter.size_hint() </del> <ins> let len = count(self.tail, self.head, self.ring.len()); (len, Some(len)) </ins> } }

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


Question: #[inline] fn next(&mut self) -> Option<T> { <del> self.iter.next().map(|elt| unsafe { ptr::read(elt) }) </del> <ins> if self.tail == self.head { return None; } let tail = self.tail; self.tail = wrap_index(self.tail.wrapping_add(1), self.ring.len()); // Safety: // - `self.tail` in a ring buffer is always a valid index. // - `self.head` and `self.tail` equality is checked above. unsafe { Some(ptr::read(self.ring.as_ptr().get_unchecked_mut(tail))) } </ins> } #[inline] fn size_hint(&self) -> (usize, Option<usize>) { <del> self.iter.size_hint() </del> <ins> let len = count(self.tail, self.head, self.ring.len()); (len, Some(len)) </ins> } }

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


Question: #[inline] fn next(&mut self) -> Option<T> { <del> self.iter.next().map(|elt| unsafe { ptr::read(elt) }) </del> <ins> if self.tail == self.head { return None; } let tail = self.tail; self.tail = wrap_index(self.tail.wrapping_add(1), self.ring.len()); // Safety: // - `self.tail` in a ring buffer is always a valid index. // - `self.head` and `self.tail` equality is checked above. unsafe { Some(ptr::read(self.ring.as_ptr().get_unchecked_mut(tail))) } </ins> } #[inline] fn size_hint(&self) -> (usize, Option<usize>) { <del> self.iter.size_hint() </del> <ins> let len = count(self.tail, self.head, self.ring.len()); (len, Some(len)) </ins> } }

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


Question: fn build_external_function(cx: &DocContext, did: DefId) -> clean::Function { let sig = cx.tcx.fn_sig(did); <del> let constness = if cx.tcx.is_const_fn(did) { </del> <ins> let constness = if cx.tcx.is_min_const_fn(did) { </ins> hir::Constness::Const } else { hir::Constness::NotConst

Regression from 1.26.0 to 1.27.0 and later. See for example See also and


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. const X: &'static str = "12345"; fn test(s: String) -> bool { match s.as_slice() { X => true, _ => false } } fn main() { assert!(test("12345".to_string())); } </ins>

On the latest nightly (previously it worked fine) Rust fails to compile this code: It emits this error message: I managed to strip it down to this example: It fails to compile with this error: If is replaced with , then it compiles fine, so the error seems to be related to matching on s.
Sorry for the breakage, fix on its way.


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. const X: &'static str = "12345"; fn test(s: String) -> bool { match s.as_slice() { X => true, _ => false } } fn main() { assert!(test("12345".to_string())); } </ins>

I just upgraded my to . But when I tried to rebuild my project, it failed with the following errors: , , etc... are constants of type . What does the error mean? I am confused.
Thanks . It seems that the bug is fixed, please merge it to upstream asap. :)
The same as


Question: Some(f) => f, None => return DummyResult::any(sp) }; <del> let file = cx.resolve_path(file, sp); </del> <ins> let file = match cx.resolve_path(file, sp) { Ok(f) => f, Err(mut err) => { err.emit(); return DummyResult::any(sp); }, }; </ins> match cx.source_map().load_binary_file(&file) { Ok(bytes) => match std::str::from_utf8(&bytes) { Ok(src) => {

to reproduce the fault this can be used: will result in this ICE: thread 'rustc' panicked at 'cannot resolve relative path in non-file source ', note: Run with RUSTBACKTRACE=1 environment variable to display a backtrace. 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.36.0 ( 2019-07-03) running on x86_64-unknown-linux-gnu the question is what is the path that shall be used when the code is from stdin maybe some temp file name in the currrent working dir.
This ICE also occurs when using and , which makes sense as they use the same mechanism under the hood (, , meaning it also .
While poking at this I also noticed that items are silently ignored, and filed .


Question: #[diag(lint_range_endpoint_out_of_range)] pub struct RangeEndpointOutOfRange<'a> { pub ty: &'a str, <del> #[suggestion(code = "{start}..={literal}{suffix}", applicability = "machine-applicable")] pub suggestion: Span, pub start: String, pub literal: u128, pub suffix: &'a str, </del> <ins> #[subdiagnostic] pub sub: UseInclusiveRange<'a>, } #[derive(Subdiagnostic)] pub enum UseInclusiveRange<'a> { #[suggestion( lint_range_use_inclusive_range, code = "{start}..={literal}{suffix}", applicability = "machine-applicable" )] WithoutParen { #[primary_span] sugg: Span, start: String, literal: u128, suffix: &'a str, }, #[multipart_suggestion(lint_range_use_inclusive_range, applicability = "machine-applicable")] WithParen { #[suggestion_part(code = "=")] eq_sugg: Span, #[suggestion_part(code = "{literal}{suffix}")] lit_sugg: Span, literal: u128, suffix: &'a str, }, </ins> } #[derive(LintDiagnostic)]

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: printing all numbers from 0 to 255 (inclusive) Instead, this happened: : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The error is correct, 256 is indeed out of range for u8. You need to use .
You can run that code if you want, by allowing the lint: if you do you'll see that it will print nothing because the overflows and becomes , so it's which is empty. Examples like this where allowing the literal overflow would do something you don't want are exactly why this lint is deny-by-default
I've renamed this issue because the lint is correct. If there's anything to be done here, it would be to add a range-specific suggestion for this situation to help guide towards the correct code.
claim


Question: use rustc_hir as hir; use rustc_middle::mir::visit::MutVisitor; use rustc_middle::mir::{self, dump_mir, MirPass}; <del> use rustc_middle::ty::{self, InstanceDef, Ty, TyCtxt}; </del> <ins> use rustc_middle::ty::{self, InstanceDef, Ty, TyCtxt, TypeVisitableExt}; </ins> use rustc_target::abi::FieldIdx; pub struct ByMoveBody;

<!-- 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: use rustc_hir as hir; use rustc_middle::mir::visit::MutVisitor; use rustc_middle::mir::{self, dump_mir, MirPass}; <del> use rustc_middle::ty::{self, InstanceDef, Ty, TyCtxt}; </del> <ins> use rustc_middle::ty::{self, InstanceDef, Ty, TyCtxt, TypeVisitableExt}; </ins> use rustc_target::abi::FieldIdx; pub struct ByMoveBody;

<!-- 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: // Parse: `for <src_pat> in <src_expr> <src_loop_block>` let pat = self.parse_pat()?; <del> self.expect_keyword(keywords::In)?; </del> <ins> if !self.eat_keyword(keywords::In) { let in_span = self.prev_span.between(self.span); let mut err = self.sess.span_diagnostic .struct_span_err(in_span, "missing `in` in `for` loop"); err.span_suggestion_short(in_span, "try adding `in` here", " in ".into()); err.emit(); } </ins> let expr = self.parse_expr_res(Restrictions::NO_STRUCT_LITERAL, None)?; let (iattrs, loop_block) = self.parse_inner_attrs_and_block()?; attrs.extend(iattrs);

Hello, with rustc 1.17.0-nightly ( 2017-03-22), the following code gives this error message: An improved error message could add a hint :
Current output: 1) How would you want to improve upon this? Adding a suggestion? 2) To do so, we could use the same strategy as in : in , try to continue building the expression as if the keyword had been found. If we find further errors, we revert the state of the compiler to right after trying to continue and return the error from . Otherwise we cancel that one and create a new custom diagnostic: 3) or just modify the existing error with the proposed (so it looks like the 2 above). []:
Looks like current output already is an improvement over the reported one, but eithwr 2 or 3 would make it even more obvious i guess. No strong opinions here
Seems to me that the third error is the most clear ("error: missing in loop"); I suspect people using fancy pattern features will figure out what's going on.


Question: <ins> #![feature(const_generics)] #![allow(incomplete_features)] use std::ffi::{CStr, CString}; unsafe fn unsafely_do_the_thing<const F: fn(&CStr) -> usize>(ptr: *const i8) -> usize { //~^ ERROR: using function pointers as const generic parameters is forbidden F(CStr::from_ptr(ptr)) } fn safely_do_the_thing(s: &CStr) -> usize { s.to_bytes().len() } fn main() { let baguette = CString::new("baguette").unwrap(); let ptr = baguette.as_ptr(); println!("{}", unsafe { unsafely_do_the_thing::<safely_do_the_thing>(ptr) }); } </ins>

I've tried reducing this but wasn't really able to so far. I might try again some other time. The code below currently ICEs on Nightly (). When trying to reproduce locally for the backtrace, I had an older Nightly first () where this actually didn't crash the compiler, so it's apparently a regression. <details<summary<strongBacktrace</strong</summary<p</p</details
This is my first time using cargo-bisect-rustc and it's fantastic. It identified the regression as... searched nightlies: from nightly-2020-02-13 to nightly-2020-05-14 regressed nightly: nightly-2020-03-20 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
is a rollup commit. The only PR which was part of that and (to me) looks like it could have caused this issue is .
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.


Question: <ins> #![feature(const_generics)] #![allow(incomplete_features)] use std::ffi::{CStr, CString}; unsafe fn unsafely_do_the_thing<const F: fn(&CStr) -> usize>(ptr: *const i8) -> usize { //~^ ERROR: using function pointers as const generic parameters is forbidden F(CStr::from_ptr(ptr)) } fn safely_do_the_thing(s: &CStr) -> usize { s.to_bytes().len() } fn main() { let baguette = CString::new("baguette").unwrap(); let ptr = baguette.as_ptr(); println!("{}", unsafe { unsafely_do_the_thing::<safely_do_the_thing>(ptr) }); } </ins>

produces: <details</detailsIt should not be possible to access the type parameter in the type of the const parameter. cc Thanks to for .
Hi, I am new to rust compiler development and have decided to try to fix this issue to get started. If I understand the const-generics RFC correctly, type parameters can not be used in a const generic parameter because it cannot be ensured that the actual types have the "structural match" property. However, checking reveals that fn pointers (as well as raw pointers and empty arrays) always support structural matching, regardless of the types used within. My question is: is there another reason why const generic parameters are not allowed to use type parameters? If so, I think an additional check has to be to .
Actually, I think I may have interpreted. It looks like this example is intended to work to me. cc just to clarify.
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.


Question: <ins> #![feature(const_generics)] #![allow(incomplete_features)] use std::ffi::{CStr, CString}; unsafe fn unsafely_do_the_thing<const F: fn(&CStr) -> usize>(ptr: *const i8) -> usize { //~^ ERROR: using function pointers as const generic parameters is forbidden F(CStr::from_ptr(ptr)) } fn safely_do_the_thing(s: &CStr) -> usize { s.to_bytes().len() } fn main() { let baguette = CString::new("baguette").unwrap(); let ptr = baguette.as_ptr(); println!("{}", unsafe { unsafely_do_the_thing::<safely_do_the_thing>(ptr) }); } </ins>

<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. -- <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p
Probably related to
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.


Question: <ins> #![feature(const_generics)] #![allow(incomplete_features)] use std::ffi::{CStr, CString}; unsafe fn unsafely_do_the_thing<const F: fn(&CStr) -> usize>(ptr: *const i8) -> usize { //~^ ERROR: using function pointers as const generic parameters is forbidden F(CStr::from_ptr(ptr)) } fn safely_do_the_thing(s: &CStr) -> usize { s.to_bytes().len() } fn main() { let baguette = CString::new("baguette").unwrap(); let ptr = baguette.as_ptr(); println!("{}", unsafe { unsafely_do_the_thing::<safely_do_the_thing>(ptr) }); } </ins>

<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. -- <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p
Depends on const generics in type dependent paths afaict. See for more info. EDIT: Also depends on const generics with generic types. Merging does not close this issue
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.
Adding the following as a test might still be useful, even if it only errors with "using function pointers as const parameters is forbidden":


Question: <ins> // check-pass //! [my_module] //~^ WARN public documentation for `private_from_crate_level` links to private item `my_module` mod my_module {} </ins>

It should say instead.
Relevant code: I think the fix is to use the crate name instead of .
Also, I would be curious to see if you can remove altogether by using : That might break renamed modules maybe? I don't remember how modules interact with re-exports.


Question: } } <ins> // This stripper discards all private import statements (`use`, `extern crate`) struct ImportStripper; impl fold::DocFolder for ImportStripper { fn fold_item(&mut self, i: Item) -> Option<Item> { match i.inner { clean::ExternCrateItem(..) | clean::ImportItem(..) if i.visibility != Some(hir::Public) => None, _ => self.fold_item_recur(i) } } } pub fn strip_priv_imports(krate: clean::Crate)  -> plugins::PluginResult { (ImportStripper.fold_crate(krate), None) } </ins> pub fn unindent_comments(krate: clean::Crate) -> plugins::PluginResult { struct CommentCleaner;

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


Question: // except according to those terms. use std::fmt::self; //~ ERROR E0429 <del> //~^ ERROR E0432 </del> fn main () { }

It currently gives two - one for outside and one for an unknown import. The latter should be silenced. e.g.,
I will work on this
On an related note, shouldn't there be a lint for . Maybe say "you can just use ."


Question: use prelude::v1::*; <ins> #[doc(hidden)] pub use self::imp::KeyInner as __KeyInner; </ins> /// Type representing a thread local storage key corresponding to a reference /// to the type parameter `T`. ///

There is an  in the scoped TLS module, which allows for sharing of data that wasn't meant to be shared. An unqualified should only_ be used when provides some sort of threadsafe locking mechanism. and do not. This lets us, for example, clone an or between threads, in safe code: Here, we have clones from different threads being interleaved, which can cause unsafety if there's a race on the refcount. We could also cause unsafety with a , or any other non-Sync type. basically lets us share across threads even if . I put the sleeps in there because somehow without them the routines are run serially. Note that this is not a problem with the API. I'm using here because to exploit one needs to be able to share across threads, and has an additional bound which doesn't satisfy. Any usable API will probably have to make the assumption that . Nor is this a problem with , since it can be done with , too. Solution: Make it ... I think. I'm not familiar with this API, and I'm not sure why it's even in the first place.
cc
cc This seems concerning: this is designed to be thread-local, so that e.g. storing a works (which would be safe, if it were guaranteed to stay on one thread). However currently requires unconditionally, hence this overly-accepting impl.
Qualifying the impl with breaks scoped TLS for (see the associated PR); because becomes no longer and thus can't be stuffed inside a static.
I believe the only way statics can be safe is by requiring the absence of Sync. That may sound odd, but consider the following: - sending thread-local references across threads is memory unsafe even with no interior mutability a static with no interior mutability is almost entirely useless, certainly not a common case non- containers offering interior mutabilities are cheaper and preferred to ones, where they can be used The main issue is actually within the libstd TLS implementation: is a wrapper for getters so it's unaffected by it, but may live in a static or a global one, depending on whether the platform natively supports TLS or not. -ing a across threads is actually safe on the architectures which do not have native TLS support. However, allowing it on some architectures and not on others is undesirable. Should use an accessor model like ?


Question: use prelude::v1::*; <ins> #[doc(hidden)] pub use self::imp::KeyInner as __KeyInner; </ins> /// Type representing a thread local storage key corresponding to a reference /// to the type parameter `T`. ///

Then the actual borrow of a static is an implementation detail and happens on the thread where the key is used, not where it was itself borrowed.
"I believe the only way #[threadlocal] statics can be safe is by requiring the absence of ." This is wrong, I think. For example, one might use thread local data for intrusive linked lists of hazard pointers. They would be thread local but might still be (one can guarantee existence with scoped threads or in certain circumstances where threads are bound to cores). That said you can obviously come up with other representations. In any case, I've mostly come around to believing that we need a separate lifetime (not just for this, but for things like ensuring that can't catch an error in a thread that changes thread local data, violating exception safety).
Based on what wrote, it seems like the TLS interface requires a that only allows non- data and is still accessible like one. One idea I had of how to enable this in todays Rust is to make generate a unit like struct instead of a . That struct would be and have a impl: According to this could also help with , but I'm not familiar enough with the TLS API in general to really reason about this.
I was expecting the impl to target an intermediary type, not the contents themselves. and have their own APIs to deal with. You would still be about to use the TLS API provided by libstd with thread-safe data, it's just the low-level which would have the requirement. Ideas of thread-local lifetimes predate the removal of from , and I'm not sure how relevant they are anymore. I'm also conflating thread-safe data access and thread lifetime... but how long does a thread live? What would unify with? Actually, there's an... easy solution for this. Somehow we were blinded by language semantics, but their details are fluid. It is trivial to make borrows of behave like borrows of an arbitrary rvalue, allowing the resulting reference to be passed down, but not returned. That would ensure that the the thread is just as alive for such borrows as it is for stack ones. would still require a like has, because it may not be when native TLS is supported. But both their APIs are compatible with such a change.
Wouldn't that limit the usability of thread locals in some cases, though?


Question: use prelude::v1::*; <ins> #[doc(hidden)] pub use self::imp::KeyInner as __KeyInner; </ins> /// Type representing a thread local storage key corresponding to a reference /// to the type parameter `T`. ///

e.g., wouldn't that make it difficult to have a thread local point to another thread local? Maybe I just have to think about it. (BTW, I'm aware we're just talking about the low-level API :)).
in a , borrows are , I didn't even think of that. First off, a global static shouldn't be allowed to borrow a static. And in general, having borrows in a is going to be difficult to support, except for non- data, because they would be right now. We could disallow borrows or we could give some kind of scope to those borrows. Which makes me think, as a compromise between a lifetime and , there could be a pseudo-(rvalue)-scope. Combined with the ability to leave out in globals' type (or not having a type at all), the scope should bubble up into users of those statics. They would behave as if they were borrowed before everything else in the function where they're used, but still not (and they can't be returned from functions).
There's a few intertwined issues here at play, so I just want to quickly summarize the way I see things: This does not affect as it which has an , which while sound should be fixed, allowing removal of the block for . A borrow of a static should not yield something with the lifetime, as that is clearly not sound. I'm not sure I follow why we might require the types in a are not , I haven't quite followed that. Due the cross-platform requirements of std, however, I believe the best solution here is to use the same strategy as with an indirect accessor to ensure the semantics are the same across platforms that have and those that don't (where a normal is used).
triage: P-medium This is an unstable API so it's not super-high priority to fix, but we should defnitely fix!
requiring that a is not is an easy way to ensure that a borrow of it, while , cannot escape the current thread. I've changed my mind and prefer an rvalue borrow semantic for , but it still is the case that and use non- statics (ignoring the workarounds for ). If was supported everywhere, having rvalue borrow semantics wouldn't hurt the std TLS API (aside from stability issues with ), as the access patterns are already through anonymous lifetimes (references passed to closures).


Question: use prelude::v1::*; <ins> #[doc(hidden)] pub use self::imp::KeyInner as __KeyInner; </ins> /// Type representing a thread local storage key corresponding to a reference /// to the type parameter `T`. ///

Maybe a combined strategy, where borrows of statics are iff the data is not (and rvalue-like otherwise), might work better and would require fewer changes to the std TLS implementation.
Right, but returning a borrow with a lifetime for a global is unsafe for other reasons (the lifetime of the thread is not ).
how can it be abused without sending it to a different thread?
The actual values themselves do not have a lifetime, so it can be a source of unsafety to advertise otherwise. For example you could stick a into a TLS value with a destructor, but when the destructor runs that pointer could be invalid.


Question: pub fn has_errors(&self) -> bool { self.diagnostic().has_errors() } <ins> pub fn has_errors_or_delayed_span_bugs(&self) -> bool { self.diagnostic().has_errors_or_delayed_span_bugs() } </ins> pub fn abort_if_errors(&self) { self.diagnostic().abort_if_errors(); }

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: <del> Subproject commit 6b3dbcc81a470e5da84576d63fcfc19e3b1154cd </del> <ins> Subproject commit 221a195b62f4373a8893f4d022e4ce981b09a857 </ins>

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --Minimized from a program was trying to debug. I tried this code: I expected to see this happen: Instead, this happened: I see this on aarch64 and not on x86_64. I don't have access to any other architectures. Output is as expected with . I can also observe this bug on the previous stable (1.56.1), current beta (1.58.0-beta.3) and current nightly ( 2022-01-10). :
Was able to also test Rust 1.53 & 1.55, both perform as expected and show i: 0
Are the numbers printed the same every time or do they vary?
Consistently on the problem arch & compilers
Thanks. The reason I was asking is that, if you're reading invalid memory, the result is usually random. Since this result is consistent, something else is probably going on.
For the sake of convenience, could you please provide the output for this program?
here you go:
It might be a coincidence but, is (4 bytes in 32-bits) and rounded to the . Seems like maybe the bits are being inverted?
~I'm able to reproduce with , but if I emit the IR and then compile it with , I do not see the issue.~ I get different IR if I compile with vs. the entire command from . Only the 2nd has the bug. Edit: It's caused by . Lowering it to removes the problem.
When I use the llc from the rustup toolchain, I see LLVM going wild with clobbers: Note that also gets passed , so we're actually converting some condition flags to float, which makes about zero sense. Weirdly I don't see this when using the llc from my local rust build :/
For this example, the llc distributed by rustup produces (with ): While my own build produces:
Looks like it works if LLVM is compiled with assertions and breaks when compiled without assertions :(
Are you saying that you can reproduce two different results using the same IR? I was seeing the issue with distributed from Homebrew. Not sure if that's compiled with or without assertions.


Question: <del> Subproject commit 6b3dbcc81a470e5da84576d63fcfc19e3b1154cd </del> <ins> Subproject commit 221a195b62f4373a8893f4d022e4ce981b09a857 </ins>

I only see the problem with IR generated with and compiling with . This is the line of IR that is causing the issues. It is only present with and removing it fixes the bug: Additionally, it's only a problem if I assign to the spill directly. If I store a constant or use a temporary, the issue goes away.
seems like it may be relevant. Switching to fixes the miscompilation.
Bisect shows this is fixed by on main. Edit: It looks that shortly after that landed and the change was reverted again.
The revert comment suggests that it should be fixed by . Are you able to confirm?
I've filed to check whether we can still get this in 13.0.1, though probably not. In that case I'll cherry-pick into our fork.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical


Question: <ins> // Copyright 2018 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. fn foo(_: &'static u32) {} fn unpromotable<T>(t: T) -> T { t } fn main() { foo(&unpromotable(5u32)); } //~^^ ERROR borrowed value does not live long enough </ins>

suggests but still won't give us a lifetime. We should not emit the if the required lifetime is for the inside the source presume there's some code already checking for producing the "borrowed value must be valid for the static lifetime" message, find that code and bubble up the knowledge about that until you have it in the scope of the "consider using a binding to increase its lifetime" message 't emit the message in that case 'll already fail a bunch of tests, I don't think you need any new tests. Running should succeed and give you a bunch of changes to commit. Check that all changes make sense and just commit them.
can I take this on if nobody is working on this?
All yours!
closing it, as required code change has been merged.


Question: /// Constructs a floating point number by multiplying `x` by 2 raised to the /// power of `exp` #[inline] <del> fn ldexp(x: f32, exp: int) -> f32 { unsafe { cmath::ldexpf(x, exp as c_int) } </del> <ins> fn ldexp(self, exp: isize) -> f32 { unsafe { cmath::ldexpf(self, exp as c_int) } </ins> } /// Breaks the number into a normalized fraction and a base-2 exponent,

has an unusual format: it takes as it's first parameter where everything else in the trait takes . It should take as it's first parameter for consistency with everything else. It is located in
+1. There are a few different things to consider here, though: does not operate on any FP number per se like most other operations do, but rather constructs a new FP number from two arguments one of which happens to be FP number. This function’s signature is consistent with most other methods that construct some kind of FP number (e.g. ). We might want to consider whether methods such as shouldn’t just go ahead and take instead. can’t currently be chained, but I see literally 0 cases where anybody would chain this function. cc
Okay, but from a consistency standpoint, it's like 1/80 for vs . It it keeps the same format, it and it's similar functions would probably be better to go at the end or beginning of the function list where they won't be so unusual.
Nominating for 1.0-beta P-backcompat-libs
One should be able to call this thing as a method, one way or another. We need to make sure that is resolved.
0 beta, P-backcompat-libs
I started to fix this.


Question: # # Check travis config for `gdb --batch` command to print all crash logs <ins> parameters: # When this parameter is set to anything other than an empty string the tests # will only be executed when the commit updates submodules only_on_updated_submodules: '' </ins> steps: # Disable automatic line ending conversion, which is enabled by default on

This issue is meant to track where on Travis we currently whenever the commit message looks like it updates a submodule. We should enable something similar for Azure Pipelines where whenever a PR is detected as updating a submodule (either via actually looking at the git history or at the git commit message) then we schedule the builder on the PR. The purpose of this PR build is to help weed out errors even sooner than before where we're just running a smoke tests on Linux on each PR.


Question: .find_ancestor_inside(value.span) .map(|span| (value.span.with_hi(span.lo()), value.span.with_lo(span.hi()))), ast::ExprKind::Paren(ref expr) => { <del> expr.span.find_ancestor_inside(value.span).map(|expr_span| { </del> <ins> // For the expr with attributes, like `let _ = (#[inline] || println!("Hello!"));`, // the span should contains the attributes, or the suggestion will remove them. let expr_span_with_attrs = if let Some(attr_lo) = expr.attrs.iter().map(|attr| attr.span.lo()).min() { expr.span.with_lo(attr_lo) } else { expr.span }; expr_span_with_attrs.find_ancestor_inside(value.span).map(|expr_span| { </ins> (value.span.with_hi(expr_span.lo()), value.span.with_lo(expr_span.hi())) }) }

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: The warning fires on all three lines of , and the suggestions should only suggest removing the parentheses, not the attribute also. Instead, this happened: The fires on the first and last lines of , and the suggestion also removes the . No warning fires on the second line (but this is probably a separate issue, unrelated to attributes; it happens even when the attribute is removed; maybe overrides it or something). <!-- 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. --: Requires use of , otherwise the is not legal in that position (though note that the warning and suggestion is the same on stable, there's just an first). The issue is not specific to closures and , but that was the simplest example of a reasonable attribute-on-expression I thought of. label +A-diagnostics +requires-nightly <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
claim


Question: assert_eq!(id, LOCAL_CRATE); tcx.crate_name }; <del> providers.maybe_unused_trait_import = |tcx, id| tcx.resolutions(()).maybe_unused_trait_imports.contains(&id); </del> <ins> providers.maybe_unused_trait_imports = |tcx, ()| &tcx.resolutions(()).maybe_unused_trait_imports; </ins> providers.maybe_unused_extern_crates = |tcx, ()| &tcx.resolutions(()).maybe_unused_extern_crates[..]; providers.names_imported_by_glob_use = |tcx, id| {

The resolver gathers a list of possibly unused trait imports in . This list is passed to resolver outputs, into the query. This query takes a and returns whether the import is possibly unused. This is used by the post-typeck unused import check in . This query iterates over all the statements in the crate, checks whether they may be unused trait imports, and warns if they are indeed unused. As there are typically very few unused trait imports compared to the number of items in a crate, it would make sense to directly iterate on . Steps: make an both in and , this will ensure a deterministic iteration order; rename query and give it the signature , and adapt the call site; we do not want to access directly, as this would prevent the query system from detecting that the set has not changed; in , inline and replace the loop over by a loop over ; the filter over there can be removed too (or replaced by a debug-assertion): the set may only point to use statements. Extra: investigate why we check for , and the consequences of removing that check; investigate the impact on perf of converting the to a simple when producing from . I am available on Zulip for any question. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
are you still working on this?
Hello yes sorry for the super slow pace. I am still working on it (mostly reading the rustc dev guide so far). Is that alright or is it important to get this done quickly?
no worries, I am a beginner looking for tasks, hence the qn.


Question: if !fail { return None; } <del> bug!("unexpected const parent path {:?}", x); </del> <ins> tcx.sess.delay_span_bug( DUMMY_SP, &format!( "unexpected const parent path {:?}", x ), ); tcx.types.err </ins> } } }

Following code sample causes a compiler panic. should be .
Also happens on nightly. Likely due to const generics changes (cc
Minimal reproduction:
Another case:


Question: <ins> // https://github.com/rust-lang/rust/issues/113462 struct S2<'b>(&'b ()); struct S<'a, const N: S2>(&'a ()); //~^ ERROR missing lifetime specifier [E0106] //~| ERROR `S2<'_>` is forbidden as the type of a const generic parameter fn main() {} </ins>

<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
searched nightlies: from nightly-2023-02-17 to nightly-2023-02-19 regressed nightly: nightly-2023-02-18 searched commit range: regressed commit: - -cc <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details


Question: | token::CloseDelim(DelimToken::NoDelim) // The pretty printer collapses many semicolons into one. | token::Semi <ins> // We don't preserve leading `|` tokens in patterns, so // we ignore them entirely | token::BinOp(token::BinOpToken::Or) // We don't preserve trailing '+' tokens in trait bounds, // so we ignore them entirely | token::BinOp(token::BinOpToken::Plus) </ins> // The pretty printer can turn `$crate` into `::crate_name` | token::ModSep = token.kind { return false;

The following code: is currently pretty-printed as: If this occurs in a macro invocation, it leads to an instance of
Extra info (but it boils down to what said): Using I get the following log: Rendered diff:
This applies to all trailing separators in theory (except that the separator is leading rather than trailing in this case), but in other cases the difference is fixed up by fuzzy comparison in .


Question: <ins> // edition:2018 struct S { foo: usize, } impl S { async fn bar(&self) { //~ HELP consider changing this to be a mutable reference //~| SUGGESTION &mut self self.foo += 1; //~ ERROR cannot assign to `self.foo`, which is behind a `&` reference [E0594] } } fn main() { S { foo: 1 }.bar(); } </ins>

Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --is not a valid argument; it needs to be either or . For some reason this problem only happens when the function is async.
This is the same diagnostic you get when mutably dereferencing let-bindings that are : So it seems like this has to do with the fact that ast_lowering emits a binding when desugaring. I wonder if we can get the name of the variable when emitting this diagnostic, and special-case when it .
Another (possibly related?) bug: doesn't have the suggestion if it's in an async block:
Same with closures. I would probably classify that as a separate bug, since the original bug has to do specifically with desugaring, and the latter has to do with closure/generator captures.
Thanks for the report and getting a PR up so quickly! label +AsyncAwait-Triaged +AsyncAwait-Polish
Another similar error, not related to async this time: isn't valid Rust.


Question: <ins> // check-pass struct Foo { foo: Option<&'static Foo> } static FOO: Foo = Foo { foo: Some(&FOO), }; fn main() {} </ins>

Let's tying to compile this code.This code compiled ok on stable and on nightly-2019-06-17 (for example at rust play site) But in current rustc 1.37.0-nightly ( 2019-06-26) compilation fails with message:
Bisected to: Ok Fail ...
I bisected to , which is also part of the range identified. I get build failures when I try to bisect further into the commits of that PR. cc
Hmm curious, we do have tests for such situations. I'll investigate, but it'll drop into beta today. It's probably an easy fix
Today? Beta cutoff is on Tuesday.
Not this time I believe
Beta cutoff is 2019-06-29 https://rust-
triage: P-high, remove nomination, assign to
FYI, Oli is on vacation for 2 weeks.
Should this be marked regression-from-stable-to-beta now?


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. pub fn foo(params: Option<&[&str]>) -> uint { params.unwrap().head().unwrap().len() } fn main() { let name = "Foo"; let msg = foo(Some(&[name.as_slice()])); //~^ ERROR mismatched types: expected `core::option::Option<&[&str]>` assert_eq!(msg, 3); } </ins>

Here is the error Here is the code that generates the error My system is x86_64 archlinux. The rust compiler version is Let me know if you guys need anything else. (The code is really short so it shouldn't be hard to just type it in to duplicate the bug)
It only needs one line for me
Workaround (in the sense that the compiler no longer ICE's): I think there is some unfortunate interaction here with the way we attempt to infer which kind of numeric literals are in the array (, , etc) and other code not being prepared to handle the that results when you don't have that information available.
This is almost certainly a duplicate of (but maybe the integer inference codepath is slightly different?).
This also causes the same ICE -
Similarly:
Looks like it's been fixed.


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. pub fn foo(params: Option<&[&str]>) -> uint { params.unwrap().head().unwrap().len() } fn main() { let name = "Foo"; let msg = foo(Some(&[name.as_slice()])); //~^ ERROR mismatched types: expected `core::option::Option<&[&str]>` assert_eq!(msg, 3); } </ins>

Swapping the order of the branches compiles fine. cc
Just checked: this fails with a normal closure too, not just a proc.
Compiles fine now but potentially needs a test.


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. pub fn foo(params: Option<&[&str]>) -> uint { params.unwrap().head().unwrap().len() } fn main() { let name = "Foo"; let msg = foo(Some(&[name.as_slice()])); //~^ ERROR mismatched types: expected `core::option::Option<&[&str]>` assert_eq!(msg, 3); } </ins>

Versions: Code to reproduce the ICE: Compilation output:
Seems to be fine now but potentially needs a test.
Nope, still failing. An updated example:
That code example fails to compile, but it's because the function signature for is wrong. It should be: When you make that change and make the struct fields public, the code compiles fine. Without the change I also didn't see any internal compiler errors. Rust Version: 0.12.0-pre-nightly, , Linux x8664
Yeah, I think this can be closed.
Flagging as needstest (not sure if one is checked in already)


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. pub fn foo(params: Option<&[&str]>) -> uint { params.unwrap().head().unwrap().len() } fn main() { let name = "Foo"; let msg = foo(Some(&[name.as_slice()])); //~^ ERROR mismatched types: expected `core::option::Option<&[&str]>` assert_eq!(msg, 3); } </ins>

It gives
cc
Looks like it no longer causes an ICE.
I agree, it is fixed, I close it.


Question: fn ty_generics<'a,'tcx>(ccx: &CrateCtxt<'a,'tcx>, space: ParamSpace, ast_generics: &hir::Generics, <del> base_generics: &ty::Generics<'tcx>) </del> <ins> base_generics: &ty::Generics<'tcx>, allow_defaults: bool) </ins> -> ty::Generics<'tcx> { let tcx = ccx.tcx;

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: <del> Subproject commit 81e59e6b92cf1729aabbbbf09b81a81a03775d64 </del> <ins> Subproject commit dadcbebfbd017aac2358cf652a4bd71a91694edc </ins>

Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great!
Ah, I see now. That PR removes splats (hopefully temporarily), and unfortunately, because of how natural it is, a few tests for Miri already use the splatting syntax. Yes, I can clean this up.
Yeah I just tried and was happy to see it work. :)
Fix happening on the Miri side in (it was so easy I just quickly did it)


Question:
// Output the documentation for each function individually if !required.is_empty() { write!(w, "
Required Methods

 Required Methods

 ")?; for m in &required {

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: <ins> error[E0107]: this associated function takes 0 generic arguments but 1 generic argument was supplied --> $DIR/issue-101421.rs:10:8 | LL |     ().f::<()>(()); |        ^------ help: remove these generics |        | |        expected 0 generic arguments | note: associated function defined here, with 0 generic parameters --> $DIR/issue-101421.rs:2:8 | LL |     fn f(&self, _: ()); |        ^ error: aborting due to previous error For more information about this error, try `rustc --explain E0107`. </ins>

Repros on the /current nightly. But works (gives an error about mismatched number of generic arguments) on stable and beta. s/o to for the minimal example. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
label regression-from-stable-to-nightly
Regressed in (nightly-2022-09-02), presumably , though seems to have already made the connection to that PR anyways :-)


Question: <ins> // revisions: cfail #![feature(const_generics, const_evaluatable_checked)] #![allow(incomplete_features)] // regression test for #79251 struct Node<const D: usize> where SmallVec<{ D * 2 }>: , { keys: SmallVec<{ D * 2 }>, } impl<const D: usize> Node<D> where SmallVec<{ D * 2 }>: , { fn new() -> Self { let mut node = Node::new(); node.keys.some_function(); //~^ error: no method named node } } struct SmallVec<const D: usize> {} fn main() {} </ins>

<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --I'm creating this issue mainly because it seems to be a different one than the ones listed in <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
What command are you running? I tried this code , but I encountered an error that doesn't have a method.
how strange, for me just causes the ice and it doesn't even come to notice that the function is missing. I just ran , and with the newest rustc () I still get the same error as above (in a new cargo project with the code copied from the playground link above).
Just ran again today and still get an ICE. Made the example a bit smaller: Output of (build also fails with the same message): Considering the rustc versions it should be the same that is currently on the playground, however there it does not cause an ICE. Maybe someone could try to reproduce this in a local environment?
can reproduce this locally, not sure why it doesn't ICE on the playground
cc -- it ICEs locally, but not on the playground
Try with ?
That indeed removes the ICE, let me just check which one of the options it is. Adding to the (or profile.release in release mode) section causes the ice to disappear.
That's even weirder. Seems like this is partly an incr-comp bug then.
Note that the ICE occurs in the incr-comp hasher (ICH): So this seems to be an incr-comp bug.
Reposting : So I removed .


Question: <ins> // revisions: cfail #![feature(const_generics, const_evaluatable_checked)] #![allow(incomplete_features)] // regression test for #79251 struct Node<const D: usize> where SmallVec<{ D * 2 }>: , { keys: SmallVec<{ D * 2 }>, } impl<const D: usize> Node<D> where SmallVec<{ D * 2 }>: , { fn new() -> Self { let mut node = Node::new(); node.keys.some_function(); //~^ error: no method named node } } struct SmallVec<const D: usize> {} fn main() {} </ins>

<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<details<summary<strongQuery Stack</strong</summary<p</p</details
modify labels to +requires-nightly
The following snippet gives the same ICE. The types are intentionally wrong. <details<summary<strongBacktrace</strong</summary<p</p</details<details<summary<strongQuery Stack</strong</summary<p</p</details
Triage: This is now fixed on the recent nightly, marking as E-needs-test.


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. pub mod two_tuple { trait T {} struct P<'a>(&'a T + 'a, &'a T + 'a); pub fn f<'a>(car: &'a T, cdr: &'a T) -> P<'a> { P(car, cdr) } } pub mod two_fields { trait T {} struct P<'a> { car: &'a T + 'a, cdr: &'a T + 'a } pub fn f<'a>(car: &'a T, cdr: &'a T) -> P<'a> { P{ car: car, cdr: cdr } } } fn main() {} </ins>


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. pub mod two_tuple { trait T {} struct P<'a>(&'a T + 'a, &'a T + 'a); pub fn f<'a>(car: &'a T, cdr: &'a T) -> P<'a> { P(car, cdr) } } pub mod two_fields { trait T {} struct P<'a> { car: &'a T + 'a, cdr: &'a T + 'a } pub fn f<'a>(car: &'a T, cdr: &'a T) -> P<'a> { P{ car: car, cdr: cdr } } } fn main() {} </ins>


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. pub mod two_tuple { trait T {} struct P<'a>(&'a T + 'a, &'a T + 'a); pub fn f<'a>(car: &'a T, cdr: &'a T) -> P<'a> { P(car, cdr) } } pub mod two_fields { trait T {} struct P<'a> { car: &'a T + 'a, cdr: &'a T + 'a } pub fn f<'a>(car: &'a T, cdr: &'a T) -> P<'a> { P{ car: car, cdr: cdr } } } fn main() {} </ins>


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. pub mod two_tuple { trait T {} struct P<'a>(&'a T + 'a, &'a T + 'a); pub fn f<'a>(car: &'a T, cdr: &'a T) -> P<'a> { P(car, cdr) } } pub mod two_fields { trait T {} struct P<'a> { car: &'a T + 'a, cdr: &'a T + 'a } pub fn f<'a>(car: &'a T, cdr: &'a T) -> P<'a> { P{ car: car, cdr: cdr } } } fn main() {} </ins>


Question: rhses: &[quoted::TokenTree]) -> Box<MacResult+'cx> { if cx.trace_macros() { <del> let sp = sp.macro_backtrace().last().map(|trace| trace.call_site).unwrap_or(sp); let mut values: &mut Vec<String> = cx.expansions.entry(sp).or_insert_with(Vec::new); values.push(format!("expands to `{}! {{ {} }}`", name, arg)); </del> <ins> trace_macros_note(cx, sp, format!("expanding `{}! {{ {} }}`", name, arg)); </ins> } // Which arm's failure should we report? (the one furthest along)

Output is: The first message here is inaccurate. The macro-use does not expand to that macro-use. shows the input to macros, not the output. So instead of "expands to:", it should say "expanding:". But changing the behavior to match what the message says would be even better. ;) This is a regression because the error messages are new. used to just dump token streams to stdout (lol).
Introduced in .
Closing -- I believe fixed this.


Question: <ins> #![crate_name = "foo"] // @has 'foo/trait.Unsafe.html' // @has - '//*[@class="object-safety-info"]' 'This trait is not object safe.' // @has - '//*[@id="object-safety"]' 'Object Safety' pub trait Unsafe { fn foo() -> Self; } // @has 'foo/trait.Unsafe2.html' // @has - '//*[@class="object-safety-info"]' 'This trait is not object safe.' // @has - '//*[@id="object-safety"]' 'Object Safety' pub trait Unsafe2<T> { fn foo(i: T); } // @has 'foo/trait.Safe.html' // @!has - '//*[@class="object-safety-info"]' '' // @!has - '//*[@id="object-safety"]' '' pub trait Safe { fn foo(&self); } // @has 'foo/struct.Foo.html' // @!has - '//*[@class="object-safety-info"]' '' // @!has - '//*[@id="object-safety"]' '' pub struct Foo; </ins>

So that it is easy for user to recognize object-safe traits. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
for the rustdoc side, just query the doc context with a given traitdef_id.
claim
Can you tell what are the relevant parts of rustdoc that needs to be changed?
sorry for late rely :) Add a field to , its value can be queried with like . Then you can append the object-safety info into the render part here I know little about the render code, could you leave some notes about that?
No, please do not add more fields to Trait. Query at the place it is used. I don't know much about render, may have suggestions.
I'm actually not sure what they want the end result to look like, so I don't know where to tell them to update the code. ;)
maybe it could be a cube icon to the right of the new button? On hover, there would be a tooltip saying or . I'm not sure where you get icons for rustdoc, but have a cube and cube-transparent icon that could be used for object-safe, and object-unsafe traits respectively. The could be reduced to fit in with the rest of the icons in rustdoc. If doesn't want to work on it I'd be happy to give it a go.
Following up from the PR with some UI discussion. I'd prefer not to add more icons up at the top of the page; we're already a bit crowded with icons. And there's no icon that has a broadly understood meaning of "object safe". I like the approach in , to write out "This trait is object-safe." But that PR puts it all the way at the top of the page, which is very high priority - and I would say object safety is more medium priority, so it should be lower on the page. One possibility would be to make an subheading in the top-doc docblock, but that results in using a lot of space for this. Our h2's are big! What about this: Under "Implementors", we could have at the very top "This trait is object safe. References to types that implement this trait can be automatically coerced to ".


Question: <ins> #![crate_name = "foo"] // @has 'foo/trait.Unsafe.html' // @has - '//*[@class="object-safety-info"]' 'This trait is not object safe.' // @has - '//*[@id="object-safety"]' 'Object Safety' pub trait Unsafe { fn foo() -> Self; } // @has 'foo/trait.Unsafe2.html' // @has - '//*[@class="object-safety-info"]' 'This trait is not object safe.' // @has - '//*[@id="object-safety"]' 'Object Safety' pub trait Unsafe2<T> { fn foo(i: T); } // @has 'foo/trait.Safe.html' // @!has - '//*[@class="object-safety-info"]' '' // @!has - '//*[@id="object-safety"]' '' pub trait Safe { fn foo(&self); } // @has 'foo/struct.Foo.html' // @!has - '//*[@class="object-safety-info"]' '' // @!has - '//*[@id="object-safety"]' '' pub struct Foo; </ins>

My reasoning here is that conceptually, is somewhat like an implementor of the trait.
I don't think this is necessarily true, you can have a that doesn't implement . But putting the text under "implementors" seems as good a place as any
Just out of curiosity, how can I have a that doesn’t implement ?
I don't think that's actually true, I misremembered.
We have one on: Would anyone else like to weigh in? Good enough to proceed with implementation?
Any update on this? :)
I'm not sure if it's already been suggested, but what about only showing a note if the trait is not object-safe?
I like suggestion to only show when a trait is not object safe, since that's the more unusual condition. If we do that, it doesn't fit logically under "Implementors" anymore. If we proceed with only marking non-object-safe traits, here are a couple of ideas: Add a section after the top-doc, but before "Implementors", called "Object Safety", and put the text there. Add information to the documentation of any method that causes the trait to be not object-safe.
I think it’s still fine to mention under “Implementors” like “This trait is not object safe: doesn’t implement ”, but I also like the idea of the new section. I see this issue doesn’t have an assignee currently, can I claim this?
You can but since we didn't reach a consensus, any PR would hang around until we reach one.


Question: config.as_ref().cloned().unwrap_or_else(|| PathBuf::from(default)) } <del> fn prepare_dir(mut path: PathBuf) -> String { </del> <ins> fn prepare_dir(destdir_env: &Option<PathBuf>, mut path: PathBuf) -> String { </ins> // The DESTDIR environment variable is a standard way to install software in a subdirectory // while keeping the original directory structure, even if the prefix or other directories // contain absolute paths. // // More information on the environment variable is available here: // https://www.gnu.org/prep/standards/html_node/DESTDIR.html <del> if let Some(destdir) = env::var_os("DESTDIR").map(PathBuf::from) { // Sanity check for the user write access on DESTDIR assert!(is_dir_writable_for_user(&destdir), "User doesn't have write access on DESTDIR."); </del> <ins> if let Some(destdir) = destdir_env { </ins> let without_destdir = path.clone(); <del> path = destdir; </del> <ins> path = destdir.clone(); </ins> // Custom .join() which ignores disk roots. for part in without_destdir.components() { if let Component::Normal(s) = part {

hey everyone, I get this message from when is executed: It seems there are some backports still missing for beta, since I can fix this by reverting locally, and there are some subsequent fixes in nightly who seemed to have fixed the issue for good. So, is there somewhere a list of the nightly backports needed to fix this problem? Thanks.
can I ping you on this? Beta is not compiling on gentoo, I assume at least one patch from nightly still needs to be backported to beta.
There is that should have fixed that and it's .
Hi, I'm on latest beta from last week. If I apply locally and compile, I get access denied error:
Logs says you don't have permission to put files into path from your build configuration. Without you would still get permission error.
I believe this is a sandbox error, so x.py install tries to write to / instead of it's prefix, and this is caused either by or it was already introduced by the older If I revert them both locally, I get a working x.py install
Interesting :thinking: Can you share your build configuration?
it basically does this: which translates to: and the patch seems to make x.py ignore the DESTDIR="" command In the rust context, the build config you asked me to share is the Have it attached for you, please feel free to ask for any additional information. also I can provide you with the full build log:
Did you wait for whole process(x.py install) to be finished? I don't understand how mkdir gets you into access denied error for path while you can actually create dirs/files in it..
Maybe there is some confusion about relative and absolute path? The access denied error is valid, as x.py never should mess with /usr/lib/ in install, but use /var/tmp/portage/dev-lang/rust-1.74.0_beta/image/ as it's prefix, if you want to name it like that.
True, there is a confusion between prefix and DESTDIR right now. I will fix it today.
Thank you, I'm happy to test any patch before you commit it to master.
You can test
yes this works for me, please also beta nominate
has this been beta-nominated? I'm new to this process, it's just I can't see a rollup pullrequest anywhere and the release of 1.74.0 is coming closer every day.


Question: config.as_ref().cloned().unwrap_or_else(|| PathBuf::from(default)) } <del> fn prepare_dir(mut path: PathBuf) -> String { </del> <ins> fn prepare_dir(destdir_env: &Option<PathBuf>, mut path: PathBuf) -> String { </ins> // The DESTDIR environment variable is a standard way to install software in a subdirectory // while keeping the original directory structure, even if the prefix or other directories // contain absolute paths. // // More information on the environment variable is available here: // https://www.gnu.org/prep/standards/html_node/DESTDIR.html <del> if let Some(destdir) = env::var_os("DESTDIR").map(PathBuf::from) { // Sanity check for the user write access on DESTDIR assert!(is_dir_writable_for_user(&destdir), "User doesn't have write access on DESTDIR."); </del> <ins> if let Some(destdir) = destdir_env { </ins> let without_destdir = path.clone(); <del> path = destdir; </del> <ins> path = destdir.clone(); </ins> // Custom .join() which ignores disk roots. for part in without_destdir.components() { if let Component::Normal(s) = part {

It is cc
for backport, the PR's responsible team (T-bootstrap) also needs to label it beta-accepted. Once it has both labels, the release team will handle the actual backport.


Question: <ins> trait Hello { fn example(val: ()); } struct Test1(i32); impl Hello for Test1 { fn example(&self, input: &i32) { //~^ ERROR `&self` declaration in the impl, but not in the trait *input = self.0; //~^ ERROR cannot assign to `*input`, which is behind a `&` reference } } fn main() {} </ins>

<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'index out of bounds: the len is 1 but the index is 1'', 'thread 'rustc' panicked at 'index out of bounds: the len is 1 but the index is 1'' 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: [mirborrowck] borrow-checking [analysis] running analysis passes on this crate --
cc
label +D-diagnostic-infra -needs-triage