Commit graph

15297 commits

Author SHA1 Message Date
Guillaume Gomez 0886faaeea
Rollup merge of #127073 - Sky9x:unnecessary-seqcst, r=Nilstrieb
Remove unnecessary SeqCst in `impl fmt::Pointer for AtomicPtr`

Unnecessarily strict ordering.
2024-06-29 14:07:22 +02:00
Guillaume Gomez e9594b504d
Rollup merge of #127072 - Sky9x:docs-includes-vs-does-include, r=scottmcm
docs: say "includes" instead of "does include"

Provides more visual difference between the negative ("does not include") and the positive ("includes"). Both phrases have the same meaning.
2024-06-29 14:07:22 +02:00
Matthias Krüger 1e39eb7d53
Rollup merge of #126953 - joboet:lazy_key, r=jhpratt
std: separate TLS key creation from TLS access

Currently, `std` performs an atomic load to get the OS key on every access to `StaticKey` even when the key is already known. This PR thus replaces `StaticKey` with the platform-specific `get` and `set` function and a new `LazyKey` type that acts as a `LazyLock<Key>`, allowing the reuse of the retreived key for multiple accesses.

Related to #110897.
2024-06-29 09:14:56 +02:00
Matthias Krüger 69996b5ac7
Rollup merge of #127071 - Sky9x:remove-ptr-to-from-bits, r=scottmcm
Remove (deprecated & unstable) {to,from}_bits pointer methods

