Rollup merge of #68074 - matthew-healy:skip-llvm-rebuild-option, r=Centril
Add `llvm-skip-rebuild` flag to `x.py`
This PR follows on from #67437 to complete the feature request from #65612.
Specifically it adds a new command-line flag, `--llvm-skip-rebuild`, which overrides both any value set in `config.toml` and the default value (`false`).
I'm not 100% confident that I've implemented the override in the "best" way, but I've checked it locally and it seems to work at least.
This option isn't currently mentioned in the Guide to Rustc Development. I'd be happy to write something on it if folk think that's worthwhile.
Based on https://github.com/rust-lang/rust/pull/67770.
This PR extracts a crate `rustc_ast_passes`:
- `ast_validation.rs`, which is contributed by `rustc_passes` (now only has HIR based passes) -- the goal here is to improve recompilation of the parser,
- `feature_gate.rs`, which is contributed by `syntax` and performs post-expansion-gating & final erroring for pre-expansion gating,
- `show_span`, which is contributed by `syntax`.
To facilitate this, we first have to also:
- Move `{leveled_}feature_err{_err}` from `syntax::feature_gate::check` into `rustc_session::parse`.
- Move `get_features` into `rustc_parse::config`, the only place it is used.
- Move some some lint datatypes and traits, e.g. `LintBuffer`, `BufferedEarlyLint`, `BuiltinLintDiagnostics`, `LintPass`, and `LintArray` into `rustc_session::lint`.
- Move all the hard-wired lint `static`s into `rustc_session::lint::builtin`.
bors [Fri, 10 Jan 2020 23:26:21 +0000 (23:26 +0000)]
Auto merge of #65241 - tmiasko:no-std-san, r=alexcrichton
build-std compatible sanitizer support
### Motivation
When using `-Z sanitizer=*` feature it is essential that both user code and
standard library is instrumented. Otherwise the utility of sanitizer will be
limited, or its use will be impractical like in the case of memory sanitizer.
The recently introduced cargo feature build-std makes it possible to rebuild
standard library with arbitrary rustc flags. Unfortunately, those changes alone
do not make it easy to rebuild standard library with sanitizers, since runtimes
are dependencies of std that have to be build in specific environment,
generally not available outside rustbuild process. Additionally rebuilding them
requires presence of llvm-config and compiler-rt sources.
The goal of changes proposed here is to make it possible to avoid rebuilding
sanitizer runtimes when rebuilding the std, thus making it possible to
instrument standard library for use with sanitizer with simple, although
verbose command:
```
env CARGO_TARGET_X86_64_UNKNOWN_LINUX_GNU_RUSTFLAGS=-Zsanitizer=thread cargo test -Zbuild-std --target x86_64-unknown-linux-gnu
```
### Implementation
* Sanitizer runtimes are no long packed into crates. Instead, libraries build
from compiler-rt are used as is, after renaming them into `librusc_rt.*`.
* rustc obtains runtimes from target libdir for default sysroot, so that
they are not required in custom build sysroots created with build-std.
* The runtimes are only linked-in into executables to address issue #64629.
(in previous design it was hard to avoid linking runtimes into static
libraries produced by rustc as demonstrated by sanitizer-staticlib-link
test, which still passes despite changes made in #64780).
Yuki Okushi [Fri, 10 Jan 2020 19:50:49 +0000 (04:50 +0900)]
Rollup merge of #68019 - cuviper:in-tree-compiletest, r=Mark-Simulacrum
Build compiletest with in-tree libtest
This updates compiletest to build in `Mode::ToolStd`, using the locally-built crates for `std` and especially `test`. This way we're immune to unstable differences in the bootstrap compiler crates, whether that's a prior-release stage0 or a current release local rebuild. Fixes #59264.
As a minor cleanup, this also removes the unused `llvm_tools` flag.
In this PR, we introduce range-from (`X..`), range-to (`..X`), and range-to-inclusive (`..=X`) patterns.
These correspond to the `RangeFrom`, `RangeTo`, and `RangeToInclusive` expression forms introduced with the same syntaxes. The correspondence is both syntactic and semantic (in the sense that e.g. a `X..` pattern matching on a scrutinee `s` holds exactly when `(X..).contains(&s)` holds).
---------------------------
Noteworthy:
- The compiler complexity added with this PR is around 10 lines (discounting new tests, which account for the large PR size).
- `...X` is accepted syntactically with the same meaning as `..=X`. This is done primarily to simplify and unify the implementation & spec. If-and-when we decide to make `X...Y` a hard error on a new edition, we can do the same for `...X` patterns as well.
- `X...` and `X..=` is rejected syntactically just like it is for the expression equivalents. We should perhaps make these into semantic restrictions (cc @petrochenkov).
- In HAIR, these half-open ranges are represented by inserting the max/min values for the approprate types. That is, `X..` where `X: u8` would become `X..=u8::MAX` in HAIR (note the `..=` since `RangeFrom` includes the end).
- Exhaustive integer / char matching does not (yet) allow for e.g. exhaustive matching on `0usize..` or `..5usize | 5..` (same idea for `isize`). This would be a substantially more invasive change, and could be added in some other PR.
- The issues with slice pattern syntax has been resolved as we decided to use `..` to mean a "rest-pattern" and `[xs @ ..]` to bind the rest to a name in a slice pattern.
- Like with https://github.com/rust-lang/rust/pull/35712, which provided `X..Y` range patterns, this is not yet backed up by an RFC. I'm providing this experimental implementation now to have something concrete to discuss. I would be happy to provide an RFC for this PR as well as for #35712 to finalize and confirm the ideas with the larger community.
bors [Fri, 10 Jan 2020 12:18:46 +0000 (12:18 +0000)]
Auto merge of #67397 - michaelwoerister:query-keys-in-self-profiling, r=wesleywiser
self-profiling: Support recording query keys
This PR makes self-profiling able to record query keys. The implementation is not as efficient as it could be yet (all query keys except for `DefId`s cause string data to be duplicated) and the rendered strings could be nicer too. But the implementation is functional and introduces the basic framework for emitting per-query-invocation event data.
I tried to add proper documentation on how everything works. Let me know if more documentation is needed.
r? @wesleywiser
@Mark-Simulacrum, heads up: This updates `measureme` to 0.7.0 which means that `summarize` on perf.rlo needs to be update accordingly once this is merged.
bors [Fri, 10 Jan 2020 02:09:41 +0000 (02:09 +0000)]
Auto merge of #68078 - Centril:rollup-qvq052k, r=Centril
Rollup of 6 pull requests
Successful merges:
- #66463 (Point at opaque and closure type definitions in type errors)
- #67501 (Reduce special treatment for zsts)
- #67820 (Parse the syntax described in RFC 2632)
- #67922 (rustc_ast_lowering: misc cleanup & rustc dep reductions)
- #68071 (Extend support of `_` in type parameters)
- #68073 (expect `fn` after `const unsafe` / `const extern`)
Rollup merge of #68071 - estebank:ice-67995, r=Centril
Extend support of `_` in type parameters
- Account for `impl Trait<_>`.
- Provide a reasonable `Span` for empty `Generics` in `impl`s.
- Account for `fn foo<_>(_: _) {}` to suggest `fn foo<T>(_: T) {}`.
- Fix #67995. Follow up to #67597.
Rollup merge of #67922 - Centril:lowering-cleanup, r=petrochenkov
rustc_ast_lowering: misc cleanup & rustc dep reductions
- The first two commits do some code simplification.
- The next three do some file splitting (getting `lib.rs` below the 3kloc tidy lint).
- The remaining commits reduce the number of `rustc::` imports. This works towards making lowering independent of the `rustc` crate.
Rollup merge of #67820 - ecstatic-morse:const-trait, r=oli-obk
Parse the syntax described in RFC 2632
This adds support for both `impl const Trait for Ty` and `?const Trait` bound syntax from rust-lang/rfcs#2632 to the parser. For now, both modifiers end up in a newly-added `constness` field on `ast::TraitRef`, although this may change once the implementation is fleshed out.
I was planning on using `delay_span_bug` when this syntax is encountered during lowering, but I can't write `should-ice` UI tests. I emit a normal error instead, which causes duplicates when the feature gate is not enabled (see the `.stderr` files for the feature gate tests). Not sure what the desired approach is; Maybe just do nothing when the syntax is encountered with the feature gate is enabled?
@oli-obk I went with `const_trait_impl` and `const_trait_bound_opt_out` for the names of these features. Are these to your liking?
Dylan MacKenzie [Fri, 3 Jan 2020 00:35:07 +0000 (16:35 -0800)]
Error when new syntax is lowered
This means the new syntax will always fail to compile, even when the
feature gate is enabled. These checks will be removed in a later PR
once the implementation is done.
Dylan MacKenzie [Thu, 2 Jan 2020 23:47:27 +0000 (15:47 -0800)]
Add a `constness` field to `ast::TraitRef`
This is used for both the `?const` syntax in bounds as well as the `impl
const Trait` syntax. I also considered handling these separately by
adding a variant of `TraitBoundModifier` and a field to
`ItemKind::Impl`, but this approach was less intrusive.
Esteban Küber [Thu, 9 Jan 2020 21:46:37 +0000 (13:46 -0800)]
Extend support of `_` in type parameters
- Account for `impl Trait<_>`.
- Provide a reasonable `Span` for empty `Generics` in `impl`s.
- Account for `fn foo<_>(_: _) {}` to suggest `fn foo<T>(_: T) {}`.
- Fix #67995.
Yuki Okushi [Thu, 9 Jan 2020 19:18:43 +0000 (04:18 +0900)]
Rollup merge of #68054 - tspiteri:null-unchecked-as_mut, r=cramertj
doc: add Null-unchecked version section to mut pointer as_mut method
The [`as_ref`](https://doc.rust-lang.org/std/primitive.pointer.html#method.as_ref-1) method already has a *Null-unchecked version* section, its example is a modification of the example in the main `as_ref` section. Similarly the example in this PR is a modification of the example in main [`as_mut`](https://doc.rust-lang.org/std/primitive.pointer.html#method.as_mut) section.
Yuki Okushi [Thu, 9 Jan 2020 19:18:39 +0000 (04:18 +0900)]
Rollup merge of #67975 - EmbarkStudios:export-statics-wasm, r=alexcrichton
Export public scalar statics in wasm
Fixes #67453
I am not sure which export level statics should get when exporting them in wasm. This small change fixes the issue that I had, but this might not be the correct way to implement this.
Yuki Okushi [Thu, 9 Jan 2020 19:18:34 +0000 (04:18 +0900)]
Rollup merge of #67725 - ssomers:into_key_slice_mut, r=RalfJung
Simplify into_key_slice_mut
Remove a rare and tiny but superfluous run-time check from into_key_slice_mut.
In #67459, I wrote that "`get_mut` [...] does visit `into_key_slice_mut`" and that was wrong. No function that operates on a map that (still) has a shared root ever dives into `into_key_slice_mut`. So it's more clear to remove the (previously existing, and always incomplete) code it has for dealing with shared roots, as well as a petty performance improvement for those using exotically aligned key types.
~~Also, some testing of the `range` function initially added to #67686 but hardly related.~~
Yuki Okushi [Thu, 9 Jan 2020 19:18:32 +0000 (04:18 +0900)]
Rollup merge of #67358 - cuviper:get_or_insert_owned, r=LukasKalbertodt
Add HashSet::get_or_insert_owned
This is an extension for tracking issue #60896. The more-general `get_or_insert_with` has potential for misuse, so we might remove it, but I think `get_or_insert_owned` covers most use cases.
Yuki Okushi [Thu, 9 Jan 2020 19:18:30 +0000 (04:18 +0900)]
Rollup merge of #67122 - petrochenkov:nodedup, r=estebank
Do not deduplicate diagnostics in UI tests
Error reporting infrastructure deduplicates identical diagnostics with identical spans.
While it's preferable to do this in "release"/"user-facing" mode, it sometimes brings [confusion](https://github.com/rust-lang/rust/pull/50682#issuecomment-390949878) and hides details that may be important during development.
Do we run some passes multiple times when we could do it once?
How many times we run them exactly? Can this number be large? Can the multiplied error construction be expensive? Can speculative checks be made cheaper if they don't report errors?
*Relying* on this mechanism to deduplicate some specific error never looks like a proper solution to me personally.
In this PR I attempt to disable this deduplication by applying `-Z deduplicate-diagnostics=no` to UI tests.
Yuki Okushi [Thu, 9 Jan 2020 19:18:29 +0000 (04:18 +0900)]
Rollup merge of #66254 - CAD97:patch-1, r=KodrAus
Make Layout::new const
This seems like a reasonable change to make. If we don't provide `Layout::new::<T>` as `const`, then users can just instead do the more error prone `Layout::from_size_align_unchecked(mem::size_of::<T>(), mem::align_of::<T>())` for the same effect and an extra `unsafe { }` incantation.
bors [Thu, 9 Jan 2020 16:10:01 +0000 (16:10 +0000)]
Auto merge of #68047 - pietroalbini:fix-toolstate-again, r=Mark-Simulacrum
ci: another take at fixing toolstate
Seems like the variable showed by `$(ciCheckoutPath)` on Azure Pipelines was wrong, making the toolstate script fail. This commit changes that function to return the variable previously used by the toolstate script. Other uses of the function were audited, and there should be no conflict.