Question: <ins> // revisions: cfail #![feature(const_generics, const_evaluatable_checked)] #![allow(incomplete_features)] // regression test for #77650 fn c<T, const N: std::num::NonZeroUsize>() where [T; N.get()]: Sized, { use std::convert::TryFrom; <[T; N.get()]>::try_from(()) //~^ error: the trait bound //~^^ error: mismatched types } 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 #77650 fn c<T, const N: std::num::NonZeroUsize>() where [T; N.get()]: Sized, { use std::convert::TryFrom; <[T; N.get()]>::try_from(()) //~^ error: the trait bound //~^^ error: mismatched types } 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: use polonius_engine::Atom; pub use rustc_ast::ast::Mutability; <del> use rustc_ast::ast::{InlineAsmOptions, InlineAsmTemplatePiece}; </del> use rustc_data_structures::fx::FxHashSet; use rustc_data_structures::graph::dominators::{dominators, Dominators}; use rustc_data_structures::graph::{self, GraphSuccessors};

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


Question: pub enum TrailingToken { None, Semi, <ins> Gt, </ins> /// If the trailing token is a comma, then capture it /// Otherwise, ignore the trailing token MaybeComma,

Found with The attribute applies to The was initially lexed as part of a token This seems to be exactly the case described by the : <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Do you have any suggestion for this case? The code path is going like this: Parser eat the first one of '' at here and set : fall pass at here: So this assertion is failed: The result is: and is true. Seems the assertion missed this scenario, do we need to add a TrailingToken::Gt ?
The assertion I wrote is overly conservative - it really just needs to check that we don't simultaneously break a token and 'really' capture a trailing token. Specifically, we only need to panic if we actually incremented in the match block. I think the simplest fix would be to add a variable, which gets set to in the parts of the block that increment . The assertion can then be changed to breaklasttoken


Question: /// Builds the whole `assert!` expression. For example, `let elem = 1; assert!(elem == 1);` expands to: /// /// ```rust <del> /// #![feature(generic_assert_internals)] </del> /// let elem = 1; /// { ///   #[allow(unused_imports)]

<!-- 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: Note that is not marked as internal I expected to see this happen: code compiles Instead, this happened: ` Maybe the lint should ignore code from expansions? <!-- 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. --:
On , the expansion of with contains a call to : is tagged with , but not .


Question: "only the last field of a struct or enum variant  may have a dynamically sized type") } <ins> traits::ObjectSized => { span_note!(tcx.sess, obligation.cause.span, "only sized types can be made into objects"); } </ins> } }

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


Question: <ins> error[E0371]: the object type `(dyn Object + Marker2 + 'static)` automatically implements the trait `Marker1` --> $DIR/coherence-impl-trait-for-marker-trait-negative.rs:14:1 | LL | impl !Marker1 for dyn Object + Marker2 { }   //~ ERROR E0371 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `(dyn Object + Marker2 + 'static)` automatically implements trait `Marker1` error[E0371]: the object type `(dyn Object + Marker2 + 'static)` automatically implements the trait `Marker2` --> $DIR/coherence-impl-trait-for-marker-trait-negative.rs:16:1 | LL | impl !Marker2 for dyn Object + Marker2 { }   //~ ERROR E0371 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `(dyn Object + Marker2 + 'static)` automatically implements trait `Marker2` error[E0117]: only traits defined in the current crate can be implemented for arbitrary types --> $DIR/coherence-impl-trait-for-marker-trait-negative.rs:22:1 | LL | impl !Send for dyn Marker2 {} //~ ERROR E0117 | ^^^^^^^^^^^^^^^^^^^^^^^^^^ impl doesn't use types inside crate | = note: the impl does not reference only types defined in this crate = note: define and implement a trait or new type instead error[E0321]: cross-crate traits with a default impl, like `std::marker::Send`, can only be implemented for a struct/enum type, not `(dyn Object + 'static)` --> $DIR/coherence-impl-trait-for-marker-trait-negative.rs:26:1 | LL | impl !Send for dyn Object {} //~ ERROR E0321 | ^^^^^^^^^^^^^^^^^^^^^^^^^ can't implement cross-crate trait with a default impl for non-struct/enum type error[E0321]: cross-crate traits with a default impl, like `std::marker::Send`, can only be implemented for a struct/enum type, not `(dyn Object + Marker2 + 'static)` --> $DIR/coherence-impl-trait-for-marker-trait-negative.rs:27:1 | LL | impl !Send for dyn Object + Marker2 {} //~ ERROR E0321 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ can't implement cross-crate trait with a default impl for non-struct/enum type error: aborting due to 5 previous errors Some errors occurred: E0117, E0321, E0371. For more information about an error, try `rustc --explain E0117`. </ins>

Code gives the same error as , giving (dyn Xyz + Abc + 'static)XyzCode passes coherence, but wfcheck fails because of the confusion:


Question: let prefix = default_path(&builder.config.prefix, "/usr/local"); let sysconfdir = prefix.join(default_path(&builder.config.sysconfdir, "/etc")); <ins> let destdir_env = env::var_os("DESTDIR").map(PathBuf::from); </ins> <del> // Sanity check for the user write access on prefix and sysconfdir assert!( is_dir_writable_for_user(&prefix), "User doesn't have write access on `install.prefix` path in the `config.toml`.", ); assert!( is_dir_writable_for_user(&sysconfdir), "User doesn't have write access on `install.sysconfdir` path in `config.toml`." ); </del> <ins> // Sanity checks on the write access of user. // // When the `DESTDIR` environment variable is present, there is no point to // check write access for `prefix` and `sysconfdir` individually, as they // are combined with the path from the `DESTDIR` environment variable. In // this case, we only need to check the `DESTDIR` path, disregarding the // `prefix` and `sysconfdir` paths. if let Some(destdir) = &destdir_env { assert!(is_dir_writable_for_user(destdir), "User doesn't have write access on DESTDIR."); } else { assert!( is_dir_writable_for_user(&prefix), "User doesn't have write access on `install.prefix` path in the `config.toml`.", ); assert!( is_dir_writable_for_user(&sysconfdir), "User doesn't have write access on `install.sysconfdir` path in `config.toml`." ); } </ins> let datadir = prefix.join(default_path(&builder.config.datadir, "share")); let docdir = prefix.join(default_path(&builder.config.docdir, "share/doc/rust"));

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: let prefix = default_path(&builder.config.prefix, "/usr/local"); let sysconfdir = prefix.join(default_path(&builder.config.sysconfdir, "/etc")); <ins> let destdir_env = env::var_os("DESTDIR").map(PathBuf::from); </ins> <del> // Sanity check for the user write access on prefix and sysconfdir assert!( is_dir_writable_for_user(&prefix), "User doesn't have write access on `install.prefix` path in the `config.toml`.", ); assert!( is_dir_writable_for_user(&sysconfdir), "User doesn't have write access on `install.sysconfdir` path in `config.toml`." ); </del> <ins> // Sanity checks on the write access of user. // // When the `DESTDIR` environment variable is present, there is no point to // check write access for `prefix` and `sysconfdir` individually, as they // are combined with the path from the `DESTDIR` environment variable. In // this case, we only need to check the `DESTDIR` path, disregarding the // `prefix` and `sysconfdir` paths. if let Some(destdir) = &destdir_env { assert!(is_dir_writable_for_user(destdir), "User doesn't have write access on DESTDIR."); } else { assert!( is_dir_writable_for_user(&prefix), "User doesn't have write access on `install.prefix` path in the `config.toml`.", ); assert!( is_dir_writable_for_user(&sysconfdir), "User doesn't have write access on `install.sysconfdir` path in `config.toml`." ); } </ins> let datadir = prefix.join(default_path(&builder.config.datadir, "share")); let docdir = prefix.join(default_path(&builder.config.docdir, "share/doc/rust"));

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: issued_borrow.borrowed_place, &issued_spans, ); <ins> self.explain_iterator_advancement_in_for_loop_if_applicable( &mut err, span, &issued_spans, ); </ins> err }

<!-- 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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: or similar. The note and/or help are both subject to changes, this is just a basic idea. We could also conceivably rewrite the error message to expand on what the note says, like so: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
It's hard to get 'c' in line 3 during the context where the compiler errors out the second mutable borrow message, because the mutable borrow happens between
I don't think it's critical to mention in the diagnostic. We shouldn't let the difficulty of doing that stop us from trying to improve the message. label +D-newcomer-roadblock
I'd love to try to fix this, but sadly I'm not familiar with the internals of rustc. If someone could point me towards the section where this error is, I could give it a try.
Hi ! Whenever I try to dive into fixing a problem with rustc, I usually start with a search through the codebase. In this case, I'd search for strings that come from the error message: , , or : <img width="528" alt="image" src="https://user-"And that leads me to here: So then I'd use rust-analyzer to try to find all the usages of that method.


Question: issued_borrow.borrowed_place, &issued_spans, ); <ins> self.explain_iterator_advancement_in_for_loop_if_applicable( &mut err, span, &issued_spans, ); </ins> err }

