make char::is_whitespace unstably const
I am adding this to the existing https://github.com/rust-lang/rust/issues/132241 feature gate, since `is_digit` and `is_whitespace` seem similar enough that one can group them together.
Rollup of 8 pull requests
Successful merges:
- #132259 (rustc_codegen_llvm: Add a new 'pc' option to branch-protection)
- #132409 (CI: switch 7 linux jobs to free runners)
- #132498 (Suggest fixing typos and let bindings at the same time)
- #132524 (chore(style): sync submodule exclusion list between tidy and rustfmt)
- #132567 (Properly suggest `E::assoc` when we encounter `E::Variant::assoc`)
- #132571 (add const_eval_select macro to reduce redundancy)
- #132637 (Do not filter empty lint passes & re-do CTFE pass)
- #132642 (Add documentation on `ast::Attribute`)
r? `@ghost`
`@rustbot` modify labels: rollup
get rid of a whole bunch of unnecessary rustc_const_unstable attributes
In general, when a `const fn` is still unstable, it doesn't need a `#[rustc_const_unstable]` attribute. The only exception is functions that internally use things that can't be used in stable const fn yet.
So this gets rid of a whole bunch of `#[rustc_const_unstable]` in libcore.
Fundamentally, we have *three* disjoint categories of functions:
1. const-stable functions
2. private/unstable functions that are meant to be callable from const-stable functions
3. functions that can make use of unstable const features
This PR implements the following system:
- `#[rustc_const_stable]` puts functions in the first category. It may only be applied to `#[stable]` functions.
- `#[rustc_const_unstable]` by default puts functions in the third category. The new attribute `#[rustc_const_stable_indirect]` can be added to such a function to move it into the second category.
- `const fn` without a const stability marker are in the second category if they are still unstable. They automatically inherit the feature gate for regular calls, it can now also be used for const-calls.
Also, several holes in recursive const stability checking are being closed.
There's still one potential hole that is hard to avoid, which is when MIR
building automatically inserts calls to a particular function in stable
functions -- which happens in the panic machinery. Those need to *not* be
`rustc_const_unstable` (or manually get a `rustc_const_stable_indirect`) to be
sure they follow recursive const stability. But that's a fairly rare and special
case so IMO it's fine.
The net effect of this is that a `#[unstable]` or unmarked function can be
constified simply by marking it as `const fn`, and it will then be
const-callable from stable `const fn` and subject to recursive const stability
requirements. If it is publicly reachable (which implies it cannot be unmarked),
it will be const-unstable under the same feature gate. Only if the function ever
becomes `#[stable]` does it need a `#[rustc_const_unstable]` or
`#[rustc_const_stable]` marker to decide if this should also imply
const-stability.
Adding `#[rustc_const_unstable]` is only needed for (a) functions that need to
use unstable const lang features (including intrinsics), or (b) `#[stable]`
functions that are not yet intended to be const-stable. Adding
`#[rustc_const_stable]` is only needed for functions that are actually meant to
be directly callable from stable const code. `#[rustc_const_stable_indirect]` is
used to mark intrinsics as const-callable and for `#[rustc_const_unstable]`
functions that are actually called from other, exposed-on-stable `const fn`. No
other attributes are required.
Update Unicode escapes in `/library/core/src/char/methods.rs`
`char::MAX` is inconsistent on how Unicode escapes should be formatted. This PR resolves that.
Mark `u8::make_ascii_uppercase` and `u8::make_ascii_lowercase` as const.
Relevant tracking issue: #130698
This PR extends #130697 by also marking the `make_ascii_uppercase` and `make_ascii_lowercase` methods in `u8` as const.
The `const_char_make_ascii` feature gate is additionally renamed to `const_make_ascii`.
Support `char::encode_utf16` in const scenarios.
Relevant tracking issue: #130660
The method `char::encode_utf16` should be marked "const" to allow compile-time conversions.
This PR additionally rewrites the `encode_utf16_raw` function for better readability whilst also reducing the amount of unsafe code.
try-job: x86_64-msvc
Mark `char::make_ascii_uppercase` and `char::make_ascii_lowercase` as const.
Relevant tracking issue: #130698
The `make_ascii_uppercase` and `make_ascii_lowercase` methods in `char` should be marked "const."
With the stabilisation of [`const_mut_refs`](https://github.com/rust-lang/rust/issues/57349/), this simply requires adding the `const` specifier to the function signatures.
some const cleanup: remove unnecessary attributes, add const-hack indications
I learned that we use `FIXME(const-hack)` on top of the "const-hack" label. That seems much better since it marks the right place in the code and moves around with the code. So I went through the PRs with that label and added appropriate FIXMEs in the code. IMO this means we can then remove the label -- Cc ``@rust-lang/wg-const-eval.``
I also noticed some const stability attributes that don't do anything useful, and removed them.
r? ``@fee1-dead``
`use` declarations will be reformatted in #125443. Very rarely, there is
a desire to force a group of `use` declarations together in a way that
auto-formatting will break up. E.g. when you want a single comment to
apply to a group. #126776 dealt with all of these in the codebase,
ensuring that no comments intended for multiple `use` declarations would
end up in the wrong place. But some people were unhappy with it.
This commit uses `#[rustfmt::skip]` to create these custom `use` groups
in an idiomatic way for a few of the cases changed in #126776. This
works because rustfmt treats any `use` item annotated with
`#[rustfmt::skip]` as a barrier and won't reorder other `use` items
around it.
There are some comments describing multiple subsequent `use` items. When
the big `use` reformatting happens some of these `use` items will be
reordered, possibly moving them away from the comment. With this
additional level of formatting it's not really feasible to have comments
of this type. This commit removes them in various ways:
- merging separate `use` items when appropriate;
- inserting blank lines between the comment and the first `use` item;
- outright deletion (for comments that are relatively low-value);
- adding a separate "top-level" comment.
We also entirely skip formatting for four library files that contain
nothing but `pub use` re-exports, where reordering would be painful.
This adds a dedicated check for the lower bound
(if it is outside of ASCII range) to the output of the `unicode-table-generator` tool.
This generalized the ASCII-only fast-path, but only for the `Grapheme_Extend` property for now,
as that is the only one with a lower bound outside of ASCII.
