Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rollup of 9 pull requests #41773

Merged
merged 31 commits into from
May 6, 2017
Merged

Rollup of 9 pull requests #41773

merged 31 commits into from
May 6, 2017

Conversation

GuillaumeGomez and others added 30 commits May 2, 2017 13:54
There are now two queries: crate and item. The crate one computes the
variance of all items in the crate; it is sort of an implementation
detail, and not meant to be used. The item one reads from the crate one,
synthesizing correct deps in lieu of the red-green algorithm.

At the same time, remove the `variance_computed` flag, which was a
horrible hack used to force invariance early on (e.g. when type-checking
constants). This is only needed because of trait applications, and
traits are always invariant anyway. Therefore, we now change to take
advantage of the query system:

- When asked to compute variances for a trait, just return a vector
  saying 'all invariant'.
- Remove the corresponding "inferreds" from traits, and tweak the
  constraint generation code to understand that traits are always
  inferred.
make it work for traits etc uniformly
(Now that variances are not part of signature.)
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
The only place this Python script is used is inside the libstd_unicode
crate, so lets move it there.
As discussed in rust-lang#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 rust-lang#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 rust-lang#41570.
Depends on rust-lang/libc#585.
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`.
…ewsxcv

Remove jquery dependency

r? @rust-lang/docs

Fixes rust-lang#39159.
…ck, r=BurntSushi

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
…-fail, r=alexcrichton

Reload nameserver information on lookup failure

As discussed in rust-lang#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 rust-lang#41570 for details). On systems with nscd, this should not be necessary, but not all systems run nscd.

Fixes rust-lang#41570.
Depends on rust-lang/libc#585.

r? @alexcrichton
…s, r=alexcrichton

Add option to display warnings in rustdoc

Part of rust-lang#41574.

r? @alexcrichton

The output for this file:

```rust
/// ```
/// fn foo(x: u32) {}
///
/// foo(2);
/// let x = 1;
/// panic!();
/// ```
fn foo() {}

/// ```
/// fn foo(x: u32) {}
///
/// foo(2);
/// let x = 1;
/// ```
fn foo2() {}

/// ```
/// fn foo(x: u32) {}
///
/// foo(2);
/// let x = 1;
/// panic!();
/// ```
fn foo3() {}

fn main() {
}
```

is the following:

```
> ./build/x86_64-apple-darwin/stage1/bin/rustdoc -Z unstable-options --display-warnings --test test.rs

running 3 tests
test test.rs - foo (line 1) ... FAILED
test test.rs - foo3 (line 18) ... FAILED
test test.rs - foo2 (line 10) ... ok

successes:

---- test.rs - foo2 (line 10) stdout ----
	warning: unused variable: `x`
 --> <anon>:2:8
  |
2 | fn foo(x: u32) {}
  |        ^
  |
  = note: #[warn(unused_variables)] on by default

warning: unused variable: `x`
 --> <anon>:5:5
  |
5 | let x = 1;
  |     ^
  |
  = note: #[warn(unused_variables)] on by default

successes:
    test.rs - foo2 (line 10)

failures:

---- test.rs - foo (line 1) stdout ----
	warning: unused variable: `x`
 --> <anon>:2:8
  |
2 | fn foo(x: u32) {}
  |        ^
  |
  = note: #[warn(unused_variables)] on by default

warning: unused variable: `x`
 --> <anon>:5:5
  |
5 | let x = 1;
  |     ^
  |
  = note: #[warn(unused_variables)] on by default

thread 'rustc' panicked at 'test executable failed:

thread 'main' panicked at 'explicit panic', <anon>:6
note: Run with `RUST_BACKTRACE=1` for a backtrace.

', src/librustdoc/test.rs:317
note: Run with `RUST_BACKTRACE=1` for a backtrace.

---- test.rs - foo3 (line 18) stdout ----
	warning: unused variable: `x`
 --> <anon>:2:8
  |
2 | fn foo(x: u32) {}
  |        ^
  |
  = note: #[warn(unused_variables)] on by default

warning: unused variable: `x`
 --> <anon>:5:5
  |
5 | let x = 1;
  |     ^
  |
  = note: #[warn(unused_variables)] on by default

thread 'rustc' panicked at 'test executable failed:

thread 'main' panicked at 'explicit panic', <anon>:6
note: Run with `RUST_BACKTRACE=1` for a backtrace.

', src/librustdoc/test.rs:317

failures:
    test.rs - foo (line 1)
    test.rs - foo3 (line 18)

test result: FAILED. 1 passed; 2 failed; 0 ignored; 0 measured
```
Suggest `!` for bitwise negation when encountering a `~`

Fix rust-lang#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
…iance, r=pnkfelix

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
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.
@rust-highfive
Copy link
Collaborator

Some changes occurred in HTML/CSS.

cc @GuillaumeGomez

@rust-highfive
Copy link
Collaborator

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @GuillaumeGomez (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

@frewsxcv
Copy link
Member Author

frewsxcv commented May 5, 2017

@bors r+ p=10

@bors
Copy link
Contributor

bors commented May 5, 2017

📌 Commit 5bed9dc has been approved by frewsxcv

@bors
Copy link
Contributor

bors commented May 5, 2017

⌛ Testing commit 5bed9dc with merge 42a4f37...

bors added a commit that referenced this pull request May 5, 2017
Rollup of 9 pull requests

- Successful merges: #41064, #41307, #41512, #41582, #41678, #41722, #41734, #41761, #41763
- Failed merges:
@bors
Copy link
Contributor

bors commented May 6, 2017

☀️ Test successful - status-appveyor, status-travis
Approved by: frewsxcv
Pushing 42a4f37 to master...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup
Projects
None yet
Development

Successfully merging this pull request may close these issues.