| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
this now always uses the name as specified by the official docs
|
|
|
|
Signed-off-by: pudongair <744355276@qq.com>
|
|
|
|
|
|
|
|
Rollup of 11 pull requests
Successful merges:
- #138128 (Stabilize `#![feature(precise_capturing_in_traits)]`)
- #138834 (Group test diffs by stage in post-merge analysis)
- #138867 (linker: Fix staticlib naming for UEFI)
- #138874 (Batch mark waiters as unblocked when resuming in the deadlock handler)
- #138875 (Trusty: Fix build for anonymous pipes and std::sys::process)
- #138877 (Ignore doctests only in specified targets)
- #138885 (Fix ui pattern_types test for big-endian platforms)
- #138905 (Add target maintainer information for powerpc64-unknown-linux-musl)
- #138911 (Allow defining opaques in statics and consts)
- #138917 (rustdoc: remove useless `Symbol::is_empty` checks.)
- #138945 (Override PartialOrd methods for bool)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
Override PartialOrd methods for bool
I noticed that `PartialOrd` implementation for `bool` does not override the individual operator methods, unlike the other primitive types like `char` and integers.
This commit extracts these `PartialOrd` overrides shared by the other primitive types into a macro and calls it on `bool` too.
CC `@scottmcm` for our recent adventures in `PartialOrd` land
|
|
Trusty: Fix build for anonymous pipes and std::sys::process
PRs #136842 (Add libstd support for Trusty targets), #137793 (Stablize anonymous pipe), and #136929 (std: move process implementations to `sys`) merged around the same time, so update Trusty to take them into account.
cc `@randomPoison`
|
|
|
|
add FCW to warn about wasm ABI transition
See https://github.com/rust-lang/rust/issues/122532 for context: the "C" ABI on wasm32-unk-unk will change. The goal of this lint is to warn about any function definition and calls whose behavior will be affected by the change. My understanding is the following:
- scalar arguments are fine
- including 128 bit types, they get passed as two `i64` arguments in both ABIs
- `repr(C)` structs (recursively) wrapping a single scalar argument are fine (unless they have extra padding due to over-alignment attributes)
- all return values are fine
`@bjorn3` `@alexcrichton` `@Manishearth` is that correct?
I am making this a "show up in future compat reports" lint to maximize the chances people become aware of this. OTOH this likely means warnings for most users of Diplomat so maybe we shouldn't do this?
IIUC, wasm-bindgen should be unaffected by this lint as they only pass scalar types as arguments.
Tracking issue: https://github.com/rust-lang/rust/issues/138762
Transition plan blog post: https://github.com/rust-lang/blog.rust-lang.org/pull/1531
try-job: dist-various-2
|
|
I noticed that `PartialOrd` implementation for `bool` does not override the
individual operator methods, unlike the other primitive types like `char`
and integers.
This commit extracts these `PartialOrd` overrides shared by the other
primitive types into a macro and calls it on `bool` too.
|
|
Recognise new IPv6 non-global range from IETF RFC 9602
This PR adds the `5f00::/16` range defined by [IETF RFC 9602](https://datatracker.ietf.org/doc/rfc9602/) to those ranges which `Ipv6Addr::is_global` recognises as a non-global IP. This range is used for Segment Routing (SRv6) SIDs.
See also: https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml
Unstable tracking issue: #27709
|
|
|
|
tags
|
|
|
|
|
|
Although the "B" extension is redefined and ratified, keeping this in the
documentation as-is have two issues:
* "B" extension is not added to `riscv.rs` yet (to be added later).
* "B" extension is ratified as a combination of "Zba", "Zbb" and "Zbs"
extensions and "Zbc" is *not* a part of "B" itself (despite that
it is listed under "B"), which makes the documentation misleading.
This commit tentatively removes the reference to the "B" extension and
replaced with "Bit Manipulation Extensions" without an extension name.
|
|
As the version 20240411 of the RISC-V ISA Manual changed wording to
describe many of the standard extensions, this commit largely follows this
scheme in general. In many cases, words "Standard Extension" are replaced
with "Extension" following the latest ratified ISA Manual.
Some RISC-V extensions had tentative summary but it also fixes that
(e.g. "Zihintpause").
Following extensions are described in parity with corresponding extensions
using floating-point registers:
* "Zfinx" Extension for Single-Precision Floating-Point in Integer Registers
* "Zdinx" Extension for Double-Precision Floating-Point in Integer Registers
* "Zhinx" Extension for Half-Precision Floating-Point in Integer Registers
* "Zhinxmin" Extension for Minimal Half-Precision Floating-Point in Integer Registers
Following extensions are named against the ISA Manual naming but
considered inconsistency inside the ISA manual:
* "Zfhmin" Extension for Minimal Half-Precision Floating-Point
ISA Manual: "Zfhmin" Standard Extension for Minimal Half-Precision Floating-Point
* "V" Extension for Vector Operations
ISA Manual: "V" Standard Extension for Vector Operations
Following extension is removed from the latest ratified ISA Manual but
named like others:
* "Zam" Extension for Misaligned Atomics
"Zb*" extensions are described like "Extension for ..." using partial
summary per extension (including cryptography-related "Zbk*" extensions).
"Zk*" extensions are described like "Cryptography Extension for ..." using
partial summary per extension (e.g. 'Zkne - NIST Suite: AES Encryption' in
the ISA Manual to '"Zkne" Cryptography Extension for NIST Suite: AES
Encryption') except following extensions:
* "Zkr" Entropy Source Extension
Following the general rule will make the description redundant.
* "Zk" Cryptography Extension for Standard scalar cryptography
The last word "extension" is removed as seemed redundant.
Link:
<https://lf-riscv.atlassian.net/wiki/spaces/HOME/pages/16154769/RISC-V+Technical+Specifications>
(ISA Specifications, Version 20240411; published in May 2024)
|
|
All RISC-V Features are reordered for better maintainability.
The author has a plan to add many RISC-V ratified extensions (mainly
discoverable from Linux) and this is a part of preparation.
Sections are divided as follows:
* Base ISAs
* "I"-related
* Extensions formerly a part of the base "I" extension
but divided later (now all of them are ratified).
* Other user-mode extensions "Zi*".
* "M"-related (currently "M" only)
* "A"-related
"A", "Za*" and "Ztso" which is named differently but absolutely
related to memory operations.
* Base FP extensions
* Base FP extensions using integer registers
* "C"-related (currently "C" only)
* "B"-related (except cryptography-related "Zbk*")
* Scalar cryptography extensions (including "Zbk*")
* Base Vector extensions (currently "V" only)
* Ratified privileged extensions
* Non-extensions and non-ratified extensions which is *not*
going to be ratified, at least in the draft form
The last section needs some explanation.
"S" is not an extension (although some buggy implementations such as QEMU
up to 7.0 emitted this character as well as "U" as an extension) and the
DeviceTree parser in the Linux kernel explicitly workarounds this issue.
There's no plan for ratification of the single-letter "J" extension
(there's a room for redefinition like the "B" extension but unlikely).
Instead, pointer masking extensions including "Supm" is one of the results
of the task group discussing J extension*s*.
There's also an instruction in the "Zfa" extension which accelerates
FP-to-int conversion matching JavaScript semantics.
"P" is being actively discussed (and will result in a single-letter "P"
extension and various "Zp*" extensions) but it seems there needs some time
until ratification.
And there's one Rust-specific issue: Rust implements Packed-SIMD intrinsics
based on an early draft of the "P" extension and they are *very unlikely*
kept as-is. For instance, `add16` does not follow standard RISC-V
instruction naming (ADD16 is the name from the Andes' proposal) and
going to be renamed.
Before moving "P" to above, we have to clearly understand what the final
"P" extension will be and resolve existing intrinsics.
|
|
This commit adds indentation as suggested by the Clippy warning.
|
|
This error occurs when the RISC-V "A" Extension is being tested.
|
|
to fix the `unsafe_op_in_unsafe_fn` lint
|
|
A 512-bit register is f64x8, not f64x4. Likely a copy-paste error from the _m256d documentation,
which seems correct.
|
|
|
|
|
|
remove remnants of const_box feature
This feature requires major design work, and the few methods it gates currently aren't actually useful. Let's reset to a clean slate so when a design materializes, we can start from scratch.
Closes https://github.com/rust-lang/rust/issues/92521 by removing the feature it tracks.
r? ````@oli-obk````
|
|
Implement some basics in UEFI fs
- Just getting some basics out of the way while waiting for #138236 to be merged.
- Adds `fs::canonicalize`. Should be same as absolute in case of UEFI since there is no symlink support and absolute path is guaranteed to be uniqe according to spec.
- Make `fs::lstat` same as `fs::stat`. Should be same since UEFI does not have symlink support.
- Implement `OptionOptions`.
cc ````@nicholasbishop```` ````@dvdhrm````
|
|
UEFI does not have specific modes for create_new, truncate and append.
So those need to to be simulated after opening the file.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
|
|
- UEFI does not have symlinks. So lstat and stat should behave the same.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
|
|
- Should be same as absolute in UEFI since there are no symlinks.
- Also each absolute path representation should be unique according to
the UEFI specification.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
|
|
PRs #136842 (Add libstd support for Trusty targets), #137793 (Stablize
anonymous pipe), and #136929 (std: move process implementations to
`sys`) merged around the same time, so update Trusty to take them into
account.
|
|
Update `compiler-builtins` to 0.1.152
Includes the following changes related to unordered atomics:
* Remove element_unordered_atomic intrinsics [1]
* Remove use of `atomic_load_unordered` and undefined behaviour [2]
There are a handful of other small changes, but nothing else user-visible.
[1]: https://github.com/rust-lang/compiler-builtins/pull/789
[2]: https://github.com/rust-lang/compiler-builtins/pull/790
|
|
Fix `FileType` `PartialEq` implementation on Windows
Fixes #138668
On Windows the [`FileType`](https://doc.rust-lang.org/stable/std/fs/struct.FileType.html) struct was deriving `PartialEq` which in turn means it was doing a bit-for-bit comparison on the file attributes and reparse point. This is wrong because `attributes` may contain many things unrelated to file type.
`FileType` on Windows allows for four possible combinations (see also [`FileTypeExt`](https://doc.rust-lang.org/stable/std/os/windows/fs/trait.FileTypeExt.html)): `file`, `dir`, `symlink_file` and `symlink_dir`. So the new implementation makes sure both symlink and directory information match (and only those things).
This could be considered just a bug fix but it is a behaviour change so someone from libs-api might want to FCP this (or might not)...
|
|
Simplify `PartialOrd` on tuples containing primitives
We noticed in https://github.com/rust-lang/rust/pull/133984#issuecomment-2704011800 that currently the tuple comparison code, while it [does optimize down](https://github.com/rust-lang/rust/blob/master/tests/codegen/comparison-operators-2-tuple.rs) today, is kinda huge: <https://rust.godbolt.org/z/xqMoeYbhE>
This PR changes the tuple code to go through an overridable "chaining" version of the comparison functions, so that for simple things like `(i16, u16)` and `(f32, f32)` (as seen in the new MIR pre-codegen test) we just directly get the
```rust
if lhs.0 == rhs.0 { lhs.0 OP rhs.0 }
else { lhs.1 OP rhs.1 }
```
version in MIR, rather than emitting a mess for LLVM to have to clean up.
Test added in the first commit, so you can see the MIR diff in the second one.
|
|
|
|
Includes the following changes related to unordered atomics:
* Remove element_unordered_atomic intrinsics [1]
* Remove use of `atomic_load_unordered` and undefined behaviour [2]
There are a handful of other small changes, but nothing else
user-visible.
[1]: https://github.com/rust-lang/compiler-builtins/pull/789
[2]: https://github.com/rust-lang/compiler-builtins/pull/790
|
|
Uses `__`-named `doc(hidden)` methods instead.
|
|
|
|
Fix ICE #138415 for invalid extern function body
Fixes #138415
|
|
std: uefi: fs: Implement mkdir
- Since there is no direct mkdir in UEFI, first check if a file/dir with same path exists and then create the directory.
cc `@dvdhrm` `@nicholasbishop`
|
|
Update test for SGX now implementing `read_buf`
In #108326, `read_buf` was implemented for a variety of types, but SGX was saved for later. Update a test from then, now that #137355 implemented it for SGX types.
cc ````@jethrogb````
|
|
uefi: Add OwnedEvent abstraction
- Events are going to become quite important for Networking, so needed owned abstractions.
- Switch to OwnedEvent abstraction for Exit boot services event.
cc ````@nicholasbishop````
|
|
Remove unused trait BoundedSize
Detected by #128637
The usage of this trait is removed in #135104
r? `@the8472`
|
|
std: move process implementations to `sys`
As per #117276, this moves the implementations of `Process` and friends out of the `pal` module and into the `sys` module, removing quite a lot of error-prone `#[path]` imports in the process (hah, get it ;-)). I've also made the `zircon` module a dedicated submodule of `pal::unix`, hopefully we can move some other definitions there as well (they are currently quite a lot of duplications in `sys`). Also, the `ensure_no_nuls` function on Windows now lives in `sys::pal::windows` – it's not specific to processes and shared by the argument implementation.
|
|
|
