Dylan DPC [Fri, 27 Mar 2020 00:23:47 +0000 (01:23 +0100)]
Rollup merge of #69644 - ecstatic-morse:unified-dataflow-cleanup, r=eddyb
Remove framework in `dataflow/mod.rs` in favor of "generic" one
This is the culmination of the work described in rust-lang/compiler-team#202. All dataflow analyses (including the one in `clippy`) have been ported to use the framework in `dataflow/generic`, which can efficiently handle both gen/kill and generic problems. This PR moves the framework in `dataflow/generic` to `dataflow/framework`, and removes the gen/kill framework in `dataflow/mod.rs`.
More comprehensive documentation for the new framework is tracked in rust-lang/rustc-guide#564.
`clippy` will need to change the path it uses to import the dataflow analysis traits.
bors [Thu, 26 Mar 2020 12:33:18 +0000 (12:33 +0000)]
Auto merge of #70427 - Centril:rollup-lrcad2c, r=Centril
Rollup of 5 pull requests
Successful merges:
- #68004 (permit negative impls for non-auto traits)
- #70385 (Miri nits: comment and var name improvement)
- #70411 (Fix for #62691: use the largest niche across all fields)
- #70417 (parser: recover on `...` as a pattern, suggesting `..`)
- #70424 (simplify match stmt)
We actually have a surprising amount of
```rust
match expr {
$($p:pat)|+ => true,
_ => false,
}
```
While I would prefer this to be replaced with `matches!`, most cases are
fairly readable anyway so we can just let them be for now.
Rollup merge of #68004 - nikomatsakis:negative-impls, r=varkor
permit negative impls for non-auto traits
This is a prototype impl that extends `impl !Trait` beyond auto traits. It is not integrated with coherence or anything else, and hence only serves to prevent downstream impls (but not to allow downstream crates to rely on the absence of such impls for coherence purposes).
- [x] need a test that you can't rely on negative impls for coherence purposes
- [x] test that negative impls cannot specialize positive ones
- [x] test that positive impls cannot specialize negative ones
- [x] extend negative impl to `Clone` in order to fully fix #66544
- [x] and maybe make `CoerceUnsized` unsafe? -- that problem is now split out into https://github.com/rust-lang/rust/issues/68015
- [x] introduce feature flag and prepare a write-up
- [x] improve diagnostics?
Currently, there are three fields in `ModuleConfig` that dictate
how object files are emitted: `emit_obj`, `obj_is_bitcode`, and
`embed_bitcode`.
Some of the combinations of these fields are nonsensical, in particular
having both `obj_is_bitcode` and `embed_bitcode` true at the same time.
Also, currently:
- we needlessly emit and then delete a bytecode file if `obj_is_bitcode`
is true but `emit_obj` is false;
- we needlessly embed bitcode in the LLVM module if `embed_bitcode` is
true and `emit_obj` is false.
This commit combines the three fields into one, with a new type
`EmitObj` (and the auxiliary `BitcodeSection`) which can encode five
different possibilities.
In the old code, `set_flags` would set `obj_is_bitcode` and
`embed_bitcode` on all three of the configs (`modules`, `allocator`,
`metadata`) if the relevant other conditions were met, even if no object
code needed to be emitted for one or more of them. Whereas
`start_async_codegen` would set `emit_obj`, but only for those configs
that need it.
In the new code, `start_async_codegen` does all the work of setting
`emit_obj`, and it only does that for the configs that need it.
`set_flags` no longer sets anything related to object file emission.
Rollup merge of #70395 - ehuss:update-cargo, r=ehuss
Update cargo.
8 commits in 7019b3ed3d539db7429d10a343b69be8c426b576..8a0d4d9c9abc74fd670353094387d62028b40ae9
2020-03-17 21:02:00 +0000 to 2020-03-24 17:57:04 +0000
- Re-implement proc-macro feature decoupling. (rust-lang/cargo#8028)
- Remove unused transitive dependencies: miniz_oxide, adler32 (rust-lang/cargo#8023)
- Fix bug with -Zfeatures=dev_dep and `check --profile=test`. (rust-lang/cargo#8027)
- Remove Config from CompileOptions. (rust-lang/cargo#8021)
- Add `rustless.org` to documented blocklist. (rust-lang/cargo#7922)
- Print colored warnings when build script panics (rust-lang/cargo#8017)
- Do not supply --crate-version flag to rustdoc if present in RUSTDOCFLAGS (rust-lang/cargo#8014)
- Add proc-macro to index, and new feature resolver. (rust-lang/cargo#8003)
bors [Wed, 25 Mar 2020 22:56:53 +0000 (22:56 +0000)]
Auto merge of #70412 - Dylan-DPC:rollup-yuq2mfy, r=Dylan-DPC
Rollup of 5 pull requests
Successful merges:
- #69700 (Rename LayoutDetails to just Layout.)
- #70392 (Make x.py compatible with python 3.8.)
- #70406 (Clean up E0458 explanation)
- #70407 (Avoid tagging as I-nominated on toolstate breakage)
- #70409 (gitignore: allow target to be a symlink)
bors [Wed, 25 Mar 2020 19:42:22 +0000 (19:42 +0000)]
Auto merge of #70404 - Dylan-DPC:rollup-iikcm6r, r=Dylan-DPC
Rollup of 5 pull requests
Successful merges:
- #70226 (use checked casts and arithmetic in Miri engine)
- #70319 (correctly normalize constants)
- #70352 (Add long error explanation for E0710 )
- #70366 (Implement Fuse with Option)
- #70379 (fix incorrect type name in doc comments)
Dylan DPC [Wed, 25 Mar 2020 18:28:12 +0000 (19:28 +0100)]
Rollup merge of #70366 - cuviper:option-fuse, r=dtolnay
Implement Fuse with Option
The former `done` flag was roughly similar to an `Option` tag, but left
the possibity of misuse. By using a real `Option`, we can set `None`
when the iterator is exhausted, removing any way to call it again. We
also allow niche layout this way, so the `Fuse` may be smaller.
The `FusedIterator` specialization does want to ignore the possibility
of exhaustion though, so it uses `unsafe { intrinsics::unreachable() }`
to optimize that branch away. The entire `Fuse` implementation is now
isolated in its own module to contain that unsafety.
Dylan DPC [Wed, 25 Mar 2020 18:28:08 +0000 (19:28 +0100)]
Rollup merge of #70226 - RalfJung:checked, r=oli-obk
use checked casts and arithmetic in Miri engine
This is unfortunately pretty annoying because we have to cast back and forth between `u64` and `usize` more often that should be necessary, and that cast is considered fallible.
For example, should [this](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/interpret/value/enum.ConstValue.html) really be `usize`?
Also, `LayoutDetails` uses `usize` for field indices, but in Miri we use `u64` to be able to also handle array indexing. Maybe methods like `mplace_field` should be suitably generalized to accept both `u64` and `usize`?