| Age | Commit message (Collapse) | Author | Lines |
|---|
|
r=alexcrichton"
This reverts commit 7870050796e5904a0fc85ecbe6fa6dde1cfe0c91, reversing
changes made to 2e7244807a7878f6eca3eb7d97ae9b413aa49014.
|
|
- Refactors the Emscripten target spec to share code with other wasm
targets.
- Replaces the incorrect wasm32 C call ABI with the old asmjs
version, which is correct for both wasm32 and JS.
- Updates the varargs ABI used by Emscripten and deletes the old one.
- Removes the obsolete wasm32-experimental-emscripten target.
- Temporarily makes Emscripten targets use panic=abort by default
because supporting unwinding will require an LLVM patch.
|
|
Fuchsia exit codes don't follow the convention of libc::WEXITSTATUS et
al, and they are 64 bits instead of 32 bits. This gives Fuchsia its own
representation of ExitStatus.
Additionally, the zircon syscall structs were out of date, causing us to
see bogus return codes.
|
|
libstd fuchsia fixes
This fixes two bugs in libstd on Fuchsia:
- `zx_time_t` was changed to an `i64`, but this never made it into libstd
- When spawning processes where any of the stdio were null, libstd attempts to open `/dev/null`, which doesn't exist on Fuchsia
r? @cramertj
|
|
Add Fuchsia to actually_monotonic
Fuchsia provides a fully monotonic clock.
Fix https://github.com/rust-lang/rust/issues/64196
cc @joshlf @tmandry
r? @alexcrichton
|
|
Fuchsia provides a fully monotonic clock.
|
|
This commit rejiggers the generics used in the implementation of
`Command::env` with the purpose of reducing the amount of codegen that
needs to happen in consumer crates, instead preferring to generate code
into libstd.
This was found when profiling the compile times of the `cc` crate where
the binary rlib produced had a lot of `BTreeMap` code compiled into it
but the crate doesn't actually use `BTreeMap`. It turns out that
`Command::env` is generic enough to codegen the entire implementation in
calling crates, but in this case there's no performance concern so it's
fine to compile the code into the standard library.
This change is done by removing the generic on the `CommandEnv` map
which is intended to handle case-insensitive variables on Windows.
Instead now a generic isn't used but rather a `use` statement defined
per-platform is used.
With this commit a debug build of `Command::new("foo").env("a", "b")`
drops from 21k lines of LLVM IR to 10k.
|
|
|
|
|
|
|
|
|
|
Re-enable Redox builder (take 2)
Closes: #63160
|
|
In sys/unix/process, we work around the sigemptyset linking issues
on android in two different ways. This change consolidates these
workarounds, and avoids duplicating bindings from `libc`.
|
|
|
|
|
|
|
|
Add an overflow check in truncate implementation for Unix.
Closes #63326.
cc @alexcrichton
|
|
|
|
|
|
|
|
|
|
|
|
provide thread name to OS for Solarish systems
Fixes #62302
Passes a Linux bootstrap build. python x.py test src/tools/tidy happy.
I tested this with a small test binary that spawns a few threads, and verified
that:
- on an illumos system lacking the libc function, the binary runs but no OS-level
thread names are set
- on an illumos system with the feature, the binary runs, and the thread names are
visible and correct under tools like MDB, pstack, core dump, etc.
|
|
|
|
|
|
|
|
Fix few Clippy warnings
|
|
|
|
|
|
|
|
filedesc: don't use ioctl(FIOCLEX) on Linux
All `ioctl(2)`s will fail on `O_PATH` file descriptors on Linux (because
they use `&empty_fops` as a security measure against `O_PATH` descriptors
affecting the backing file).
As a result, `File::try_clone()` and various other methods would always
fail with `-EBADF` on `O_PATH` file descriptors. The solution is to simply
use `F_SETFD` (as is used on other unices) which works on `O_PATH`
descriptors because it operates through the `fnctl(2)` layer and not
through `ioctl(2)`s.
Since this code is usually only used in strange error paths (a broken or
ancient kernel), the extra overhead of one syscall shouldn't cause any
dramas. Most other systems programming languages also use the fnctl(2)
so this brings us in line with them.
Fixes: rust-lang/rust#62314
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
|
|
All ioctl(2)s will fail on O_PATH file descriptors on Linux (because
they use &empty_fops as a security measure against O_PATH descriptors
affecting the backing file).
As a result, File::try_clone() and various other methods would always
fail with -EBADF on O_PATH file descriptors. The solution is to simply
use F_SETFD (as is used on other unices) which works on O_PATH
descriptors because it operates through the fnctl(2) layer and not
through ioctl(2)s.
Since this code is usually only used in strange error paths (a broken or
ancient kernel), the extra overhead of one syscall shouldn't cause any
dramas. Most other systems programming languages also use the fnctl(2)
so this brings us in line with them.
Fixes: rust-lang/rust#62314
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
|
|
request at least ptr-size alignment from posix_memalign
Fixes https://github.com/rust-lang/rust/issues/62251
|
|
|
|
|
|
|
|
|
|
|
|
For `libc` types that will be initialized in FFI calls, we can just use
`MaybeUninit` and then pass around raw pointers.
For `sun_path_offset()`, which really wants `offset_of`, all callers
have a real `sockaddr_un` available, so we can use that reference.
|
|
macos tlv workaround
fixes: #60141
Includes:
* remove dead code: `requires_move_before_drop`. This hasn't been needed for a while now (oops I should have removed it in #57655)
* redox had a copy of `fast::Key` (not sure why?). That has been removed.
* Perform a `read_volatile` on OSX to reduce `tlv_get_addr` calls per `__getit` from (4-2 depending on context) to 1.
`tlv_get_addr` is relatively expensive (~1.5ns on my machine).
Previously, in contexts where `__getit` was inlined, 4 calls to `tlv_get_addr` were performed per lookup. For some reason when `__getit` is not inlined this is reduced to 2x - and performance improves to match.
After this PR, I have only ever seen 1x call to `tlv_get_addr` per `__getit`, and macos now benefits from situations where `__getit` is inlined.
I'm not sure if the `read_volatile(&&__KEY)` trick is working around an LLVM bug, or a rustc bug, or neither.
r? @alexcrichton
|
|
Print PermissionExt::mode() in octal in Documentation Examples
Printing the file permission mode on unix systems in decimal feels unintuitive. Printing it in octal gives the expected form of e.g. `664`.
|
|
|
|
This commit removes all in-tree support for generating backtraces in
favor of depending on the `backtrace` crate on crates.io. This resolves
a very longstanding piece of duplication where the standard library has
long contained the ability to generate a backtrace on panics, but the
code was later extracted and duplicated on crates.io with the
`backtrace` crate. Since that fork each implementation has seen various
improvements one way or another, but typically `backtrace`-the-crate has
lagged behind libstd in one way or another.
The goal here is to remove this duplication of a fairly critical piece
of code and ensure that there's only one source of truth for generating
backtraces between the standard library and the crate on crates.io.
Recently I've been working to bring the `backtrace` crate on crates.io
up to speed with the support in the standard library which includes:
* Support for `StackWalkEx` on MSVC to recover inline frames with
debuginfo.
* Using `libbacktrace` by default on MinGW targets.
* Supporting `libbacktrace` on OSX as an option.
* Ensuring all the requisite support in `backtrace`-the-crate compiles
with `#![no_std]`.
* Updating the `libbacktrace` implementation in `backtrace`-the-crate to
initialize the global state with the correct filename where necessary.
After reviewing the code in libstd the `backtrace` crate should be at
exact feature parity with libstd today. The backtraces generated should
have the same symbols and same number of frames in general, and there's
not known divergence from libstd currently.
Note that one major difference between libstd's backtrace support and
the `backtrace` crate is that on OSX the crates.io crate enables the
`coresymbolication` feature by default. This feature, however, uses
private internal APIs that aren't published for OSX. While they provide
more accurate backtraces this isn't appropriate for libstd distributed
as a binary, so libstd's dependency on the `backtrace` crate explicitly
disables this feature and forces OSX to use `libbacktrace` as a
symbolication strategy.
The long-term goal of this refactoring is to eventually move us towards
a world where we can drop `libbacktrace` entirely and simply use Gimli
and the surrounding crates for backtrace support. That's still aways off
but hopefully will much more easily enabled by having the source of
truth for backtraces live in crates.io!
Procedurally if we go forward with this I'd like to transfer the
`backtrace-rs` crate to the rust-lang GitHub organization as well, but I
figured I'd hold off on that until we get closer to merging.
|
|
DoubleEndedIterators."
This reverts commit 3e86cf36b5114f201868bf459934fe346a76a2d4.
|
|
convert custom try macro to `?`
resolves #60580
r? @frewsxcv
|
|
Fall back to `/dev/urandom` on `EPERM` for `getrandom`
This can happen because of seccomp or some VMs.
Fixes #52609.
|
|
This reverts commit d252f3b77f3b7d4cd59620588f9d026633c05816.
|
|
|
|
|
|
Remove bitrig support from rust
Resolves #60743
using `find` and `rg` I delete every occurence of "bitrig" in the sources, expect for the llvm submodule (is this correct?).
There's also this file https://github.com/rust-lang/rls/blob/5b8e99bb61958ca8abcb7c5eda70521726be1065/rls-analysis/test_data/rust-analysis/libstd-af9bacceee784405.json which contains a bitrig string in it. What to do with that?
|
