Rollup merge of #66575 - Mark-Simulacrum:no-uii, r=petrochenkov
Remove pretty printing of specific nodes in AST
The ability to print a specific item as identified by NodeId or path
seems not particularly useful, and certainly carries quite a bit of
complexity with it.
This is intended to simplify our CLI parsing a bit and remove a
non-uncomplicated piece of it; I largely did this to remove the
dependency on NodeId from librustc/session but it's not really
necessary to do so in this invasive a way. The alternative is
moving it to librustc_interface or driver, probably.
Rollup merge of #66183 - Centril:empty-vis-trait-decl, r=petrochenkov
*Syntactically* permit visibilities on trait items & enum variants
Fixes #65041
Suppose we have `$vis trait_item` or `$vis enum_variant` and `$vis` is a `:vis` macro fragment. Before this PR, this would fail to parse. This is now instead allowed as per language team consensus in https://github.com/rust-lang/rust/issues/65041#issuecomment-538105286. (See added tests for elaboration.)
Moreover, we now also permit visibility modifiers on trait items & enum variants *syntactically* but reject them with semantic checks (in `ast_validation`):
Pietro Albini [Mon, 18 Nov 2019 14:34:07 +0000 (15:34 +0100)]
ci: guess some environment variables based on builder name and os
Some environment variables (like DEPLOY or DEPLOY_ALT for dist builders,
or IMAGE on Linux builders) are set on a lot of builders, and whether
they should be present or not can be detected automatically based on the
builder name and the platform.
This commit simplifies the CI configuration by automatically setting
those environment variables.
bors [Fri, 22 Nov 2019 13:54:41 +0000 (13:54 +0000)]
Auto merge of #66460 - cjgillot:hashstable_generic, r=Zoxc
Add a proc-macro to derive HashStable in librustc dependencies
A second proc-macro is added to derive HashStable for crates librustc depends on.
This proc-macro HashStable_Generic (to bikeshed) allows to decouple code and some librustc's boilerplate.
Not everything is migrated, because `Span` and `TokenKind` require to be placed inside librustc.
Types using them stay there too.
bors [Fri, 22 Nov 2019 10:33:29 +0000 (10:33 +0000)]
Auto merge of #66565 - Mark-Simulacrum:syntax-cfg-mod, r=petrochenkov
Move process_configure_mod to rustc_parse
This removes the hack in favor of perhaps a less principled, but less painful, approach.
This also supports my work to decouple `Session` from librustc, as `ParseSess` currently has `Attribute` as "part" of it but after this PR will no longer do so.
bors [Fri, 22 Nov 2019 04:06:52 +0000 (04:06 +0000)]
Auto merge of #66524 - ecstatic-morse:compiletest-multiple-revisions, r=Centril
Support multiple revisions in `compiletest`
The `//[X]~` syntax filters errors for tests that are run across multiple cfgs with `// revisions:`. This commit extends that syntax to accept `//[X,Y]~`, which will match multiple cfgs to the same error annotation. This is functionally the same as writing two comments, `//[X]~` and `//[Y]~`, but can fit on a single line.
While refactoring `compiletest` to support this, I also uncovered a small bug that was causing an incremental test to always pass, despite no errors being emitted.
Dylan MacKenzie [Mon, 18 Nov 2019 05:11:42 +0000 (21:11 -0800)]
Reorganize, bless and add tests for const control flow
This creates a new test directory, `ui/consts/control-flow` to hold
tests related to control flow in a const context. It also blesses all
existing tests with the new error messages, and adds new tests for the
`const_if_match` feature.
bors [Fri, 22 Nov 2019 00:16:40 +0000 (00:16 +0000)]
Auto merge of #66282 - Centril:simplify-try, r=oli-obk
[mir-opt] asking `?`s in a more optimized fashion
This PR works towards https://github.com/rust-lang/rust/issues/66234 by providing two optimization passes meant to run in sequence:
- `SimplifyArmIdentity` which transforms something like:
```rust
_LOCAL_TMP = ((_LOCAL_1 as Variant ).FIELD: TY );
((_LOCAL_0 as Variant).FIELD: TY) = move _LOCAL_TMP;
discriminant(_LOCAL_0) = VAR_IDX;
```
into:
```rust
_LOCAL_0 = move _LOCAL_1
```
- `SimplifyBranchSame` which transforms `SwitchInt`s to identical basic blocks into a `goto` to the first reachable target.
Together, these are meant to simplify the following into just `res`:
```rust
match res {
Ok(x) => Ok(x),
Err(x) => Err(x),
}
```
It should be noted however that the desugaring of `?` includes a function call and so the first pass in this PR relies on inlining to substitute that function call for identity on `x`. Inlining requires `mir-opt-level=2` so this might not have any effect in perf-bot but let's find out.
r? @oli-obk -- This is WIP, but I'd appreciate feedback. :)
Dylan MacKenzie [Mon, 18 Nov 2019 04:41:34 +0000 (20:41 -0800)]
Allow `Downcast` projections if `const_if_match` enabled
These are generated when matching on enum variants to extract the value
within. We should have no problem evaluating these, but care should be
taken that we aren't accidentally allowing some other operation.
Dylan MacKenzie [Mon, 18 Nov 2019 18:06:21 +0000 (10:06 -0800)]
Fix broken incremental test
This test does not actually emit any warnings, since
`#![allow(warnings)]` was specified. `compiletest` was erroneously
ignoring `//~` tests and looking only for `//[X]~` ones. As a result of
the changes in the previous commit, we now look for `//~` comments in
incremental tests and expect them to appear in *all* revisions.
Dylan MacKenzie [Sat, 16 Nov 2019 05:40:05 +0000 (21:40 -0800)]
Allow multiple cfgs per comment in "revisions:" tests
The `//[X]~` syntax filters errors for tests that are run across
multiple cfgs with `// revisions:`. This commit extends that syntax to
accept `//[X,Y]~`, which will match multiple cfgs to the same error
annotation. This is functionally the same as writing two comments,
`//[X]~` and `//[Y]~`, but can fit on a single line.
Introduce MIR optimizations for simplifying `x?` on `Result`s.
This optimization depends on inlining for the identity
conversions introduced by the lowering of the `?`.
To take advantage of `SimplifyArmIdentity`, `-Z mir-opt-level=2`
is required because that triggers the inlining MIR optimization.
bors [Thu, 21 Nov 2019 14:30:02 +0000 (14:30 +0000)]
Auto merge of #66607 - Centril:rollup-yb7cl73, r=Centril
Rollup of 5 pull requests
Successful merges:
- #65355 (Stabilize `!` in Rust 1.41.0)
- #65730 (Suggest to add lifetime constraint at explicit ouput of functions)
- #66468 (Cleanup Miri SIMD intrinsics)
- #66515 (Reduce size of `hir::Expr` by boxing more of `hir::InlineAsm`)
- #66602 (Revert "Update Source Code Pro and include italics")
Rollup merge of #65355 - Centril:almost-is-never-enough, r=oli-obk
Stabilize `!` in Rust 1.41.0
This PR stabilizes the `never_type` (written `!`). The type represents computations that we know diverge in the type system and therefore has no values / inhabitants / elements / members.
The current nightly version is 1.40.0 which will become stable on 2019-12-19.
- In #62661 we reserved `impl<T> From<!> for T` so this concern should be resolved.
- The type inference fallback change is moved to `#![feature(never_type_fallback)]` (https://github.com/rust-lang/rust/issues/65992).
- You can find all of the tests referencing `never_type` in this PR which also reorganizes these tests whereas they were more scattered before.
Aaron Hill [Thu, 21 Nov 2019 00:24:44 +0000 (19:24 -0500)]
Fix cycle when debug-printing opaque types
Fixes #61577
When printing an opaque type in non-verbose mode, we use the
`tcx.predicates_of` query to retrieve the opaque type's bounds for
pretty-printing. However, the pervasiveness of logging within librustc
means that we may already be executing `tcx.predicates_of` for the
opaque type we're trying to print, leading to a cycle error.
This commit adds a new 'no queries' thread-local flag to the pretty
printer. This flag is enabled during the computation of `predicates_of`
for opaque types, and causes us to print the opaque type in 'verbose'
mode (which does not require computing any additinal queries). This
should only affect debug logging for highly nested log messages, not any
user-visible output.
bors [Wed, 20 Nov 2019 19:15:41 +0000 (19:15 +0000)]
Auto merge of #66578 - Centril:rollup-pgz1v7t, r=Centril
Rollup of 7 pull requests
Successful merges:
- #66060 (Making ICEs and test them in incremental)
- #66298 (rustdoc: fixes #64305: disable search field instead of hidding it)
- #66457 (Just derive Hashstable in librustc)
- #66496 (rustc_metadata: Privatize more things)
- #66514 (Fix selected crate search filter)
- #66535 (Avoid ICE when `break`ing to an unreachable label)
- #66573 (Ignore run-make reproducible-build-2 on Mac)
Rollup merge of #66573 - pnkfelix:issue-66568-ignore-reproducible-build-2-on-macos, r=alexcrichton
Ignore run-make reproducible-build-2 on Mac
Ignore run-make reproducible-build-2 on Mac (we already ignore it on Windows).
Until we can dedicate resources to fixing this properly, I think we are best off just ignoring this test on platforms/contexts where it does not matter as much.
Rollup merge of #66496 - petrochenkov:metapriv2, r=eddyb
rustc_metadata: Privatize more things
Continuation of https://github.com/rust-lang/rust/pull/66056.
The most notable change here is that `CrateMetadata` is moved from `cstore.rs` to `decoder.rs`.
Most of uses of `CrateMetadata` fields are in the decoder and uses of `root: CrateRoot` and other fields are so intertwined with each other that it would be hard to move a part of them into `cstore.rs` to privatize `CrateMetadata` fields, so we are going the other way round.
`cstore.rs` can probably be dismantled now, but I'll leave this to some other day.
Similarly, remaining `CrateMetadata` fields can be privatized by introducing some getter/setter methods, but not today.
Mark Rousskov [Wed, 20 Nov 2019 13:27:42 +0000 (08:27 -0500)]
Remove pretty printing of specific nodes in AST
The ability to print a specific item as identified by NodeId or path
seems not particularly useful, and certainly carries quite a bit of
complexity with it.
That post claims that there is no clean way to check for garbage pointers, and
so this PR adopts the same solution of tentatively attempting to convert a
dererence to a string, which throws a clean exception on garbage that we can
catch and recover from.
I only made the change to vec and not the other pretty printers because I wanted
to focus my effort on the simplest thing that would resolve issue #64343. In
particular, I *considered* generalizing this fix to work on the other datatypes
in the pretty-printing support library, but I don't want to invest effort in
that until after we resolve our overall debugging support strategy; see also
issues #60826 and #65564.
Ignore run-make reproducible-build-2 on Mac (we already ignore it on Windows).
Until we can dedicate resources to fixing this properly, I think we are
best off just ignoring this test on platforms/contexts where it does not
matter as much.
Rollup merge of #66548 - lenary:riscv/disable-atomics-non-a, r=alexcrichton
[RISCV] Disable Atomics on all Non-A RISC-V targets
In a `TargetOptions` configuration, `max_atomic_width: None` causes `max_atomic_width()` to return `Some(target_pointer_width)`. So, contrary to assumptions, `max_atomic_width: None` means you do have atomic support!
RISC-V's rv32i and rv32imc do not have architectural support for atomic memory accesses of any size, because they do not include the `A` architecture extension. This means the values in the target definition should be `Some(0)`.
This bug has been observed via a build failure with oreboot/oreboot#191, where LLVM was still generating libcalls for atomic operations. According to rust-lang/compiler-builtins, "Rust only exposes atomic types on platforms that support them, and therefore does not need to fall back to software implementations." - so this PR tries to bring rustc inline with this decision.
This commit also removes the outdated bug link, which references a now irrelevant GCC bug.
I will likely also have to revisit the `min_atomic_width` of all the RISC-V targets so they are correct and match what the hardware is capable of (which is more restricted than one might imagine).
Rollup merge of #66532 - cuviper:dwarf-aranges, r=michaelwoerister
Generate DWARF address ranges for faster lookups
This adds a new option `-Zgenerate-arange-section`, enabled by default,
corresponding to LLVM's `-generate-arange-section`. This creates a
`.debug_aranges` section with DWARF address ranges, which some tools
depend on to optimize address lookups (elfutils [22288], [25173]).
This only has effect when debuginfo is enabled, and the additional data
is small compared to the other debug sections. For example, libstd.so
with full debuginfo is about 11MB, with just 61kB in aranges.
Rollup merge of #66497 - Nadrieril:fix-53820, r=varkor
Fix #53820
This fixes ICE #53820 by being more clever when matching large arrays with slice patterns.
In particular, it avoids treating large arrays like large tuples, and instead reuses the `VarLenSlice` constructor behaviour to only consider as little values as needed.
As a side-effect, such matches also get improved diagnostics, by reporting `[true, ..]` missing instead of `[true, _, _, _, _, _, _, _]`.
Rollup merge of #66478 - petrochenkov:rmplugin, r=davidtwco
rustc_plugin: Remove the compatibility shim
The compatibility crate was introduced in https://github.com/rust-lang/rust/pull/62727 to migrate Cargo and some other tools, but now it's no longer necessary.
Rollup merge of #65665 - tspiteri:italic-and-update-SourceCodePro, r=GuillaumeGomez
Update Source Code Pro and include italics
Fixes #65502.
A few notes:
* As stated in #65502, this does increase the download size.
* Since this PR changes the font set, I think docs.rs would have to be updated if this PR is merged.
* The fonts have a double extension (.ttf.woff); this is to keep the names consistent with the upstream font release which does that to distinguish these from the .otf.woff files ([Source Code Pro otf renders poorly on older Windows system apps](https://github.com/adobe-fonts/source-code-pro/issues/25#issuecomment-9019600)).