In this case, turns out there's only one: And there we see that there is already some conditional suggestion being made; it calls . And it seems there's a family of those . So I think it would make sense to try to write your own or something like that. You'll need to figure out how to sort of "back track" from the MIR back to the HIR or the AST so you can figure out whether you're inside a loop. I would study the code in to try to figure out how to do that. And don't forget to write a handful of regression tests in somewhere, maybe in : https://rustc-dev- It might also be possible to perform this check at a higher level, say, in . If you can figure out that you're in a for loop, and that the user is trying to call on the iterator, then you could raise the error then.


Question: <ins> // This test certify that we can mix attribute macros from Rust and external proc-macros. // For instance, `#[derive(Default)]` uses `#[default]` and `#[derive(SmartPointer)]` uses // `#[pointee]`. // The scoping rule should allow the use of the said two attributes when external proc-macros // are in scope. //@ check-pass //@ aux-build: another-proc-macro.rs //@ compile-flags: -Zunpretty=expanded #![feature(derive_smart_pointer)] #[macro_use] extern crate another_proc_macro; #[pointee] fn f() {} #[default] fn g() {} </ins>

https://crater- https://crater- cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc
label F-derivesmartpointer
Thread on zulip: https://rust-
claim
WG-prioritization assigning priority (). label -I-prioritize +P-high


Question: /// This function should maybe change to /// `new_const<const MSG: &'static str>(kind: ErrorKind)` /// in the future, when const generics allow that. <ins> #[inline] </ins> pub(crate) const fn new_const(kind: ErrorKind, message: &'static &'static str) -> Error { Self { repr: Repr::SimpleMessage(kind, message) } }

I am facing a problem while reading different kinds of binary formats. If you are going to read primitives like too often, then performance degrades. This is mainly due to the fact that returns box. Also it does boxing TWICE! doc link: I wrote simple bench to show pref problem. Use to get it We can clearly see that performance is degrading. The more calls it takes to read, the worse the results will be. The first very popular crate that comes to mind is . It mainly depends on the data format. But what if you need to receive data over the network? The attacker may abuse wrong data to make ton of pointless memory allocations. stdlib is also use often enough. Let's run a simple bash to make sure of this In many cases, you will see that it is used . stdlib sometimes create with macro, however it doesn't happen very often. Consider adding a new static method such as and new internal member of that's enum. How about using something like , but with static lifetime? : Update 07.03.2021: Benchmarks have been improved as per the comment. This should show the problem better.
The "std_err" bench is still pretty slow though
Yes, I probably made a mistake while copying the code for the benchmark of . It should be . However, this shows that not zero-cost.
This is fixed by
Turns out it was three times, if you also count the that the is copied into.
Running your benchmark (thanks!): Before: After: Looks like it isn't completely solved yet. Adding to now... :)
That fixed it.


