Fix "an" usage
Since the pr i reviewed on got merged way before the author had a chance to quickly change it, i just did it myself. (Or well, someone else asked me to, if you want me to be honest)
Add an example to std:🧵:Result type
This PR is a part of https://github.com/rust-lang/rust/issues/29378. I submit this PR with the help (mentoring) of @steveklabnik. I'm still not sure my request is good enough but I don't want to spoil the issue with too much questions so I continue here. r? @steveklabnik
Move unicode Python script into libstd_unicode crate.
The only place this Python script is used is inside the libstd_unicode
crate, so lets move it there.
Refactor variance and remove last `[pub]` map
This PR refactors variance to work in a more red-green friendly way. Because red-green doesn't exist yet, it has to be a bit hacky. The basic idea is this:
- We compute a big map with the variance for all items in the crate; when you request variances for a particular item, we read it from the crate
- We now hard-code that traits are invariant (which they are, for deep reasons, not gonna' change)
- When building constraints, we compute the transitive closure of all things within the crate that depend on what using `TransitiveRelation`
- this lets us gin up the correct dependencies when requesting variance of a single item
Ah damn, just remembered, one TODO:
- [x] Update the variance README -- ah, I guess the README updates I did are sufficient
r? @michaelwoerister
Suggest `!` for bitwise negation when encountering a `~`
Fix#41679
Here is a program
```rust
fn main() {
let x = ~1;
}
```
It's output:
```
error: `~` can not be used as an unary operator
--> /home/fcc/temp/test.rs:4:13
|
4 | let x = ~1;
| ^^
|
= help: use `!` instead of `~` if you meant to bitwise negation
```
cc @bstrie
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
std: Avoid locks during TLS destruction on Windows
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
refactor NonZero, Shared, and Unique APIs
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 `ptr` getter to Shared/Unique to replace Deref impl
* Added Unique's `get` and `get_mut` conveniences to Shared
* Deprecated `as_mut_ptr` on Shared in favour of `ptr`
Note that Shared used to primarily expose only `*const` but there isn't
a good justification for that, so I made it `*mut`.
std: Prevent deadlocks in doctests on Windows
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.
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
```
