Question: // Does the expected pattern type originate from an expression and what is the span? let (origin_expr, ty_span) = match (decl.ty, decl.init) { <del> (Some(ty), _) => (false, Some(ty.span)), // Bias towards the explicit user type. </del> <ins> (Some(ty), _) => (None, Some(ty.span)), // Bias towards the explicit user type. </ins> (_, Some(init)) => { <del> (true, Some(init.span.find_ancestor_inside(decl.span).unwrap_or(init.span))) </del> <ins> (Some(init), Some(init.span.find_ancestor_inside(decl.span).unwrap_or(init.span))) </ins> } // No explicit type; so use the scrutinee. <del> _ => (false, None), // We have `let $pat;`, so the expected type is unconstrained. </del> <ins> _ => (None, None), // We have `let $pat;`, so the expected type is unconstrained. </ins> }; // Type check the pattern. Override if necessary to avoid knock-on errors.

<!-- 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 suggest to the user that they need to initialize the enum variant's value in order to use the . <!-- 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 --
Can you give the output of what it should look like?
It should probably look similar to the suggestion given for and So I guess sth. like: Edit: Or instead of saying “to instantiate this tuple variant” we could say “to call this function” like it's done for the erroneous snippet (where is a ).
claim
commit the fix


Question: #[unstable(feature = "scoped_tls", reason = "scoped TLS has yet to have wide enough use to fully consider  stabilizing its interface")] <del> pub struct ScopedKey<T> { inner: imp::KeyInner<T> } </del> <ins> pub struct ScopedKey<T> { inner: fn() -> &'static imp::KeyInner<T> } </ins> /// Declare a new scoped thread local storage key. ///

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


Question: #[unstable(feature = "scoped_tls", reason = "scoped TLS has yet to have wide enough use to fully consider  stabilizing its interface")] <del> pub struct ScopedKey<T> { inner: imp::KeyInner<T> } </del> <ins> pub struct ScopedKey<T> { inner: fn() -> &'static imp::KeyInner<T> } </ins> /// Declare a new scoped thread local storage key. ///

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


Question: #[unstable(feature = "scoped_tls", reason = "scoped TLS has yet to have wide enough use to fully consider  stabilizing its interface")] <del> pub struct ScopedKey<T> { inner: imp::KeyInner<T> } </del> <ins> pub struct ScopedKey<T> { inner: fn() -> &'static imp::KeyInner<T> } </ins> /// Declare a new scoped thread local storage key. ///

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


Question: #[unstable(feature = "scoped_tls", reason = "scoped TLS has yet to have wide enough use to fully consider  stabilizing its interface")] <del> pub struct ScopedKey<T> { inner: imp::KeyInner<T> } </del> <ins> pub struct ScopedKey<T> { inner: fn() -> &'static imp::KeyInner<T> } </ins> /// Declare a new scoped thread local storage key. ///

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


Question: /// an underlying type by providing a mutable reference. See [`Borrow<T>`] /// for more information on borrowing as another type. #[stable(feature = "rust1", since = "1.0.0")] <ins> #[rustc_diagnostic_item = "BorrowMut"] </ins> pub trait BorrowMut<Borrowed: ?Sized>: Borrow<Borrowed> { /// Mutably borrows from an owned value. ///

... and trying to use afterwards, which triggers Example: currently yields I suggest that it should also contain
AsRef is a library trait, so IMO we should not do that. Also to me "value moved here" is pretty much the "you need to use this as reference".
While this might be obvious to us, I've had students struggling strongly with these errors. When I tell them "just add an ampersand", they're like "Oh, that makes total sense". I don't see that as reason not to do it. Could you elaborate?
This should also handle , , .
and aren't as clear, since the object will be modified, so the user might also want to , but that can later be signalled through and/or multiple suggestions
Obvious way of doing this would involve making a language item or otherwise special in some other way. To me it is pretty clear that language and the standard library should be as independent as possible and IME a diagnostic is a pretty minor gain for the special casing involved. One could imagine a similar diagnostic independent of library traits (e.g. always suggest a reference for "value moved here" if there’s a trait implementation for also), but then the problem of suggestion not being always correct kicks in. So, I will not oppose a change that implements this without making any more of the libstd/libcore special and is always correct, but I have no idea how anybody even begin approaching this problem.
I fully agree that that is not desirable In clippy we have similar diagnostics which in this case would simply check for (see for all the paths that we resolve manually).
Triage: this still produces the same error message. Given the concerns voiced above, should this issue stay open? I suppose we could leave this open should someone come up with a clever way to handle this without special casing , but that seems unlikely.
We have diagnostic items nowadays, so we can make a diagnostic item and detect in in these situations. Though I'm not sure how easy it is to detect. The error may get reported far too late
Current :


