Implement rfc 1789: Conversions from `&mut T` to `&Cell<T>`
I'm surprised that RFC 1789 has not been implemented for several months. Tracking issue: https://github.com/rust-lang/rust/issues/43038
Please note: when I was writing tests for `&Cell<[i32]>`, I found it is not easy to get the length of the contained slice. So I designed a `get_with` method which might be useful for similar cases. This method is not designed in the RFC, and it certainly needs to be reviewed by core team. I think it has some connections with `Cell::update` https://github.com/rust-lang/rust/issues/50186 , which is also in design phase.
rustc: Work around an upstream wasm ThinLTO bug
This commit implements a workaround for an [upstream LLVM bug][1] where custom
sections were accidentally duplicated amongst codegen units when ThinLTO passes
were performed. This is due to the fact that custom sections for wasm are stored
as metadata nodes which are automatically imported into modules when ThinLTO
happens. The fix here is to forcibly delete the metadata node from imported
modules before LLVM has a chance to try to copy it over.
[1]: https://bugs.llvm.org/show_bug.cgi?id=38184
(pnkfelix updated to address tidy, and to change the buffer from
`Vec<DiagnosticBuilder<'errs>>` to a `Vec<Diagnostic>` in order to
avoid painful lifetime maintenance.)
Since NonNull is Copy the inner field of the cloned Waker was copied for
use in the new LocalWaker, however this left Waker to be dropped. Which
means that when cloning LocalWaker would also erroneously call drop_raw.
This change forgets the Waker, rather then dropping it, leaving the
inner field to be used by the returned LocalWaker.
Closes#52629.
Attach deprecation lint `proc_macro_derive_resolution_fallback` to a specific node id
So it can be `allow`-ed from inside the derive.
cc https://github.com/rust-lang/rust/pull/51952
Don't keep the possibly initialized flow around longer than needed
The possibly initialized flow isn't used after liveness is computed, so don't keep it around. Locally this is about a 10% time win for tuple-stress (which is spending a lot of time calculating flows now that it's not spending so much on liveness).
r? @nikomatsakis
LHS of assign op is invariant
This addresses a bug injected by #45435. That PR changed the way we type-check `LHS <op> RHS` to coerce the LHS to the expected supertype in much the same way that we coerce the RHS.
The problem is that when we have a case of `LHS <op>= RHS`, we do not want to coerce to a supertype; we need the type to remain invariant. Otherwise we risk leaking a value with short-lifetimes into a expression context that needs to satisfy a long lifetime.
Fix#52126
add structured suggestions and fix false-positive for elided-lifetimes-in-paths lint
This adds structured suggestions to the elided-lifetimes-in-paths lint (introduced in Nov. 2017's #46254), prevents it from emitting a false-positive on anonymous (underscore) lifetimes (!), and adds it to the idioms-2018 group (#52041).
~~As an aside, "elided-lifetimes-in-paths" seems like an unfortunate name, because it's not clear exactly what "elided" means. The motivation for this lint (see original issue #45992, and [RFC 2115](e978a8d301/text/2115-argument-lifetimes.md (motivation))) seems to be specifically about not supplying angle-bracketed lifetime arguments to non-`&` types, but (1) the phrase "lifetime elision" has historically also referred to the ability to not supply a lifetime name to `&` references, and (2) an `is_elided` method in the HIR returns true for anoymous/underscore lifetimes, which is _not_ what we're trying to lint here. (That naming confusion is almost certainly what led to the false positive addressed here.) Given that the lint is relatively new and is allow-by-default, is it too late to rename it ... um, _again_ (#50879)?~~
~~This does _not_ address a couple of other false positives discovered in https://github.com/rust-lang/rust/issues/52041#issuecomment-402547901.~~
r? @nikomatsakis
cc @nrc @petrochenkov
