Currently, when enabling CFI via -Zsanitizer=cfi and executing e.g.
std::sys::random::getrandom, we can observe a CFI violation. This is
the case for all consumers of the std::sys::pal::weak::weak macro,
as it is defining weak functions which don't show up in LLVM IR
metadata. CFI fails for all these functions.
Similar to other such cases in
https://github.com/rust-lang/rust/issues/115199, this change stops
emitting the CFI typecheck for consumers of the macro via the
\#[no_sanitize(cfi)] attribute.
Eliminate any redundant, unobservable logic from the their default
method implementations.
The observable changes are that `Write::write_fmt` for both types now
ignores the formatting arguments, so a user fmt impl which has side
effects is not invoked, and `Write::write_all_vectored` for both types
does not advance the borrowed buffers. Neither behavior is guaranteed by
the docs and the latter is documented as unspecified.
`Empty` is not marked as vectored, so that `Chain<Empty, _>` and
`Chain<_, Empty>` are not forced to be vectored.
Support `File::seek` for Hermit
`lseek` was added in `hermit-abi` in commit [87dd201](87dd201a14) (add missing interface for lseek, 2024-07-15), which was just released in version 0.5.0.
cc ``@mkroening,`` ``@stlankes``
Fixes https://github.com/hermit-os/hermit-rs/issues/652
- Just the permission and file type.
- FileTimes will need some new conversion functions and thus will come
with a future PR. Trying to keep things simple here.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
- Similar to FilePermissions, using bool to represent the bitfield.
- FileType cannot be changed, so no need to worry about converting back
to attribute.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
- UEFI file permissions are indicated using a u64 bitfield used for
readonly/filetype, etc.
- Using normal bool with to and from attribute conversions to
FilePermission from overriding some other bitfields.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
As per #117276, this moves the platform definitions of `Stdout` and friends into `sys`. This PR also unifies the UNIX and Hermit implementations and moves the `__rust_print_err` function needed by libunwind on SGX into the dedicated module for such helper functions.
Windows: Don't link std (and run-make) against advapi32, except on win7
Std no longer depends on any functionality provided by advapi32, so we can remove it from the list of external libraries we link against. Except, the win7 targets do still rely on advapi32-provided functionality. This PR therefore moves linking against it to only occur on win7 targets, so that no new uses of it slip in without being noticed.
Mention `env` and `option_env` macros in `std::env::var` docs
Fixes https://github.com/rust-lang/rust/issues/138159.
Just like there are mentions in `env!` and `option_env!` docs to `std::env::var`, it'd be nice to have a "mention back" as well.
Windows: Fix error in `fs::rename` on Windows 1607
Fixes#137499
There's a bug in our Windows implementation of `fs::rename` that only manifests on a specific version of Windows. Both newer and older versions of Windows work.
I took the safest route to fixing this by using the old `MoveFileExW` function to implement this and only falling back to the new behaviour if that fails. This is similar to what is done in `unlink` (just above this function).
try-job: dist-x86_64-mingw
try-job: dist-x86_64-msvc
Put the alloc unit tests in a separate alloctests package
Same rationale as https://github.com/rust-lang/rust/pull/135937. This PR has some extra complexity though as a decent amount of tests are testing internal implementation details rather than the public api. As such I opted to include the modules containing the types under test using `#[path]` into the alloctests package. This means that those modules still need `#[cfg(test)]`, but the rest of liballoc no longer need it.
* Clarify relationship to `dyn` after #133003.
* Add an example of using it with `dyn` as #133003 enabled.
* Add an example of implementing it.
* Add links to Rust Reference for the mentioned concepts.
* Mention that its method should rarely be called.
* Replace parameter name `dst` with `dest` to avoids confusion between
“DeSTination” and “Dynamically-Sized Type”.
* Various small corrections.
atomic: clarify that failing conditional RMW operations are not 'writes'
Fixes https://github.com/rust-lang/rust/issues/136669
r? ``@Amanieu``
Cc ``@rust-lang/opsem`` ``@chorman0773`` ``@gnzlbg`` ``@briansmith``
add a "future" edition
This idea has been discussed previously [on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/Continuous.20edition-like.20changes.3F/near/432559262) (though what I've implemented isn't exactly the "next"/"future" editions proposed in that message, just the "future" edition). I've found myself prototyping changes that involve edition migrations and wanting to target an upcoming edition for those migrations, but none exists. This should be permanently unstable and not removed.