These unstable methods have been deprecated for more than a year (since #95583). Remove them.

See https://github.com/rust-lang/rust/issues/91126#issuecomment-1835796457 and https://github.com/rust-lang/rust/pull/110441/files#r1169574509.

Closes #91126.

r? `@scottmcm`
2024-06-28 22:04:20 +02:00
Matthias Krüger 6499b9c340
Rollup merge of #127070 - Sky9x:unit-const-param-ty, r=BoxyUwU
add () to the marker_impls macro for ConstParamTy

Seems to have escaped bootstrap
2024-06-28 22:04:19 +02:00
Matthias Krüger afde8485df
Rollup merge of #127055 - shepmaster:hash-finish-must-use, r=dtolnay
Mark Hasher::finish as #[must_use]
2024-06-28 22:04:18 +02:00
joboet 65aea99daf
std: add safety comments 2024-06-28 10:44:26 +02:00
Matthias Krüger 2c228260dc
Rollup merge of #126970 - DaniPopes:simplify-str-clone_into, r=cuviper
Simplify `str::clone_into`

Removes an `unsafe` in favor of just using `String` methods.
2024-06-28 08:34:09 +02:00
Matthias Krüger c4d0c08925
Rollup merge of #126956 - joboet:fmt_no_extern_ty, r=RalfJung
core: avoid `extern type`s in formatting infrastructure

```@RalfJung``` [said](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Use.20of.20.60extern.20type.60.20in.20formatting.20machinery/near/446552837):

>How attached are y'all to using `extern type` in the formatting machinery?
Seems like this was introduced a [long time ago](34ef8f5441). However, it's also [not really compatible with Stacked Borrows](https://github.com/rust-lang/unsafe-code-guidelines/issues/256), and only works currently because we effectively treat references-to-extern-type almost like raw pointers in Stacked Borrows -- which of course is unsound, it's not how LLVM works. I was planning to make Miri emit a warning when this happens to avoid cases like [this](https://github.com/rust-lang/rust/issues/126814#issuecomment-2183816373) where people use extern type specifically to silence Miri without realizing what happens. but with the formatting machinery using  extern type, this warning would just show up everywhere...
>
> The "proper" way to do this in Stacked Borrows is to use raw pointers (or `NonNull`).

This PR does just that.

r? ```@RalfJung```
2024-06-28 08:34:08 +02:00
Sky df7331fcd2
Remove unnecessary SeqCst in impl fmt::Pointer for AtomicPtr 2024-06-28 00:20:35 -04:00
Sky 9bbf3d9805
docs: say "includes" instead of "does include" 2024-06-28 00:01:32 -04:00
Sky 264e8093aa
Remove (deprecated & unstable) {to,from}_bits pointer methods 2024-06-27 23:32:20 -04:00
Sky 8bcd1dede6
add () to the marker_impls macro for ConstParamTy
seems to have escaped bootstrap
2024-06-27 22:37:29 -04:00
Jake Goulding 448dd30ed4 Mark Hasher::finish as #[must_use] 2024-06-27 14:16:27 -04:00
joboet 7e7d0a959d
core: improve comment
Co-authored-by: Ralf Jung <post@ralfj.de>
2024-06-27 12:16:46 +02:00
Jacob Pratt 8905be5ef3
Rollup merge of #126980 - Borgerr:fix-extendfromslice-check, r=workingjubilee
set self.is_known_utf8 to false in extend_from_slice

try-job: x86_64-msvc

closes #126977
Related to #126885, #126333, and [this conversation](<aa46a3368e (r143539097)>)
2024-06-27 02:06:20 -04:00
Jacob Pratt d3debc0037
Rollup merge of #126929 - nnethercote:rm-__rust_force_expr, r=oli-obk
Remove `__rust_force_expr`.

This was added (with a different name) to improve an error message. It is no longer needed -- removing it changes the error message, but overall I think the new message is no worse:
- the mention of `#` in the first line is a little worse,
- but the extra context makes it very clear what the problem is, perhaps even clearer than the old message,
- and the removal of the note about the `expr` fragment (an internal detail of `__rust_force_expr`) is an improvement.

Overall I think the error is quite clear and still far better than the old message that prompted #61933, which didn't even mention patterns.

The motivation for this is #124141, which will cause pasted metavariables to be tokenized and reparsed instead of the AST node being cached. This change in behaviour occasionally has a non-zero perf cost, and `__rust_force_expr` causes the tokenize/reparse step to occur twice. Removing `__rust_force_expr` greatly reduces the extra overhead for the `deep-vector` benchmark.

r? ```@oli-obk```
2024-06-27 02:06:19 -04:00
bors 4bdf8d2d58 Auto merge of #126608 - tgross35:f16-f128-library, r=Mark-Simulacrum
Add more constants, functions, and tests for `f16` and `f128`

This adds everything that was in some way blocked on const eval, since https://github.com/rust-lang/rust/pull/126429 landed. There is a lot of `cfg(bootstrap)` since that is a fairly recent change.

`f128` tests are disabled on everything except x86_64 and Linux aarch64, which are two platforms I know have "good" support for these types - meaning basic math symbols are available and LLVM doesn't hit selection crashes. `f16` tests are enabled on almost everything except for known LLVM crashes. Doctests are only enabled on x86_64.

Tracking issue: https://github.com/rust-lang/rust/issues/116909
2024-06-26 12:06:05 +00:00
Jubilee Young 5aac24909c std: test a variety of ways to extend a Wtf8Buf 2024-06-25 23:44:49 -07:00
ash e5167fe7bd set self.is_known_utf8 to false in extend_from_slice 2024-06-25 23:58:43 -06:00
Matthias Krüger cf22be186c
Rollup merge of #126879 - the8472:next-chunk-filter-drop, r=cuviper
fix Drop items getting leaked in Filter::next_chunk

The optimization only makes sense for non-drop elements anyway. Use the default implementation for items that are Drop instead.

It also simplifies the implementation.

fixes #126872
tracking issue #98326
2024-06-26 07:50:18 +02:00
joboet 23d1cc4b84
core: avoid extern types in formatting infrastructure 2024-06-26 00:06:16 +02:00
joboet 2c9556d28a
fix UI test, simplify error message 2024-06-25 23:43:19 +02:00
The 8472 0d7aef9738 regression test for leaks in the the Filter::next_chunk implementation
previously next_chunk would forget items rejected by the filter
2024-06-25 23:22:27 +02:00
The 8472 2be2d77c50 add comments explaining optimizations for Filter::next_chunk 2024-06-25 23:20:00 +02:00
The 8472 133e7b10a4 fix Drop items getting leaked in Filter::next_chunk
The optimization only makes sense for non-drop elements anyway.
Use the default implementation for items that are Drop instead.

It also simplifies the implementation.
2024-06-25 23:19:58 +02:00
DaniPopes d5ff4f4f65
Simplify str::clone_into
Removes an `unsafe` in favor of just using `String` methods.
2024-06-25 22:34:41 +02:00
Matthias Krüger e9700179bb
Rollup merge of #126946 - cyrgani:patch-1, r=compiler-errors
Add missing slash in `const_eval_select` doc comment

In the middle of the doc comment, one line has only two slashes instead of three and isn't included in the [rendered documentation](https://doc.rust-lang.org/std/intrinsics/fn.const_eval_select.html#stability-concerns). This PR adds the missing slash.
2024-06-25 21:33:44 +02:00
Matthias Krüger 3795c56bd1
Rollup merge of #126927 - workingjubilee:vaargsafe-is-unsafe, r=joboet
core: VaArgSafe is an unsafe trait

`T: VaArgSafe` is relied on for soundness. Safe impls promise nothing. Therefore this must be an unsafe trait. Slightly pedantic, as only core can impl this, but we *could* choose to unseal the trait. That would allow soundly (but unsafely) implementing this for e.g. a `#[repr(C)] struct` that should be passable by varargs.

Relates to https://github.com/rust-lang/rust/issues/44930
2024-06-25 21:33:43 +02:00
Matthias Krüger 9d7e1465a3
Rollup merge of #126885 - Borgerr:rm_internal_pathbuf_asmutvec, r=workingjubilee
Remove internal `PathBuf::as_mut_vec`

closes #126333
2024-06-25 21:33:42 +02:00
Matthias Krüger 58bbade921
Rollup merge of #126302 - mu001999-contrib:ignore/default, r=michaelwoerister
Detect unused structs which derived Default

<!--
If this PR is related to an unstable feature or an otherwise tracked effort,
please link to the relevant tracking issue here. If you don't know of a related
tracking issue or there are none, feel free to ignore this.

This PR will get automatically assigned to a reviewer. In case you would like
a specific user to review your work, you can assign it to them by using

    r​? <reviewer name>
-->

Fixes #98871
2024-06-25 21:33:41 +02:00
joboet e8516f8b52
std: separate TLS key creation from TLS access
Currently, `std` performs an atomic load to get the OS key on every access to `StaticKey` even when the key is already known. This PR thus replaces `StaticKey` with the platform-specific `get` and `set` function and a new `LazyKey` type that acts as a `LazyLock<Key>`, allowing the reuse of the retreived key for multiple accesses.
2024-06-25 18:30:49 +02:00
mu001999 6997b6876d Detect unused structs which derived Default 2024-06-25 23:29:44 +08:00
ash aa46a3368e PathBuf::as_mut_vec removed and verified for UEFI and Windows platforms #126333 2024-06-25 07:36:34 -06:00
ash 7e187e8e4b remove references to PathBuf::as_mut_vec in PathBuf::_set_extension 2024-06-25 07:36:34 -06:00
ash b08cd69684 inner truncate methods for UEFI platforms 2024-06-25 07:36:34 -06:00
ash 2155c6c477 #126333 remove PathBuf::as_mut_vec reference at top of PathBuf::_push 2024-06-25 07:36:34 -06:00
cyrgani c7b579a7cb
Add missing slash in const_eval_select doc comment 2024-06-25 13:37:22 +02:00
Trevor Gross e181297c8c Add tests for f16 and f128
This suite tests all library functions that are now available for the
types. Tests are only run on certain platforms where `f16` and `f128`
are known to work (have symbols available and don't crash LLVM).
2024-06-25 01:32:36 -04:00
Trevor Gross 6e2d934a88 Add more f16 and f128 library functions and constants
This adds everything that was directly or transitively blocked on const
arithmetic for these types, which was recently merged.

Since const arithmetic is recent, most of these need to be gated by
`bootstrap`.

Anything that relies on intrinsics that are still missing is excluded.
2024-06-25 01:32:36 -04:00
Trevor Gross 0eee0557d0 Add doctests to existing f16 and f128 functions
The symbols that these tests rely on are not available on all platforms
and some ABIs are buggy, tests that rely on external functions are
configured to only run on x86 (`f128`) or aarch64 (`f16`).
2024-06-25 01:32:36 -04:00
Trevor Gross 99ed3d3e99 Add build.rs config for reliable f16 and f128
There are some complexities about what platforms we can test f16 and
f128 on.  Put this in build.rs so we have an easy way to configure tests
with a single attribute, and keep it up to date.
2024-06-25 01:32:36 -04:00
Nicholas Nethercote 9828e960ab Remove __rust_force_expr.
This was added (with a different name) to improve an error message. It
is no longer needed -- removing it changes the error message, but overall
I think the new message is no worse:
- the mention of `#` in the first line is a little worse,
- but the extra context makes it very clear what the problem is, perhaps
  even clearer than the old message,
- and the removal of the note about the `expr` fragment (an internal
  detail of `__rust_force_expr`) is an improvement.

Overall I think the error is quite clear and still far better than the
old message that prompted #61933, which didn't even mention patterns.

The motivation for this is #124141, which will cause pasted
metavariables to be tokenized and reparsed instead of the AST node being
cached. This change in behaviour occasionally has a non-zero perf cost,
and `__rust_force_expr` causes the tokenize/reparse step to occur twice.
Removing `__rust_force_expr` greatly reduces the extra overhead for the
`deep-vector` benchmark.
2024-06-25 14:35:09 +10:00
Jubilee Young 050595a826 core: VaArgSafe is an unsafe trait
`T: VaArgSafe` is relied on for soundness. Safe impls promise nothing.
Therefore this must be an unsafe trait. Slightly pedantic, as
only core can impl this, but we could choose to unseal the trait.
That would allow soundly (but unsafely) implementing this for e.g.
a `#[repr(C)] struct` that should be passable by varargs.
2024-06-24 20:40:33 -07:00
bors fc555cd832 Auto merge of #126852 - scottmcm:more-checked-math-tweaks, r=Amanieu
Also get `add nuw` from `uN::checked_add`

When I was doing this for `checked_{sub,shl,shr}`, it was mentioned https://github.com/rust-lang/rust/pull/124114#issuecomment-2066173305 that it'd be worth trying for `checked_add` too.

It makes a particularly-big difference for `x.checked_add(C)`, as doing this means that LLVM removes the intrinsic and does it as a normal `x <= MAX - C` instead.

cc `@DianQK` who had commented about `checked_add` related to https://github.com/rust-lang/hashbrown/issues/509 before

cc https://github.com/llvm/llvm-project/issues/80637 for how LLVM is unlikely to do this itself
2024-06-25 02:50:37 +00:00
Michael Goulet 85eb835a14
Rollup merge of #126904 - GrigorenkoPV:nonzero-fixme, r=joboet
Small fixme in core now that NonZero is generic

I doubt I have the rights to, but
`@bors` rollup=always
2024-06-24 15:51:05 -04:00
Michael Goulet ed460d2eaa
Rollup merge of #125575 - dingxiangfei2009:derive-smart-ptr, r=davidtwco
SmartPointer derive-macro

<!--
If this PR is related to an unstable feature or an otherwise tracked effort,
please link to the relevant tracking issue here. If you don't know of a related
tracking issue or there are none, feel free to ignore this.

This PR will get automatically assigned to a reviewer. In case you would like
a specific user to review your work, you can assign it to them by using

    r​? <reviewer name>
-->

Possibly replacing #123472 for continued upkeep of the proposal rust-lang/rfcs#3621 and implementation of the tracking issue #123430.

cc `@Darksonn` `@wedsonaf`
2024-06-24 15:51:01 -04:00
Michael Goulet c77dc28f87
Rollup merge of #125082 - kpreid:const-uninit, r=dtolnay
Remove `MaybeUninit::uninit_array()` and replace it with inline const blocks.

\[This PR originally contained the changes in #125995 too. See edit history for the original PR description.]

The documentation of `MaybeUninit::uninit_array()` says:

> Note: in a future Rust version this method may become unnecessary when Rust allows [inline const expressions](https://github.com/rust-lang/rust/issues/76001). The example below could then use `let mut buf = [const { MaybeUninit::<u8>::uninit() }; 32];`.

The PR adding it also said: <https://github.com/rust-lang/rust/pull/65580#issuecomment-544200681>

> if it’s stabilized soon enough maybe it’s not worth having a standard library method that will be replaceable with `let buffer = [MaybeUninit::<T>::uninit(); $N];`

That time has come to pass — inline const expressions are stable — so `MaybeUninit::uninit_array()` is now unnecessary. The only remaining question is whether it is an important enough *convenience* to keep it around.

I believe it is net good to remove this function, on the principle that it is better to compose two orthogonal features (`MaybeUninit` and array construction) than to have a specific function for the specific combination, now that that is possible.
2024-06-24 15:51:01 -04:00
Kevin Reid 13fca73f49 Replace MaybeUninit::uninit_array() with array repeat expression.
This is possible now that inline const blocks are stable; the idea was
even mentioned as an alternative when `uninit_array()` was added:
<https://github.com/rust-lang/rust/pull/65580#issuecomment-544200681>

> if it’s stabilized soon enough maybe it’s not worth having a
> standard library method that will be replaceable with
> `let buffer = [MaybeUninit::<T>::uninit(); $N];`

Const array repetition and inline const blocks are now stable (in the
next release), so that circumstance has come to pass, and we no longer
have reason to want `uninit_array()` other than convenience. Therefore,
let’s evaluate the inconvenience by not using `uninit_array()` in
the standard library, before potentially deleting it entirely.
2024-06-24 10:23:50 -07:00
bors 5a3e2a4e92 Auto merge of #126523 - joboet:the_great_big_tls_refactor, r=Mark-Simulacrum
std: refactor the TLS implementation

As discovered by Mara in #110897, our TLS implementation is a total mess. In the past months, I have simplified the actual macros and their expansions, but the majority of the complexity comes from the platform-specific support code needed to create keys and register destructors. In keeping with #117276, I have therefore moved all of the `thread_local_key`/`thread_local_dtor` modules to the `thread_local` module in `sys` and merged them into a new structure, so that future porters of `std` can simply mix-and-match the existing code instead of having to copy the same (bad) implementation everywhere. The new structure should become obvious when looking at `sys/thread_local/mod.rs`.

Unfortunately, the documentation changes associated with the refactoring have made this PR rather large. That said, this contains no functional changes except for two small ones:
* the key-based destructor fallback now, by virtue of sharing the implementation used by macOS and others, stores its list in a `#[thread_local]` static instead of in the key, eliminating one indirection layer and drastically simplifying its code.
* I've switched over ZKVM (tier 3) to use the same implementation as WebAssembly, as the implementation was just a way worse version of that

Please let me know if I can make this easier to review! I know these large PRs aren't optimal, but I couldn't think of any good intermediate steps.

`@rustbot` label +A-thread-locals
2024-06-24 15:55:28 +00:00