Question: } } <ins> pub mod signal { use libc::types::os::arch::c95::c_int; use libc::types::os::common::posix01::sighandler_t; #[cfg(not(target_os = "android"))] extern { pub fn signal(signum: c_int, handler: sighandler_t) -> sighandler_t; } #[cfg(target_os = "android")] extern { #[link_name = "bsd_signal"] pub fn signal(signum: c_int, handler: sighandler_t) -> sighandler_t; } } </ins> pub mod wait { use libc::types::os::arch::c95::{c_int}; use libc::types::os::arch::posix88::{pid_t};

Scripts to reproduce Steps to reproduce: Output:  Backtrace: None Exit code: 141 Version:
What are you expecting to happen? When you send a TERM signal to a process without a registered handler, it terminates promptly. The runtime currently doesn't register any TERM/INT handlers, that's up to you.
I was expecting the runtime to return some upon requesting an action from a defunct process. I also tried polling the state of the defunct process using (as mentioned in the ), but this returned as well. Even if the runtime dosn't "catch" the SIG{TERM,INT}, is it not possible at all to or return in any of the two cases mentioned above?
Oh whoops, sorry! I had my understanding backwards, and apparently this isn't a bug on OSX which caused more confusion for me. Anyway, closing as a dupe of , it's the same cause.
Oh wow, I've done it again. I'm sorry, again! I apologize for not investigating more thoroughly. This is indeed separate from


Question: <ins> // Regression test for #54779, checks if the diagnostics are confusing. #![feature(nll)] trait DebugWith<Cx: ?Sized> { fn debug_with<'me>(&'me self, cx: &'me Cx) -> DebugCxPair<'me, Self, Cx> { DebugCxPair { value: self, cx } } fn fmt_with(&self, cx: &Cx, fmt: &mut std::fmt::Formatter<'_>) -> std::fmt::Result; } struct DebugCxPair<'me, Value: ?Sized, Cx: ?Sized> where Value: DebugWith<Cx>, { value: &'me Value, cx: &'me Cx, } trait DebugContext {} struct Foo { bar: Bar, } impl DebugWith<dyn DebugContext> for Foo { fn fmt_with( &self, cx: &dyn DebugContext, fmt: &mut std::fmt::Formatter<'_>, ) -> std::fmt::Result { let Foo { bar } = self; bar.debug_with(cx); //~ ERROR: lifetime may not live long enough Ok(()) } } struct Bar {} impl DebugWith<dyn DebugContext> for Bar { fn fmt_with( &self, cx: &dyn DebugContext, fmt: &mut std::fmt::Formatter<'_>, ) -> std::fmt::Result { Ok(()) } } fn main() {} </ins>

This example: gives this error: It took me some time to puzzle out what was happening here: expands to the default from the impl however is the impl method is accepted because it is more general than the trait definition but it fails to recursively invoke The error message without NLL, of course, is also not very illuminating.
Assigning myself to bookmark.
This seems to be a persistent ergonomics wart where traits get evaluated to (happens as well with returning and others I can't remember now) where it isn't expected. It is a bit sad, and we can improve the diagnostic errors, but I'm worried we'll be unable to preempt all the cases from being caught by accurate diagnostics, pushing people away from deeply nested structures. Maybe that is for the best, though.
I just want to note that the use of is, I think, a red herring in terms of the complaint about the diagnostic here. That is, I get the exact same diagnostic even if I add an explicit binder to the method, and then one can remove the . This is relevant because it means that if that feature is a red herring, then this bug may be relevant to the 2018 edition.
discussed with . We agreed this is not a blocker for 2018 edition. Tagging with NLL-deferred so it does not clog up our triage process.
I forgot to actual test how migration-mode (enabled for the 2018 edition) compares to . <detailsCurrent (nightly) 2018 edition output (): Current (nightly) output with (): </details
As for this week's triage, tagging this as P-medium priority.
I recently landed some changes ( and ) that are tangentially related to this but a similar strategy to them could be applied to this case.
Since feature has been removed, can this issue be closed as obsolete?
The example without : The error message isn't the same as migrate mode, but is on-par in terms of information (pointing out that the anonymous lifetime doesn't live as long as ). This issue can be closed by adding the above as a test.


Question: <ins> // aux-build:issue-99221-aux.rs // build-aux-docs // ignore-cross-compile #![crate_name = "foo"] #[macro_use] extern crate issue_99221_aux; pub use issue_99221_aux::*; // @count foo/index.html '//a[@class="macro"]' 1 mod inner { #[macro_export] macro_rules! print { () => () } } </ins>

I tried to create a minimum example from an issue we've seen in our project (). I tried running: On the following crate: : I expected to see this happen: The command should succeed. Instead, this happened: It crashed with an ICE <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details
This issue may be related to , however I can only reproduce it on the nightly build. On the stable channel, rustdoc succeeds.
cc
does this reproduce on beta?
I know I'm not celinval, but I've been able to reduce this to a test case, and yeah, it reproduces on beta.
That was quick. Thank you!
Reopening to track beta breakage.
I was silly and nominated even though the PR has already been nominated, and that's really the thing that's supposed to be. Please ignore, and sorry for the noise.


Question: map.insert("required-associated-consts".into(), 1); map.insert("required-methods".into(), 1); map.insert("provided-methods".into(), 1); <ins> map.insert("object-safety".into(), 1); </ins> map.insert("implementors".into(), 1); map.insert("synthetic-implementors".into(), 1); map.insert("implementations-list".into(), 1);

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: map.insert("required-associated-consts".into(), 1); map.insert("required-methods".into(), 1); map.insert("provided-methods".into(), 1); <ins> map.insert("object-safety".into(), 1); </ins> map.insert("implementors".into(), 1); map.insert("synthetic-implementors".into(), 1); map.insert("implementations-list".into(), 1);

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: }) { let (child_field_idx, child_capture) = child_captures.next().unwrap(); <ins> // This analysis only makes sense if the parent capture is a // prefix of the child capture. assert!( child_capture.place.projections.len() >= parent_capture.place.projections.len(), "parent capture ({parent_capture:#?}) expected to be prefix of  child capture ({child_capture:#?})" ); </ins> // Store this set of additional projections (fields and derefs). // We need to re-apply them later. let child_precise_captures =

This bug only happens when calling a method on two different referenced variables inside an async closure. For some reason, this bug will not happen if the lines are flipped (calling it on test first then temp). It also will not happen if test isn't cloned outside the closure first. This will error: This will not: Neither will: Nor will: But if both the order is flipped and the line order is flipped it will crash (variable name changed to make sure shadowing wasn't the issue): This setup for the bug was found entirely through trial and error. The original issue was found in a nightly build of a project I'm working on (). This bug was introduced in the latest version of nightly (2024-04-08). It was not present in 2024-04-07. rustc 1.79.0-nightly ( 2024-04-08) binary: rustc commit-hash: commit-date: 2024-04-08 host: x8664-pc-windows-msvc release: 1.79.0-nightly LLVM version: 18.1.3 ICE txt file:
thank you for producing these examples; they're very helpful. i will have a fix out tomorrow, sorry for the inconvenience and hope it doesn't discourage you from testing async closures more.
Wow, that was quick! Thanks, I'll make sure to report any more I come across, I plan on implementing more async closures into the project with my next big refactor because of how helpful they are.


Question: /// } /// ``` #[inline] <del> #[unstable(feature = "needs_drop", issue = "41890")] </del> <ins> #[stable(feature = "needs_drop", since = "1.22.0")] </ins> pub fn needs_drop<T>() -> bool { unsafe { intrinsics::needs_drop::<T>() } }

About to submit a PR for exposing intrinsics::needs_drop under mem. Needs a tracking issue. Here it is!
The PR is
fcp merge Seems like this may be good to stabilize!
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.