Question: && let Some(pos) = args.iter().position(|arg| arg.hir_id == expr.hir_id) && let Some(arg) = fn_sig.decl.inputs.get(pos + offset) { <del> let mut span: MultiSpan = arg.span.into(); span.push_span_label( arg.span, "this parameter takes ownership of the value".to_string(), ); let descr = match node.fn_kind() { Some(hir::intravisit::FnKind::ItemFn(..)) | None => "function", Some(hir::intravisit::FnKind::Method(..)) => "method", Some(hir::intravisit::FnKind::Closure) => "closure", }; span.push_span_label(ident.span, format!("in this {descr}")); err.span_note( span, format!( "consider changing this parameter type in {descr} `{ident}` to borrow  instead if owning the value isn't necessary", ), ); </del> <ins> let mut is_mut = false; if let hir::TyKind::Path(hir::QPath::Resolved(None, path)) = arg.kind && let Res::Def(DefKind::TyParam, param_def_id) = path.res && self .infcx .tcx .predicates_of(def_id) .instantiate_identity(self.infcx.tcx) .predicates .into_iter() .any(|pred| { if let ty::ClauseKind::Trait(predicate) = pred.kind().skip_binder() && [ self.infcx.tcx.get_diagnostic_item(sym::AsRef), self.infcx.tcx.get_diagnostic_item(sym::AsMut), self.infcx.tcx.get_diagnostic_item(sym::Borrow), self.infcx.tcx.get_diagnostic_item(sym::BorrowMut), ] .contains(&Some(predicate.def_id())) && let ty::Param(param) = predicate.self_ty().kind() && let generics = self.infcx.tcx.generics_of(def_id) && let param = generics.type_param(*param, self.infcx.tcx) && param.def_id == param_def_id { if [ self.infcx.tcx.get_diagnostic_item(sym::AsMut), self.infcx.tcx.get_diagnostic_item(sym::BorrowMut), ] .contains(&Some(predicate.def_id())) { is_mut = true; } true } else { false } }) { // The type of the argument corresponding to the expression that got moved // is a type parameter `T`, which is has a `T: AsRef` obligation. err.span_suggestion_verbose( expr.span.shrink_to_lo(), "borrow the value to avoid moving it", format!("&{}", if is_mut { "mut " } else { "" }), Applicability::MachineApplicable, ); can_suggest_clone = is_mut; } else { let mut span: MultiSpan = arg.span.into(); span.push_span_label( arg.span, "this parameter takes ownership of the value".to_string(), ); let descr = match node.fn_kind() { Some(hir::intravisit::FnKind::ItemFn(..)) | None => "function", Some(hir::intravisit::FnKind::Method(..)) => "method", Some(hir::intravisit::FnKind::Closure) => "closure", }; span.push_span_label(ident.span, format!("in this {descr}")); err.span_note( span, format!( "consider changing this parameter type in {descr} `{ident}` to  borrow instead if owning the value isn't necessary", ), ); } </ins> } let place = &self.move_data.move_paths[mpi].place; let ty = place.ty(self.body, self.infcx.tcx).ty;


Question: } // Don't report FFI errors for unit return types. This check exists here, and not in <del> // `check_foreign_fn` (where it would make more sense) so that normalization has definitely </del> <ins> // the caller (where it would make more sense) so that normalization has definitely </ins> // happened. if is_return_type && ty.is_unit() { return;

The function itself is considered FFI-safe and does not trigger the warning (). Its function pointer should also be allowed, to be consistent. Discovered on CI The original code has several more levels of indirection, but is also considered FFI-safe before. <details<summaryExtracted original code</summary</detailsAccording to CI logs, the warning occurs since rust 1.72.0-nightly ( 2023-07-03). Probably caused by . cc
Okay, so, I had a fix for this that just got rid of the regression, but I'm not sure that's the correct solution here - I think this is correct to be linting in the fn-ptr case and should be linting for the function case. is FFI-unsafe, but we allow a function to return because that's the default, but that doesn't mean that a within a type is okay (with the exception of a wrapper around the - because that's just returning , which we've already decided is okay). In the function case that works right now, that's being allowed because of this code.. ..which is there to support the case. However, it's not quite the right check. It doesn't actually check for ! It checks that the type - however nested - which was deemed FFI-unsafe is and that type is part of a return type. So any FFI-unsafe in a return type makes the entire return type FFI-safe - which is clearly incorrect. That's making the example below compile, which absolutely shouldn't. I've submitted , which makes this even more of a regression by making the function case fail too. We already had a simple "is it a unit" check, so I extended that to check for transparent newtype wrappers too, and removed the incorrect check.
This is unfortunate since I'm trying to return a where is likely to be . What should I do instead if I want to be FFI-safe with layout ?
I'm not so sure anymore after reading comment (). It's clear that some changes are required regardless - our current implementation wrong as demonstrated in the final example from my previous comment, but it's also inconsistent, in that this example... lint for the argument use of , but not the return use of , when really it should be both or neither. After my pull request, it's both.


Question: } // Don't report FFI errors for unit return types. This check exists here, and not in <del> // `check_foreign_fn` (where it would make more sense) so that normalization has definitely </del> <ins> // the caller (where it would make more sense) so that normalization has definitely </ins> // happened. if is_return_type && ty.is_unit() { return;

