| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
workingjubilee:you-dont-need-to-see-this-cpuid-move-along, r=Amanieu
Finish removing `has_cpuid`
The one use of it was guaranteed to be always true.
try-job: test-various
|
|
[`macro_metavar_expr_concat`] Dogfooding
cc #124225
Starts inner usage to test the robustness of the implementation.
|
|
The one use of it was guaranteed to be always true.
|
|
|
|
fix(hermit): `deny(unsafe_op_in_unsafe_fn)`
Tracking issue: https://github.com/rust-lang/rust/issues/127747
r? workingjubilee
CC: ``@stlankes``
|
|
Signed-off-by: Martin Kröning <martin.kroening@eonerc.rwth-aachen.de>
|
|
Signed-off-by: Martin Kröning <martin.kroening@eonerc.rwth-aachen.de>
|
|
android: Remove libstd hacks for unsupported Android APIs
Our minimum supported API version is 21, remove hacks to support older Android APIs.
try-job: arm-android
r? tgross35
|
|
Signed-off-by: Martin Kröning <martin.kroening@eonerc.rwth-aachen.de>
|
|
This silences this rust-analyzer-specific error: `expected !, found ()`
Signed-off-by: Martin Kröning <martin.kroening@eonerc.rwth-aachen.de>
|
|
|
|
Our minimum supported API version is 21, remove hacks to support older
Android APIs.
|
|
|
|
Fix vita build of std and forbid unsafe in unsafe in the os/vita module
See #127747
r? `@workingjubilee`
`@pheki` `@nikarh`
|
|
After things that are immediately followed by a `use` declaration and
look like they might apply to that `use` item but actually don't.
|
|
The previous commit updated `rustfmt.toml` appropriately. This commit is
the outcome of running `x fmt --all` with the new formatting options.
|
|
|
|
Signed-off-by: Jiahao XU <Jiahao_XU@outlook.com>
|
|
Many tiny changes to stdlib doc comments to make them consistent (for example
"Returns foo", rather than "Return foo", per RFC1574), adding missing periods, paragraph
breaks, backticks for monospace style, and other minor nits.
https://github.com/rust-lang/rfcs/blob/master/text/1574-more-api-documentation-conventions.md#appendix-a-full-conventions-text
|
|
|
|
Rollup of 6 pull requests
Successful merges:
- #126908 (Use Cow<'static, str> for InlineAsmTemplatePiece::String)
- #127999 (Inject arm32 shims into Windows metadata generation)
- #128137 (CStr: derive PartialEq, Eq; add test for Ord)
- #128185 (Fix a span error when parsing a wrong param of function.)
- #128187 (Fix 1.80.0 version in RELEASES.md)
- #128189 (Turn an unreachable code path into an ICE)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Inject arm32 shims into Windows metadata generation
I had been keen to eventually move to using windows-sys as a normal Cargo dependency. But for linking, compile times and other reasons that's unlikely to ever happen.
So if we're sticking with generated bindings then injecting any necessary missing type definitions (i.e. for the MS unsupported arm32) is simpler than defining whole functions ourselves just because we need to manually implement those types on a tier 3 platform. This also reduces the places we need to change when making changes to how we use `#[link]`.
r? libs
|
|
Fix connect timeout for non-linux targets, read readiness of socket connection, Read readiness to detect errors. `Fixes #127018`
Fixes #127018
Connect_timeout would call `poll` and check `pollfd.revents` for POLLHUP error, rather that checking readiness. This behavior was meant for Linux as it returns POLLHUP | POLLOUT | POLLERR in case of errors. But on targets that do not return POLLHUP in `pollfd.revents`, this would indicate a false success and result in this issue. To resolve this we will check readiness of socket using `getsockopt():` and return success from connect_timeout when there are no errors.
Changes were tested on Linux and an rtos.
Thank you.
|
|
pollerr for refused connections in linux
|
|
Import `c_void` rather than using the full path
Follow up to #128092. As requested, this imports `c_void` in more places. I also fixed up some imports to use `core` for core types instead of `crate`. While that is not strictly necessary, I think ideally things in `sys/pal` should only depend on itself or core so that the code is less spaghetti. We're far away from that ideal at the moment but I can at least try to slowly move in that direction.
Also this forbids `unsafe_op_in_unsafe_fn` for library/std/src/sys/pal/windows by fixing up the remaining unsafe bits that are just punting their unsafe requirements onto the caller of the `unsafe` function (or definition macro).
<!--
r? workingjubilee
-->
|
|
Replace some `mem::forget`'s with `ManuallyDrop`
> but I would like to see a larger effort to replace all uses of `mem::forget`.
_Originally posted by `@saethlin` in https://github.com/rust-lang/rust/issues/127584#issuecomment-2226087767_
So,
r? `@saethlin`
Sorry, I have finished writing all of this before I got your response.
|
|
Fix build failure on vxworks #127084
PR to address issue #127084 .
1. Skip `reset_segpipe` for vxworks
2. Return unimplemented error for vxworks from settimes and lchown
3. Temporarily skip dirfd for vxworks
4. Add allow unused unsafe on read_at and write_at functions in unix/fs.rs
5. Using cfg disable ON_BROKEN_PIPE_FLAG_USED and on_broken_pipe_flag_used() for vxworks
6. Remove old crate::syscommon::thread::min_stack() reference from process_vxworks.rs and update to set stack size of rtpthread
Thank you.
|
|
|
|
|
|
|
|
Fix return type of FileAttr methods on AIX target
At some point it seems `SystemTime::new` changed from returning `SystemTime` to `io::Result<SystemTime>`. This seems to have been addressed on other platforms, but was never changed for AIX.
This was caught by running
```
python3 x.py build --host x86_64-unknown-linux-gnu --target powerpc64-ibm-aix
```
|
|
Remove wrapper functions from c.rs
I'd like for the windows `c.rs` just to contain the basic platform definitions and not anything higher level unless absolutely necessary. So this removes some wrapper functions that weren't really necessary in any case. The functions are only used in a few places which themselves are relatively thin wrappers. The "interesting" bit is that we had an `AlertableIoFn` that abstracted over `ReadFileEx` and `WriteFileEx`. I've replaced this with a closure.
Also I removed an `#[allow(unsafe_op_in_unsafe_fn)]` while I was moving things around.
|
|
Initial implementation of anonymous_pipe API
ACP completed in rust-lang/libs-team#375
Tracking issue: #127154
try-job: x86_64-msvc
try-job: i686-mingw
|
|
At some point it seems `SystemTime::new` changed from returning `SystemTime` to `io::Result<SystemTime>`. This seems to have been addressed on other platforms, but was never changed for AIX.
This was caught by running
```
python3 x.py build --host x86_64-unknown-linux-gnu --target powerpc64-ibm-aix
```
|
|
Co-authored-by: Alphyr <47725341+a1phyr@users.noreply.github.com>
Co-authored-by: Jubilee <46493976+workingjubilee@users.noreply.github.com>
Signed-off-by: Jiahao XU <Jiahao_XU@outlook.com>
|
|
can set the stack size using RUST_MIN_STACK, with min size of libc::PTHREAD_STACK_MIN(4kib)
|
|
|
|
|
|
|
|
lchown for vxworks
|
|
|
|
ian-h-chamberlain:fix/horizon-warnings-unsafe-in-unsafe, r=tgross35
Clean up warnings + `unsafe_op_in_unsafe_fn` when building std for armv6k-nintendo-3ds
See #127747
ping `@AzureMarker` `@Meziu`
I could only find one instance needing an extra `unsafe` that was not also shared with many other `unix` targets (presumably these will get covered in larger sweeping changes, I didn't want to introduce churn that would potentially conflict with those). The one codepath I found is shared with `vita` however, so also pinging `@nikarh` `@pheki` `@zetanumbers` just to make sure they're aware of this change.
Also removed one unused import from `process_unsupported` which should simply fix the warning for any target that uses it.
|
|
Deal with invalid UTF-8 from `gai_strerror`
When the system is using a non-UTF-8 locale, the value will indeed not be UTF-8. That sucks for everyone involved, but is no reason for panic. We can "handle" this gracefully by just using from lossy, replacing the invalid UTF-8 with � and keeping the accidentally valid UTF-8. Good luck when debugging, but at least it's not a crash.
We already do this for `strerror_r`.
fixes #127563
|
|
Also fix one instance of unsafe_op_in_unsafe_fn that's specific to
horizon + vita - most others should be common with other code.
|
|
When the system is using a non-UTF-8 locale, the value will indeed not
be UTF-8. That sucks for everyone involved, but is no reason for panic.
We can "handle" this gracefully by just using from lossy, replacing the
invalid UTF-8 with the ? and keeping the accidentally valid UTF-8.
Good luck when debugging, but at least it's not a crash.
We already do this for `strerror_r`.
|
|
|
|
Windows: move BSD socket shims to netc
On Windows we need to alter a few types so that they can be used in the cross-platform socket code. Currently these alterations are spread throughout the `c` module with some more in the `netc` module.
Let's gather all our BSD compatibility shims in the `netc` module so it's all in one place and easier to discover.
|
|
r=Amanieu
kmc-solid: `#![forbid(unsafe_op_in_unsafe_fn)]`
The path logic _should_ handle the forbiddance in the itron sources correctly, despite them being an "out-of-line" module.
|
|
r=joboet
unix: document unsafety for std `sig{action,altstack}`
I found many surprising elements here while trying to wrap a measly 5 functions with `unsafe`. I would rather not "just" mindlessly wrap this code with `unsafe { }`, so I decided to document it properly.
On Unix, this code covers the "create and setup signal handler" part of the stack overflow code, and serves as the primary safety boundary for the signal handler. It is rarely audited, very gnarly, and worth extra attention. It calls other unsafe functions defined in this module, but "can we correctly map the right memory, or find the right address ranges?" are separate questions, and get increasingly platform-specific. The question here is the more general "are we doing everything in the correct order, and setting up the handler in the correct way?"
As part of this audit, I noticed that we do some peculiar things that we should probably refrain from. However, I avoided making changes that I deemed might have a different final result in Rust programs. I did, however, reorder some events so that the signal handler is installed _after_ we install the alternate stack. We do not run much code between these events, but it is probably best if the timespan between the handler being available and the new stack being installed is 0 nanoseconds.
|