Question: let tcx = self.infcx.tcx; let generics = tcx.generics_of(self.mir_def_id); let param = generics.type_param(&param_ty, tcx); <del> if let Some(generics) = tcx.hir().get_generics(self.mir_def_id) { </del> <ins> if let Some(generics) = tcx.hir().get_generics(tcx.closure_base_def_id(self.mir_def_id)) { </ins> suggest_constraining_type_param( generics, &mut err,

I encounter an ICE: with rustc 1.41.0-nightly ( 2019-12-06) running on x86_64-pc-windows-msvc when compiling The Stable compiler outputs But Nightly crashed.
Confirmed on Linux too. <details<summaryBacktrace</summary</details
Reduced slightly:
cc
Really reduced: This comes from this unwrap: The used should be


Question: //////////////////////////////////////////////////////////////////////////////// #[macro_use] mod local; <del> #[macro_use] mod scoped; </del> <ins> #[macro_use] mod scoped_tls; </ins> #[stable(feature = "rust1", since = "1.0.0")] pub use self::local::{LocalKey, LocalKeyState};

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


Question: <ins> error[E0277]: expected a `FnOnce<(&mut UIView<'_, T>,)>` closure, found `F` --> $DIR/issue-100690.rs:37:23 | LL |         real_dispatch(f) |         ------------- ^ expected an `FnOnce<(&mut UIView<'_, T>,)>` closure, found `F` |         | |         required by a bound introduced by this call | = note: expected a closure with arguments `(&mut UIView<'a, T>,)` found a closure with arguments `(&mut UIView<'_, T>,)` note: required by a bound in `real_dispatch` --> $DIR/issue-100690.rs:9:8 | LL | fn real_dispatch<T, F>(f: F) -> Result<(), io::Error> |    ------------- required by a bound in this ... LL |     F: FnOnce(&mut UIView<T>) -> Result<(), io::Error> + Send + 'static, |        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ required by this bound in `real_dispatch` error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>

Sorry, this is not necessarily the smallest possible example. Please let me know if this is unhelpful and I'll come up with something more concise. Given the following code: The output in current stable (1.63.0) is: (Please note the "expected closure with ... found closure with ..." hint.) From 1.64 onwards, the expected/found hint is omitted: To me the 1.63 behaviour is preferable to that from 1.64+ as it can often be non-obvious where the differences lie.
searched nightlies: from nightly-2022-06-01 to nightly-2022-08-11 regressed nightly: nightly-2022-07-23 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Looks like it was caused by , which is pretty big diagnostics PR in that rollup. cc
Of course I caused it.
label -E-needs-bisection
WG-prioritization assigning priority (). label -I-prioritize +P-medium


Question: <ins> error: unexpected closing delimiter: `}` --> $DIR/issue-98601-delimiter-error-1.rs:7:1 | LL | fn foo() { |          - this delimiter might not be properly closed... LL |     match 0 { LL |       _ => {} |            -- block is empty, you might have not meant to close it ... LL |     } |     - ...as it matches this but it has different indentation LL | } | ^ unexpected closing delimiter error: aborting due to previous error </ins>

See: This code: produces on latest stable (1.61.0).
Maybe we could form a heuristic around tokens that we know should eventually be followed by -- , , , etc. If we see one of those, (then some random other tokens), then we see , then that would be a suspicious rbrace which we could point out later.. e.g. if we see that triggers the heuristic, but not
The problem is that the error happens in the lexer, not the parser. Ideally we'd rework the lexer to have a token stream mode of operation instead of a token tree mode of operation, only for code that is being passed to the parser (i.e., not coming from a macro).
This is particularly confusing when the points to a macro: gives on 1.65.0-nightly (2022-08-31 )
the output now changed to: Do you think the should be removed?
This is changed to: it seems more helpful now.
Let's close this ticket after adding these two cases to the test suite then. I'm sure there are outstanding issues in this area, but we can hope that we'll get tickets for those more specific cases, while the tests keep us from regressing silently (hopefully, lets make sure the tests are fully annotated so its harder to do that by accident).


Question: // compile-flags: -O // min-llvm-version: 15.0 <del> #![crate_type="lib"] </del> <ins> #![crate_type = "lib"] </ins> use std::mem::MaybeUninit;

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


Question: println!("`x.py` will now use the configuration at {}", include_path.display()); let build = TargetSelection::from_user(&env!("BUILD_TRIPLE")); <del> let stage_path = ["build", build.rustc_target_arg(), "stage1"].join("/"); </del> <ins> let stage_path = ["build", build.rustc_target_arg(), "stage1"].join(&MAIN_SEPARATOR.to_string()); </ins> println!();

I tried this code on a fresh git clone of rust-lang/rust: I expected to see this happen: setup works without errors. Instead, this happened: x.py gives an error: This feature was introduced in and worked at that time. do you have time to look into this? The original bug report was from Nazar Mokrynskyi , not sure their github username. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Yes, I'll take a look over the next few days.
Hello. Is there a workaround for this issue for now? I got But when I ran , I got .
OK. After reading the zulip thread, I figured out how to work around it. After running , succeeded.
claim


Question: let result_subst = CanonicalVarValues { var_values: self.tcx.mk_args_from_iter( query_response.variables.iter().enumerate().map(|(index, info)| { <del> if info.is_existential() { </del> <ins> if info.universe() != ty::UniverseIndex::ROOT { // A variable from inside a binder of the query. While ideally these shouldn't // exist at all, we have to deal with them for now. self.instantiate_canonical_var(cause.span, info, |u| { universe_map[u.as_usize()] }) } else if info.is_existential() { </ins> match opt_values[BoundVar::new(index)] { Some(k) => k, None => self.instantiate_canonical_var(cause.span, info, |u| {

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


Question: /// ```rust /// # use std::fmt::Write; /// # let mut buf = String::new(); <del> /// /// // Bad </del> /// writeln!(buf, ""); <del> /// /// // Good /// writeln!(buf); </del> /// ``` pub WRITELN_EMPTY_STRING, style,

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


Question: /// ```rust /// # use std::fmt::Write; /// # let mut buf = String::new(); <del> /// /// // Bad </del> /// writeln!(buf, ""); <del> /// /// // Good /// writeln!(buf); </del> /// ``` pub WRITELN_EMPTY_STRING, style,

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


Question: /// ```rust /// # use std::fmt::Write; /// # let mut buf = String::new(); <del> /// /// // Bad </del> /// writeln!(buf, ""); <del> /// /// // Good /// writeln!(buf); </del> /// ``` pub WRITELN_EMPTY_STRING, style,

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


Question: /// ```rust /// # use std::fmt::Write; /// # let mut buf = String::new(); <del> /// /// // Bad </del> /// writeln!(buf, ""); <del> /// /// // Good /// writeln!(buf); </del> /// ``` pub WRITELN_EMPTY_STRING, style,

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


Question: assert!(plan.iter().any(|s| s.name.contains("-ui"))); assert!(plan.iter().any(|s| s.name.contains("cfail"))); <del> assert!(plan.iter().any(|s| s.name.contains("cfail"))); </del> assert!(plan.iter().any(|s| s.name.contains("cfail-full"))); assert!(plan.iter().any(|s| s.name.contains("codegen-units"))); assert!(plan.iter().any(|s| s.name.contains("debuginfo")));

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


Question: <ins> // Copyright 2016 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #![crate_type="lib"] pub enum Foo { FooV { data: () } } </ins>

rustc crashes when compiling the following source code. I expect this to compile or report error. Instead the compiler crashed.
Reduced testcase:
This also causes an ICE with the latest nightly:
Any update on the issue. Please let me know if you need more information. Thanks


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

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


Question: i -= 1u; } <del> let mut val = s[i] as uint; </del> <ins> let mut val = s[i] as u32; </ins> let w = UTF8_CHAR_WIDTH[val] as uint; assert!((w != 0));

We need some way to interpret a as UTF-8, using the replacement character for invalid sequences instead of conditions. This would ideally be provided in the form of an .
Could we remove the current condition API in favour of this? It doesn't really seem to offer anything but failing, and we already have an API returning an .
I would be quite pleased if we could do that. Using the condition is rather awkward, and I would rather just have replacement chars myself.
This is a duplicate of , no?
And also the e-mail thread here I think is relevant:
This is an implementation of a mostly complete → UTF-8 decoder
It's only a duplicate if the intended resolution of is to use the replacement char instead of conditions, but it's unclear from the discussion if that's the plan.
I guess my thinking was that a maximally expressive condition-based solution would let one express a replacement char approach using conditions. But I don't actually favor doing that at this point. Or at least, I don't favor making that the only way to accomplish this, since I suspect a more specialized approach will be much nicer to use (both in terms of programmer convenience and in terms of efficiency). So okay, this is not a duplicate of .
Rust needs to support both fatal and replacement error handling modes, it should follow the WHATWG spec simonsapin has said (edit by is WHATWG spec.)
the fatal mode is already handled by the API
well, the current functions in str don't handle decoding buffers in chunks like the proposed encodings API. But yes, it does handle one-off decoding with 'fatal' error handling.
I think we need to improve/extend our API along the lines suggested here for 1.0. Nominating for P-backcompat-lang. (Arguably we could avoid the backwards compatibility hazard by offering a fail-only method for 1.0 and then adding an alternative entry point that provides the more flexible API supporting replacement characters in post 1.0. But I think this case is important enough that we should try to get the primary API method to provide both choices up front. That, or put dynamic fluid support in for representing the state of that choice.)
I submitted a PR for this last night, although I forgot there was an open issue too so I didn't link them. The PR is


Question: <del> #![feature(inherent_associated_types)] #![allow(dead_code, incomplete_features)] #![crate_type = "lib"] #![deny(unused_attributes)] // run-rustfix pub trait Trait { type It; const IT: (); fn it0(); fn it1(); fn it2(); } pub struct Implementor; impl Implementor { #[doc(hidden)] // no error type Inh = (); #[doc(hidden)] // no error const INH: () = (); #[doc(hidden)] // no error fn inh() {} } impl Trait for Implementor { #[doc(hidden)] type It = (); //~^^ ERROR `#[doc(hidden)]` is ignored //~|  WARNING this was previously accepted #[doc(hidden)] const IT: () = (); //~^^ ERROR `#[doc(hidden)]` is ignored //~|  WARNING this was previously accepted #[doc(hidden, alias = "aka")] fn it0() {} //~^^ ERROR `#[doc(hidden)]` is ignored //~|  WARNING this was previously accepted #[doc(alias = "this", hidden,)] fn it1() {} //~^^ ERROR `#[doc(hidden)]` is ignored //~|  WARNING this was previously accepted #[doc(hidden, hidden)] fn it2() {} //~^^ ERROR `#[doc(hidden)]` is ignored //~|  WARNING this was previously accepted //~|  ERROR `#[doc(hidden)]` is ignored //~|  WARNING this was previously accepted } </del>

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


Question: <del> #![feature(inherent_associated_types)] #![allow(dead_code, incomplete_features)] #![crate_type = "lib"] #![deny(unused_attributes)] // run-rustfix pub trait Trait { type It; const IT: (); fn it0(); fn it1(); fn it2(); } pub struct Implementor; impl Implementor { #[doc(hidden)] // no error type Inh = (); #[doc(hidden)] // no error const INH: () = (); #[doc(hidden)] // no error fn inh() {} } impl Trait for Implementor { #[doc(hidden)] type It = (); //~^^ ERROR `#[doc(hidden)]` is ignored //~|  WARNING this was previously accepted #[doc(hidden)] const IT: () = (); //~^^ ERROR `#[doc(hidden)]` is ignored //~|  WARNING this was previously accepted #[doc(hidden, alias = "aka")] fn it0() {} //~^^ ERROR `#[doc(hidden)]` is ignored //~|  WARNING this was previously accepted #[doc(alias = "this", hidden,)] fn it1() {} //~^^ ERROR `#[doc(hidden)]` is ignored //~|  WARNING this was previously accepted #[doc(hidden, hidden)] fn it2() {} //~^^ ERROR `#[doc(hidden)]` is ignored //~|  WARNING this was previously accepted //~|  ERROR `#[doc(hidden)]` is ignored //~|  WARNING this was previously accepted } </del>

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


Question: debug!("ty_generics_for_trait(trait_id={:?}, substs={:?})", ccx.tcx.map.local_def_id(trait_id), substs); <del> let mut generics = ty_generics_for_type_or_impl(ccx, ast_generics); </del> <ins> let mut generics = ty_generics_for_type(ccx, ast_generics); </ins> // Add in the self type parameter. //

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: self.verbose > 0 } <ins> pub fn symlink_file<P: AsRef<Path>, Q: AsRef<Path>>(&self, src: P, link: Q) -> io::Result<()> { #[cfg(unix)] use std::os::unix::fs::symlink as symlink_file; #[cfg(windows)] use std::os::windows::fs::symlink_file; if !self.dry_run() { symlink_file(src.as_ref(), link.as_ref()) } else { Ok(()) } } </ins> pub(crate) fn create(&self, path: &Path, s: &str) { if self.dry_run() { return;

broke the rust-analyzer config we suggest in the dev-guide: https://rustc-dev- since now rustfmt is in instead of . Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Hi! Just to clarify, the idea is to change to code to match the docs?
I think the idea is changing the docs to match the new behavior.
For reference:
I'd prefer to change the code so that we don't force all contributors to update their config.
I don't think we can put the binary back, or at least, that feels iffy - we'd be trying to overlap two different sysroots. rustfmt used to be statically linked to libstd and librustc_driver, but that's no longer the case.
I suppose we could try to create a symlink from the old path to the new one? That might work, not sure.
Maybe add a proxy? On Linux it might just be
A symlink seems like a good solution to me.
Does the symlink still finds the correct so?
try it and see
I'll experiment adding a symlink.
On Windows, creating a symlink does not find the needed DLLs. Trying to execute the symlink pops two msgbox saying that it doesn't find the and DLLs. You would need to symlink also the DLLs. On Linux, it does find the correct SOs.
Symlinking also works on macOS.
Ok, this is pretty messy. How about doing both: Add the symlink, which will work with both the old and new config on Mac and Linux Update the recommended config in the dev-guide, which will help contributors fix the error message on Windows and from there we can work long-term to using the same toolchain for rustfmt and other tools, without having a time pressure.
cc ,
May I get some guidance and the creation of the symlink? Do I use rust to create the symlink in after the rustfmt_path line or do I use a bash command? If I do use a bash command, is there a file I should be adding it to? Thank you!
use
And just to confirm, I use that symlink function here?


Question: self.verbose > 0 } <ins> pub fn symlink_file<P: AsRef<Path>, Q: AsRef<Path>>(&self, src: P, link: Q) -> io::Result<()> { #[cfg(unix)] use std::os::unix::fs::symlink as symlink_file; #[cfg(windows)] use std::os::windows::fs::symlink_file; if !self.dry_run() { symlink_file(src.as_ref(), link.as_ref()) } else { Ok(()) } } </ins> pub(crate) fn create(&self, path: &Path, s: &str) { if self.dry_run() { return;

yes
I think it would be possible to move rustfmt back to the same sysroot as the bootstrap compiler by only taking , and from the nightly rustc component and not copying any other files like the rustc binary. and both contain a hash in their name unique for each rustc version. should contain the rustc version, so that shouldn't conflict either.
Doing the same with the DLLs on Windows could also work.
related (different error with rustfmt, but caused by the same change):
Hi any progress on the symlink? happy to help out if you're running into trouble :)
Hey ! Thanks for reaching out! I'll be starting tomorrow and will reach out to you if/when I need help! Apologies for the delay!


Question: <ins> error: using function pointers as const generic parameters is forbidden --> $DIR/issue-71381.rs:13:61 | LL |     pub fn call_me<Args: Sized, const IDX: usize, const FN: unsafe extern "C" fn(Args)>(&self) { |                                                             ^^^^^^^^^^^^^^^^^^^^^^^^^^ error: using function pointers as const generic parameters is forbidden --> $DIR/issue-71381.rs:21:19 | LL |         const FN: unsafe extern "C" fn(Args), |                   ^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to 2 previous errors </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> error: using function pointers as const generic parameters is forbidden --> $DIR/issue-71381.rs:13:61 | LL |     pub fn call_me<Args: Sized, const IDX: usize, const FN: unsafe extern "C" fn(Args)>(&self) { |                                                             ^^^^^^^^^^^^^^^^^^^^^^^^^^ error: using function pointers as const generic parameters is forbidden --> $DIR/issue-71381.rs:21:19 | LL |         const FN: unsafe extern "C" fn(Args), |                   ^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to 2 previous errors </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> error: using function pointers as const generic parameters is forbidden --> $DIR/issue-71381.rs:13:61 | LL |     pub fn call_me<Args: Sized, const IDX: usize, const FN: unsafe extern "C" fn(Args)>(&self) { |                                                             ^^^^^^^^^^^^^^^^^^^^^^^^^^ error: using function pointers as const generic parameters is forbidden --> $DIR/issue-71381.rs:21:19 | LL |         const FN: unsafe extern "C" fn(Args), |                   ^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to 2 previous errors </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> error: using function pointers as const generic parameters is forbidden --> $DIR/issue-71381.rs:13:61 | LL |     pub fn call_me<Args: Sized, const IDX: usize, const FN: unsafe extern "C" fn(Args)>(&self) { |                                                             ^^^^^^^^^^^^^^^^^^^^^^^^^^ error: using function pointers as const generic parameters is forbidden --> $DIR/issue-71381.rs:21:19 | LL |         const FN: unsafe extern "C" fn(Args), |                   ^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to 2 previous errors </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: dependencies = [ "lazy_static 1.3.0 (registry+https://github.com/rust-lang/crates.io-index)", "new_debug_unreachable 1.0.3 (registry+https://github.com/rust-lang/crates.io-index)", <del> "phf_shared 0.7.22 (registry+https://github.com/rust-lang/crates.io-index)", </del> <ins> "phf_shared 0.7.24 (registry+https://github.com/rust-lang/crates.io-index)", </ins> "precomputed-hash 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)", "serde 1.0.92 (registry+https://github.com/rust-lang/crates.io-index)", "string_cache_codegen 0.4.2 (registry+https://github.com/rust-lang/crates.io-index)",

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


Question: dependencies = [ "lazy_static 1.3.0 (registry+https://github.com/rust-lang/crates.io-index)", "new_debug_unreachable 1.0.3 (registry+https://github.com/rust-lang/crates.io-index)", <del> "phf_shared 0.7.22 (registry+https://github.com/rust-lang/crates.io-index)", </del> <ins> "phf_shared 0.7.24 (registry+https://github.com/rust-lang/crates.io-index)", </ins> "precomputed-hash 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)", "serde 1.0.92 (registry+https://github.com/rust-lang/crates.io-index)", "string_cache_codegen 0.4.2 (registry+https://github.com/rust-lang/crates.io-index)",

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


Question: impl<T, A: Allocator> DoubleEndedIterator for Drain<'_, T, A> { #[inline] fn next_back(&mut self) -> Option<T> { <del> self.iter.next_back().map(|elt| unsafe { ptr::read(elt) }) </del> <ins> if self.tail == self.head { return None; } self.head = wrap_index(self.head.wrapping_sub(1), self.ring.len()); // Safety: // - `self.head` 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(self.head))) } </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: impl<T, A: Allocator> DoubleEndedIterator for Drain<'_, T, A> { #[inline] fn next_back(&mut self) -> Option<T> { <del> self.iter.next_back().map(|elt| unsafe { ptr::read(elt) }) </del> <ins> if self.tail == self.head { return None; } self.head = wrap_index(self.head.wrapping_sub(1), self.ring.len()); // Safety: // - `self.head` 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(self.head))) } </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: impl<T, A: Allocator> DoubleEndedIterator for Drain<'_, T, A> { #[inline] fn next_back(&mut self) -> Option<T> { <del> self.iter.next_back().map(|elt| unsafe { ptr::read(elt) }) </del> <ins> if self.tail == self.head { return None; } self.head = wrap_index(self.head.wrapping_sub(1), self.ring.len()); // Safety: // - `self.head` 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(self.head))) } </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: <ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // Test transitive analysis for associated types. Collected types // should be normalized and new obligations generated. use std::borrow::{ToOwned, Cow}; fn assert_send<T: Send>(_: T) {} fn main() { assert_send(Cow::Borrowed("foo")); } </ins>

For example, this code does not compile: cc
I think this may be another instance of
Trusting analysis, closing in favor of but adding test case there as well.
(it of course would be good to confirm that this actually is an instance of -- my initial reaction when I saw it was "they might be related ... but wait, wasn't part of the opt-in-builtin-bounds work to be able to move the special case handling of / out into library code...?"; I've only done some rough skimming that makes me think the hypothesis remains plausible.)
Ah either way is fine by me, I personally like fewer issues :). We can reopen once is addressed one way or another if necessary (or if you'd like to reopen now that's also fine by me!)
oh that was really just a note to myself as much as anything else, not a comment on your choice to close this ticket. :)
I don't think this code uses type-contents. If it does, that is itself a bug! Either way, we should keep this open for the time being.
cc


Question: <ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // Test transitive analysis for associated types. Collected types // should be normalized and new obligations generated. use std::borrow::{ToOwned, Cow}; fn assert_send<T: Send>(_: T) {} fn main() { assert_send(Cow::Borrowed("foo")); } </ins>

The following doesn't compile, but I believe it should: Error: Even though , and . In fact, this compiles:
should be , because the old definition that didn't use assoc types was . Probably the code that detects builtin bounds wasn't updated to handle associated types. cc
This breaks us in hyper. For now, I'll have to manually , knowing that it's safe.,,


Question: } } <ins> if !unnormalized_trait_sig.output().references_error() { debug_assert!( !collector.types.is_empty(), "expect >0 RPITITs in call to `collect_return_position_impl_trait_in_trait_tys`" ); } </ins> // FIXME: This has the same issue as #108544, but since this isn't breaking // existing code, I'm not particularly inclined to do the same hack as above // where we process wf obligations manually. This can be fixed in a forward-

<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed: expect 1 RPITITs in call to '', 'thread 'rustc' panicked at 'assertion failed: expect 1 RPITITs in call to '' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- query stack: [collectreturnpositionimpltraitintraittys] comparing an impl and trait method signature, inferring any hidden types in the process [typeof] computing type of [checkmodimplwf] checking that impls are well-formed in top-level module [analysis] running analysis passes on this crate --
<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details
fyi


Question: .param_env .and(type_op::implied_outlives_bounds::ImpliedOutlivesBounds { ty }) .fully_perform(self.infcx, DUMMY_SP) <del> .unwrap_or_else(|_| bug!("failed to compute implied bounds {:?}", ty)); </del> <ins> .map_err(|_: ErrorGuaranteed| debug!("failed to compute implied bounds {:?}", ty)) .ok()?; </ins> debug!(?bounds, ?constraints); self.add_outlives_bounds(bounds); constraints

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
Regression in cc :sweat_smile:
I knew this was a source of ICEs Most of these should already be reachable if they are in the body of a constant used in an array length. If you want to try fuzzing by sticking code into a const body...


Question: } // We probe again, taking all traits into account (not only those in scope). <del> let candidates = match self.lookup_probe( </del> <ins> let mut candidates = match self.lookup_probe( </ins> span, segment.ident, self_ty,

Issues with this diagnostic: method is not being invoked on a trait object; it's invoked on the concrete value . note suggests importing the same trait that is already being reported about.
/cc also looks relevant based on the title, but appears to have a different enough error message.
Is the following output from enough?
I don't feel like it's at the usual amazing quality . My points still appear to exist: In some magical world, I might hope for something like this (and I'm very flexible in that): I tried to address my points via the s.


Question: if instance.def.is_inline(tcx) { attributes::inline(llfn, attributes::InlineAttr::Hint); } <del> attributes::from_fn_attrs(cx, llfn, instance.def.def_id()); </del> <ins> attributes::from_fn_attrs(cx, llfn, Some(instance.def.def_id())); </ins> let instance_def_id = instance.def_id();

and are both broken on s390x since Rust 1.28. When is built without debuginfo, the tests hang with their backtracing processes stuck in a loop. With debuginfo, it fails with output like: I believe the problem is this part of : where doesn't identify that is a 64-bit platform. See also alexcrichton/backtrace-rs. I plan to update that here when it's published, and make a similar fix in .
fixes the backtrace when is built with debuginfo, but I'm still getting a hang without. In GDB, it looks like the unwinder gets to the that catches panics, then loops unwinding that same PC forever. This part of the regression is older -- happens on 1.27.2 as well, but 1.26.2 is fine. Binaries from the older version don't appear to have a distinct symbol at all, but maybe that's just inlined differently. I'm bisecting for that hang now.
Bisecting pointed me at (cc which attributes to all functions. For s390x the base features actually include a removal, . But it doesn't look like the features are applied to the synthesized (), and as a result it doesn't get inlined anymore since it has more features (w/ ) than the callee. We probably should apply target-features to as well. I don't know why the non-inlined can't be unwound -- maybe we need to force ? By default GDB backtrace stops at crate , but tries to go further: Maybe Rust's could have a similar defensive check, at least.
Nice find Definitely makes sense to me, and this should be fixed up (at least the business) in
With , , and , I believe we have this fixed.


Question: ..(ori_link.range.start + before_second_backtick_group) } <ins> /// Returns true if we should ignore `link` due to it being unlikely /// that it is an intra-doc link. `link` should still have disambiguators /// if there were any. /// /// The difference between this and [`should_ignore_link()`] is that this /// check should only be used on links that still have disambiguators. fn should_ignore_link_with_disambiguators(link: &str) -> bool { link.contains(|ch: char| !(ch.is_alphanumeric() || ":_<>, !*&;@()".contains(ch))) } /// Returns true if we should ignore `path_str` due to it being unlikely /// that it is an intra-doc link. fn should_ignore_link(path_str: &str) -> bool { path_str.contains(|ch: char| !(ch.is_alphanumeric() || ":_<>, !*&;".contains(ch))) } </ins> #[derive(Copy, Clone, Debug, PartialEq, Eq, Hash)] /// Disambiguators for a link. crate enum Disambiguator {

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: rustdoc parses the link as an email address and renders it as a mailto: link. Instead, this happened: <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --(from a GitHub Actions run, the latest nightly won't install on my Arch box due to broken components)
This turned out to be a bug in my docs; I didn't intend for this to be rendered as a link, but I was hoping for a better error message.
I think this PR introduced this new behavior:
This is weird - rustdoc should be ignoring any link that has in it:
Ah I see the issue - should only be reported if the link isn't ignored. do you have time to fix it? It should be as simple as adding the same check here:
Assigning and removing as in the prioritization working group. label: +P-medium -I-prioritize
can part of the fix here be to improve the error message? "Unknown disambiguator" doesn't tell me much about what is wrong or how to fix it.
I'm confused. After there won't be an error message, because the link shouldn't have been treated as an intra-doc link in the first place. Are you asking for a lint that warns about docs that will be rendered as mailto: links? I'm not sure how useful that is, mailto: links are normal and reasonable to write.
based on the UI tests that are checked in, if I actually intend to use an intradoc link with a disambiguator and fat finger as , the error message is not super friendly.
Hmm, what would you like to see instead? There's quite a few valid disambiguators, I'm not sure it makes sense to list them all. Maybe we could add a header to the disambiguator section of and link there?
Ideally I'd like to see a suggestion to use a disambiguator that corresponds to an item that is currently in scope or otherwise resolvable via the path after the invalid disambiguator.


Question: ..(ori_link.range.start + before_second_backtick_group) } <ins> /// Returns true if we should ignore `link` due to it being unlikely /// that it is an intra-doc link. `link` should still have disambiguators /// if there were any. /// /// The difference between this and [`should_ignore_link()`] is that this /// check should only be used on links that still have disambiguators. fn should_ignore_link_with_disambiguators(link: &str) -> bool { link.contains(|ch: char| !(ch.is_alphanumeric() || ":_<>, !*&;@()".contains(ch))) } /// Returns true if we should ignore `path_str` due to it being unlikely /// that it is an intra-doc link. fn should_ignore_link(path_str: &str) -> bool { path_str.contains(|ch: char| !(ch.is_alphanumeric() || ":_<>, !*&;".contains(ch))) } </ins> #[derive(Copy, Clone, Debug, PartialEq, Eq, Hash)] /// Disambiguators for a link. crate enum Disambiguator {

Hmm, that seems useful, although I think it should be a separate issue. Maybe we could try resolving without a disambiguator and see if there are any results? That would need a pretty significant overhaul of how it works currently, right now all the errors are emitted eagerly which would end up with a lot more verbose output that might not be relevant. What would you expect to see if the link isn't valid even without the disambiguator?
I think an extra to more docs on intradoc link disambiguators would be helpful per your previous comment. The idea to attempt to resolve items for all invalid disambiguators feels similar to the Ruby CLI and REPL's "did you mean" feature, which I find quite useful.
The PR improving the diagnostics is being reverted in , reopening the issue.
I don't think this is still a regression; the diagnostics improvement was not part of the fix for the regression. (The regression was fixed in .)
Yeah, never had a tracking issue.
was relanded in


Question: use rustc_hir::{HirId, HirIdSet, Node}; use rustc_middle::lint::LintDiagnosticBuilder; use rustc_middle::ty::subst::{GenericArgKind, Subst}; <del> use rustc_middle::ty::{self, Ty, TyCtxt}; </del> <ins> use rustc_middle::ty::{self, layout::LayoutError, Ty, TyCtxt}; </ins> use rustc_session::lint::FutureIncompatibleInfo; use rustc_session::Session; use rustc_span::edition::Edition;

<!-- 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: } #[test] <del> fn wtf8_show() { let mut string = Wtf8Buf::from_str("aé 💩"); string.push(CodePoint::from_u32(0xD800).unwrap()); assert_eq!(format!("{:?}", string), r#""aé 💩u{D800}""#); </del> <ins> fn wtf8buf_show_str() { let text = "até 💩r"; let mut string = Wtf8Buf::from_str(text); assert_eq!(format!("{:?}", text), format!("{:?}", string)); </ins> } #[test]

Formatting a string containing special characters with usually prints them escaped i.e.. This snippet runs as expected in the . However on Windows, using both and , the is printed unescaped : From what I can gather,  only concerns itself with faulty surrogates and completely ignores special characters.


Question: extern crate issue_76736_2; // @has foo/struct.Foo.html <del> // @has - '//*[@class="impl"]//h3[@class="code-header"]' 'MaybeResult' </del> <ins> // @!has - '//*[@class="impl"]//h3[@class="code-header"]' 'MaybeResult' </ins> pub struct Foo; // @has foo/struct.Bar.html <del> // @has - '//*[@class="impl"]//h3[@class="code-header"]' 'MaybeResult' </del> <ins> // @!has - '//*[@class="impl"]//h3[@class="code-header"]' 'MaybeResult' </ins> pub use issue_76736_2::Bar;

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


Question: size: (1100, 800) // We check that ".item-info" is bigger than its content. assert-css: (".item-info", {"width": "807px"}) <del> assert-css: (".item-info .stab", {"width": "343px"}) </del> <ins> assert-css: (".item-info .stab", {"width": "341px"}) </ins>

Right now, the docs produced on the stable and beta channels include unstable items. The docs are already fairly complex and contain a lot of information to sort through, and finding documentation for items that are not usable for the majority of developers working on stable Rust does not help with this. In addition, unstable APIs have very attention-grabbing warnings associated with them, making them much more prominent than the APIs that are actually usable. <img width="1031" alt="Screen shot demonstrating eye-catching unstable warning" src="https://user-"This has been broken out of to provide smaller, actionable items that can be independently discussed and worked on. A review of rustdoc for accessibility, especially for dyslexia and attention disorders, finds that there are a number of visually distracting elements in rustdoc which can draw attention away from the main content. This should be considered along with the other issues mentioned in about the overall effect of a number of distracting elements on the page. This has been previously discussed and closed in and . However, when it was first discussed was very shortly after the Rust 1.0 release, when there was a large amount of API surface which had not been stabilized for the 1.0 release, and what could be done with stable Rust was fairly limited (for example, no stable proc macros so Serde was only usable on nightly Rust). At this point, most people can use stable Rust for most tasks. There is a lot less reason for the average Rust developer to need to switch to nightly to use unstable standard library features. There is also the open issue that the stable docs of unstable items may be out of date; because these items are unstable, they can change in nightly releases, so not only are they a distraction, but they may be misleading for people who actually try to use them. Between the extra information that most people don't need, distracting UI, potential for being out of date, and time since this was last discussed, I think that it is worth reconsidering this decision and hiding unstable items in the stable docs by default. This would require either providing an opt-in setting for seeing them, or make finding the nightly docs easier. An alternative discussed in the comments is to just make them less visually prominent; unstable items are already rendered at lower contrast and at the bottom on module index pages, but within struct or trait documentation they have big bright warning boxes calling attention to them.


Question: size: (1100, 800) // We check that ".item-info" is bigger than its content. assert-css: (".item-info", {"width": "807px"}) <del> assert-css: (".item-info .stab", {"width": "343px"}) </del> <ins> assert-css: (".item-info .stab", {"width": "341px"}) </ins>

Making them less visually prominent, such as by reducing their contrast and making the warning just plain unstyled text, perhaps in the same place that stability information goes (though see for discussion on that), would help out a lot.
I would prefer this option. One benefit of showing the unstable APIs is that it invites people to test them, so having an opt-in for the curious would be good.
I would prefer an opt-out to an opt-in, that is, keep what we do today, but provide the ability to hide it if desired.
After spending some more time browsing the docs with an eye out for things that are visually distracting or attention grabbing, another option would be to just use a less attention grabbing way to denote unstable and deprecated items. Right now, they each use an extra, brightly colored box that makes them take up more visual space on the screen than stable items. On module index pages, they are actually made less prominent; they are sorted to the bottom, and made lower contrast with the background. This helps make them less attention catching, rather than more attention catching. But when browsing the methods provided on a struct or trait, they come with the big bright warning boxes that make them stand out more. I think I would still have a slight preference for having them hidden by default and just making the nightly docs easier to discover, such as having a version chooser in the header or sidebar, because of the issue mentioned in about docs of unstable items potentially being out of date. But making them less visually prominent rather than more visually prominent would help a lot.
I agree that the better way to solve this is by (perhaps) reducing the prominence of the "nightly-only" box. I don't think we should hide unstable items in the stable rustdoc generated at If someone is reading code that uses an unstable method, there's a good chance they will go to look it up in the stable docs. It would be a frustrating and confusing experience to not be able to find the method in the docs. It's a much better experience to find the method and be informed it's nightly-only / unstable. We probably don't want to reduce the prominence too much, though. If someone's looking for a method to call, it's pretty important that they notice when it's nightly-only. If they're working on a stable crate, that may mean they're not able to use the method at all.
Candidate PR at


Question: }); debug!("instantiate_method_substs: user_type_annotation={:?}", user_type_annotation); <del> self.fcx.write_user_type_annotation(self.call_expr.hir_id, user_type_annotation); </del> <ins> if !self.skip_record_for_diagnostics { self.fcx.write_user_type_annotation(self.call_expr.hir_id, user_type_annotation); } </ins> } self.normalize(self.span, substs)

<!-- 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. --No user code, just trying to compile my project. The is <!-- 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. --:
Do you mind checking if this still ICEs on the most recent nightly?
I just did that now, and it looks like the issue is fixed on the latest nightly. (sorry should have tried that in first place!)
That's weird, because I can repro it (cross-compiling for from linux if it matters).
on the latest nightly?
yep: Also the version of winit from the report () is not the latest . I'm working on bisecting and reducing now
Wait, this actually ICEs on stable too and I didn't notice because rustc emitted a bunch of errors after the ICE (?!)
I've reduced it down to this (which is no longer macOS or aarch64 dependent): (The assignment to was of course something more reasonable in the original code, but now I can't seem to replace it without making the ICE go away) This failed to compile without ICE on 1.69: Regression in () searched nightlies: from nightly-2023-03-06 to nightly-2023-04-19 regressed nightly: nightly-2023-04-15 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details label regression-from-stable-to-stable
Whoops, I seemed to have caused it I'll look into it!
WG-prioritization assigning priority (). label -I-prioritize +P-medium