Remove some unnecessary parens in `assert!` conditions
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.
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.
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)
Fix `unreachable_pub` lint for hermit target
The build for the hermit target (`#[cfg(target_os = "hermit")]`) fails on master as of [8df89d1cb0](8df89d1cb0) (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
```
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.
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]: 2d2642f483/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.
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
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.
Extract `core::ffi` primitives to a separate (internal) module
### Introduce library/core/src/ffi/primitives.rs
The regex preprocessing for PR #133944 would be more robust if the relevant types from core/src/ffi/mod.rs were first moved to library/core/src/ffi/primitives.rs, then there isn't a need to deal with traits / c_str / va_list / whatever might wind up in that module in the future
r? `@tgross35`
Implement unstable `new_range` feature
Switches `a..b`, `a..`, and `a..=b` to resolve to the new range types.
For rust-lang/rfcs#3550
Tracking issue #123741
also adds the re-export that was missed in the original implementation of `new_range_api`
Move some std tests to integration tests
Unit tests directly inside of standard library crates require a very fragile way of building that is hard to reproduce outside of bootstrap.
Follow up to https://github.com/rust-lang/rust/pull/133859
Display of integers without raw pointers and without overflowing_literals
The benchmarks as is measure formatting speed of literals. The first commit `black_box`-es input to simulate runtime speed instead.
The second commit replaces `unsafe` pointer optimizations with plain array indices. The performance is equivalent on Apple M1. Needs peer review on Intel.
Happy to do the 128-bit version too if such change is welcome.
This has now been approved as a language feature and no longer needs
a `rustc_` prefix.
Also change the `contracts` feature to be marked as incomplete and
`contracts_internals` as internal.
1. Document the new intrinsics.
2. Make the intrinsics actually check the contract if enabled, and
remove `contract::check_requires` function.
3. Use panic with no unwind in case contract is using to check for
safety, we probably don't want to unwind. Following the same
reasoning as UB checks.
The extended syntax for function signature that includes contract clauses
should never be user exposed versus the interface we want to ship
externally eventually.
includes post-developed commit: do not suggest internal-only keywords as corrections to parse failures.
includes post-developed commit: removed tabs that creeped in into rustfmt tool source code.
includes post-developed commit, placating rustfmt self dogfooding.
includes post-developed commit: add backquotes to prevent markdown checking from trying to treat an attr as a markdown hyperlink/
includes post-developed commit: fix lowering to keep contracts from being erroneously inherited by nested bodies (like closures).
Rebase Conflicts:
- compiler/rustc_parse/src/parser/diagnostics.rs
- compiler/rustc_parse/src/parser/item.rs
- compiler/rustc_span/src/hygiene.rs
Remove contracts keywords from diagnostic messages
