Commit Graph

16807 Commits

Author SHA1 Message Date
Urgau
00444bab26 Round negative signed integer towards zero in iN::midpoint
Instead of towards negative infinity as is currently the case.

This done so that the obvious expectations of
`midpoint(a, b) == midpoint(b, a)` and
`midpoint(-a, -b) == -midpoint(a, b)` are true, which makes the even
more obvious implementation `(a + b) / 2` true.

https://github.com/rust-lang/rust/issues/110840#issuecomment-2336753931
2024-10-26 18:46:41 +02:00
bors
54761cb3e8 Auto merge of #131349 - RalfJung:const-stability-checks, r=compiler-errors
Const stability checks v2

The const stability system has served us well ever since `const fn` were first stabilized. It's main feature is that it enforces *recursive* validity -- a stable const fn cannot internally make use of unstable const features without an explicit marker in the form of `#[rustc_allow_const_fn_unstable]`. This is done to make sure that we don't accidentally expose unstable const features on stable in a way that would be hard to take back. As part of this, it is enforced that a `#[rustc_const_stable]` can only call `#[rustc_const_stable]` functions. However, some problems have been coming up with increased usage:
- It is baffling that we have to mark private or even unstable functions as `#[rustc_const_stable]` when they are used as helpers in regular stable `const fn`, and often people will rather add `#[rustc_allow_const_fn_unstable]` instead which was not our intention.
- The system has several gaping holes: a private `const fn` without stability attributes whose inherited stability (walking up parent modules) is `#[stable]` is allowed to call *arbitrary* unstable const operations, but can itself be called from stable `const fn`. Similarly, `#[allow_internal_unstable]` on a macro completely bypasses the recursive nature of the check.

Fundamentally, the problem is that we have *three* disjoint categories of functions, and not enough attributes to distinguish them:
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

Functions in the first two categories cannot use unstable const features and they can only call functions from the first two categories.

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, all the holes mentioned above have been 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 be manually marked `#[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.

Also see the updated dev-guide at https://github.com/rust-lang/rustc-dev-guide/pull/2098.

I think in the future we may want to tweak this further, so that in the hopefully common case where a public function's const-stability just exactly mirrors its regular stability, we never have to add any attribute. But right now, once the function is stable this requires `#[rustc_const_stable]`.

### Open question

There is one point I could see we might want to do differently, and that is putting `#[rustc_const_unstable]`  functions (but not intrinsics) in category 2 by default, and requiring an extra attribute for `#[rustc_const_not_exposed_on_stable]` or so. This would require a bunch of extra annotations, but would have the advantage that turning a `#[rustc_const_unstable]` into `#[rustc_const_stable]`  will never change the way the function is const-checked. Currently, we often discover in the const stabilization PR that a function needs some other unstable const things, and then we rush to quickly deal with that. In this alternative universe, we'd work towards getting rid of the `rustc_const_not_exposed_on_stable` before stabilization, and once that is done stabilization becomes a trivial matter. `#[rustc_const_stable_indirect]` would then only be used for intrinsics.

I think I like this idea, but might want to do it in a follow-up PR, as it will need a whole bunch of annotations in the standard library. Also, we probably want to convert all const intrinsics to the "new" form (`#[rustc_intrinsic]` instead of an `extern` block) before doing this to avoid having to deal with two different ways of declaring intrinsics.

Cc `@rust-lang/wg-const-eval` `@rust-lang/libs-api`
Part of https://github.com/rust-lang/rust/issues/129815 (but not finished since this is not yet sufficient to safely let us expose `const fn` from hashbrown)
Fixes https://github.com/rust-lang/rust/issues/131073 by making it so that const-stable functions are always stable

try-job: test-various
2024-10-25 23:29:40 +00:00
Matthias Krüger
4f2e9c5284
Rollup merge of #132137 - RalfJung:behavior, r=Noratrieb
library: consistently use American spelling for 'behavior'

