Move special treatment of `derive(Copy, PartialEq, Eq)` from expansion infrastructure to elsewhere
As described in https://github.com/rust-lang/rust/pull/62086#issuecomment-515195477.
Reminder:
- `derive(PartialEq, Eq)` makes the type it applied to a "structural match" type, so constants of this type can be used in patterns (and const generics in the future).
- `derive(Copy)` notifies other derives that the type it applied to implements `Copy`, so `derive(Clone)` can generate optimized code and other derives can generate code working with `packed` types and types with `rustc_layout_scalar_valid_range` attributes.
First, the special behavior is now enabled after properly resolving the derives, rather than after textually comparing them with `"Copy"`, `"PartialEq"` and `"Eq"` in `fn add_derived_markers`.
The markers are no longer kept as attributes in AST since derives cannot modify items and previously did it through hacks in the expansion infra.
Instead, the markers are now kept in a "global context" available from all the necessary places, namely - resolver.
For `derive(PartialEq, Eq)` the markers are created by the derive macros themselves and then consumed during HIR lowering to add the `#[structural_match]` attribute in HIR.
This is still a hack, but now it's a hack local to two specific macros rather than affecting the whole expansion infra.
Ideally we should find the way to put `#[structural_match]` on the impls rather than on the original item, and then consume it in `rustc_mir`, then no hacks in expansion and lowering will be required.
(I'll make an issue about this for someone else to solve, after this PR lands.)
The marker for `derive(Copy)` cannot be emitted by the `Copy` macro itself because we need to know it *before* the `Copy` macro is expanded for expanding other macros.
So we have to do it in resolve and block expansion of any derives in a `derive(...)` container until we know for sure whether this container has `Copy` in it or not.
Nasty stuff.
r? @eddyb or @matthewjasper
Rollup of 5 pull requests
Successful merges:
- #62954 (Fix typo in Delimited::open_tt)
- #63146 (Cleanup syntax::attr)
- #63218 (rustbuild: RISC-V is no longer an experimental LLVM target)
- #63227 (dead_code: Properly inspect fields in struct patterns with type relative paths)
- #63229 (A bit of Miri error cleanup)
Failed merges:
r? @ghost
Miri: dispatch first on the type
Based on the fact that Miri now always has intptrcast available, we can change binops and casts to first check the type of the source operand and then decide based on that what to do, instead of considering the value (pointer vs bits) first.
Change opaque type syntax from `existential type` to type alias `impl Trait`
This implements a new feature gate `type_alias_impl_trait` (this is slightly different from the originally proposed feature name, but matches what has been used in discussion since), deprecating the old `existential_types` feature.
The syntax for opaque types has been changed. In addition, the "existential" terminology has been replaced with "opaque", as per previous discussion and the RFC.
This makes partial progress towards implementing https://github.com/rust-lang/rust/issues/63063.
r? @Centril
On `format!()` arg count mismatch provide extra info
When positional width and precision formatting flags are present in a
formatting string that has an argument count mismatch, provide extra
information pointing at them making it easiser to understand where the
problem may lay:
```
error: 4 positional arguments in format string, but there are 3 arguments
--> $DIR/ifmt-bad-arg.rs:78:15
|
LL | println!("{} {:.*} {}", 1, 3.2, 4);
| ^^ ^^--^ ^^ --- this parameter corresponds to the precision flag
| |
| this precision flag adds an extra required argument at position 1, which is why there are 4 arguments expected
|
= note: positional arguments are zero-based
= note: for information about formatting flags, visit https://doc.rust-lang.org/std/fmt/index.html
error: 4 positional arguments in format string, but there are 3 arguments
--> $DIR/ifmt-bad-arg.rs:81:15
|
LL | println!("{} {:07$.*} {}", 1, 3.2, 4);
| ^^ ^^-----^ ^^ --- this parameter corresponds to the precision flag
| | |
| | this precision flag adds an extra required argument at position 1, which is why there are 4 arguments expected
| this width flag expects an `usize` argument at position 7, but there are 3 arguments
|
= note: positional arguments are zero-based
= note: for information about formatting flags, visit https://doc.rust-lang.org/std/fmt/index.html
error: invalid reference to positional argument 7 (there are 3 arguments)
--> $DIR/ifmt-bad-arg.rs:84:18
|
LL | println!("{} {:07$} {}", 1, 3.2, 4);
| ^^^--^
| |
| this width flag expects an `usize` argument at position 7, but there are 3 arguments
|
= note: positional arguments are zero-based
= note: for information about formatting flags, visit https://doc.rust-lang.org/std/fmt/index.html
```
Fix#49384.
Rollup of 8 pull requests
Successful merges:
- #62644 (simplify std::io::Write::write rustdoc)
- #62971 (Add keywords item into the sidebar)
- #63122 (Account for `maybe_whole_expr` in range patterns)
- #63158 (Add test for issue-58951)
- #63170 (cleanup StringReader fields)
- #63179 (update test cases for vxWorks)
- #63188 (Fix typos in release notes.)
- #63191 (ci: fix toolstate not pushing data for Linux)
Failed merges:
r? @ghost
update test cases for vxWorks
issue-2214.rs: lgamma is lgamma on vxWorks
ignore process-envs.rs and process-remove-from-env.rs as there is no 'env' on vxWorks
Remove derives `Encodable`/`Decodable` and unstabilize attribute `#[bench]`
`Encodable` and `Decodable` were deprecated before 1.0 and emitted an unsuppressable warning all this time.
`#[bench]` is a part of the custom test framework feature and cannot be used meaningfully on stable, only as `cfg(false)`.
Crater results can be found in https://github.com/rust-lang/rust/pull/62507#issuecomment-513850732 and below.
This PR also reroutes the tracking issue for `feature(test)` from #27812 (compiler internals) to #50297 (custom test frameworks).
Closes https://github.com/rust-lang/rust/issues/62048
Some fixes for i686-msvc and Windows have landed on the `backtrace`
crate but hadn't made their way here yet. Let's update that and see if
it passes CI.
`const fn`-ify `std::any::type_name` as laid out in #63084
A test, based on the one I added when I implemented support for the underlying `core::intrinsics::type_name` being allowed in `const fn` contexts, is included.
Turn `INCOMPLETE_FEATURES` into lint
We do this because it is annoying to see the warning when building rustc and because this is better from a "separation of concerns" POV.
The drawback to this change is that this will respect `--cap-lints`.
Also note that this is not a buffered lint so if there are fatal parser errors then the lint will not trigger.
r? @varkor
