Windows historically has problems with threads panicking and the main thread
exiting at the same time, typically causing deadlocks. In the past (#25824)
we've joined on threads but this just prevents running the test for now to avoid
tampering with the example.
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.
Since LLVM doesn't vectorize the loop for us, do unaligned reads
of a larger type and use LLVM's bswap intrinsic to do the
reversing of the actual bytes. cfg!-restricted to x86 and
x86_64, as I assume it wouldn't help on things like ARMv5.
Also makes [u16]::reverse() a more modest 1.5x faster by
loading/storing u32 and swapping the u16s with ROT16.
Thank you ptr::*_unaligned for making this easy :)
On recursive types of infinite size, point at all the fields that make
the type recursive.
```rust
struct Foo {
bar: Bar,
}
struct Bar {
foo: Foo,
}
```
outputs
```
error[E0072]: recursive type `Foo` has infinite size
--> file.rs:1:1
1 | struct Foo {
| _^ starting here...
2 | | bar: Bar,
| | -------- recursive here
3 | | }
| |_^ ...ending here: recursive type has infinite size
|
= help: insert indirection (e.g., a `Box`, `Rc`, or `&`) at some point to make `Foo` representable
error[E0072]: recursive type `Bar` has infinite size
--> file.rs:5:1
|
5 | struct Bar {
| _^ starting here...
6 | | foo: Foo,
| | -------- recursive here
7 | | }
| |_^ ...ending here: recursive type has infinite size
|
= help: insert indirection (e.g., a `Box`, `Rc`, or `&`) at some point to make `Bar` representable
```
Remove use of `Self: Sized` from libsyntax
The bound is not required for compiling but it prevents using `next_token()` from a trait object.
Fixes#33506.
rustc: Forbid `-Z` flags on stable/beta channels
First deprecated in rustc 1.8.0 the intention was to never allow `-Z` flags make
their way to the stable channel (or unstable options). After a year of warnings
we've seen one of the main use cases, `-Z no-trans`, stabilized as `cargo
check`. Otherwise while other use cases remain the sentiment is that now's the
time to start forbidding `-Z` by default on stable/beta.
Closes#31847
This commit stabilizes the `crt-static` feature accepted by the compiler. Note
that this does not stabilize the `#[cfg]` attribute for `crt-static` as
that's going to be covered by #29717. This only stabilizes a few small pieces:
* The `crt-static` feature as accepted by the `-C target-feature` flag, and its
connection with the platform-specific definition of `crt-static`.
* The semantics of `--print cfg` printing out activated `crt-static` feature, if
available.
This should be enough to get the benefits of `crt-static` on stable Rust with
MSVC and with musl, but sidsteps the issue of stabilizing #29717 first.
Closes#37406
Major difference is that I removed Deref impls, as apparently LLVM has
trouble maintaining metadata with a `&ptr -> &ptr` API. This was cited
as a blocker for ever stabilizing this API. It wasn't that ergonomic
anyway.
* Added `get` to NonZero to replace Deref impl
* Added `as_ptr` to Shared/Unique to replace Deref impl
* Added Unique's `as_ref` and `as_mut` conveniences to Shared
* Added `::empty()` convenience constructor for Unique/Shared
* Deprecated `as_mut_ptr` on Shared in favour of `as_ptr`
* Improved documentation of types
Note that Shared now only refers to *mut, and not *const
First deprecated in rustc 1.8.0 the intention was to never allow `-Z` flags make
their way to the stable channel (or unstable options). After a year of warnings
we've seen one of the main use cases, `-Z no-trans`, stabilized as `cargo
check`. Otherwise while other use cases remain the sentiment is that now's the
time to start forbidding `-Z` by default on stable/beta.
Closes#31847
Run non-native tests on real device
After #40733, I've made some hacks to the QEMU client-server tools to allow running the tests on a real device when cross compiling Rust. The address and port of the remote server can be set using an environment variable.
I've made this mainly for local testing purposes, if you're interested in merging this, I'd clean it a bit more (eg. renaming the functions from `qemu-` to something else). I'm not asking for CI integration or adding ARM boards to the build system; it's just that I used these modifications and I was wondering if you'd find them useful too.
Remove obsolete --disable-elf-tls configure switch.
Support for disabling ELF-style thread local storage in
the standard library at configure time was removed in
pulls #30417 and #30678, in favour of a member in
the TargetOptions database. The new mentod respects
MACOSX_DEPLOYMENT_TARGET on macOS, addressing the
original use case for this configure optionl
However, those commits left the configure option itself
in place. It's no longer referenced anywhere and can
be removed.
Remove ast-ty-to-ty cache
As discussed on IRC, this basically just removes the cache, and rewrites rustdoc and save-analysis so call into the astconv code. It *might* make sense for this to be a more fine-grained query, but that would (at least) require us to be using `HirId` and not `NodeId`.
(Perhaps I should open a FIXME?)
I didn't measure perf impact (yet?). I did observe that the cache seems to hit *rarely* -- and only in between items (I experimented with a cache "per def-id", but that had zero hits). In other words, every single hit on the cache is a dependency bug, since it is "shuttling" information between items without dependency edges.
r? @eddyb
