| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
The previous version used `['l', 'l']` as pattern, which would suggest that it matches the `ll` of `Hello world` as a whole.
|
|
|
|
|
|
Fixes #126425
Replace the potentially panicking `[]` indexing with `get_unchecked()`
to prevent linking with panic-related code.
|
|
|
|
remove const-support for align_offset and is_aligned
As part of the recent discussion to stabilize `ptr.is_null()` in const context, the general vibe was that it's okay for a const function to panic when the same operation would work at runtime (that's just a case of "dynamically detecting that something is not supported as a const operation"), but it is *not* okay for a const function to just return a different result.
Following that, `is_aligned` and `is_aligned_to` have their const status revoked in this PR, since they do return actively wrong results at const time. In the future we can consider having a new intrinsic or so that can check whether a pointer is "guaranteed to be aligned", but the current implementation based on `align_offset` does not have the behavior we want.
In fact `align_offset` itself behaves quite strangely in const, and that support needs a bunch of special hacks. That doesn't seem worth it. Instead, the users that can fall back to a different implementation should just use const_eval_select directly, and everything else should not be made const-callable. So this PR does exactly that, and entirely removes const support for align_offset.
Closes some tracking issues by removing the associated features:
Closes https://github.com/rust-lang/rust/issues/90962
Closes https://github.com/rust-lang/rust/issues/104203
Cc `@rust-lang/wg-const-eval` `@rust-lang/libs-api`
|
|
Modify `NonZero` documentation to reference the underlying integer type
This change updates the documentation for `NonZero` integer types to explicitly reference the underlying integer type each `NonZero` variant wraps, instead of using a general "integer" term.
**Before**
**After**
|
|
Yeet the `effects` feature, move it onto `const_trait_impl`
This PR merges the `effects` feature into the `const_trait_impl` feature. There's really no need to have two feature gates for one feature.
After this PR, if `const_trait_impl` **is** enabled:
* Users can use and define const traits
* `HostEffect` const conditions will be enforced on the HIR
* We re-check the predicates in MIR just to make sure that we don't "leak" anything during MIR lowering
And if `const_trait_impl` **is not** enabled:
* Users cannot use nor define const traits
* `HostEffect` const conditions are not enforced on the HIR
* We will raise a const validation error if we call a function that has any const conditions (i.e. const traits and functions with any `~const` in their where clasues)
This should be the last step for us to be able to enable const traits in the standard library. We still need to re-constify `Drop` and `Destruct` and stuff for const traits to be particularly *useful* for some cases, but this is a good step :D
r? fee1-dead
cc `@rust-lang/project-const-traits`
|
|
|
|
add const_panic macro to make it easier to fall back to non-formatting panic in const
Suggested by `@tgross35`
r? `@tgross35`
|
|
Operations like is_aligned would return actively wrong results at compile-time,
i.e. calling it on the same pointer at compiletime and runtime could yield
different results. That's no good.
Instead of having hacks to make align_offset kind-of work in const-eval, just
use const_eval_select in the few places where it makes sense, which also ensures
those places are all aware they need to make sure the fallback behavior is
consistent.
|
|
This change updates the documentation for `NonZero` integer types to
explicitly reference the underlying integer type each `NonZero` variant
wraps, instead of using a general "integer" term.
|
|
stabilize const_arguments_as_str
FCP passed in the [tracking issue](https://github.com/rust-lang/rust/issues/103900#issuecomment-2397096659).
|
|
better test for const HashMap; remove const_hash leftovers
The existing `const_with_hasher` test is kind of silly since the HashMap it constructs can never contain any elements. So this adjusts the test to construct a usable HashMap, which is a bit non-trivial since the default hash builder cannot be built in `const`. `BuildHasherDefault::new()` helps but is unstable (https://github.com/rust-lang/rust/issues/123197), so we also have a test that does not involve that type.
The second commit removes the last remnants of https://github.com/rust-lang/rust/issues/104061, since they aren't actually useful -- without const traits, you can't do any hashing in `const`.
Cc ``@rust-lang/libs-api`` ``@rust-lang/wg-const-eval``
Closes #104061
Related to https://github.com/rust-lang/rust/issues/102575
|
|
unicode_data.rs: show command for generating file
https://github.com/rust-lang/rust/pull/131647 made this an easily runnable tool, now we just have to mention that in the comment. :)
Fixes https://github.com/rust-lang/rust/issues/131640.
|
|
Add LowerExp and UpperExp implementations to NonZero
Adds `LowerExp` and `UpperExp` trait implementations to `NonZero`, as discussed in rust-lang/libs-team#458.
I had to modify the macro to mark the new impls with a different rust version. Let me know if this is the right way to do it (first timer here!)
|
|
in const
|
|
|
|
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.
|
|
original lifetime
|
|
library: fix some stability annotations
This PR updates some stability attributes to correctly reflect when some items actually got stabilized. Found while testing https://github.com/rust-lang/rust/pull/132481.
### `core::char` / `std::char`
In https://github.com/rust-lang/rust/pull/26192, the `core::char` module got "stabilized" for 1.2.0, but the `core` crate itself was still unstable until 1.6.0.
In https://github.com/rust-lang/rust/pull/49698, the `std::char` module was changed to a re-export of `core::char`, making `std::char` appear as "stable since 1.2.0", even though it was already stable in 1.0.0.
By marking `core::char` as stable since 1.0.0, the docs will show correct versions for both `core::char` (since 1.6.0) and `std::char` (since 1.0.0). This is also consistent with the stabilities of similar re-exported modules like `core::mem`/`std::mem` for example.
### `{core,std}::array` and `{core,std}::array::TryFromSliceError`
In https://github.com/rust-lang/rust/pull/58302, the `core::array::TryFromSliceError` type got stabilized for 1.34.0, together with `TryFrom`. At that point the `core::array` module was still unstable and a `std::array` re-export didn't exist, but `core::array::TryFromSliceError` could still be named due to https://github.com/rust-lang/rust/pull/95956 to existing yet.
Then, `core::array` got stabilized and `std::array` got added, first targeting 1.36.0 in https://github.com/rust-lang/rust/pull/60657, but then getting backported for 1.35.0 in https://github.com/rust-lang/rust/pull/60838.
This means that `core::array` and `std::array` actually got stabilized in 1.35.0 and `core::array::TryFromSliceError` was accessible through the unstable module in 1.34.0 -- mark them as such so that the docs display the correct versions.
|
|
|
|
|
|
|
|
|
|
Add a couple of intra-doc links to str
|
|
|
|
feat(byte_sub_ptr): unstably add ptr::byte_sub_ptr
This is an API that naturally should exist as a combination of byte_offset_from and sub_ptr
both existing (they showed up at similar times so this union was never made). Adding these
is a logical (and perhaps final) precondition of stabilizing ptr_sub_ptr (https://github.com/rust-lang/rust/issues/95892).
Original PR by ``@Gankra`` (https://github.com/rust-lang/rust/pull/121919), I am just reviving it. The 2nd commit (with a small docs tweak) is by me.
|
|
make const_alloc_layout feature gate only about functions that are already stable
The const_alloc_layout feature gate has two kinds of functions: those that are stable, but not yet const-stable, and those that are fully unstable.
I think we should split that up. So this PR makes const_alloc_layout just about functions that are already stable but waiting for const-stability; all the other functions now have their constness guarded by the gate that also guards their regular stability.
Cc https://github.com/rust-lang/rust/issues/67521
|
|
r=tgross35
remove some unnecessary rustc_allow_const_fn_unstable
These are either unstable functions that don't need the attribute, or the attribute refers to a feature that is already stable.
|
|
Cleanup attributes around unchecked shifts and unchecked negation in const
The underlying intrinsic is marked as "safe to expose on stable", so we shouldn't need any `rustc_allow_const_fn_unstable(unchecked_shifts)` anywhere. However, bootstrap rustc doesn't yet have the new const stability checks, so these changes only apply under `cfg(not(bootstrap))`.
|
|
update offset_of! docs to reflect the stabilization of nesting
this seems to have been missed.
|
|
|
|
|
|
|
|
|
|
allocation
|
|
This is an API that naturally should exist as a combination of byte_offset_from and sub_ptr
both existing (they showed up at similar times so this union was never made). Adding these
is a logical (and perhaps final) precondition of stabilizing ptr_sub_ptr (#95892).
|
|
stable
the rest has their constness guarded by their usual feature gate
|
|
can get rid of a bunch of attributes
|
|
|
|
Co-authored-by: Jubilee <workingjubilee@gmail.com>
|
|
|
|
|
|
|
|
This commit is a response to feedback on the displayed type
signatures results, by making generics act stricter.
Generics are tightened by making order significant. This means
`Vec<Allocator>` now matches only with a true vector of allocators,
instead of matching the second type param. It also makes unboxing
within generics stricter, so `Result<A, B>` only matches if `B`
is in the error type and `A` is in the success type. The top level
of the function search is unaffected.
Find the discussion on:
* <https://rust-lang.zulipchat.com/#narrow/stream/393423-t-rustdoc.2Fmeetings/topic/meeting.202024-07-08/near/449965149>
* <https://github.com/rust-lang/rust/pull/124544#issuecomment-2204272265>
* <https://rust-lang.zulipchat.com/#narrow/channel/266220-t-rustdoc/topic/deciding.20on.20semantics.20of.20generics.20in.20rustdoc.20search/near/476841363>
|
|
|