With and without my pull request, when you change this to , it doesn't lint.
I'll nominate this issue so that it sees some discussion - see also and .
I posted some more info on zulip but it may also worth mentioning here. ZST is still zero-sized under repr(C), rather than FFI-unsafe.
The issue now also exists in beta. I also found uitests which seems to expect ZST to be FFI-safe, but ends in to suppress the warning and tests nothing.
We discussed this in today's meeting. We didn't have consensus that this should warn; at least some people thought the code in the top comment should continue to compile without warnings. We did have consensus that changing that (to warn) would need an FCP. So, we felt that we'd like to see a fix removing the warning applied to beta and nightly, and then separately if someone wants to propose that we change this to warn, we could evaluate that and do an FCP on it. But at the moment the temperature of the team seems to be that we don't have consensus for such an FCP.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
labels -I-lang-nominated We rendered our opinion


Question: // Computing common supertype in an if expression IfExpression(Span), <ins> // Computing common supertype of an if expression with no else counter-part IfExpressionWithNoElse(Span) </ins> } /// See `error_reporting.rs` for more details

I apologize in advance if this is a separate issue. With the map() generic function from the tutorial: That code gives a nice error message: However, remove the assignment and what should be the same error message becomes:
Yes, that is unrelated to this issue. You're seeing an expected type mismatch error since the return type of main() is () and your samples result in two different non-() results.
Thanks I was one hour into learning Rust when I came across this. I understand what is going on now. I still think the error message could be improved to mention that "expected " is referring to the return type of main(). That simple clue could help people not as familiar with Rust to remember the semicolon rule to turn a statement into an expression.
Not critical for 0.7, but improving error messages is always good. Nominating for milestone 5.
declined. this is bad but it's not a blocker.
Confirmed that the situation is unchanged.
This is still an issue.
Bug triage. Still an issue.
Very, very small change:


Question: <ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // Test that wrapping an unsized struct in an enum which gets optimised does // not ICE. struct Str { f: [u8] } fn main() { let str: Option<&Str> = None; str.is_some(); } </ins>

I was playing with DST by reimplementing the primitive as a , but hit an ICE while testing. The code is in this cc This seems similar to cc
Minimal test case:


Question: } } } <ins> // just tests by whether or not this compiles fn _pending_impl_all_auto_traits<T>() { use std::panic::{RefUnwindSafe, UnwindSafe}; fn all_auto_traits<T: Send + Sync + Unpin + UnwindSafe + RefUnwindSafe>() {} all_auto_traits::<std::future::Pending<T>>(); } </ins>

Right.. is my own PR; I'm noting this as an issue, mainly so I won't forget this, because I won't do this myself right now / today. Or someone else can do this if they want. I'm not 100% certain where the best place for such a test to go is, and/or whether it makes sense to have them in one place or separated and more close to the respective type's definition. A test to prevent any future regression removing the new auto trait implementations introduced by can look about as follows <s` </sEdit: This code is needlessly complicated, see my comment below. label C-enhancement, A-testsuite, E-easy, E-needs-test, T-libs <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
FYI, somehow I missed the more straightforward way of writing these.


Question: () => ((file!(), line!())) } <del> #[cfg(all(unix, not(target_os = "macos"), not(target_os = "ios"), not(target_os = "android"), not(all(target_os = "linux", target_arch = "arm"))))] </del> macro_rules! dump_and_die { ($($pos:expr),*) => ({ // FIXME(#18285): we cannot include the current position because // the macro span takes over the last frame's file/line. <del> dump_filelines(&[$($pos),*]); panic!(); </del> <ins> if cfg!(target_os = "macos") || cfg!(target_os = "ios") || cfg!(target_os = "android") || cfg!(all(target_os = "linux", target_arch = "arm")) || cfg!(all(windows, target_env = "gnu")) { // skip these platforms as this support isn't implemented yet. } else { dump_filelines(&[$($pos),*]); panic!(); } </ins> }) } <del> // this does not work on Windows, Android, OSX or iOS #[cfg(not(all(unix, not(target_os = "macos"), not(target_os = "ios"), not(target_os = "android"), not(all(target_os = "linux", target_arch = "arm")))))] macro_rules! dump_and_die { ($($pos:expr),*) => ({ let _ = [$($pos),*]; }) } </del> // we can't use a function as it will alter the backtrace macro_rules! check { ($counter:expr; $($pos:expr),*) => ({

Symbol names are not properly supported yet on msvc, so backtraces are generally unhelpful. As a result, is currently disabled. This issue can be closed when it's been reenabled.


