A couple of tiny polonius things
Here's a couple of tiny things I had ready to go @jackh726
- a tiny cleanup to avoid round-tripping through `Location`s to check for liveness, since we're already working with points
- while I was there, I fixed the doc which wasn't showing up properly (maybe a rustdoc or bootstrap bug when we build locally or during dist, either way, both don't show up correctly linked most of the time) for `PointIndex`es.
- and in the second commit slightly expand test coverage with [an example](https://internals.rust-lang.org/t/get-mut-map-back-from-entry-api/24003) that would have needed stdlib changes (cc author @Darksonn for visibility here)
More soon.
r? @jackh726
improve associated-type suggestions from bounds
Should address invalid suggestions I could come up with, but the suggestion is too hand-crafted and invalid patterns may exist.
r? @estebank
Fix https://github.com/rust-lang/rust/issues/73321
Feed `ErrorGuaranteed` from late lifetime resolution errors through to bound variable resolution
If late lifetime resolution fails for whatever reason, forward to RBV the guarantee that an error was emitted - thereby eliminating the need for a "hack" to suppress subsequent/superfluous error diagnostics.
Fixesrust-lang/rust#152014
r? fmease
rustdoc: sort stable items first
Finally tackling this again now that the search system refactor is done. The tests and the general approach were taken from the original PR.
If late lifetime resolution fails for whatever reason, forward to RBV
the guarantee that an error was emitted - thereby eliminating the need
for a "hack" to suppress subsequent/superfluous error diagnostics.
Remove `deprecated_safe` and its corresponding feature gate
This unimplements the feature gate for tracking issue https://github.com/rust-lang/rust/issues/94978
The author of that tracking issue and the MCP seem to no longer exist
Afaik we can just do this, but let me know if I'm wrong
Because this feature has been idle for 3+ years, and it is in the way to finish the attribute refactoring (https://github.com/rust-lang/rust/issues/131229#issuecomment-2971351163)
When someone wants to do work on it the feature gate can be re-added
r? @jdonszelmann
sparc64: enable abi compatibility test
fixes https://github.com/rust-lang/rust/issues/115336
We can now remove the exceptions for sparc64 from the abi compatibility tests (since https://github.com/rust-lang/rust/pull/142680).
I was also able to remove a cfg for mips64. The remaining (tested) issues seem to be around how `f64` is handled there.
cc @RalfJung
r? tgross35
Start using pattern types in libcore (NonZero and friends)
part of rust-lang/rust#136006
This PR only changes the internal representation of `NonZero`, `NonMax`, ... and other integral range types in libcore. This subsequently affects other types made up of it, but nothing really changes except that the field of `NonZero` is now accessible safely in contrast to the `rustc_layout_scalar_range_start` attribute, which has all kinds of obscure rules on how to properly access its field.
llvm will look at both
1. the values of "target-features" and
2. the function string attributes.
this removes the redundant function string attribute because it is not needed at all.
rustc sets the `+backchain` attribute through `target_features_attr(...)`
Correctly check if a macro call is actually a macro call in rustdoc highlighter
Fixesrust-lang/rust#151904.
Issues was that if there was a `!` following an ident, we would always assume it's a macro call... except it's very lacking. I'm actually surprised it went for so long unnoticed. To fix it, I added a check for the next (non-blank) token after the `!`, if it's a `{` or a `[` or a `(`, then only do we consider it to be a macro call.
r? @lolbinarycat
Add FCW for derive helper attributes that will conflict with built-in attributes
Adds a future-compatibility-warning deny-by-default lint that helps catch invalid derive helper attribute names early.
This issues the lint, saying that `ignore` helper will clash with the built-in `ignore` attribute.
```rust
#![crate_type = "proc-macro"]
#![deny(ambiguous_derive_helpers)]
use proc_macro::TokenStream;
#[proc_macro_derive(Trait, attributes(ignore))]
pub fn example(input: TokenStream) -> TokenStream {
TokenStream::new()
}
```
If you actually tried to use that `ignore` helper attribute, you won't be able to due to the ambiguity:
```rust
#[derive(Trait)]
struct Foo {
#[ignore]
field: (),
}
```
Produces:
```
error[E0659]: `ignore` is ambiguous
--> src/lib.rs:5:7
|
5 | #[ignore]
| ^^^^^^ ambiguous name
|
= note: ambiguous because of a name conflict with a builtin attribute
= note: `ignore` could refer to a built-in attribute
note: `ignore` could also refer to the derive helper attribute defined here
--> src/lib.rs:3:10
|
3 | #[derive(Trait)]
| ^^^^^
```
