Files
rust/tests/ui/consts
Stuart Cook dd4f062b07 Rollup merge of #128399 - mammothbane:master, r=Amanieu,tgross35
liballoc: introduce String, Vec const-slicing

This change `const`-qualifies many methods on `Vec` and `String`, notably `as_slice`, `as_str`, `len`. These changes are made behind the unstable feature flag `const_vec_string_slice`.

## Motivation
This is to support simultaneous variance over ownership and constness. I have an enum type that may contain either `String` or `&str`, and I want to produce a `&str` from it in a possibly-`const` context.

```rust
enum StrOrString<'s> {
    Str(&'s str),
    String(String),
}

impl<'s> StrOrString<'s> {
    const fn as_str(&self) -> &str {
        match self {
             // In a const-context, I really only expect to see this variant, but I can't switch the implementation
             // in some mode like #[cfg(const)] -- there has to be a single body
             Self::Str(s) => s,

             // so this is a problem, since it's not `const`
             Self::String(s) => s.as_str(),
        }
    }
}
```

Currently `String` and `Vec` don't support this, but can without functional changes. Similar logic applies for `len`, `capacity`, `is_empty`.

## Changes

The essential thing enabling this change is that `Unique::as_ptr` is `const`. This lets us convert `RawVec::ptr` -> `Vec::as_ptr` -> `Vec::as_slice` -> `String::as_str`.

I had to move the `Deref` implementations into `as_{str,slice}` because `Deref` isn't `#[const_trait]`, but I would expect this change to be invisible up to inlining. I moved the `DerefMut` implementations as well for uniformity.
2024-10-07 15:37:06 +11:00
..
2024-09-14 18:07:06 +02:00
2024-09-15 09:51:32 +02:00
2024-09-15 10:20:47 +02:00
2024-01-13 12:46:58 -05:00
2024-09-15 09:51:32 +02:00
2024-08-18 19:46:53 +02:00
2023-01-11 09:32:08 +00:00
2024-04-24 13:12:33 +01:00
2024-06-21 11:57:24 +00:00
2024-02-07 10:42:01 +08:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2024-09-15 09:51:32 +02:00
2024-09-15 09:51:32 +02:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2024-09-15 09:51:32 +02:00
2024-09-15 09:51:32 +02:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2024-06-28 10:57:35 +00:00
2024-09-15 09:51:32 +02:00
2024-09-15 09:51:32 +02:00
2023-01-11 09:32:08 +00:00
2023-11-12 04:33:19 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-01-31 17:26:06 +00:00
2024-01-13 12:46:58 -05:00
2024-02-25 12:03:48 +01:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2024-04-21 15:43:43 -03:00
2024-04-21 15:43:43 -03:00
2024-04-21 15:43:43 -03:00
2024-04-21 15:43:43 -03:00
2023-04-16 11:38:52 +00:00
2023-07-27 15:51:02 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-04-03 15:59:21 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-07-27 15:51:02 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-04-03 15:59:21 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2024-09-15 09:51:32 +02:00
2024-04-24 13:12:33 +01:00
2023-10-08 10:06:17 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2024-01-24 07:56:23 +01:00
2024-01-24 07:56:23 +01:00
2023-01-11 09:32:08 +00:00
2024-09-15 09:51:32 +02:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-01-15 19:46:20 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2024-09-14 18:07:06 +02:00
2024-01-13 12:46:58 -05:00