| Age | Commit message (Collapse) | Author | Lines |
|---|
|
The wasm32-wasi target delegates its malloc implementation to the
functions in wasi-libc, but the invocation of `aligned_alloc` was
incorrect by passing the number of bytes requested first rather than the
alignment. This commit swaps the order of these two arguments to ensure
that we allocate over-aligned memory correctly.
|
|
avoid creating unnecessary reference in Windows Env iterator
Discovered in https://github.com/rust-lang/miri/pull/1225: the Windows `Env` iterator violates Stacked Borrows by creating an `&u16`, turning it into a raw pointer, and then accessing memory outside the range of that type.
There is no need to create a reference here in the first place, so the fix is trivial.
Cc @JOE1994
Cc https://github.com/rust-lang/unsafe-code-guidelines/issues/134
|
|
|
|
|
|
|
|
|
|
fix TryEnterCriticalSection return type
Source: https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-tryentercriticalsection
Fixes https://github.com/rust-lang/rust/issues/70504
|
|
ASCII methods on OsStr
Would close #69566
I don't know enough about encodings to know if this is a valid change, however the comment on the issue suggests it could be.
This does two things:
1. Makes ASCII methods available on OsStr
2. Makes it possible to obtain a `&mut OsStr`. This is necessary to actually use `OsStr::make_ascii_*case` methods since they modify the underlying value. As far as I can tell, the only way to modify a `&mut OsStr` is via the methods I just added.
My original hope was to have these methods on `OsStrExt` for Windows, since the standard library already assumes `make_ascii_uppercase` is valid in Windows (see the change I made to windows/process.rs). If it is found these are not valid changes on non-Windows platforms, I can move the methods to the ext trait instead.
|
|
|
|
|
|
|
|
|
|
Rename asm! to llvm_asm!
As per https://github.com/rust-lang/rfcs/pull/2843, this PR renames `asm!` to `llvm_asm!`. It also renames the compiler's internal `InlineAsm` data structures to `LlvmInlineAsm` in preparation for the new `asm!` functionality specified in https://github.com/rust-lang/rfcs/pull/2850.
This PR doesn't actually deprecate `asm!` yet, it just makes it redirect to `llvm_asm!`. This is necessary because we first need to update the submodules (in particular stdarch) to use `llvm_asm!`.
|
|
Allow obtaining &mut OsStr
```rust
impl DerefMut for OsString {...} // type Target = OsStr
impl IndexMut<RangeFull> for OsString {...} // type Output = OsStr
```
---
This change is pulled out of #69937 per @dtolnay
This implements `DerefMut for OsString` to allow obtaining a `&mut OsStr`. This also implements `IndexMut for OsString`, which is used by `DerefMut`. This pattern is the same as is used by `Deref`.
This is necessary to for methods like `make_ascii_lowercase` which need to mutate the underlying value.
|
|
asm! is left as a wrapper around llvm_asm! to maintain compatibility.
|
|
Use getentropy(2) on macos
resolves #70179
|
|
Fix abort-on-eprintln during process shutdown
This commit fixes an issue where if `eprintln!` is used in a TLS
destructor it can accidentally cause the process to abort. TLS
destructors are executed after `main` returns on the main thread, and at
this point we've also deinitialized global `Lazy` values like those
which store the `Stderr` and `Stdout` internals. This means that despite
handling TLS not being accessible in `eprintln!`, we will fail due to
not being able to call `stderr()`. This means that we'll double-panic
quickly because panicking also attempt to write to stderr.
The fix here is to reimplement the global stderr handle to avoid the
need for destruction. This avoids the need for `Lazy` as well as the
hidden panic inside of the `stderr` function.
Overall this should improve the robustness of printing errors and/or
panics in weird situations, since the `stderr` accessor should be
infallible in more situations.
|
|
|
|
This commit fixes an issue where if `eprintln!` is used in a TLS
destructor it can accidentally cause the process to abort. TLS
destructors are executed after `main` returns on the main thread, and at
this point we've also deinitialized global `Lazy` values like those
which store the `Stderr` and `Stdout` internals. This means that despite
handling TLS not being accessible in `eprintln!`, we will fail due to
not being able to call `stderr()`. This means that we'll double-panic
quickly because panicking also attempt to write to stderr.
The fix here is to reimplement the global stderr handle to avoid the
need for destruction. This avoids the need for `Lazy` as well as the
hidden panic inside of the `stderr` function.
Overall this should improve the robustness of printing errors and/or
panics in weird situations, since the `stderr` accessor should be
infallible in more situations.
|
|
|
|
- add initial version to support sockets
- use TcpStream as test case
- HermitCore uses smoltcp as IP stack for pure Rust applications
- further functionalities (e.g. UDP support) will be added step by step
|
|
this patch increases the compatibility to other operating systems
|
|
unix: Set a guard page at the end of signal stacks
This mitigates possible issues when signal stacks overflow, which could
manifest as segfaults or in unlucky circumstances possible clobbering of
other memory values as stack overflows tend to enable.
I went ahead and made a PR for this because it's a pretty small change, though if I should open an issue/RFC for this and discuss there first I'll happily do so. I've also added some example programs that demonstrate the uncomfortably clobber-happy behavior we currently have, and the segfaults that could/should result instead, [here](https://github.com/iximeow/jubilant-train).
|
|
|
|
|
|
|
|
|
|
|
|
std: on Windows, use GetSystemTimePreciseAsFileTime if it is available
This implements #67266.
|
|
Implement `Copy` for `IoSlice`
Resolves #69395
r? @sfackler
|
|
|
|
also unmap the whole thing when cleaning up, rather than leaving a spare
page floating around.
|
|
This mitigates possible issues when signal stacks overflow, which could
manifest as segfaults or in unlucky circumstances possible clobbering of
other memory values as stack overflows tend to enable.
|
|
|
|
Although `stack_overflow::init` runs very early in the process, even
before `main`, there may already be signal handlers installed for things
like the address sanitizer. In that case, just leave it alone, and don't
bother trying to allocate our own signal stacks either.
|
|
|
|
it. (clippy::redundant_static_lifetimes)
|
|
|
|
example:
let s: String = format!("hello").into();
|
|
|
|
Split non macro portion of unused_doc_comment from macro part into two passes/lints
## Motivation
This change is motivated by the needs of the [spandoc library](https://github.com/yaahc/spandoc). The specific use case is that my macro is removing doc comments when an attribute is applied to a fn with doc comments, but I would like the lint to still appear when I forget to add the `#[spandoc]` attribute to a fn, so I don't want to have to silence the lint globally.
## Approach
This change splits the `unused _doc_comment` lint into two lints, `unused_macro_doc_comment` and `unused_doc_comment`. The non macro portion is moved into an `early_lint_pass` rather than a pre_expansion_pass. This allows proc macros to silence `unused_doc_comment` warnings by either adding an attribute to silence it or by removing the doc comment before the early_pass runs.
The `unused_macro_doc_comment` lint however will still be impossible for proc-macros to silence, but the only alternative that I can see is to remove this lint entirely, which I don't think is acceptable / is a decision I'm not comfortable making personally, so instead I opted to split the macro portion of the check into a separate lint so that it can be silenced globally with an attribute if necessary without needing to globally silence the `unused_doc_comment` lint as well, which is still desireable.
fixes https://github.com/rust-lang/rust/issues/67838
|
|
|
|
|
|
macOS: avoid calling pthread_self() twice
|
|
|
|
Fix std::fs::copy on WASI target
Previously `std::fs::copy` on wasm32-wasi would reuse code from the `sys_common` module and would successfully copy contents of the file just to fail right before closing it.
This was happening because `sys_common::copy` tries to copy permissions of the file, but permissions are not a thing in WASI (at least yet) and `set_permissions` is implemented as an unconditional runtime error.
This change instead adds a custom working implementation of `std::fs::copy` (like Rust already has on some other targets) that doesn't try to call `set_permissions` and is essentially a thin wrapper around `std::io::copy`.
Fixes #68560.
|
|
|
|
Make the SGX arg cleanup implementation a NOP
fixes #64304
cc @jethrogb
|
|
Previously `std::fs::copy` on wasm32-wasi would reuse code from the `sys_common` module and would successfully copy contents of the file just to fail right before closing it.
This was happening because `sys_common::copy` tries to copy permissions of the file, but permissions are not a thing in WASI (at least yet) and `set_permissions` is implemented as an unconditional runtime error.
This change instead adds a custom working implementation of `std::fs::copy` (like Rust already has on some other targets) that doesn't try to call `set_permissions` and is essentially a thin wrapper around `std::io::copy`.
Fixes #68560.
|
|
Cleanup SGX entry code
cc @aandyl
|