We use "behavior" a lot more often than "behaviour", but some "behaviour" have even snuck into user-facing docs. This makes the spelling consistent.
2024-10-25 20:33:13 +02:00
Ralf Jung
16b9bb744d get rid of the internal unlikely macro 2024-10-25 20:31:40 +02:00
Ralf Jung
a0215d8e46 Re-do recursive const stability checks
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.
2024-10-25 20:31:40 +02:00
Ralf Jung
854e3c43e0 library: consistently use American spelling for 'behavior' 2024-10-25 12:02:47 +02:00
Jubilee
fd78b671a8
Rollup merge of #131457 - kpreid:fnaddr, r=dtolnay
Expand `ptr::fn_addr_eq()` documentation.

* Describe more clearly what is (not) guaranteed, and de-emphasize the description of rustc implementation details.
* Explain what you *can* reliably use it for.

Tracking issue for `ptr_fn_addr_eq`: #129322

The motivation for this PR is that I just learned that `ptr::fn_addr_eq()` exists, read the documentation, and thought: “*I* know what this means, but someone not already familiar with how `rustc` works could be left wondering whether this is even good for anything.” Fixing that seems especially important if we’re going to recommend people use it instead of `==` (as per #118833).
2024-10-24 23:23:54 -07:00
bors
788202a2ce Auto merge of #132121 - workingjubilee:rollup-yrtn33e, r=workingjubilee
Rollup of 6 pull requests

Successful merges:

 - #131851 ([musl] use posix_spawn if a directory change was requested)
 - #132048 (AIX: use /dev/urandom for random implementation )
 - #132093 (compiletest: suppress Windows Error Reporting (WER) for `run-make` tests)
 - #132101 (Avoid using imports in thread_local_inner! in static)
 - #132113 (Provide a default impl for Pattern::as_utf8_pattern)
 - #132115 (rustdoc: Extend fake_variadic to "wrapped" tuples)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-10-25 01:18:09 +00:00
Jubilee
96ae9d4703
Rollup merge of #132113 - LaihoE:pattern_as_utf8_default_impl, r=workingjubilee
Provide a default impl for Pattern::as_utf8_pattern

Newly added ```Pattern::as_utf8_pattern()``` causes needless breakage for crates that implement Pattern. This provides a default implementation instead.
r? `@BurntSushi`
2024-10-24 15:53:35 -07:00
Jubilee
abfad21c97
Rollup merge of #132101 - youknowone:thread_local-gyneiene, r=tgross35
Avoid using imports in thread_local_inner! in static

Fixes #131863 for wasm targets

All other macros were done in #131866, but this sub module is missed.

r? `@jieyouxu`
2024-10-24 15:53:35 -07:00
Jubilee
a0afe45466
Rollup merge of #132048 - mustartt:aix-random-impl, r=workingjubilee
AIX: use /dev/urandom for random implementation

On AIX, we can poll `/dev/urandom` for cryptographically secure random output to implement `fill_bytes` because we don't have equivalent syscalls like other platforms. https://www.ibm.com/docs/en/aix/7.3?topic=files-random-urandom-devices
2024-10-24 15:53:33 -07:00
Jubilee
f8af0aad41
Rollup merge of #131851 - sunshowers:musl-posix, r=workingjubilee
[musl] use posix_spawn if a directory change was requested

Currently, not all libcs have the `posix_spawn_file_actions_addchdir_np` symbol available to them. So we attempt to do a weak symbol lookup for that function. But that only works if libc is a dynamic library -- with statically linked musl binaries the symbol lookup would never work, so we would never be able to use it even if the musl in use supported the symbol.

Now that Rust has a minimum musl version of 1.2.3, all supported musl versions now include this symbol, so we can unconditionally expect it to be there. This symbol was added to libc in https://github.com/rust-lang/libc/pull/3949 -- use it here.

I couldn't find any tests for whether the posix_spawn path is used, but I've verified with cargo-nextest that this change works. This is a substantial improvement to nextest's performance with musl. On my workstation with a Ryzen 7950x, against https://github.com/clap-rs/clap at
61f5ee514f8f60ed8f04c6494bdf36c19e7a8126:

Before:

```
     Summary [   1.071s] 879 tests run: 879 passed, 0 skipped
```

After:

```
     Summary [   0.392s] 879 tests run: 879 passed, 0 skipped
```

Fixes #99740.

try-job: dist-various-1
try-job: dist-various-2
2024-10-24 15:53:33 -07:00
Jeong YunWon
5368b120a1 Avoid use imports in thread_local_inner! in statik
Fixes #131863 for wasm targets

All other macros were done in #131866, but this sub module is missed.
2024-10-25 05:44:42 +09:00
bors
a93c1718c8 Auto merge of #132116 - matthiaskrgr:rollup-3a0ia4r, r=matthiaskrgr
Rollup of 4 pull requests

Successful merges:

 - #131790 (Document textual format of SocketAddrV{4,6})
 - #131983 (Stabilize shorter-tail-lifetimes)
 - #132097 (sanitizer.md: LeakSanitizer is not supported on aarch64 macOS)
 - #132107 (Remove visit_expr_post from ast Visitor)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-10-24 20:28:20 +00:00
Matthias Krüger
a20e7ffdb1
Rollup merge of #131790 - nmathewson:doc_socketaddr_representation, r=tgross35
Document textual format of SocketAddrV{4,6}

This commit adds new "Textual representation" documentation sections to SocketAddrV4 and SocketAddrV6, by analogy to the existing "textual representation" sections of Ipv4Addr and Ipv6Addr.

Rationale: Without documentation about which formats are actually accepted, it's hard for a programmer to be sure that their code will actually behave as expected when implementing protocols that require support (or rejection) for particular representations. This lack of clarity can in turn can lead to ambiguities and security problems like those discussed in RFC 6942.

(I've tried to describe the governing RFCs or standards where I could, but it's possible that the actual implementers had something else in mind.  I could not find any standards that corresponded _exactly_ to the one implemented in SocketAddrv6, but I have linked the relevant documents that I could find.)
2024-10-24 19:39:13 +02:00
bors
1d4a7670d4 Auto merge of #131985 - compiler-errors:const-pred, r=fee1-dead
Represent trait constness as a distinct predicate

cc `@rust-lang/project-const-traits`
r? `@ghost` for now

Also mirrored everything that is written below on this hackmd here: https://hackmd.io/`@compiler-errors/r12zoixg1l`

# Tl;dr:

* This PR removes the bulk of the old effect desugaring.
* This PR reimplements most of the effect desugaring as a new predicate and set of a couple queries. I believe it majorly simplifies the implementation and allows us to move forward more easily on its implementation.

I'm putting this up both as a request for comments and a vibe-check, but also as a legitimate implementation that I'd like to see land (though no rush of course on that last part).

## Background

### Early days

Once upon a time, we represented trait constness in the param-env and in `TraitPredicate`. This was very difficult to implement correctly; it had bugs and was also incomplete; I don't think this was anyone's fault though, it was just the limit of experimental knowledge we had at that point.

Dealing with `~const` within predicates themselves meant dealing with constness all throughout the trait solver. This was difficult to keep track of, and afaict was not handled well with all the corners of candidate assembly.

Specifically, we had to (in various places) remap constness according to the param-env constness:

574b64a97f/compiler/rustc_trait_selection/src/traits/select/mod.rs (L1498)

This was annoying and manual and also error prone.

### Beginning of the effects desugaring

Later on, #113210 reimplemented a new desugaring for const traits via a `<const HOST: bool>` predicate. This essentially "reified" the const checking and separated it from any of the remapping or separate tracking in param-envs. For example, if I was in a const-if-const environment, but I wanted to call a trait that was non-const, this reification would turn the constness mismatch into a simple *type* mismatch of the effect parameter.

While this was a monumental step towards straightening out const trait checking in the trait system, it had its own issues, since that meant that the constness of a trait (or any item within it, like an associated type) was *early-bound*. This essentially meant that `<T as Trait>::Assoc` was *distinct* from `<T as ~const Trait>::Assoc`, which was bad.

### Associated-type bound based effects desugaring

After this, #120639 implemented a new effects desugaring. This used an associated type to more clearly represent the fact that the constness is not an input parameter of a trait, but a property that could be computed of a impl. The write-up linked in that PR explains it better than I could.

However, I feel like it really reached the limits of what can comfortably be expressed in terms of associated type and trait calculus. Also, `<const HOST: bool>` remains a synthetic const parameter, which is observable in nested items like RPITs and closures, and comes with tons of its own hacks in the astconv and middle layer.

For example, there are pieces of unintuitive code that are needed to represent semantics like elaboration, and eventually will be needed to make error reporting intuitive, and hopefully in the future assist us in implementing built-in traits (eventually we'll want something like `~const Fn` trait bounds!).

elaboration hack: 8069f8d17a/compiler/rustc_type_ir/src/elaborate.rs (L133-L195)

trait bound remapping hack for diagnostics: 8069f8d17a/compiler/rustc_trait_selection/src/error_reporting/traits/fulfillment_errors.rs (L2370-L2413)

I want to be clear that I don't think this is a issue of implementation quality or anything like that; I think it's simply a very clear sign that we're using types and traits in a way that they're not fundamentally supposed to be used, especially given that constness deserves to be represented as a first-class concept.

### What now?

This PR implements a new desugaring for const traits. Specifically, it introduces a `HostEffect` predicate to represent the obligation an impl is const, rather than using associated type bounds and the compat trait that exists for effects today.

### `HostEffect` predicate

A `HostEffect` clause has two parts -- the `TraitRef` we're trying to prove, and a `HostPolarity::{Maybe, Const}`.

`HostPolarity::Const` corresponds to `T: const Trait` bounds, which must *always* be proven as const, and which can be written in any context. These are lowered directly into the predicates of an item, since they're not "context-specific".

On the other hand, `HostPolarity::Maybe` corresponds to `T: ~const Trait` bounds which must only exist in a conditionally-const context like a method in a `#[const_trait]`, or a `const fn` free function. We do not lower these immediately into the predicates of an item; instead, we collect them into a new query called the **`const_conditions`**. These are the set of trait refs that we need to prove have const implementations for an item to be const.

Notably, they're represented as bare (poly) trait refs because they are meant to be paired back together with a `HostPolarity` when they're being registered in typeck (see next section).

For example, given:

```rust
const fn foo<T: ~const A + const B>() {}
```

`foo`'s const conditions would contain `T: A`, but not `T: B`. On the flip side, foo's predicates (`predicates_of`) query would contain `HostEffect(T: B, HostPolarity::Const)` but not `HostEffect(T: A, HostPolarity::Maybe)` since we don't need to prove that predicate in a non-const environment (and it's not even the right predicate to prove in an unconditionally const environment).

### Type checking const bodies

When type checking bodies in HIR, when we encounter a call expression, we additionally register the callee item's const conditions with the `HostPolarity` from the body we're typechecking (`Const` for unconditionally const things like `const`/`static` items, and `Maybe` for conditionally const things like const fns; and we don't register `HostPolarity` predicates for non-const bodies).

When type-checking a conditionally const body, we augment its param-env with `HostEffect(..., Maybe)` predicates.

### Checking that const impls are WF

We extend the logic in `compare_method_predicate_entailment` to also check the const-conditions of the impl method, to make sure that we error for:

```rust
#[const_trait] Bar {}
#[const_trait] trait Foo {
    fn method<T: Bar>();
}

impl Foo for () {
    fn method<T: ~const Bar>() {} // stronger assumption!
}
```

We also extend the WF check for impls to register the const conditions of the trait that is being implemented. This is to make sure we error for:

```rust
#[const_trait] trait Bar {}
#[const_trait] trait Foo<T> where T: ~const Bar {}

impl<T> const Foo<T> for () {}
//~^ `T: ~const Bar` is missing!
```

### Proving a `HostEffect` predicate

We have several ways of proving a `HostEffect` predicate:

1. Matching a `HostEffect` predicate from the param-env
2. From an impl - we do impl selection very similar to confirming a trait goal, except we filter for only const impls, and we additionally register the impl's const conditions (i.e. the impl's `~const` where clauses).

Later I expect that we will add more built-in implementations for things like `Fn`.

## What next?

After this PR, I'd like to split out the work more so it can proceed in parallel and probably amongst others that are not me.

* Register `HostEffect` goal for places in HIR typeck that correspond to call terminators, like autoderef.
* Make traits in libstd const again.
    * Probably need to impl host effect preds in old solver.
* Implement built-in `HostEffect` rules for traits like `Fn`.
* Rip out const checking from MIR altogether.

## So what?

This ends up being super convenient basically everywhere in the compiler. Due to the design of the new trait solver, we end up having an almost parallel structure to the existing trait and projection predicates for assembling `HostEffect` predicates; adding new candidates and especially new built-in implementations is now basically trivial, and it's quite straightforward to understand the confirmation logic for these predicates.

Same with diagnostics reporting; since we have predicates which represent the obligation to prove an impl is const, we can simplify and make these diagnostics richer without having to write a ton of logic to intercept and rewrite the existing `Compat` trait errors.

Finally, it gives us a much more straightforward path for supporting the const effect on the old trait solver. I'm personally quite passionate about getting const trait support into the hands of users without having to wait until the new solver lands[^1], so I think after this PR lands we can begin to gauge how difficult it would be to implement constness in the old trait solver too. This PR will not do this yet.

[^1]: Though this is not a prerequisite or by any means the only justification for this PR.
2024-10-24 17:33:42 +00:00
Laiho
689101f8a3 provide default impl for as_utf8_pattern 2024-10-24 19:19:38 +03:00
bors
f61306d47b Auto merge of #123550 - GnomedDev:remove-initial-arc, r=Noratrieb
Remove the `Arc` rt::init allocation for thread info

Removes an allocation pre-main by just not storing anything in std:🧵:Thread for the main thread.
- The thread name can just be a hard coded literal, as was done in #123433.
- Storing ThreadId and Parker in a static that is initialized once at startup. This uses SyncUnsafeCell and MaybeUninit as this is quite performance critical and we don't need synchronization or to store a tag value and possibly leave in a panic.
2024-10-24 13:35:50 +00:00
Nick Mathewson
0e5c5a2596 Document textual format of SocketAddrV{4,6}
This commit adds new "Textual representation" documentation sections to
SocketAddrV4 and SocketAddrV6, by analogy to the existing
"textual representation" sections of Ipv4Addr and Ipv6Addr.

Rationale: Without documentation about which formats are actually
accepted, it's hard for a programmer to be sure that their code
will actually behave as expected when implementing protocols that
require support (or rejection) for particular representations.
This lack of clarity can in turn can lead to ambiguities and
security problems like those discussed in RFC 6942.

(I've tried to describe the governing RFCs or standards where I
could, but it's possible that the actual implementers had something
else in mind.  I could not find any standards that corresponded
_exactly_ to the one implemented in SocketAddrv6, but I have linked
the relevant documents that I could find.)
2024-10-24 08:56:32 -04:00
Michael Goulet
a16d491054 Remove associated type based effects logic 2024-10-24 09:46:36 +00:00
Rain
7f74c894b0 [musl] use posix_spawn if a directory change was requested
Currently, not all libcs have the `posix_spawn_file_actions_addchdir_np` symbol
available to them. So we attempt to do a weak symbol lookup for that function.
But that only works if libc is a dynamic library -- with statically linked musl
binaries the symbol lookup would never work, so we would never be able to use it
even if the musl in use supported the symbol.

Now that Rust has a minimum musl version of 1.2.3, all supported musl versions
now include this symbol, so we can unconditionally expect it to be there. This
symbol was added to libc in https://github.com/rust-lang/libc/pull/3949 -- use
it here.

I couldn't find any tests for whether the posix_spawn path is used, but I've
verified with cargo-nextest that this change works. This is a substantial
improvement to nextest's performance with musl. On my workstation with a Ryzen
7950x, against https://github.com/clap-rs/clap at
61f5ee514f8f60ed8f04c6494bdf36c19e7a8126:

Before:

```
     Summary [   1.071s] 879 tests run: 879 passed, 0 skipped
```

After:

```
     Summary [   0.392s] 879 tests run: 879 passed, 0 skipped
```

Fixes #99740.
2024-10-23 22:11:55 -07:00
Stuart Cook
9c73bcfa8d
Rollup merge of #130225 - adetaylor:rename-old-receiver, r=wesleywiser
Rename Receiver -> LegacyReceiver

As part of the "arbitrary self types v2" project, we are going to replace the current `Receiver` trait with a new mechanism based on a new, different `Receiver` trait.

This PR renames the old trait to get it out the way. Naming is hard. Options considered included:
* HardCodedReceiver (because it should only be used for things in the standard library, and hence is sort-of hard coded)
* LegacyReceiver
* TargetLessReceiver
* OldReceiver

These are all bad names, but fortunately this will be temporary. Assuming the new mechanism proceeds to stabilization as intended, the legacy trait will be removed altogether.

Although we expect this trait to be used only in the standard library, we suspect it may be in use elsehwere, so we're landing this change separately to identify any surprising breakages.

It's known that this trait is used within the Rust for Linux project; a patch is in progress to remove their dependency.

This is a part of the arbitrary self types v2 project,
https://github.com/rust-lang/rfcs/pull/3519
https://github.com/rust-lang/rust/issues/44874

r? `@wesleywiser`
2024-10-24 14:19:53 +11:00
León Orell Valerian Liehr
fbe33e35af
Rollup merge of #132066 - tifv:ptr-docs-typo, r=Amanieu
Fix a typo in documentation of `pointer::sub_ptr()`

Just a typo in docs.
2024-10-23 22:11:06 +02:00
León Orell Valerian Liehr
b0a8e4e030
Rollup merge of #132065 - tifv:dangling-docs, r=Noratrieb
Clarify documentation of `ptr::dangling()` function

Also fixes the safety comment in `NonNull::dangling()` function.

Fixes #132004.
2024-10-23 22:11:06 +02:00
León Orell Valerian Liehr
8b1141a5c3
Rollup merge of #132060 - joshtriplett:innermost-outermost, r=jieyouxu
"innermost", "outermost", "leftmost", and "rightmost" don't need hyphens

These are all standard dictionary words and don't require hyphenation.

-----

Encountered an instance of this in error messages and it bugged me, so I
figured I'd fix it across the entire codebase.
2024-10-23 22:11:05 +02:00
León Orell Valerian Liehr
28aacb3d03
Rollup merge of #132039 - a1phyr:vecdeque_read_exact, r=Noratrieb
Specialize `read_exact` and `read_buf_exact` for `VecDeque`
2024-10-23 22:11:05 +02:00
León Orell Valerian Liehr
af2c7dffda
Rollup merge of #130991 - LaihoE:vectorized_slice_contains, r=Noratrieb
Vectorized SliceContains

Godbolt for the u32 case: https://rust.godbolt.org/z/exT9xYWGs

Unsure about:
- Should align_to be used? It didn't seem to matter in my benchmark but maybe I was lucky with alignment?
- Should u8/i8 also be implemented? Currently uses memchr (SWAR)

Some benchmarks on x86 (contains called on an array with no matches, worst case may be slightly worse):

## Large N
![large_n_contains](https://github.com/user-attachments/assets/5be79072-970b-44be-a56c-16dc677dee46)

## Small N
![small_n_contains](https://github.com/user-attachments/assets/b8a33790-c176-459f-84f4-05feee893cd0)
2024-10-23 22:11:02 +02:00
Laiho
c11bfd828e vectorized SliceContains 2024-10-23 20:14:17 +02:00
July Tikhonov
b515bbfb85 fix a typo in documentation of pointer::sub_ptr() 2024-10-23 19:37:51 +06:00
July Tikhonov
f4c8ff33de fix documentation of ptr::dangling() function 2024-10-23 19:17:36 +06:00
Josh Triplett
ecdc2441b6 "innermost", "outermost", "leftmost", and "rightmost" don't need hyphens
These are all standard dictionary words and don't require hyphenation.
2024-10-23 02:45:24 -07:00
Benoît du Garreau
77a7164ec9 Specialize read_exact and read_buf_exact for VecDeque 2024-10-23 10:09:24 +02:00
Matthias Krüger
af356d6d73
Rollup merge of #132031 - slanterns:rc_default, r=ibraheemdev
Optimize `Rc<T>::default`

The missing piece of https://github.com/rust-lang/rust/pull/131460.

Also refactored `Arc<T>::default` by using a safe `NonNull::from(Box::leak(_))` to replace the unnecessarily unsafe call to `NonNull::new_unchecked(Box::into_raw(_))`. The remaining unsafety is coming from `[Rc|Arc]::from_inner`, which is safe from the construction of `[Rc|Arc]Inner`.
2024-10-23 06:51:25 +02:00
Matthias Krüger
38eaf608eb
Rollup merge of #131707 - clarfonthey:constify-core-tests, r=thomcc
Run most `core::num` tests in const context too

This adds some infrastructure for something I was going to use in #131566, but it felt worthwhile enough on its own to merge/discuss separately.

Essentially, right now we tend to rely on UI tests to ensure that things work in const context, rather than just using library tests. This uses a few simple macro tricks to make it *relatively* painless to execute tests in both runtime and compile-time context. And this only applies to the numeric tests, and not anything else.

Recommended to review without whitespace in the diff.

cc `@RalfJung`
2024-10-23 06:51:23 +02:00
bors
b13176595d Auto merge of #131929 - LaihoE:replace_default_capacity, r=joboet
better default capacity for str::replace

Adds smarter capacity for str::replace in cases where we know that the output will be at least as long as the original string.
2024-10-23 01:03:48 +00:00
Henry Jiang
8ca39104f1 AIX use /dev/urandom for impl 2024-10-22 20:18:11 -04:00
Laiho
c8391802af better default capacity for str::replace 2024-10-22 19:53:33 +03:00
Adrian Taylor
8f85b90ca6 Rename Receiver -> LegacyReceiver
As part of the "arbitrary self types v2" project, we are going to
replace the current `Receiver` trait with a new mechanism based on a
new, different `Receiver` trait.

This PR renames the old trait to get it out the way. Naming is hard.
Options considered included:
* HardCodedReceiver (because it should only be used for things in the
  standard library, and hence is sort-of hard coded)
* LegacyReceiver
* TargetLessReceiver
* OldReceiver

These are all bad names, but fortunately this will be temporary.
Assuming the new mechanism proceeds to stabilization as intended, the
legacy trait will be removed altogether.

Although we expect this trait to be used only in the standard library,
we suspect it may be in use elsehwere, so we're landing this change
separately to identify any surprising breakages.

It's known that this trait is used within the Rust for Linux project; a
patch is in progress to remove their dependency.

This is a part of the arbitrary self types v2 project,
https://github.com/rust-lang/rfcs/pull/3519
https://github.com/rust-lang/rust/issues/44874

r? @wesleywiser
2024-10-22 12:55:16 +00:00
Slanterns
0a963ab2da
refactor Arc<T>::default 2024-10-22 02:25:48 -07:00
Slanterns
5b12d906bb
optimize Rc<T>::default 2024-10-22 01:37:53 -07:00
Jubilee
763fbf8a90
Rollup merge of #131697 - ShE3py:rt-arg-lifetimes, r=Amanieu
`rt::Argument`: elide lifetimes

`@rustbot` label +C-cleanup
2024-10-21 20:32:01 -07:00
Matthias Krüger
64f4aa6725
Rollup merge of #132003 - RalfJung:abi-compat-docs, r=traviscross
update ABI compatibility docs for new option-like rules

Documents the rules decided [here](https://github.com/rust-lang/rust/pull/130628#issuecomment-2402761599) for our ABI compatibility rules.

Long-term this should be moved to the reference, but for now this is what we got.

Cc `@rust-lang/lang` `@rust-lang/opsem`
2024-10-21 18:11:23 +02:00
Matthias Krüger
20b1dadf92
Rollup merge of #130350 - RalfJung:strict-provenance, r=dtolnay
stabilize Strict Provenance and Exposed Provenance APIs

Given that [RFC 3559](https://rust-lang.github.io/rfcs/3559-rust-has-provenance.html) has been accepted, t-lang has approved the concept of provenance to exist in the language. So I think it's time that we stabilize the strict provenance and exposed provenance APIs, and discuss provenance explicitly in the docs:
```rust
// core::ptr
pub const fn without_provenance<T>(addr: usize) -> *const T;
pub const fn dangling<T>() -> *const T;
pub const fn without_provenance_mut<T>(addr: usize) -> *mut T;
pub const fn dangling_mut<T>() -> *mut T;
pub fn with_exposed_provenance<T>(addr: usize) -> *const T;
pub fn with_exposed_provenance_mut<T>(addr: usize) -> *mut T;

impl<T: ?Sized> *const T {
    pub fn addr(self) -> usize;
    pub fn expose_provenance(self) -> usize;
    pub fn with_addr(self, addr: usize) -> Self;
    pub fn map_addr(self, f: impl FnOnce(usize) -> usize) -> Self;
}

impl<T: ?Sized> *mut T {
    pub fn addr(self) -> usize;
    pub fn expose_provenance(self) -> usize;
    pub fn with_addr(self, addr: usize) -> Self;
    pub fn map_addr(self, f: impl FnOnce(usize) -> usize) -> Self;
}

impl<T: ?Sized> NonNull<T> {
    pub fn addr(self) -> NonZero<usize>;
    pub fn with_addr(self, addr: NonZero<usize>) -> Self;
    pub fn map_addr(self, f: impl FnOnce(NonZero<usize>) -> NonZero<usize>) -> Self;
}
```

I also did a pass over the docs to adjust them, because this is no longer an "experiment". The `ptr` docs now discuss the concept of provenance in general, and then they go into the two families of APIs for dealing with provenance: Strict Provenance and Exposed Provenance. I removed the discussion of how pointers also have an associated "address space" -- that is not actually tracked in the pointer value, it is tracked in the type, so IMO it just distracts from the core point of provenance. I also adjusted the docs for `with_exposed_provenance` to make it clear that we cannot guarantee much about this function, it's all best-effort.

There are two unstable lints associated with the strict_provenance feature gate; I moved them to a new [strict_provenance_lints](https://github.com/rust-lang/rust/issues/130351) feature since I didn't want this PR to have an even bigger FCP. ;)

`@rust-lang/opsem` Would be great to get some feedback on the docs here. :)
Nominating for `@rust-lang/libs-api.`

Part of https://github.com/rust-lang/rust/issues/95228.

[FCP comment](https://github.com/rust-lang/rust/pull/130350#issuecomment-2395114536)
2024-10-21 18:11:19 +02:00
Ralf Jung
75cadc09f2 update ABI compatibility docs for new option-like rules 2024-10-21 16:25:32 +01:00
Ralf Jung
56ee492a6e move strict provenance lints to new feature gate, remove old feature gates 2024-10-21 15:22:17 +01:00
Ralf Jung
c3e928d8dd stabilize Strict Provenance and Exposed Provenance
This comes with a big docs rewrite.
2024-10-21 15:05:35 +01:00
klensy
2920ed0999 fix docs 2024-10-20 18:25:38 +03:00
klensy
8abe67c949 replace FindFirstFileW with FindFirstFileExW and apply optimization 2024-10-20 18:24:55 +03:00
klensy
22a9a8b76e replace FindFirstFileW with FindFirstFileExW and regenerate bindings 2024-10-20 16:05:49 +03:00
bors
b596184f3b Auto merge of #131948 - matthiaskrgr:rollup-c9rvzu6, r=matthiaskrgr
Rollup of 12 pull requests

Successful merges:

 - #116863 (warn less about non-exhaustive in ffi)
 - #127675 (Remove invalid help diagnostics for const pointer)
 - #131772 (Remove `const_refs_to_static` TODO in proc_macro)
 - #131789 (Make sure that outer opaques capture inner opaques's lifetimes even with precise capturing syntax)
 - #131795 (Stop inverting expectation in normalization errors)
 - #131920 (Add codegen test for branchy bool match)
 - #131921 (replace STATX_ALL with (STATX_BASIC_STATS | STATX_BTIME) as former is deprecated)
 - #131925 (Warn on redundant `--cfg` directive when revisions are used)
 - #131931 (Remove unnecessary constness from `lower_generic_args_of_path`)
 - #131932 (use tracked_path in rustc_fluent_macro)
 - #131936 (feat(rustdoc-json-types): introduce rustc-hash feature)
 - #131939 (Get rid of `OnlySelfBounds`)

Failed merges:

 - #131181 (Compiletest: Custom differ)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-10-19 22:33:42 +00:00