Auto merge of #51987 - nikomatsakis:nll-region-infer-scc, r=pnkfelix
nll experiment: compute SCCs instead of iterative region solving
This is an attempt to speed up region solving by replacing the current iterative dataflow with a SCC computation. The idea is to detect cycles (SCCs) amongst region constraints and then compute just one value per cycle. The graph with all cycles removed is of course a DAG, so we can then solve constraints "bottom up" once the liveness values are known.
I kinda ran out of time this morning so the last commit is a bit sloppy but I wanted to get this posted, let travis run on it, and maybe do a perf run, before I clean it up.
Auto merge of #51622 - kennytm:three-field-range-inclusive, r=SimonSapin
Change RangeInclusive to a three-field struct.
Fix #45222.
This PR also reverts #48012 (i.e. removed the `try_fold`/`try_rfold` specialization for `RangeInclusive`) because LLVM no longer has trouble recognizing a RangeInclusive loop.
Niko Matsakis [Mon, 2 Jul 2018 15:29:39 +0000 (11:29 -0400)]
compute region values using SCCs not iterative flow
The strategy is this:
- we compute SCCs once all outlives constraints are known
- we allocate a set of values **per region** for storing liveness
- we allocate a set of values **per SCC** for storing the final values
- when we add a liveness constraint to the region R, we also add it
to the final value of the SCC to which R belongs
- then we can apply the constraints by just walking the DAG for the
SCCs and union'ing the children (which have their liveness
constraints within)
There are a few intermediate refactorings that I really ought to have
broken out into their own commits:
- reverse the constraint graph so that `R1: R2` means `R1 -> R2` and
not `R2 -> R1`. This fits better with the SCC computation and new
style of inference (`->` now means "take value from" and not "push
value into")
- this does affect some of the UI tests, since they traverse the
graph, but mostly the artificial ones and they don't necessarily
seem worse
- put some things (constraint set, etc) into `Rc`. This lets us root
them to permit mutation and iteration. It also guarantees they don't
change, which is critical to the correctness of the algorithm.
- Generalize various helpers that previously operated only on points
to work on any sort of region element.
Auto merge of #52275 - alexcrichton:no-macro-use, r=nrc
rustc: Lint against `#[macro_use]` in 2018 idioms
This commit adds a lint to the compiler to warn against the `#[macro_use]`
directive as part of the `rust_2018_idioms` lint. This lint is turned off by
default and is only enabled when the `use_extern_macros` feature is also
enabled.
The lint here isn't fully fleshed out as it's just a simple warning rather than
suggestions of how to actually import the macro, but hopefully it's a good base
to start from!
Alex Crichton [Wed, 11 Jul 2018 21:25:29 +0000 (14:25 -0700)]
rustc: Lint against `#[macro_use]` in 2018 idioms
This commit adds a lint to the compiler to warn against the `#[macro_use]`
directive as part of the `rust_2018_idioms` lint. This lint is turned off by
default and is only enabled when the `use_extern_macros` feature is also
enabled.
The lint here isn't fully fleshed out as it's just a simple warning rather than
suggestions of how to actually import the macro, but hopefully it's a good base
to start from!
Auto merge of #51339 - sdroege:exact-chunks-remainder, r=alexcrichton
Add ExactChunks::remainder and ExactChunks::into_remainder
These allow to get the leftover items of the slice that are not being
iterated as part of the iterator due to not filling a complete chunk.
The mutable version consumes the slice because otherwise we would either
a) have to borrow the iterator instead of taking the lifetime of
the underlying slice, which is not what *any* of the other iterator
functions is doing, or
b) would allow returning multiple mutable references to the same data
The current behaviour of consuming the iterator is consistent with
IterMut::into_slice for the normal iterator.
----
This is related to https://github.com/rust-lang/rust/issues/47115#issuecomment-392685177 and the following comments.
While there the discussion was first about a way to get the "tail" of the iterator (everything from the slice that is still not iterated yet), this gives kind of unintuitive behaviour and is inconsistent with how the other slice iterators work.
Unintuitive because the `next_back` would have no effect on the tail (or otherwise the tail could not include the remainder items), inconsistent because a) generally the idea of the slice iterators seems to be to only ever return items that were not iterated yet (and don't provide a way to access the same item twice) and b) we would return a "flat" `&[T]` slice but the iterator's shape is `&[[T]]` instead, c) the mutable variant would have to borrow from the iterator instead of the underlying slice (all other iterator functions borrow from the underlying slice!)
As such, I've only implemented functions to get the remainder. This also allows the implementation to be completely safe still (and around slices instead of raw pointers), while getting the tail would either be inefficient or would have to be implemented around raw pointers.
- #51816 (bootstrap: write texts to a .tmp file first for atomicity)
- #51912 (impl Clone for Box<CStr>, Box<OsStr>, Box<Path>)
- #52164 (use proper footnote syntax for references)
- #52220 (Deny bare trait objects in `src/bootstrap`)
- #52276 (rustc: Verify #[proc_macro] is only a word)
- #52277 (Uncapitalize "If")
- #52287 (Deny bare trait objects in src/librustc_resolve)
- #52295 (Deny bare trait objects in src/libsyntax_ext)
- #52298 (make reference to dirs crate clickable in terminals)
Rollup merge of #51816 - nodakai:conf-py-tmpfile, r=kennytm
bootstrap: write texts to a .tmp file first for atomicity
If you are using a hard-linked file as your config.toml, this change will affect the way other instances of the file is modified.
The original version would modify all other instances whereas the new version will leave others unchanged, reducing the ref count by one.
Auto merge of #52230 - alexcrichton:attr-and-derive, r=petrochenkov
rustc: Search all derives for inert attributes
This commit fixes an apparent mistake in librustc_resolve where when the
`proc_macro` feature is enabled (or `rust_2018_preview`) the resolution of
custom attributes for custom derive was tweaked. Previously when an attribute
failed to resolve it was attempted to locate if there is a custom derive also in
scope which declares the attribute, but only the first custom derive directive
was search.
Instead this commit fixes the loop to search all custom derive invocations
looking for any which register the attribute in question.
Auto merge of #52089 - eddyb:issue-51907, r=nagisa
rustc_codegen_llvm: replace the first argument early in FnType::new_vtable.
Fixes #51907 by removing the vtable pointer before the `ArgType` is even created.
This allows any ABI to support trait object method calls, regardless of how it passes `*dyn Trait`.
Auto merge of #52268 - Mark-Simulacrum:rollup, r=Mark-Simulacrum
Rollup of 14 pull requests
Successful merges:
- #51614 (Correct suggestion for println)
- #51952 ( hygiene: Decouple transparencies from expansion IDs)
- #52193 (step_by: leave time of item skip unspecified)
- #52207 (improve error message shown for unsafe operations)
- #52223 (Deny bare trait objects in in src/liballoc)
- #52224 (Deny bare trait objects in in src/libsyntax)
- #52239 (Remove sync::Once::call_once 'static bound)
- #52247 (Deny bare trait objects in in src/librustc)
- #52248 (Deny bare trait objects in in src/librustc_allocator)
- #52252 (Deny bare trait objects in in src/librustc_codegen_llvm)
- #52253 (Deny bare trait objects in in src/librustc_data_structures)
- #52254 (Deny bare trait objects in in src/librustc_metadata)
- #52261 (Deny bare trait objects in in src/libpanic_unwind)
- #52265 (Deny bare trait objects in in src/librustc_codegen_utils)
Mark Rousskov [Wed, 11 Jul 2018 18:38:40 +0000 (12:38 -0600)]
Rollup merge of #52239 - CAD97:patch-1, r=alexcrichton
Remove sync::Once::call_once 'static bound
See https://internals.rust-lang.org/t/sync-once-per-instance/7918 for more context.
Suggested r is @alexcrichton, the one who added the `'static` bound back in 2014. I don't want to officially r? though, if the system would even let me. I'd rather let the system choose the appropriate member since it knows more than I do.
`git blame` history for `sync::Once::call_once`'s signature:
> ```text
> The second layer is the layer provided by `std::sync` which is intended to be
> the thinnest possible layer on top of `sys_common` which is entirely safe to
> use. There are a few concerns which need to be addressed when making these
> system primitives safe:
>
> * Once used, the OS primitives can never be **moved**. This means that they
> essentially need to have a stable address. The static primitives use
> `&'static self` to enforce this, and the non-static primitives all use a
> `Box` to provide this guarantee.
> ```
The author of this diff is @alexcrichton. `sync::Once` now contains only a pointer to (privately hidden) `Waiter`s, which are all stack-allocated. The `'static` bound to `sync::Once` is thus unnecessary to guarantee that any OS primitives are non-relocatable.
As the `'static` bound is not required for `sync::Once`'s operation, removing it is strictly more useful. As an example, it allows attaching a one-time operation to instances rather than only to global singletons.
Mark Rousskov [Wed, 11 Jul 2018 18:38:36 +0000 (12:38 -0600)]
Rollup merge of #52207 - RalfJung:unsafety-errors, r=estebank
improve error message shown for unsafe operations
Add a short explanation saying why undefined behavior could arise. In particular, the error many people got for "creating a pointer to a packed field requires unsafe block" was not worded great -- it lead to people just adding the unsafe block without considering if what they are doing follows the rules.
I am not sure if a "note" is the right thing, but that was the easiest thing to add...
Inspired by @gnzlbg at https://github.com/rust-lang/rust/issues/46043#issuecomment-381544673
Mark Rousskov [Wed, 11 Jul 2018 18:38:33 +0000 (12:38 -0600)]
Rollup merge of #51952 - petrochenkov:transmark, r=alexcrichton
hygiene: Decouple transparencies from expansion IDs
And remove fallback to parent modules during resolution of names in scope.
This is a breaking change for users of unstable macros 2.0 (both procedural and declarative), code like this:
```rust
#![feature(decl_macro)]
macro m($S: ident) {
struct $S;
mod m {
type A = $S;
}
}
fn main() {
m!(S);
}
```
or equivalent
```rust
#![feature(decl_macro)]
macro m($S: ident) {
mod m {
type A = $S;
}
}
fn main() {
struct S;
m!(S);
}
```
stops working due to module boundaries being properly enforced.
For proc macro derives this is still reported as a compatibility warning to give `actix_derive`, `diesel_derives` and `palette_derive` time to fix their issues.
Fixes https://github.com/rust-lang/rust/issues/50504 in accordance with [this comment](https://github.com/rust-lang/rust/issues/50504#issuecomment-399764767).
Auto merge of #51702 - ecstatic-morse:infinite-loop-detection, r=oli-obk
Infinite loop detection for const evaluation
Resolves #50637.
An `EvalContext` stores the transient state (stack, heap, etc.) of the MIRI virtual machine while it executing code. As long as MIRI only executes pure functions, we can detect if a program is in a state where it will never terminate by periodically taking a "snapshot" of this transient state and comparing it to previous ones. If any two states are exactly equal, the machine must be in an infinite loop.
Instead of fully cloning a snapshot every time the detector is run, we store a snapshot's hash. Only when a hash collision occurs do we fully clone the interpreter state. Future snapshots which cause a collision will be compared against this clone, causing the interpreter to abort if they are equal.
At the moment, snapshots are not taken until MIRI has progressed a certain amount. After this threshold, snapshots are taken every `DETECTOR_SNAPSHOT_PERIOD` steps. This means that an infinite loop with period `P` will be detected after a maximum of `2 * P * DETECTOR_SNAPSHOT_PERIOD` interpreter steps. The factor of 2 arises because we only clone a snapshot after it causes a hash collision.
This is done using the ipcd daemon. It's not exactly like unix sockets because there is not actually a physical file for the path, but it's close enough for a basic implementation :)
This allows mio-uds and tokio-uds to work with a few modifications as well, which is exciting!
Auto merge of #51230 - nikic:no-verify-lto, r=pnkfelix
Disable LLVM verification by default
Currently -Z no-verify only controls IR verification prior to LLVM codegen, while verification is performed unconditionally both before and after linking with (Thin)LTO.
Also wondering what the sentiment is on disabling verification by default (and e.g. only enabling it on ALT builds with assertions). This does not seem terribly useful outside of rustc development and it does seem to show up in profiles (at something like 3%).
**EDIT:** A table showing the various configurations and what is enabled when.
| Configuration | Dynamic verification performed | LLVM static assertions compiled in |
| --- | --- | --- |
| alt builds | | yes |
| nightly builds | | no |
| stable builds | | no |
| CI builds | | |
| dev builds in a checkout | | |
Auto merge of #51966 - alexcrichton:llvm7, r=michaelwoerister
Upgrade to LLVM's master branch (LLVM 7)
### Current status
~~Blocked on a [performance regression](https://github.com/rust-lang/rust/pull/51966#issuecomment-402320576). The performance regression has an [upstream LLVM issue](https://bugs.llvm.org/show_bug.cgi?id=38047) and has also [been bisected](https://reviews.llvm.org/D44282) to an LLVM revision.~~
Ready to merge!
---
This commit upgrades the main LLVM submodule to LLVM's current master branch.
The LLD submodule is updated in tandem as well as compiler-builtins.
Along the way support was also added for LLVM 7's new features. This primarily
includes the support for custom section concatenation natively in LLD so we now
add wasm custom sections in LLVM IR rather than having custom support in rustc
itself for doing so.
Some other miscellaneous changes are:
* We now pass `--gc-sections` to `wasm-ld`
* The optimization level is now passed to `wasm-ld`
* A `--stack-first` option is passed to LLD to have stack overflow always cause
a trap instead of corrupting static data
* The wasm target for LLVM switched to `wasm32-unknown-unknown`.
* The syntax for aligned pointers has changed in LLVM IR and tests are updated
to reflect this.
* ~~The `thumbv6m-none-eabi` target is disabled due to an [LLVM bug][llbug]~~
Nowadays we've been mostly only upgrading whenever there's a major release of
LLVM but enough changes have been happening on the wasm target that there's been
growing motivation for quite some time now to upgrade out version of LLD. To
upgrade LLD, however, we need to upgrade LLVM to avoid needing to build yet
another version of LLVM on the builders.
The revision of LLVM in use here is arbitrarily chosen. We will likely need to
continue to update it over time if and when we discover bugs. Once LLVM 7 is
fully released we can switch to that channel as well.
projects / rust.git / log