| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
This mostly brings them in line with existing linking convention, but
also has some minor re-wording.
The text at the top has been re-focused, by starting out with what the
prelude does, rather than starting from injecting std.
Also, it now mentions that other preludes exist.
Part of https://github.com/rust-lang/rust/issues/29369
|
|
This mostly brings them in line with existing linking convention, but
also has some minor re-wording.
The text at the top has been re-focused, by starting out with what the
prelude does, rather than starting from injecting std.
Also, it now mentions that other preludes exist.
Part of https://github.com/rust-lang/rust/issues/29369
|
|
|
|
|
|
Moved from #29753. r? @steveklabnik
|
|
The comparison of IP addresses should happen not always in network endianness
but rather in the host endianness format, so be sure to convert to that before
comparing addresses.
There are still locations where the endianness will factor into visible
properties, such as the hash, but these are not important to be independent of
the endianness in play (as hash values are pretty undefined anyway.
Closes #29691
|
|
|
|
r? @steveklabnik
|
|
* Delete `sys::unix::{c, sync}` as these are now all folded into libc itself
* Update all references to use `libc` as a result.
* Update all references to the new flat namespace.
* Moves all windows bindings into sys::c
|
|
The comparison of IP addresses should happen not always in network endianness
but rather in the host endianness format, so be sure to convert to that before
comparing addresses.
There are still locations where the endianness will factor into visible
properties, such as the hash, but these are not important to be independent of
the endianness in play (as hash values are pretty undefined anyway.
Closes #29691
|
|
|
|
|
|
|
|
* Store the native representation directly in the `ExitStatus` structure instead
of a "parsed version" (mostly for Unix).
* On Windows, be more robust against processes exiting with the status of 259.
Unfortunately this exit code corresponds to `STILL_ACTIVE`, causing libstd to
think the process was still alive, causing an infinite loop. Instead the loop
is removed altogether and `WaitForSingleObject` is used to wait for the
process to exit.
|
|
* Store the native representation directly in the `ExitStatus` structure instead
of a "parsed version" (mostly for Unix).
* On Windows, be more robust against processes exiting with the status of 259.
Unfortunately this exit code corresponds to `STILL_ACTIVE`, causing libstd to
think the process was still alive, causing an infinite loop. Instead the loop
is removed altogether and `WaitForSingleObject` is used to wait for the
process to exit.
|
|
Also remove `stable` stability annotations from inherent impls
(There will be a warning for useless stability annotations soon.)
r? @Gankro
|
|
&format!("...") is the same as "" if we're not doing any interpolation,
and doesn't allocate an intermediate String.
|
|
|
|
Currently if a print happens while a thread is being torn down it may cause a
panic if the LOCAL_STDOUT TLS slot has been destroyed by that point. This adds a
guard to check and prints to the process stdout if that's the case (as we do for
if the slot is already borrowed).
Closes #29488
|
|
As discovered in #29298, `env::set_var("", "")` will panic, but it turns out
that it *also* deadlocks on Unix systems. This happens because if a panic
happens while holding the environment lock, we then go try to read
RUST_BACKTRACE, grabbing the environment lock, causing a deadlock.
Specifically, the changes made here are:
* The environment lock is pushed into `std::sys` instead of `std::env`. This
also only puts it in the Unix implementation, not Windows where the functions
are already threadsafe.
* The `std::sys` implementation now returns `io::Result` so panics are
explicitly at the `std::env` level.
|
|
Remove `stable` stability annotations from inherent impls
|
|
|
|
&format!("...") is the same as "" if we're not doing any interpolation,
and doesn't allocate an intermediate String.
|
|
Fixes #24591
|
|
|
|
|
|
Fixes #24591
|
|
|
|
|
|
Closes #26220.
r? @alexcrichton
|
|
Almost all operations on Path are based on the components iterator in one form
or another to handle equivalent paths. The `Hash` implementations, however,
mistakenly just went straight to the underlying `OsStr`, causing these
equivalent paths to not get merged together.
This commit updates the `Hash` implementation to also be based on the iterator
which should ensure that if two paths are equal they hash to the same thing.
cc #29008, but doesn't close it
|
|
Almost all operations on Path are based on the components iterator in one form
or another to handle equivalent paths. The `Hash` implementations, however,
mistakenly just went straight to the underlying `OsStr`, causing these
equivalent paths to not get merged together.
This commit updates the `Hash` implementation to also be based on the iterator
which should ensure that if two paths are equal they hash to the same thing.
cc #29008, but doesn't close it
|
|
Only tested on DragonFly.
|
|
Closes #26220.
|
|
Only tested on DragonFly.
|
|
Note: for now, this change only affects `-windows-gnu` builds.
So why was this `libgcc` dylib dependency needed in the first place?
The stack unwinder needs to know about locations of unwind tables of all the modules loaded in the current process. The easiest portable way of achieving this is to have each module register itself with the unwinder when loaded into the process. All modules compiled by GCC do this by calling the __register_frame_info() in their startup code (that's `crtbegin.o` and `crtend.o`, which are automatically linked into any gcc output).
Another important piece is that there should be only one copy of the unwinder (and thus unwind tables registry) in the process. This pretty much means that the unwinder must be in a shared library (unless everything is statically linked).
Now, Rust compiler tries very hard to make sure that any given Rust crate appears in the final output just once. So if we link the unwinder statically to one of Rust's crates, everything should be fine.
Unfortunately, GCC startup objects are built under assumption that `libgcc` is the one true place for the unwind info registry, so I couldn't find any better way than to replace them. So out go `crtbegin`/`crtend`, in come `rsbegin`/`rsend`!
A side benefit of this change is that rustc is now more in control of the command line that goes to the linker, so we could stop using `gcc` as the linker driver and just invoke `ld` directly.
|
|
|
|
Currently if a print happens while a thread is being torn down it may cause a
panic if the LOCAL_STDOUT TLS slot has been destroyed by that point. This adds a
guard to check and prints to the process stdout if that's the case (as we do for
if the slot is already borrowed).
Closes #29488
|
|
The "optionally" stuff just makes things confusing.
r? @steveklabnik
|
|
The "optionally" stuff just makes things confusing.
|
|
These two commits do a few things:
1. reformat to 80 cols
2. use the reference-style links where appropriate for improved in-source readability
3. adds a few links, tweaks a couple of words, `3` -> `three`, stuff like that
While the diff is big due to these edits, there's no significant content change.
r? @brson
|
|
Part of https://github.com/rust-lang/rust/issues/29330
Needed because of https://github.com/rust-lang/rust/issues/29481 and https://github.com/rust-lang/rust/issues/29483
|
|
Part of #29330
|
|
|
|
There was a bunch of manual fixes too... rustfmt isn't quite there yet
|
|
|
|
|
|
|
|
As discovered in #29298, `env::set_var("", "")` will panic, but it turns out
that it *also* deadlocks on Unix systems. This happens because if a panic
happens while holding the environment lock, we then go try to read
RUST_BACKTRACE, grabbing the environment lock, causing a deadlock.
Specifically, the changes made here are:
* The environment lock is pushed into `std::sys` instead of `std::env`. This
also only puts it in the Unix implementation, not Windows where the functions
are already threadsafe.
* The `std::sys` implementation now returns `io::Result` so panics are
explicitly at the `std::env` level. The panic messages have also been improved
in these situations.
|
