pretty-pretty extremal constants!
(A resurrection of the defunct #57073.)
While many programmers may intuitively appreciate the significance of "magic numbers" like −2147483648, Rust is about empowering everyone to build reliable and efficient software! It's a bit more legible to print the constant names (even noisy fully-qualified-paths thereof).
The bit-manipulation methods mirror those in `librustc_mir::hair::pattern::_match::all_constructors`; thanks to the immortal Varkor for guidance.
Resolves#56393.
r? @varkor
While many programmers may intuitively appreciate the significance of
"magic numbers" like −2147483648, Rust is about empowering everyone to
build reliable and efficient software! It's a bit more legible to
print the constant names (even noisy fully-qualified-paths thereof).
The bit-manipulation methods mirror those in
`librustc_mir::hair::pattern::_match::all_constructors`; thanks to the
immortal Varkor for guidance.
Resolves#56393.
Fix generator size regressions due to optimization
I tested the generator optimizations in #60187 and #61922 on the Fuchsia
build, and noticed that some small generators (about 8% of the async fns
in our build) increased in size slightly.
This is because in #60187 we split the fields into two groups, a
"prefix" non-overlap region and an overlap region, and lay them out
separately. This can introduce unnecessary padding bytes between the two
groups.
In every single case in the Fuchsia build, it was due to there being
only a single variant being used in the overlap region. This means that
we aren't doing any overlapping, period. So it's better to combine the
two regions into one and lay out all the fields at once, which is what
this change does.
r? @cramertj
cc @eddyb @Zoxc
I tested the generator optimizations in #60187 and #61922 on the Fuchsia
build, and noticed that some small generators (about 8% of the async fns
in our build) increased in size slightly.
This is because in #60187 we split the fields into two groups, a
"prefix" non-overlap region and an overlap region, and lay them out
separately. This can introduce unnecessary padding bytes between the two
groups.
In every single case in the Fuchsia build, it was due to there being
only a single variant being used in the overlap region. This means that
we aren't doing any overlapping, period. So it's better to combine the
two regions into one and lay out all the fields at once, which is what
this change does.
Revert "Rollup merge of #62696 - chocol4te:fix_#62194, r=estebank"
This reverts commit df21a6f040 (#62696), reversing
changes made to cc16d04869.
That PR makes error messages worse than before, and we couldn't come up with a way of actually making them better, so revert it for now. Any idea for making this error message better is welcome!
Fixes#63145.
r? @estebank
Remove special code-path for handing unknown tokens
In `StringReader`, we have a buffer of fatal errors, which is used only in a single case: when we see something which is not a reasonable token at all, like `🦀`. I think a more straightforward thing to do here is to produce an explicit error token in this case, and let the next layer (the parser), deal with it.
However currently this leads to duplicated error messages. What should we do with this? Naively, I would think that emitting (just emitting, not raising) `FatalError` should stop other errors, but looks like this is not the case? We can also probably tweak parser on the case-by-case basis, to avoid emitting "expected" errors if the current token is an `Err`. I personally also fine with cascading errors in this case: it's quite unlikely that you actually type a fully invalid token.
@petrochenkov, which approach should we take to fight cascading errors?
CTFE: simplify ConstValue by not checking for alignment
I hope the test suite actually covers the problematic cases here?
r? @oli-obk
Fixes https://github.com/rust-lang/rust/issues/61952
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
More Miri error tweaks
* Add `err_` version of the `_format!` macros
* Add `UbExperimental` variant so that Miri can mark some UB as experimental (e.g. Stacked Borrows)
r? @oli-obk
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.