Question: // MACRO_RULES ITEM self.parse_item_macro_rules(vis, has_bang)? } else if self.isnt_macro_invocation() <del> && (self.token.is_ident_named(sym::import) || self.token.is_ident_named(sym::using)) </del> <ins> && (self.token.is_ident_named(sym::import) || self.token.is_ident_named(sym::using) || self.token.is_ident_named(sym::include) || self.token.is_ident_named(sym::require)) </ins> { return self.recover_import_as_use(); } else if self.isnt_macro_invocation() && vis.kind.is_pub() {

I was looking at namely issue when I thought about this. If work is being put into improving error messages when somebody uses a keyword that defines a function in another language, there should also be improved error messages if someone uses the incorrect directive to bring something into the scope of their module or namespace/ Given the following code: The current output is: The error message should preferably suggest the user to use the directive to bring something into scope of their module. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
For the record, on nightly, both and suggest using . I'm sure it's not that difficult to add .
ah. I was not aware of this. Less work to do then!
[Ignore this, just notes]
And also add ? Rust may go tooooo friendly in diagnostic message . Do you mind that I make a PR for it? I'm a newbie in hacking Rust compiler.
Sure! The earlier message should clarify where the edits are needed to be made. Ain't nothing as a diagnostic too friendly. =)
Remember to assign yourself using rustbot. Just a note for the future, usually if someone has already claimed an issue, it's not exactly common for someone else to fix it [aside from if the issue is abandoned by the claimee]. Since you're a newcomer here, I removed my assignment (and because I was working on another). However, you can find loads of easy issues with the E-Easy and/or E-Mentor tag for gaining experience. A few resources that might be helpful - Have fun hacking on Rust!
claim
Totally forgot about ! Good catch!


Question: )?; write_minify("search.js", static_files::SEARCH_JS)?; write_minify("settings.js", static_files::SETTINGS_JS)?; <ins> write_minify("sidebar-items.js", static_files::sidebar::ITEMS)?; </ins> if cx.shared.include_sources { write_minify("source-script.js", static_files::sidebar::SOURCE_SCRIPT)?; }

<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --Since i don't know which version, when running on a project, the left sidebar of the docs no longer has a nav for all crates in the dependency graph. However, the documentation for all dependencies is still compiled. a Rust project with a few dependencies. : Left sidebar has a list of all dependencies, linking to each crate's local docs. : No such thing. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: I honestly don't remember. I update my nightly before every dev session. Allegedly that bug is 27 days old. <!-- Provide the version you are using that has the regression. --: <!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --
Appears to be a regression from , the call to was moved into , but this function is not called on the crate-root doc page. I tested locally that it fails on and works on .
Checking looks like this has made it onto the 1.53 beta.
cc
I think the ideal fix is around We should emit a sidebar- for the top page that just calls . And remove that comment, since we now have dynamic crate loading. A quicker fix is to just move the call to addSidebarCrates so it gets called independently from initSidebarItems. I like that less since the crates really are a sidebar item and should be treated as such.
I can do that if no one else wants to do it!
Go for it! I'm happy to review.
Assigning .
It's actually something I fixed in (still waiting for approval/review).
I propose we plan on landing and backporting to fix the regression: it's much smaller and limited to the specific fix. Then we can work on landing in nightly.
No, the approach taken in is problematic. The information is already there and we don't need this new file.


Question: )?; write_minify("search.js", static_files::SEARCH_JS)?; write_minify("settings.js", static_files::SETTINGS_JS)?; <ins> write_minify("sidebar-items.js", static_files::sidebar::ITEMS)?; </ins> if cx.shared.include_sources { write_minify("source-script.js", static_files::sidebar::SOURCE_SCRIPT)?; }

