Corey Farwell [Fri, 5 May 2017 21:35:29 +0000 (17:35 -0400)]
Rollup merge of #41734 - nikomatsakis:incr-comp-refactor-variance, 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
Corey Farwell [Fri, 5 May 2017 21:35:28 +0000 (17:35 -0400)]
Rollup merge of #41722 - F001:warnTilde, r=petrochenkov
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
```
Corey Farwell [Fri, 5 May 2017 21:35:26 +0000 (17:35 -0400)]
Rollup merge of #41582 - jonhoo:reread-nameservers-on-lookup-fail, 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.
Corey Farwell [Fri, 5 May 2017 21:35:25 +0000 (17:35 -0400)]
Rollup merge of #41512 - alexcrichton:fix-windows-tls-deadlock, 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!
Corey Farwell [Fri, 5 May 2017 21:35:24 +0000 (17:35 -0400)]
Rollup merge of #41064 - Gankro:ptr-redux, r=alexcrichton
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`.
bors [Fri, 5 May 2017 20:44:15 +0000 (20:44 +0000)]
Auto merge of #41769 - alexcrichton:fix-doc-test, r=aturon
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.
Alex Crichton [Fri, 5 May 2017 14:02:48 +0000 (07:02 -0700)]
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.
Alex Crichton [Mon, 24 Apr 2017 18:34:16 +0000 (11:34 -0700)]
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!
Jon Gjengset [Thu, 27 Apr 2017 16:58:52 +0000 (12:58 -0400)]
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.
Introduces an std linkage dependency on libresolv on macOS/iOS (which
also makes it necessary to update run-make/tools.mk).
Corey Farwell [Fri, 5 May 2017 01:35:28 +0000 (21:35 -0400)]
Rollup merge of #41741 - rap2hpoutre:patch-3, r=steveklabnik
join method returns a thread::Result
Join method returns a std::thread::Result, not a std::result::Result: https://doc.rust-lang.org/std/thread/struct.JoinHandle.html#method.join Maybe I misunderstood something.
I have seen this mistake(?) because I wanted to tackle this issue https://github.com/rust-lang/rust/issues/29378 (about Result). It's still one of my first PR. Sorry if I missed something.
bors [Fri, 5 May 2017 01:00:13 +0000 (01:00 +0000)]
Auto merge of #41751 - alexcrichton:unstable-flags, r=eddyb
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.
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
Alex Crichton [Thu, 4 May 2017 16:34:44 +0000 (09:34 -0700)]
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.
bors [Thu, 4 May 2017 14:50:33 +0000 (14:50 +0000)]
Auto merge of #41268 - mmatyas:test_on_device, r=alexcrichton
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.
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.
bors [Thu, 4 May 2017 09:15:23 +0000 (09:15 +0000)]
Auto merge of #41733 - nikomatsakis:incr-comp-remove-ast-ty-to-ty-cache, r=eddyb
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.
Corey Farwell [Wed, 3 May 2017 22:34:01 +0000 (18:34 -0400)]
Rollup merge of #41715 - martinhath:master, r=aturon
Fix @martinhath's mailmap entry
I stumbled upon a name duplication issue in [rust-lang-nursery/thanks](https://github.com/rust-lang-nursery/thanks/), and realized that this problem is easily fixable. I've (hopefully) done the right thing here. It works locally (`git shortlog | grep "Thoresen"` only returns one entry instead of two).
I didn't bother creating an issue in the `thanks` repository, since I did the `.mailmap` editing myself.
Niko Matsakis [Mon, 24 Apr 2017 15:15:12 +0000 (11:15 -0400)]
factor variances into a proper query
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.
bors [Wed, 3 May 2017 06:04:12 +0000 (06:04 +0000)]
Auto merge of #41713 - cuviper:cmake-sanitizers, r=alexcrichton
rustbuild: Sanity-check cmake for sanitizers too
It's possible to build the sanitizers when using an external LLVM, but
we still need cmake for this. Extend the sanity check to look for cmake
whenever sanitizers are enabled too.
Corey Farwell [Wed, 3 May 2017 01:21:22 +0000 (21:21 -0400)]
Rollup merge of #41657 - malbarbo:android-armv7-linker, r=alexcrichton
Add -march=armv7-a parameter to armv7 android linker
Without this option, the linker fails to link any library that uses `std::future`. The error points some undefined references, like `std::__future_base::_Result_base`.
For example, it fails to link rustc because llvm 4.0 uses `std::future`.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64735
Corey Farwell [Wed, 3 May 2017 01:21:20 +0000 (21:21 -0400)]
Rollup merge of #41653 - achernyak:master, r=nikomatsakis
Queries for Crate Metadata
This resolves following parts of #41417:
* `fn stability(&self, def: DefId) -> Option<attr::Stability>;`
* `fn deprecation(&self, def: DefId) -> Option<attr::Deprecation>;`
Corey Farwell [Wed, 3 May 2017 01:21:19 +0000 (21:21 -0400)]
Rollup merge of #41640 - gaurikholkar:master, r=nikomatsakis
Consider changing to & for let bindings #40402
This is a fix for #40402
For the example
```
fn main() {
let v = vec![String::from("oh no")];
let e = v[0];
}
```
It gives
```
error[E0507]: cannot move out of indexed content
--> ex1.rs:4:13
|
4 | let e = v[0];
| ^^^^ cannot move out of indexed content
|
= help: consider changing to `&v[0]`
error: aborting due to previous error
```
Another alternative is
```
error[E0507]: cannot move out of indexed content
--> ex1.rs:4:13
|
4 | let e = v[0];
| ^^^^ consider changing to `&v[0]`
error: aborting due to previous error
```
Also refer to #41564 for more details.
Corey Farwell [Wed, 3 May 2017 01:21:18 +0000 (21:21 -0400)]
Rollup merge of #41625 - nikomatsakis:incr-comp-dep-tracking-cell-mir, r=eddyb
rework the queries for the MIR pipeline
This PR refashions the MIR pipeline. There are a number of changes:
* We no longer have "MIR passes" and the pass manager is completely reworked. Unless we are doing the interprocedural optimization (meaning, right now, the inline pass), we will process a single MIR from beginning to finish in a completely on-demand fashion; i.e., when you request `optimized_mir(D)`, that will trigger the MIR for `D` to actually be built and optimized, but no other functions are built or touched.
* We no longer use `&'tcx RefCell<Mir<'tcx>>` as the result of queries, since that spoils the view of queries as "pure functions". To avoid however copying the MIR, we use a `&'tcx Steal<Mir<'tcx>>` -- this is something like a ref-cell, in that you can use `borrow()` to read it, but it has no `borrow_mut()`. Instead, it has `steal()`, which will take the contents and then panic if any further read attempt occurs.
* We now support `[multi]` queries, which can optionally yield not just one result but a sequence of (K, V) pairs. This is used for the inlining pass. If inlining is enabled, then when it is invoked on **any** def-id D, it will go and read the results for **all** def-ids and transform them, and then return the results for all of them at once. This isn't ideal, and we'll probably want to rework this further, but it seems ok for now (note that MIR inlining is not enabled by default).
**Tips for the reviewer:** The commits here are meant to build individually, but the path is a *bit* meandering. In some cases, for example, I introduce a trait in one commit, and then tweak it in a later commit as I actually try to put it to use. You may want to read the README in the final commit to get a sense of where the overall design is headed.
@eddyb I did not wind up adding support for queries that produce more than one *kind* of result. Instead, I decided to just insert judicious use of the `force()` command. In other words, we had talked about e.g. having a query that produced not only the MIR but also the `const_qualif` result for the MIR in one sweep. I realized you can also have the same effect by having a kind of meta-query that forces the const-qualif pass and then reads the result. See the README for a description. (We can still do these "multi-query results" later if we want, I'm not sure though if it is necessary.)
r? @eddyb
cc @michaelwoerister @matthewhammer @arielb1, who participated in the IRC discussion.
bors [Wed, 3 May 2017 00:18:26 +0000 (00:18 +0000)]
Auto merge of #41624 - RalfJung:mutexguard-sync, r=alexcrichton
MutexGuard<T> may be Sync only if T is Sync
Fixes #41622
This is a breaking change. Does that imply any further process?
I am not sure whether I wrote that "compilation must fail"-test correctly, but at least it is passing here with the patch applied. Same for the `since = "1.18.0"`, I just picked it because I had to pick something.
bors [Tue, 2 May 2017 20:44:03 +0000 (20:44 +0000)]
Auto merge of #41605 - tschottdorf:param-env, r=nikomatsakis
Store interned predicates in ParameterEnvironment
See #41444. As a first step towards untangling `ParameterEnvironment`, change
its `caller_bounds` field from a `Vec` into an interned slice of
`ty::Predicate`s.
This change is intentionally well-contained and doesn't pull on any of the
loose ends. In particular, you'll note that `normalize_param_env_or_error`
now interns twice.