| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Adjust paths such that these macros don't go through the private `math`
module. `feature = "private-test-deps"` is still needed.
Additionally, ensure that `cargo check` for this crate gets run in CI
because `cargo test` does not seem to identify this problem.
`compiler_builtins` will need to reexport the `support` module.
|
|
Print a better diff when lists are unsorted, and always check tidy lists
even if `--check` is not passed.
|
|
|
|
|
|
While working on #122661, some of these started triggering our "unnecessary parens" lints due to a change in the `assert!` desugaring. A cursory search identified a few more. Some of these have been carried from before 1.0, were a bulk rename from the previous name of `assert!` left them in that state. I went and removed as many of these unnecessary parens as possible in order to have fewer annoyances in the future if we make the lint smarter.
|
|
|
|
Stabilize `map_many_mut` feature
This PR stabilize `HashMap::get_many_mut` as `HashMap::get_disjoint_mut` and `HashMap::get_many_unchecked_mut` as `HashMap::get_disjoint_unchecked_mut` per FCP.
FCP at https://github.com/rust-lang/rust/issues/97601#issuecomment-2532710423
Fixes #97601
r? libs
|
|
|
|
Change two std process tests to not output to std{out,err}, and fix test suite stat reset in bootstrap CI test rendering
I don't really know how to test if this unbreaks CI (since #136607 reported that this breaks the CI test rendering *sometimes*).
Fixes #136607.
r? `@ChrisDenton` (two Windows process tests, but feel free to reroll)
|
|
|
|
This was never modified since `std::net` was originally introduced, when
each CI job was running multiple jobs concurrently which caused issues
with fighting over the same ports. This is not the case in the current
CI infrastructure, so remove this relic.
|
|
`test_proc_thread_attributes`
|
|
We need someplace to collect known failures, previous regressions, edge
cases that are difficult to construct from generics, and similar.
Introduce this here.
|
|
Rollup of 13 pull requests
Successful merges:
- #133932 (Avoid using make_direct_deprecated() in extern "ptx-kernel")
- #136269 (Pass spans around new solver)
- #136550 (Fix `rustc_hidden_type_of_opaques` for RPITITs with no default body)
- #136558 (Document minimum supported host tooling on macOS)
- #136563 (Clean up `Trivial*Impls` macros)
- #136566 (Fix link in from_fn.rs)
- #136573 (Document why some "type mismatches" exist)
- #136583 (Only highlight unmatchable parameters at the definition site)
- #136587 (Update browser-ui-test version to `0.20.2`)
- #136590 (Implement RustcInternal for RawPtrKind)
- #136591 (Add `rustc_hir_pretty::expr_to_string` function)
- #136595 (Fix `unreachable_pub` lint for hermit target)
- #136611 (cg_llvm: Remove the `mod llvm_` hack, which should no longer be necessary)
Failed merges:
- #136565 (compiler: Clean up weird `rustc_abi` reexports)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
- Just a copy of sys/net/unsupported.
- Will make the future net PRs easier to review.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
|
|
Fix `unreachable_pub` lint for hermit target
The build for the hermit target (`#[cfg(target_os = "hermit")]`) fails on master as of [8df89d1cb07](https://github.com/rust-lang/rust/commit/8df89d1cb077cd76013d3f9f5a4e92c5b5a9280c) (2025-02-05), due to introducing `#[warn(unreachable_pub)]` at the root in https://github.com/rust-lang/rust/pull/134286 (Enable unreachable_pub lint in core, merged 2025-01-20).
Make the relevant visibility modifiers more specific to resolve the warning.
```
$ ./x build --target x86_64-unknown-hermit
Building bootstrap
Finished `dev` profile [unoptimized] target(s) in 0.34s
Building stage0 library artifacts (x86_64-apple-darwin)
Finished `release` profile [optimized] target(s) in 0.15s
Building compiler artifacts (stage0 -> stage1, x86_64-apple-darwin)
Finished `release` profile [optimized] target(s) in 1.67s
Creating a sysroot for stage1 compiler (use `rustup toolchain link 'name' build/host/stage1`)
Building stage1 library artifacts {alloc, core, panic_abort, panic_unwind, proc_macro, std, sysroot, test, unwind} (x86_64-apple-darwin -> x86_64-unknown-hermit)
Compiling panic_unwind v0.0.0 (library/panic_unwind)
error: unreachable `pub` item
--> library/panic_unwind/src/hermit.rs:10:9
|
10 | pub fn __rust_abort() -> !;
| ---^^^^^^^^^^^^^^^^^^^^^^^^
| |
| help: consider restricting its visibility: `pub(crate)`
|
= help: or consider exporting it for use by other crates
= note: `-D unreachable-pub` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(unreachable_pub)]`
error: unreachable `pub` item
--> library/panic_unwind/src/hermit.rs:17:9
|
17 | pub fn __rust_abort() -> !;
| ---^^^^^^^^^^^^^^^^^^^^^^^^
| |
| help: consider restricting its visibility: `pub(crate)`
|
= help: or consider exporting it for use by other crates
error: could not compile `panic_unwind` (lib) due to 2 previous errors
Build completed unsuccessfully in 0:00:39
```
|
|
Fix link in from_fn.rs
|
|
Use `widening_mul` instead of a separate function
A helper function became obsolete after `widening_mul` became available for `u128` values.
|
|
A few bugs have been fixed, including the sign of `fma(tiny, -tiny,
0.0)`. Switch to tracking `master` rather than the latest tag so we
don't need to xfail these tests.
|
|
Currently, `fma(tiny, -tiny, 0.0)` returns 0.0 while the answer should
be -0.0. This is because `-0.0 + 0.0 = +0.0` in the default rounding
mode; however, the result should be negative. Musl has the same pattern
but that version worked because the C compiler was contracting `x*y + z`
to (ironically) `fmadd`.
Musl was fixed in 9683bd6241 ("math: fix fma(x,y,0) when x*y rounds to
-0"). Add the same fix here, which allows dropping the xfails.
|
|
Now that we have a hex float formatter, make use of it for test output.
This produces values that are easier to read than the bitwise hex
representation.
Example:
thread 'mp_quickspace_fmaf128' panicked at crates/libm-test/tests/multiprecision.rs:17:48:
called `Result::unwrap()` on an `Err` value:
input: (0xe38d71c71c71c71c71c71c71c71c71c8, 0xe38d71c71c71c71c71c71c71c71c71c8, 0xffff0000000000000000000000000000)
as hex: (-0x1.71c71c71c71c71c71c71c71c71c8p+9102, -0x1.71c71c71c71c71c71c71c71c71c8p+9102, -inf)
as bits: (0xe38d71c71c71c71c71c71c71c71c71c8, 0xe38d71c71c71c71c71c71c71c71c71c8, 0xffff0000000000000000000000000000)
expected: 0xffff0000000000000000000000000000 -inf 0xffff0000000000000000000000000000
actual: 0x7fff8000000000000000000000000000 NaN 0x7fff8000000000000000000000000000
Caused by:
real value != NaN
|
|
In order to make these more interchangeable in more places, always
return `(impl Iterator, u64)`. This will facilitate using other
generators for extensive tests.
|
|
This is the first step toward making `fma` usable for `f128`, and
possibly `f32` on platforms where growing to `f64` is not fast. This
does not yet work for anything other than `f64`.
|
|
This crate has a handful of lists that need to list all API and can't
easily be verified. Additionally, some longer lists should be kept
sorted so they are easier to look through. Resolve both of these by
adding a check in `update-api-list.py` that looks for annotations and
verifies the contents are as expected.
Annotations are `verify-apilist-start`, `verify-apilist-end`,
`verify-sorted-start`, and `verify-sorted-end`.
This includes fixes for anything that did not meet the criteria.
|
|
This is just a collection of all functions and should not trigger
extensive tests when changed.
|
|
|
|
Use the generic `scalbn` to provide `f16` and `f128` versions, which
also work for `ldexp`.
This involves a new algorithm for `f16` because the default does not
converge fast enough with a limited number of rounds.
|
|
|
|
Rename `slice::take...` methods to `split_off...`
This rename was discussed and recommended in a recent t-libs meeting.
cc https://github.com/rust-lang/rust/issues/62280
There's an additional commit here which modifies internals of unstable `OneSidedRange` APIs in order to implement `split_off` methods in a panic-free way (remove `unreachable!()`) as recommended in https://github.com/rust-lang/rust/pull/88502/files#r760177240. I can split this out into a separate PR if needed.
|
|
Update `compiler-builtins` to 0.1.145
This includes https://github.com/rust-lang/compiler-builtins/pull/752 which is required for LLVM 20.
|
|
implement inherent str constructors
implement #131114
this implements
- str::from_utf8
- str::from_utf8_mut
- str::from_utf8_unchecked
- str::from_utf8_unchecked_mut
i left `std::str::from_raw_parts` and `std::str::from_raw_parts_mut` out of this as those are unstable and were not mentioned by the tracking issue or the original pull request, but i can add those here as well.
i was also unsure of what to do with the `rustc_const_(un)stable` attributes: i removed the `#[rustc_const_stable]` attribute from `str::from_utf8`, `str::from_utf8_unchecked` and `str::from_utf8_unchecked_mut`, and left the`#[rust_const_unstable]` in `str::from_utf8_mut` (btw why is that one not const stable yet with #57349 merged?).
is there a way to redirect users to the stable `std::str::from_utf8` instead of only saying "hey this is unstable"?
for now i just removed the check for `str::from_utf8` in the test in `tests/ui/suggestions/suggest-std-when-using-type.rs`.
|
|
std: move network code into `sys`
As per #117276, this PR moves `sys_common::net` and the `sys::pal::net` into the newly created `sys::net` module. In order to support #135141, I've moved all the current network code into a separate `connection` module, future functions like `hostname` can live in separate modules.
I'll probably do a follow-up PR and clean up some of the actual code, this is mostly just a reorganization.
|
|
uefi: process: Add support for command environment variables
Set environment variables before launching the process and restore the prior variables after the program exists.
This is the same implementation as the one used by UEFI Shell Execute [0].
[0]: https://github.com/tianocore/edk2/blob/2d2642f4832ebc45cb7d5ba9430b933d953b94f2/ShellPkg/Application/Shell/ShellProtocol.c#L1700
|
|
|
|
|
|
Mark `std::fmt::from_fn` as `#[must_use]`
While working on #135494 I managed to shoot my own foot a few times by forgetting to actually use the result of `fmt::from_fn`, so I think a `#[must_use]` could be appropriate!
Didn't have a good message to put in the attr so left it blank, still unstable so we can come back to it I guess?
cc #117729 (and a huge +1 for getting it stabilized, it's very useful IMHO)
|
|
#[contracts::requires(...)] + #[contracts::ensures(...)]
cc https://github.com/rust-lang/rust/issues/128044
Updated contract support: attribute syntax for preconditions and postconditions, implemented via a series of desugarings that culminates in:
1. a compile-time flag (`-Z contract-checks`) that, similar to `-Z ub-checks`, attempts to ensure that the decision of enabling/disabling contract checks is delayed until the end user program is compiled,
2. invocations of lang-items that handle invoking the precondition, building a checker for the post-condition, and invoking that post-condition checker at the return sites for the function, and
3. intrinsics for the actual evaluation of pre- and post-condition predicates that third-party verification tools can intercept and reinterpret for their own purposes (e.g. creating shims of behavior that abstract away the function body and replace it solely with the pre- and post-conditions).
Known issues:
* My original intent, as described in the MCP (https://github.com/rust-lang/compiler-team/issues/759) was to have a rustc-prefixed attribute namespace (like rustc_contracts::requires). But I could not get things working when I tried to do rewriting via a rustc-prefixed builtin attribute-macro. So for now it is called `contracts::requires`.
* Our attribute macro machinery does not provide direct support for attribute arguments that are parsed like rust expressions. I spent some time trying to add that (e.g. something that would parse the attribute arguments as an AST while treating the remainder of the items as a token-tree), but its too big a lift for me to undertake. So instead I hacked in something approximating that goal, by semi-trivially desugaring the token-tree attribute contents into internal AST constucts. This may be too fragile for the long-term.
* (In particular, it *definitely* breaks when you try to add a contract to a function like this: `fn foo1(x: i32) -> S<{ 23 }> { ... }`, because its token-tree based search for where to inject the internal AST constructs cannot immediately see that the `{ 23 }` is within a generics list. I think we can live for this for the short-term, i.e. land the work, and continue working on it while in parallel adding a new attribute variant that takes a token-tree attribute alongside an AST annotation, which would completely resolve the issue here.)
* the *intent* of `-Z contract-checks` is that it behaves like `-Z ub-checks`, in that we do not prematurely commit to including or excluding the contract evaluation in upstream crates (most notably, `core` and `std`). But the current test suite does not actually *check* that this is the case. Ideally the test suite would be extended with a multi-crate test that explores the matrix of enabling/disabling contracts on both the upstream lib and final ("leaf") bin crates.
|
|
See discussion in https://github.com/rust-lang/rust/pull/88502/files#r760177240
|
|
|
|
|
|
Add `unchecked_disjoint_bitor` per ACP373
Following the names from libs-api in https://github.com/rust-lang/libs-team/issues/373#issuecomment-2085686057
Includes a fallback implementation so this doesn't have to update cg_clif or cg_gcc, and overrides it in cg_llvm to use `or disjoint`, which [is available in LLVM 18](https://releases.llvm.org/18.1.0/docs/LangRef.html#or-instruction) so hopefully we don't need any version checks.
|
|
intrinsic
|
|
Rollup of 6 pull requests
Successful merges:
- #136398 (add UnsafeCell direct access APIs)
- #136465 (Some `rustc_middle` cleanups)
- #136479 (std::fs: further simplify dirent64 handling)
- #136504 (Fix last compare-mode false negatives in tests)
- #136511 (Add `cast_signed` and `cast_unsigned` methods for `NonZero` types)
- #136518 (Add note about `FnPtr` trait being exposed as public bound)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Rollup of 5 pull requests
Successful merges:
- #134777 (Enable more tests on Windows)
- #135621 (Move some std tests to integration tests)
- #135844 ( Add new tool for dumping feature status based on tidy )
- #136167 (Implement unstable `new_range` feature)
- #136334 (Extract `core::ffi` primitives to a separate (internal) module)
Failed merges:
- #136201 (Removed dependency on the field-offset crate, alternate approach)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
This includes [1] which is required for LLVM 20.
[1]: https://github.com/rust-lang/compiler-builtins/pull/752
|
|
|
|
[1] has not gone forward, so this needs to be reverted again in order to
unblock a compiler-builtins upgrade that is necessary for the LLVM 20
upgrade.
This reverts commit a2494f14e99ae90c964f12bf0c059d63ccc07c2a.
[1]: https://github.com/rust-lang/rust/pull/135501
|
|
Add note about `FnPtr` trait being exposed as public bound
|
|
Add `cast_signed` and `cast_unsigned` methods for `NonZero` types
Requested in https://github.com/rust-lang/rust/issues/125882 .
Note that this keeps the same names as the methods currently present on other
integer types. If we want to rename them, we can rename them all at the same
time.
|
|
std::fs: further simplify dirent64 handling
Follow-up to https://github.com/rust-lang/rust/pull/134678.
r? `@tgross35`
|
