| Age | Commit message (Collapse) | Author | Lines |
|---|
|
r=workingjubilee
Add code example for `wrapping_neg` method for signed integers
With this example, we make it obvious that `wrapping_neg` works both ways (neg to pos and pos to neg).
r? `@workingjubilee`
|
|
blesses tests/ui/intrinsics
blesses tests/ui/intrinsics
|
|
Add `AsyncFn*` to the prelude in all editions
The general vibe is that we will most likely stabilize the `feature(async_closure)` *without* the `async Fn()` trait bound modifier.
Without `async Fn()` bound syntax, this necessitates users to spell the bound like `AsyncFn()`. Since `core::ops::AsyncFn` is not in the prelude, users will need to import these any time they actually want to use the trait. This seems annoying, so let's add these traits to the prelude unstably.
We're trying to work on the general vision of `async` trait bound modifier in general in: https://github.com/rust-lang/rfcs/pull/3710, however that RFC still needs more time for consensus to converge, and we've decided that the value that users get from calling the bound `async Fn()` is *not really* worth blocking landing async closures in general.
|
|
btree: don't leak value if destructor of key panics
This PR fixes a regression from https://github.com/rust-lang/rust/pull/84904.
The `BTreeMap` already attempts to handle panicking destructors of the key-value pairs by continuing to execute the remaining destructors after one destructor panicked. However, after #84904 the destructor of a value in a key-value pair gets skipped if the destructor of the key panics, only continuing with the next key-value pair. This PR reverts to the behavior before #84904 to also drop the corresponding value if the destructor of a key panics.
This avoids potential memory leaks and can fix the soundness of programs that rely on the destructors being executed (even though this should not be relied upon, because the std collections currently do not guarantee that the remaining elements are dropped after a panic in a destructor).
cc `@Amanieu` because you had opinions on panicking destructors
|
|
This crate doesn't contain any actual Rust code; it's just C/C++ code built and
packaged in a Rust-friendly way.
|
|
|
|
|
|
|
|
|
|
Rollup of 4 pull requests
Successful merges:
- #133217 ([AIX] Add option -X32_64 to the "strip" command)
- #133237 (Minimally constify `Add`)
- #133355 (Add language tests for aggregate types)
- #133374 (show abi_unsupported_vector_types lint in future breakage reports)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
Rollup of 6 pull requests
Successful merges:
- #127483 (Allow disabling ASan instrumentation for globals)
- #131505 (use `confstr(_CS_DARWIN_USER_TEMP_DIR, ...)` as a `TMPDIR` fallback on Darwin)
- #132949 (Add specific diagnostic for using macro_rules macro as attribute/derive)
- #133286 (Re-delay a resolve `bug` related to `Self`-ctor in patterns)
- #133332 (Mark `<[T; N]>::as_mut_slice` with the `const` specifier.)
- #133366 (Remove unnecessary bool from `ExpectedFound::new`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Minimally constify `Add`
* This PR removes the requirement for `impl const` to have a const stability attribute. cc ``@RalfJung`` I believe you mentioned that it would make much more sense to require `const_trait`s to have const stability instead. I agree with that sentiment but I don't think that is _required_ for a small scale experimentation like this PR. https://github.com/rust-lang/project-const-traits/issues/16 should definitely be prioritized in the future, but removing the impl check should be good for now as all callers need `const_trait_impl` enabled for any const impl to work.
* This PR is intentionally minimal as constifying other traits can become more complicated (`PartialEq`, for example, would run into requiring implementing it for `str` as that is used in matches, which runs into the implementation for slice equality which uses specialization)
Per the reasons above, anyone who is interested in making traits `const` in the standard library are **strongly encouraged** to reach out to us on the [Zulip channel](https://rust-lang.zulipchat.com/#narrow/channel/419616-t-compiler.2Fproject-const-traits) before proceeding with the work.
cc ``@rust-lang/project-const-traits``
I believe there is prior approval from libs that we can experiment, so
r? project-const-traits
|
|
Mark `<[T; N]>::as_mut_slice` with the `const` specifier.
Tracking issue: #133333
`<[T; N]>::as_mut_slice` can have the `const` specifier without any changes to the function body.
|
|
use `confstr(_CS_DARWIN_USER_TEMP_DIR, ...)` as a `TMPDIR` fallback on Darwin
Rebased version of https://github.com/rust-lang/rust/pull/100824, FCP has completed there. Motivation from https://github.com/rust-lang/rust/pull/100824#issuecomment-1262264127:
> This is a behavioral change in an edge case on Darwin platforms (macOS, iOS, ...).
>
> Specifically, this changes it so that iff `TMPDIR` is unset in the environment, then we use `confstr(_CS_DARWIN_USER_TEMP_DIR, ...)` to query the user temporary directory (previously we just returned `"/tmp"`). If this fails (probably possible in a sandboxed program), only then do we fallback to `"/tmp"` (as before).
>
> The motivations here are two-fold:
>
> 1. This is better for security, and is in line with the [platform security recommendations](https://developer.apple.com/library/archive/documentation/Security/Conceptual/SecureCodingGuide/Articles/RaceConditions.html#//apple_ref/doc/uid/TP40002585-SW10), as it is unavailable to other users (although it is the same value as seen by all other processes run by the same user).
> 2. This is a more consistent fallback for when `getenv("TMPDIR")` is unavailable, as `$TMPDIR` is usually initialized to the `DARWIN_USER_TEMP_DIR`.
>
> It seems quite unlikely that anybody will break because of this, and I think it falls under the carve-out we have for platform specific behavior: https://doc.rust-lang.org/nightly/std/io/index.html#platform-specific-behavior.
Closes https://github.com/rust-lang/rust/issues/99608.
Closes https://github.com/rust-lang/rust/pull/100824.
``@rustbot`` label O-apple T-libs-api
r? Dylan-DPC
|
|
Update `cc` + bump bootstrap deps
https://github.com/rust-lang/rust/pull/132556#issuecomment-2471741435
note: The compiler/library/tools cc bumps have been tested with a try job, the bootstrap changes have not
|
|
Rollup of 8 pull requests
Successful merges:
- #132090 (Stop being so bail-y in candidate assembly)
- #132658 (Detect const in pattern with typo)
- #132911 (Pretty print async fn sugar in opaques and trait bounds)
- #133102 (aarch64 softfloat target: always pass floats in int registers)
- #133159 (Don't allow `-Zunstable-options` to take a value )
- #133208 (generate-copyright: Now generates a library file too.)
- #133215 (Fix missing submodule in `./x vendor`)
- #133264 (implement OsString::truncate)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
implement OsString::truncate
part of #133262
|
|
Implement `~const Destruct` effect goal in the new solver
This also fixed a subtle bug/limitation of the `NeedsConstDrop` check. Specifically, the "`Qualif`" API basically treats const drops as totally structural, even though dropping something that has an explicit `Drop` implementation cannot be structurally decomposed. For example:
```rust
#![feature(const_trait_impl)]
#[const_trait] trait Foo {
fn foo();
}
struct Conditional<T: Foo>(T);
impl Foo for () {
fn foo() {
println!("uh oh");
}
}
impl<T> const Drop for Conditional<T> where T: ~const Foo {
fn drop(&mut self) {
T::foo();
}
}
const FOO: () = {
let _ = Conditional(());
//~^ This should error.
};
fn main() {}
```
In this example, when checking if the `Conditional(())` rvalue is const-drop, since `Conditional` has a const destructor, we would previously recurse into the `()` value and determine it has nothing to drop, which means that it is considered to *not* need a const drop -- even though dropping `Conditional(())` would mean evaluating the destructor which relies on that `T: const Foo` bound to hold!
This could be fixed alternatively by banning any const conditions on `const Drop` impls, but that really sucks -- that means that basically no *interesting* const drop impls could be written. We have the capability to totally and intuitively support the right behavior, which I've implemented here.
|
|
Currently the `Debug` implementation for `MaybeUninit` winds up being
pretty verbose. This struct:
#[derive(Debug)]
pub struct Foo {
pub a: u32,
pub b: &'static str,
pub c: MaybeUninit<u32>,
pub d: MaybeUninit<String>,
}
Prints as:
Foo {
a: 0,
b: "hello",
c: core::mem::maybe_uninit::MaybeUninit<u32>,
d: core::mem::maybe_uninit::MaybeUninit<alloc::string::String>,
}
The goal is just to be a standin for content so the path prefix doesn't
add any useful information. Change the implementation to trim
`MaybeUninit`'s leading path, meaning the new result is now:
Foo {
a: 0,
b: "hello",
c: MaybeUninit<u32>,
d: MaybeUninit<alloc::string::String>,
}
|
|
|
|
|
|
|
|
const_precise_live_drops post-drop-elaboration check
|
|
Rollup of 8 pull requests
Successful merges:
- #133238 (re-export `is_loongarch_feature_detected`)
- #133288 (Support `each_ref` and `each_mut` in `[T; N]` in constant expressions.)
- #133311 (Miri subtree update)
- #133313 (Use arc4random of libc for RTEMS target)
- #133319 (Simplify `fulfill_implication`)
- #133323 (Bail in effects in old solver if self ty is ty var)
- #133330 (library: update comment around close())
- #133337 (Fix typo in `std::thread::Scope::spawn` documentation.)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Fix typo in `std::thread::Scope::spawn` documentation.
Just a simple fix for a typo that caught my attention.
|
|
library: update comment around close()
r? `@the8472`
|
|
Use arc4random of libc for RTEMS target
Switch to the `arc4random` from libc. It is available since libc 0.2.162
|
|
Support `each_ref` and `each_mut` in `[T; N]` in constant expressions.
Tracking issue: #133289
The methods `<[T; N]>::each_ref` and `<[T; N]>::each_mut` can easily be reimplemented to allow marking them with the `const` specifier.
This specific implementation takes a different approach than the original as to avoid using iterators (which are illegal in constant expressions).
|
|
re-export `is_loongarch_feature_detected`
r? ``@Amanieu``
|
|
distinguish overflow and unimplemented in Step::steps_between
|
|
|
|
|
|
|
|
|
|
Stabilize `Ipv6Addr::is_unique_local` and `Ipv6Addr::is_unicast_link_local`
Make `Ipv6Addr::is_unique_local` and `Ipv6Addr::is_unicast_link_local` stable (+const).
Newly stable API:
```rust
impl Ipv6Addr {
// Newly stable under `ipv6_is_unique_local`
const fn is_unique_local(&self) -> bool;
// Newly stable under `ipv6_is_unique_local`
const fn is_unicast_link_local(&self) -> bool;
}
```
These stabilise a subset of the following tracking issue:
- #27709
I have looked and could not find any issues with `is_unique_local` and `is_unicast_link_local`. There is a well received comment calling for stabilisation of the latter function.
Both functions are well defined and consistent with implementations in other languages:
- [Go](https://cs.opensource.google/go/go/+/refs/tags/go1.23.0:src/net/netip/netip.go;l=518)
- [Python](https://github.com/python/cpython/blob/e9d1bf353c3ccafc0d9b61b1b3688051bc976604/Lib/ipaddress.py#L2319-L2321)
- [Ruby (unique local)](https://ruby-doc.org/stdlib-2.5.1/libdoc/ipaddr/rdoc/IPAddr.html#private-3F-source)
- [Ruby (unicast link local)](https://ruby-doc.org/stdlib-2.5.1/libdoc/ipaddr/rdoc/IPAddr.html#link_local-3F-source)
cc implementor `@little-dude`
(I can't find the original PR for `is_unqiue_local`)
r? libs-api
`@rustbot` label +T-libs-api +needs-fcp
|
|
|
|
Is available since libc 0.2.162
|
|
This is explicitly mentioned for std::fs::remove_file's documentation,
but not in the aforementioned function.
It is more likely for a slightly lazy programmer to believe that
removing a file would work and that they do not have to distinguish
between directories (with contents) and files themself, because of the
function's recursive nature and how it distinguishes between files and
directories when removing them.
|
|
|
|
|
|
Emscripten: link with -sWASM_BIGINT
When linking an executable without dynamic linking, this is a pure improvement. It significantly reduces code size and avoids a lot of buggy behaviors. It is supported in all browsers for many years and in all maintained versions of Node.
It does change the ABI, so people who are dynamically linking with a library or executable that uses the old ABI may need to turn it off. It can be disabled if needed by passing `-Clink-arg -sWASM_BIGINT=0` to `rustc`. But few people will want to turn it off.
Note this includes a libc bump to 0.2.162!
|
|
|
|
Make `PointerLike` opt-in instead of built-in
The `PointerLike` trait currently is a built-in trait that computes the layout of the type. This is a bit problematic, because types implement this trait automatically. Since this can be broken due to semver-compatible changes to a type's layout, this is undesirable. Also, calling `layout_of` in the trait system also causes cycles.
This PR makes the trait implemented via regular impls, and adds additional validation on top to make sure that those impls are valid. This could eventually be `derive()`d for custom smart pointers, and we can trust *that* as a semver promise rather than risking library authors accidentally breaking it.
On the other hand, we may never expose `PointerLike`, but at least now the implementation doesn't invoke `layout_of` which could cause ICEs or cause cycles.
Right now for a `PointerLike` impl to be valid, it must be an ADT that is `repr(transparent)` and the non-1zst field needs to implement `PointerLike`. There are also some primitive impls for `&T`/ `&mut T`/`*const T`/`*mut T`/`Box<T>`.
|
|
Mark `get_mut` and `set_position` in `std::io::Cursor` as const.
Relevant tracking issue: #130801
The methods `get_mut` and `set_position` can trivially be marked as const due to #57349 being stabilised.
|
|
uefi: process: Add args support
- Wrap all args with quotes.
- Escape ^ and " inside quotes using ^.
- Doing reverse of arg parsing: https://github.com/rust-lang/rust/blob/d571ae851d93541bef826c3c48c1e9ad99da77d6/library/std/src/sys/pal/uefi/args.rs#L81
r? joboet
|
|
|
|
|
