| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Fixes #43649
|
|
|
|
|
|
This breaks the "single syscall rule", but it's really annoying to hand
write and is pretty foundational.
|
|
rustc: Enable #[thread_local] for Windows
I think LLVM has had support for quite some time now for this, we just never got
around to testing it out and binding it. We've had some trouble landing this in
the past I believe, but it's time to try again!
This commit flags the `#[thread_local]` attribute as being available for Windows
targets and adds an implementation of `register_dtor` in the `thread::local`
module to ensure we can destroy these keys. The same functionality is
implemented in clang via a function called `__tlregdtor` (presumably provided in
some Windows runtime somewhere), but this function unfortunately does not take a
data pointer (just a thunk) which means we can't easily call it. For now
destructors are just run in the same way the Linux fallback is implemented,
which is just keeping track via a single OS-based TLS key.
|
|
I think LLVM has had support for quite some time now for this, we just never got
around to testing it out and binding it. We've had some trouble landing this in
the past I believe, but it's time to try again!
This commit flags the `#[thread_local]` attribute as being available for Windows
targets and adds an implementation of `register_dtor` in the `thread::local`
module to ensure we can destroy these keys. The same functionality is
implemented in clang via a function called `__tlregdtor` (presumably provided in
some Windows runtime somewhere), but this function unfortunately does not take a
data pointer (just a thunk) which means we can't easily call it. For now
destructors are just run in the same way the Linux fallback is implemented,
which is just keeping track via a single OS-based TLS key.
|
|
Replaced by adding extra imports, adding hidden code (`# ...`), modifying
examples to be runnable (sorry Homura), specifying non-Rust code, and
converting to should_panic, no_run, or compile_fail.
Remaining "```ignore"s received an explanation why they are being ignored.
|
|
This is an API that allows types to indicate that they can be passed
buffers of uninitialized memory which can improve performance.
|
|
Fixes #38879
|
|
Improve docs in os::windows::ffi and os::windows::fs
Part of #29367
This PR makes changes to the documentation in `os::windows::ffi` and `os::windows::fs` with the goal of fleshing them out and bringing them in line with Rust's quality standards.
r? @steveklabnik
|
|
When `RUST_BACKTRACE=1`, remove all frames after
`__rust_maybe_catch_panic`. Tested on `main`, threads, tests and
benches. Cleaning of the top of the stacktrace is let to a future PR.
Fixes #40201
See #41815
|
|
|
|
|
|
r=alexcrichton
Reload nameserver information on lookup failure
As discussed in #41570, UNIX systems often cache the contents of `/etc/resolv.conf`, which can cause lookup failures to persist even after a network connection becomes available. This patch modifies lookup_host to force a reload of the nameserver entries following a lookup failure. This is in line with what many C programs already do (see #41570 for details). On systems with nscd, this should not be necessary, but not all systems run nscd.
Fixes #41570.
Depends on rust-lang/libc#585.
r? @alexcrichton
|
|
Gecko recently had a bug reported [1] with a deadlock in the Rust TLS
implementation for Windows. TLS destructors are implemented in a sort of ad-hoc
fashion on Windows as it doesn't natively support destructors for TLS keys. To
work around this the runtime manages a list of TLS destructors and registers a
hook to get run whenever a thread exits. When a thread exits it takes a look at
the list and runs all destructors.
Unfortunately it turns out that there's a lock which is held when our "at thread
exit" callback is run. The callback then attempts to acquire a lock protecting
the list of TLS destructors. Elsewhere in the codebase while we hold a lock over
the TLS destructors we try to acquire the same lock held first before our
special callback is run. And as a result, deadlock!
This commit sidesteps the issue with a few small refactorings:
* Removed support for destroying a TLS key on Windows. We don't actually ever
exercise this as a public-facing API, and it's only used during `lazy_init`
during racy situations. To handle that we just synchronize `lazy_init`
globally on Windows so we never have to call `destroy`.
* With no need to support removal the global synchronized `Vec` was tranformed
to a lock-free linked list. With the removal of locks this means that
iteration no long requires a lock and as such we won't run into the deadlock
problem mentioned above.
Note that it's still a general problem that you have to be extra super careful
in TLS destructors. For example no code which runs a TLS destructor on Windows
can call back into the Windows API to do a dynamic library lookup. Unfortunately
I don't know of a great way around that, but this at least fixes the immediate
problem that Gecko was seeing which is that with "well behaved" destructors the
system would still deadlock!
[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1358151
|
|
As discussed in #41570, UNIX systems often cache the contents of
/etc/resolv.conf, which can cause lookup failures to persist even after
a network connection becomes available. This patch modifies lookup_host
to force a reload of the nameserver entries following a lookup failure.
This is in line with what many C programs already do (see #41570 for
details). On systems with nscd, this should not be necessary, but not
all systems run nscd.
Introduces an std linkage dependency on libresolv on macOS/iOS (which
also makes it necessary to update run-make/tools.mk).
Fixes #41570.
Depends on rust-lang/libc#585.
|
|
It was discovered #40264 that this backtrace pruning logic is a little too
aggressive, so while we figure how out to handle #40264 this commit backs out
the changes to prune frames. Note that other cosmetic changes, such as better
path printing and such remain.
|
|
documentation to channel() and sync_channel(); adding more links #29377
|
|
Fixes #40149
|
|
|
|
std: remove a workaround for privacy limitations
`std::thread::Thread` implements a non-exported `NewThread` trait to allow for internal-only use of `Thread::new`. Nowadays we have `pub(crate)`, which accomplishes the same thing but much more idiomatically.
Rustdoc handles this correctly (I checked and I didn't see `Thread::new` on the rustdoc entry for `Thread` with this change), and the stage1 `rustc` emits the correct error still (I'm assuming that the stage1 compiler uses my `libstd`?):
```
$ ./build/x86_64-apple-darwin/stage1/bin/rustc test.rs
error: method `new` is private
--> test.rs:4:18
|
4 | let thread = thread::Thread::new(None);
| ^^^^^^^^^^^^^^^^^^^
error: aborting due to previous error
```
|
|
Leftovers from #39594; From<Box> impls
These are a few more impls that follow the same reasoning as those from #39594.
What's included:
* `From<Box<str>> for String`
* `From<Box<[T]>> for Vec<T>`
* `From<Box<CStr>> for CString`
* `From<Box<OsStr>> for OsString`
* `From<Box<Path>> for PathBuf`
* `Into<Box<str>> for String`
* `Into<Box<[T]>> for Vec<T>`
* `Into<Box<CStr>> for CString`
* `Into<Box<OsStr>> for OsString`
* `Into<Box<Path>> for PathBuf`
* `<Box<CStr>>::into_c_string`
* `<Box<OsStr>>::into_os_string`
* `<Box<Path>>::into_path_buf`
* Tracking issue for latter three methods + three from previous PR.
Currently, the opposite direction isn't doable with `From` (only `Into`) because of the separation between `liballoc` and `libcollections`. I'm holding off on those for a later PR.
|
|
|
|
OsString::shrink_to_fit.
Considering how the other capacity-related methods are there, I found it odd that this one wasn't included.
Will create a tracking issue once I get an OK on this.
|
|
|
|
|
|
This change introduces a Dockerfile and script which builds a complete
Fuchsia toolchain which can be used to build Rust distribution for
Fuchsia. We only support cross-compiling at the moment, hence only
setting the target.
|
|
Add missing url in sync structs
r? @frewsxcv
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- `RUST_BACKTRACE=full` prints all the informations (old behaviour)
- `RUST_BACKTRACE=(0|no)` disables the backtrace.
- `RUST_BACKTRACE=<everything else>` (including `1`) shows a simplified
backtrace, without the function addresses and with cleaned filenames
and symbols. Also removes some unneded frames at the beginning and the
end.
Fixes #37783.
PR is #38165.
|
|
|
|
These are all now no longer needed that we've only got rustbuild in tree.
|
|
Add peek APIs to std::net
Adds "peek" APIs to `std::net` sockets, including:
- `UdpSocket.peek()`
- `UdpSocket.peek_from()`
- `TcpStream.peek()`
These methods enable socket reads without side-effects. That is, repeated calls to `peek()` return identical data. This is accomplished by providing the POSIX flag `MSG_PEEK` to the underlying socket read operations.
This also moves the current implementation of `recv_from` out of the platform-independent `sys_common` and into respective `sys/windows` and `sys/unix` implementations. This allows for more platform-dependent implementations where necessary.
Fixes #38980
|
|
These methods enable socket reads without side-effects. That is,
repeated calls to peek() return identical data. This is accomplished
by providing the POSIX flag MSG_PEEK to the underlying socket read
operations.
This also moves the current implementation of recv_from out of the
platform-independent sys_common and into respective sys/windows and
sys/unix implementations. This allows for more platform-dependent
implementations.
|
|
|
|
This is done by adding a function that can return a filename
to pass to backtrace_create_state. The filename is obtained in
a safe way by first getting the filename, locking the file so it can't
be moved, and then getting the filename again and making sure it's the same.
See: https://github.com/rust-lang/rust/pull/37359#issuecomment-260123399
Issue: #33985
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Make the directory structure reflect the module structure. I've always
found the existing structure confusing.
|