EDIT: also, is ready, there is a debate for the other part of the PR (the change on module's sidebar) which I can move to another PR.
See - after some discussion, and concluded to merge as our quick fix. To explain why I proposed to add a tiny sidebar- We have one that's loaded by a variety of different pages. It also potentially has many different entry points. For instance, the primary entry point is that when itself is loaded, it runs various functions, adding event handlers and so on. Another entry point is that when sidebar- loads, it calls . That's the root cause of this bug - code in expected would get called, and for a subset of pages it wasn't. It's a bit inelegant to have a small file whose purpose is only to call a known function. But I think that inelegance is balanced against the improved maintainability of having most doc pages follow closer to the same code path through The more code paths, the more chances for bugs and the more complexity in testing. Another way to address this longer-term would be to eliminate the entrypoint entirely. Instead, when runs, it would trigger the load of sidebar-items and run any callbacks based on that load. Yet another way to address this would be to separate out from , so that is called unconditionally for all pages.


Question: <ins> error[E0106]: missing lifetime specifier --> $DIR/opaque-and-lifetime-mismatch.rs:5:24 | LL |     fn bar() -> Wrapper<impl Sized>; |                        ^ expected named lifetime parameter | = help: this function's return type contains a borrowed value, but there is no value for it to be borrowed from help: consider using the `'static` lifetime, but this is uncommon unless you're returning a borrowed value from a `const` or a `static`, or if you will only have owned values | LL |     fn bar() -> Wrapper<'static, impl Sized>; |                         ++++++++ error[E0412]: cannot find type `T` in this scope --> $DIR/opaque-and-lifetime-mismatch.rs:1:22 | LL | struct Wrapper<'rom>(T); |                      ^ not found in this scope | help: you might be missing a type parameter | LL | struct Wrapper<'rom, T>(T); |                    +++ error[E0107]: struct takes 0 generic arguments but 1 generic argument was supplied --> $DIR/opaque-and-lifetime-mismatch.rs:5:17 | LL |     fn bar() -> Wrapper<impl Sized>; |                 ^^^^^^^ ---------- help: remove this generic argument |                 | |                 expected 0 generic arguments | note: struct defined here, with 0 generic parameters --> $DIR/opaque-and-lifetime-mismatch.rs:1:8 | LL | struct Wrapper<'rom>(T); |        ^^^^^^^ error[E0053]: method `bar` has an incompatible return type for trait --> $DIR/opaque-and-lifetime-mismatch.rs:11:17 | LL |     fn bar() -> i32 { |                 ^^^ |                 | |                 expected `Wrapper<'static>`, found `i32` |                 return type in trait error[E0053]: method `bar` has an incompatible type for trait --> $DIR/opaque-and-lifetime-mismatch.rs:11:17 | LL |     fn bar() -> i32 { |                 ^^^ |                 | |                 expected `Wrapper<'static>`, found `i32` |                 help: change the output type to match the trait: `Wrapper<'static>` | note: type in trait --> $DIR/opaque-and-lifetime-mismatch.rs:5:17 | LL |     fn bar() -> Wrapper<impl Sized>; |                 ^^^^^^^^^^^^^^^^^^^ = note: expected signature `fn() -> Wrapper<'static>` found signature `fn() -> i32` error: aborting due to 5 previous errors Some errors have detailed explanations: E0053, E0106, E0107, E0412. For more information about an error, try `rustc --explain E0053`. </ins>

<!-- 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: <ins> error[E0596]: cannot borrow `*inner` as mutable, as it is behind a `&` reference --> $DIR/issue-91206.rs:13:5 | LL |     let inner = client.get_inner_ref(); |         ----- help: consider changing this to be a mutable reference: `&mut Vec<usize>` LL | LL |     inner.clear(); |     ^^^^^^^^^^^^^ `inner` is a `&` reference, so the data it refers to cannot be borrowed as mutable error: aborting due to previous error For more information about this error, try `rustc --explain E0596`. </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. --: In case it helps, when using the stable toolchain, the compiler does not panic but instead emits this error: <!-- 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 --
Bisected to . CC searched nightlies: from nightly-2021-10-01 to nightly-2021-11-25 regressed nightly: nightly-2021-11-23 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: aarch64-apple-darwin Reproduce with: </details label regression-from-stable-to-nightly
I can fix this quickly -- seems like just changing an to a since the can be out of bounds. claim
(only tangentially related) I also noticed a regression in error spans between stable and beta... stable: beta:
That was an intentional change, meant to highlight the fact that the attempted mutable borrow is occurring because of the method call. However, it seems to be confusing for a lot of people, so I'll look into improving it.
Ah thanks for letting me know. Maybe we can split the span up into the receiver and the method, and add a note on the latter like "due to this method which takes &mut self". Not sure if that much info bubbles down into borrowck. I'd be interested in making that change if you've got a lot on your plate and it's (relatively) easy to do.
See for discussion about this exact idea. It'd be nice, but likely hard to implement.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high


Question: use libc::types::os::arch::c95::{c_int, size_t}; pub static SIGTRAP : c_int = 5; <ins> pub static SIGPIPE: c_int = 13; pub static SIG_IGN: size_t = 1; </ins> pub static GLOB_ERR      : c_int = 1 << 0; pub static GLOB_MARK     : c_int = 1 << 1;

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> // edition:2021 #![feature(async_closure)] // Don't ICE in ByMove shim builder when MIR body is tainted by writeback errors fn main() { let _ = async || { used_fn(); //~^ ERROR cannot find function `used_fn` in this scope 0 }; } </ins>

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


Question: <ins> // edition:2021 #![feature(async_closure)] // Don't ICE in ByMove shim builder when MIR body is tainted by writeback errors fn main() { let _ = async || { used_fn(); //~^ ERROR cannot find function `used_fn` in this scope 0 }; } </ins>

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


Question: <ins> error: invalid asm template string: unmatched `}` found --> $DIR/ice-bad-err-span-in-template-129503.rs:12:10 | LL |     asm!(concat!(r#"lJ𐏿Æ�.𐏿�"#, "r} {}")); |          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ unmatched `}` in asm template string | = note: if you intended to print `}`, you can escape it using `}}` = note: this error originates in the macro `concat` (in Nightly builds, run with -Z macro-backtrace for more info) error: invalid asm template string: unmatched `}` found --> $DIR/ice-bad-err-span-in-template-129503.rs:18:10 | LL |     asm!(concat!("abc", "r} {}")); |          ^^^^^^^^^^^^^^^^^^^^^^^ unmatched `}` in asm template string | = note: if you intended to print `}`, you can escape it using `}}` = note: this error originates in the macro `concat` (in Nightly builds, run with -Z macro-backtrace for more info) error: invalid asm template string: unmatched `}` found --> $DIR/ice-bad-err-span-in-template-129503.rs:24:19 | LL |     asm!("abc", "r} {}"); |                   ^ unmatched `}` in asm template string | = note: if you intended to print `}`, you can escape it using `}}` error: aborting due to 3 previous errors </ins>

<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'', 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [resolverforlowering_raw] getting the resolver for lowering --
cc
(without looking at the code, is it ?) EDIT: ah no this might be the other class of macro-related unicode troubles, seems similar to


Question: } } <ins> let document_hidden = cx.render_options.document_hidden; </ins> let predicates = tcx.explicit_predicates_of(did); let (trait_items, generics) = match impl_item { Some(impl_) => ( impl_ .items .iter() <del> .map(|item| tcx.hir().impl_item(item.id).clean(cx)) </del> <ins> .map(|item| tcx.hir().impl_item(item.id)) .filter(|item| { // Filter out impl items whose corresponding trait item has `doc(hidden)` // not to document such impl items. // For inherent impls, we don't do any filtering, because that's already done in strip_hidden.rs. // When `--document-hidden-items` is passed, we don't // do any filtering, too. if document_hidden { return true; } if let Some(associated_trait) = associated_trait { let assoc_kind = match item.kind { hir::ImplItemKind::Const(..) => ty::AssocKind::Const, hir::ImplItemKind::Fn(..) => ty::AssocKind::Fn, hir::ImplItemKind::TyAlias(..) => ty::AssocKind::Type, }; let trait_item = tcx .associated_items(associated_trait.def_id) .find_by_name_and_kind( tcx, item.ident, assoc_kind, associated_trait.def_id, ) .unwrap(); // SAFETY: For all impl items there exists trait item that has the same name. !tcx.get_attrs(trait_item.def_id).lists(sym::doc).has_word(sym::hidden) } else { true } }) .map(|item| item.clean(cx)) </ins> .collect::<Vec<_>>(), impl_.generics.clean(cx), ),

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


Question: match ct.ty.kind() { ty::Uint(_) => {} <ins> ty::Bool => {} </ins> _ => { bug!("symbol_names: unsupported constant of type `{}` ({:?})", ct.ty, ct); }

Command was with the following <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
And yes, was enough to get the build to finish, in case there were any questions as to whether that was the difference.
This is the first PR that fails with the error described in I do not know if the fault is here or in the symbol mangling but it as I understand it that function that is called is only used for the the size of an array and it feels strange that it shall be a bool -- it seems pretty clear the bug is in the symbol mangling rather than with , because it's not adding anything out of the "ordinary" Rust code. That said, it's likely that the const generic could be replaced to avoid the error perhaps.
Yeah, isn't this "just" an instance of new symbol mangling not being compatible with const generics?
was to tired that night when I hade bisected the rust build and this hade nothing to do with arrays that I was writing. was possible to avoid the bisect all together if I only hade looked trough all of the log. it is saying that it is eg. that fails so it is the bool in the path that is triggering the fault in symbol mangling. according to only unsigned integers is handled and the rest is left for "future const-generics work" shall this be marked with some const-generic label? right now it is only bool that also needs to be handled for rustc to compile but do not know how to go forward
seems like there is a issue for adding mangling support here so this will probably be fixed when that issue is fixed.


Question: } #[test] <ins> fn test_buf_writer() { let mut buf = [0 as u8, ..8]; { let mut writer = BufWriter::new(buf); assert_eq!(writer.tell(), 0); writer.write([0]); assert_eq!(writer.tell(), 1); writer.write([1, 2, 3]); writer.write([4, 5, 6, 7]); assert_eq!(writer.tell(), 8); } assert_eq!(buf, [0, 1, 2, 3, 4, 5, 6, 7]); } #[test] fn test_buf_writer_seek() { let mut buf = [0 as u8, ..8]; { let mut writer = BufWriter::new(buf); assert_eq!(writer.tell(), 0); writer.write([1]); assert_eq!(writer.tell(), 1); writer.seek(2, SeekSet); assert_eq!(writer.tell(), 2); writer.write([2]); assert_eq!(writer.tell(), 3); writer.seek(-2, SeekCur); assert_eq!(writer.tell(), 1); writer.write([3]); assert_eq!(writer.tell(), 2); writer.seek(-1, SeekEnd); assert_eq!(writer.tell(), 7); writer.write([4]); assert_eq!(writer.tell(), 8); } assert_eq!(buf, [1, 3, 2, 0, 0, 0, 0, 4]); } #[test] fn test_buf_writer_error() { let mut buf = [0 as u8, ..2]; let mut writer = BufWriter::new(buf); writer.write([0]); let mut called = false; do io_error::cond.trap(|err| { assert_eq!(err.kind, OtherIoError); called = true; }).inside { writer.write([0, 0]); } assert!(called); } #[test] </ins> fn test_mem_reader() { let mut reader = MemReader::new(~[0, 1, 2, 3, 4, 5, 6, 7]); let mut buf = [];

Currently all of its functions immediately . We need to either remove this or implement it. I vote for implementing it.


Question: let const_did = tcx.def_map.borrow().get_copy(&pat.id).def_id(); let const_pty = ty::lookup_item_type(tcx, const_did); fcx.write_ty(pat.id, const_pty.ty); <del> demand::eqtype(fcx, pat.span, expected, const_pty.ty); </del> <ins> demand::suptype(fcx, pat.span, expected, const_pty.ty); </ins> } ast::PatIdent(bm, ref path, ref sub) if pat_is_binding(&tcx.def_map, pat) => { let typ = fcx.local_ty(pat.span, pat.id);

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


Question: let const_did = tcx.def_map.borrow().get_copy(&pat.id).def_id(); let const_pty = ty::lookup_item_type(tcx, const_did); fcx.write_ty(pat.id, const_pty.ty); <del> demand::eqtype(fcx, pat.span, expected, const_pty.ty); </del> <ins> demand::suptype(fcx, pat.span, expected, const_pty.ty); </ins> } ast::PatIdent(bm, ref path, ref sub) if pat_is_binding(&tcx.def_map, pat) => { let typ = fcx.local_ty(pat.span, pat.id);

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


Question: <ins> const A: usize ⩵ 2; //~^ ERROR unknown start of token: u{2a75} //~| ERROR unexpected `==` </ins>

<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'', 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'' File: --snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: --
cc
I suspect that we don't really need anymore, tbh.
Addressed in Every time I convince myself that "synthesizing a is ok this time", I'm proved wrong.
WG-prioritization assigning priority (). label -I-prioritize +P-medium


Question: { continue; } <ins> // opaque types generated when desugaring an async function can have a single // use lifetime even if it is explicitly denied (Issue #77175) if let hir::Node::Item(hir::Item { kind: hir::ItemKind::OpaqueTy(ref opaque), .. }) = self.tcx.hir().get(parent_hir_id) { if opaque.origin != hir::OpaqueTyOrigin::AsyncFn { continue 'lifetimes; } // We want to do this only if the liftime identifier is already defined // in the async function that generated this. Otherwise it could be // an opaque type defined by the developer and we still want this // lint to fail compilation for p in opaque.generics.params { if defined_by.contains_key(&p.name) { continue 'lifetimes; } } } </ins> } }

I tried this code: I expected to see this happen: the code is correct. Instead, this happened: Just swap the functions, then the code compiles: Update : The examples may be misleading. I forgot that takes effect on a single item. It was a typo. Here is a new example. It should be correct. But the compiler does not accept it. <!-- 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. --: :
Very strange. I'm thinking we have some stateful HIR lowering code that is hanging onto state it shouldn't.
This bug existed as far back as November 2019 (when was stabilized), so it's not a recent regression.
Marking this as P-medium based on the
I did some digging into this. I'm brand new to the compiler so slowly learning the architecture along the way. Below are some thoughts on what I've seen so far. The desugared HIR for both samples is the same: async first async last As expected both resolves the same set of lifetimes (from ) and process them in the same order (since ). Dump from the property at the first iteration: async first async last Interestingly both included the lifetime as used only once in the opaque/desugared async function and both . However, for the second case (async last) the compilation still succeeds - this is really confusing and I'm probably missing something big about the compiler architecture. Need to dig deeper.
The examples may be misleading. I forgot that takes effect on a single item. It was a typo. Here is a new example.
Makes sense. Then the behavior is no longer magical and makes a lot of sense.
Based on what I've seen the desugaring process is working correctly and the object is keeping the correct state. The lifetime linting identifies the lifetime as only used once within the return opaque type generated by the desugaring process. This behavior seems correct since we'd still want to catch this for an opaque type implementation from the user. My suggestion would be to include an exception in the linting specifically for opaque types of async functions that use a lifetime name already declared in the generic params of the parent function. I have validated this simple change (I named the loop ) and propose to include it alongside .


Question: { continue; } <ins> // opaque types generated when desugaring an async function can have a single // use lifetime even if it is explicitly denied (Issue #77175) if let hir::Node::Item(hir::Item { kind: hir::ItemKind::OpaqueTy(ref opaque), .. }) = self.tcx.hir().get(parent_hir_id) { if opaque.origin != hir::OpaqueTyOrigin::AsyncFn { continue 'lifetimes; } // We want to do this only if the liftime identifier is already defined // in the async function that generated this. Otherwise it could be // an opaque type defined by the developer and we still want this // lint to fail compilation for p in opaque.generics.params { if defined_by.contains_key(&p.name) { continue 'lifetimes; } } } </ins> } }

One more question for the team ( what would we expect in this case? This compiles successfully, which is counter intuitive by looking at the function signature. It compiles because the desugared generator uses the same lifetime as the async function.


Question: // FIXME: This can be smarter and take `StorageDead` into account (which // invalidates borrows). if self.ever_borrowed_locals.contains(dest.local) <del> && self.ever_borrowed_locals.contains(src.local) </del> <ins> || self.ever_borrowed_locals.contains(src.local) </ins> { return; }

This little matrix processing code shows miscompilation if compiled with: But it compiles correctly with: With:
Hmm, on first glance the replacement it performs looks correct: It replaces local () with the return place . Previously the return place was only used in the block by a copy statement, so this transformation should be correct. Maybe this part of the diff causes a problem? We're using our return place as the return destination for the inner call. It's possible that there's an undocumented (and maybe unintended) assumption that the return place is not reused like this, either in other MIR optimizations or in codegen. Haven't looked too deeply yet though.
Ah, there's this bad call in LLVM IR: It passes a reference to as both the return pointer, and the second (immutable) argument.
we have this corresponding MIR, where we already incorrectly pass a reference to as an argument, while also assigning the call result to it: The destination propagation pass already has code that prevents merging a call destination with one of the arguments, but here we pass a reference instead. Curiously, the was produced by merging with , which is not really something the pass should be doing since a reference is taken to , and we avoid touching any local that has its address taken.
The propagation is disabled only if both locals have their address taken. Changing that to be more conservative does fix this issue. Minimized:
Oof, this should have been an , not an
Thanks
Opened with a fix


Question: ) .fold_with(&mut collector); <del> if !unnormalized_trait_sig.output().references_error() { debug_assert_ne!( collector.types.len(), 0, "expect >1 RPITITs in call to `collect_return_position_impl_trait_in_trait_tys`" ); } </del> let trait_sig = ocx.normalize(&misc_cause, param_env, unnormalized_trait_sig); trait_sig.error_reported()?; let trait_return_ty = trait_sig.output();


Question: } pub fn ext(&mut self, ext: ArgExtension) -> &mut Self { <del> assert!(self.arg_ext == ArgExtension::None || self.arg_ext == ext); </del> <ins> assert!( self.arg_ext == ArgExtension::None || self.arg_ext == ext, "cannot set {:?} when {:?} is already set", ext, self.arg_ext ); </ins> self.arg_ext = ext; self }

<!-- 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
modify labels: +regression-from-stable-to-stable This happens since rust
More minimal reproducer. Does not occur with just 1 variant. Or if one of the variants has a negative discriminant. Affects most targets if not all of them, despite the failure seemingly occurring inside the target-specific code.
Assigning P-medium as .20enum.20from.20an.20extern.20c.E2.80.A6) and removing I-prioritize.


Question: } /// Adds a list of lookup paths to `cmd`'s dynamic library lookup path. <del> /// If The dylib_path_par is already set for this cmd, the old value will be overwritten! </del> <ins> /// If the dylib_path_var is already set for this cmd, the old value will be overwritten! </ins> pub fn add_dylib_path(path: Vec<PathBuf>, cmd: &mut Command) { let mut list = dylib_path(); for path in path {

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


Question: #[diag(lint_supertrait_as_deref_target)] pub struct SupertraitAsDerefTarget<'a> { pub t: Ty<'a>, <del> pub target_principal: String, // pub target_principal: Binder<'a, ExistentialTraitRef<'b>>, </del> <ins> pub target_principal: PolyExistentialTraitRef<'a>, </ins> #[subdiagnostic] pub label: Option<SupertraitAsDerefTargetLabel>, }

<!-- 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. --ICE with in I just noticed the error actually says openpgp-card at the bottom, perhaps compilation doesn't even get to the final crate. In any case, I'm no good at minimizing these things, so I'm handing this off to people who are good at that. <!-- 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 label +E-needs-mcve
searched nightlies: from nightly-2023-01-01 to nightly-2023-01-15 regressed nightly: nightly-2023-01-14 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
This fixes the ICE, although I'm not sure if that's the right approach
label -E-needs-mcve