Changes:
````
travis: temporarily disable rustfmt ci check until #4742 is resolved
rustup https://github.com/rust-lang/rust/pull/65792/
Fix ICE #4579
Add regression test for ICE #4579
Run update_lints for Unicode lint
Re-add false positive check
Add raw string regression test for useless_format lint
Re-factor useless_format lint
Update Unicode lint tests
[Backported] Rustup to https://github.com/rust-lang/rust/pull/59545
````
It seems that `eval_always` was mistakenly(?) added to `const_field` and then it ended up on `const_caller_location` (which is used much more often than `const_field` is).
bors [Tue, 29 Oct 2019 07:38:50 +0000 (07:38 +0000)]
Auto merge of #65435 - michaelwoerister:fix-issue-64153, r=alexcrichton
Fix #64153
This PR changes how the compiler detects if an object file from an upstream crate is a Rust object file or not. Instead of checking if the name starts with the crate name and ends with `.o` (which is not always the case, as described in #64153), it now just checks if the filename ends with `.rcgu.o`.
This fixes #64153. However, ideally we'd clean up the code around filename generation some more. Then this check could be made more robust.
bors [Tue, 29 Oct 2019 04:12:23 +0000 (04:12 +0000)]
Auto merge of #65919 - Centril:rollup-qrgwnt6, r=Centril
Rollup of 5 pull requests
Successful merges:
- #65294 (Lint ignored `#[inline]` on function prototypes)
- #65318 (Call out the types that are non local on E0117)
- #65531 (Update backtrace to 0.3.40)
- #65562 (Improve the "try using a variant of the expected type" hint.)
- #65809 (Add new EFIAPI ABI)
Rollup merge of #65809 - roblabla:eficall-abi, r=nagisa
Add new EFIAPI ABI
Fixes #54527
Adds a new ABI, "efiapi", which reflects the calling convention as specified by [the current spec UEFI spec](https://uefi.org/sites/default/files/resources/UEFI%20Spec%202_7_A%20Sept%206.pdf#G6.999903). When compiling for x86_64, we should select the `win64` ABI, while on all other architectures (Itanium, x86, ARM and ARM64 and RISC-V), we should select the `C` ABI.
Currently, this is done by just turning it into the C ABI everywhere except on x86_64, where it's turned into the win64 ABI. Should we prevent this ABI from being used on unsupported architectures, and if so, how would this be done?
- Adds a `unused_attribute` lint for `#[inline]` on function prototypes.
- As a consequence, foreign items, impl items and trait items now have their attributes checked, which could cause some code to no longer compile (it was previously erroneously ignored).
bors [Mon, 28 Oct 2019 20:59:36 +0000 (20:59 +0000)]
Auto merge of #65907 - Centril:rollup-9i8ev23, r=Centril
Rollup of 9 pull requests
Successful merges:
- #65563 (Add long error explanation for E0587)
- #65640 (Use heuristics to recover parsing of missing `;`)
- #65643 (Correct handling of type flags with `ConstValue::Placeholder`)
- #65825 (rustc: use IndexVec<DefIndex, T> instead of Vec<T>.)
- #65858 (suggest `const_in_array_repeat_expression` flag)
- #65877 (doc: introduce `once` in `iter::chain` document)
- #65887 (doc: mention `get(_mut)` in Vec)
- #65891 (self-profiling: Record something more useful for crate metadata generation event.)
- #65893 (Output previous stable error messaging when using stable build.)
Rollup merge of #65893 - jafern14:let-expr-stable-error-messaging, r=Centril
Output previous stable error messaging when using stable build.
Fixes #65254
As I had mentioned previously there I have the logic running right now however I'm not getting the exact same syntax highlighting as there was originally for this error.
I'm currently getting the following:
```
error: expected expression, found statement (`let`)
--> src/main.rs:2:14
|
2 | let x = (let y = 6);
| ^^^^^^^^^
|
= note: variable declaration using `let` is a statement
```
I'd like to get the following instead:
```
| let x = (let y = 6);
| ^^^
```
My current understanding is that the `span` being passed into `lower_expr_let` is coming from `lowering.rs`. I still don't know how the byte range is calculated for the erroneous syntax and need to look into it a bit more. In the meantime does anybody have any hints/tips regarding this??
Rollup merge of #65891 - michaelwoerister:sp-crate-metadata, r=wesleywiser
self-profiling: Record something more useful for crate metadata generation event.
Before this commit, we had an event that would only track the compression step
for proc-macros and Rust dylibs. After the commit we measure the time for
acutally generating the crate metadata bytes.
Rollup merge of #65858 - davidtwco:rfc-2203-feature-gate-in-error, r=ecstatic-morse
suggest `const_in_array_repeat_expression` flag
This PR adds a suggestion to add the `#![feature(const_in_array_repeat_expression)]` attribute to the crate when a promotable expression is used in a repeat expression and the feature gate is not enabled.
Unfortunately, this ended up being a little bit more complex than I anticipated, which may not have been worth it given that this would all be removed when the feature is stabilized. However, with #65732 and #65737 being open, and the feature gate having not been being suggested to potential users, the feature might not be stabilized in a while, so maybe this is worth landing.
cc @Centril (addresses [this comment](https://github.com/rust-lang/rust/pull/61749#discussion_r307863857))
r? @ecstatic-morse (opened issues related to RFC 2203 recently)
Changes:
````
travis: temporarily disable rustfmt ci check until #4742 is resolved
rustup https://github.com/rust-lang/rust/pull/65792/
Fix ICE #4579
Add regression test for ICE #4579
Run update_lints for Unicode lint
Re-add false positive check
Add raw string regression test for useless_format lint
Re-factor useless_format lint
Update Unicode lint tests
[Backported] Rustup to https://github.com/rust-lang/rust/pull/59545
````
David Wood [Sat, 26 Oct 2019 22:59:24 +0000 (23:59 +0100)]
suggest `const_in_array_repeat_expression` flag
This commit adds a suggestion to add the
`#![feature(const_in_array_repeat_expression)]` attribute to the crate
when a promotable expression is used in a repeat expression.
bors [Mon, 28 Oct 2019 17:17:30 +0000 (17:17 +0000)]
Auto merge of #65202 - pietroalbini:scriptify-ci-config, r=alexcrichton
ci: move most of the prepare config into scripts
This PR moves most of the configuration from the CI yamls into bash scripts, driven by a small Python script (which understands and emulates the two `##vso[` commands we use).
There are two reasons why we'd want to do this:
* Being able to prepare the build environment locally by just running `src/ci/prepare.py` simplifies a lot setting up a local VM similar to CI (software pre-installed in the CI images won't be prepared, but it's a start anyway).
* When we'll switch to GitHub Actions we'll need to either duplicate code in multiple workflows or write a preprocessor. Having all the prepare steps in a single one is going to simplify the implementation of both options.
Along with the move I did a few changes to the actual scripts:
* Mirrored all the remaining external URLs we download (except chocolatey) to the `rust-lang-ci-mirrors` bucket, to increase reliability and reduce the chance of supply chain attacks. I didn't audit and mirror the CI scripts outside this PR though.
* Extracted CI-specific behavior (like issuing `##vso[` commands and detecting the host platform) into `shared.sh` and included it in most of the scripts. This way a switch to another CI provider will be less painful.
It's possible (and easier) to review this commit-by-commit.
r? @alexcrichton
cc @rust-lang/infra
self-profiling: Record something more useful for crate metadata generation event.
Before this commit, we had an event that would only track the compression step
for proc-macros and Rust dylibs. After the commit we measure the time for
acutally generating the crate metadata bytes.
Tuple struct and tuple variant constructors are now considered to be constant functions. As such a call expression where the callee has a tuple struct or variant constructor "function item" type can be called:
```rust
const fn make_options() {
// These already work because they are special cased:
Some(0);
(Option::Some)(1);
// These also work now:
let f = Option::Some;
f(2);
{Option::Some}(3);
<Option<_>>::Some(5);
}
```
### Motivation
Consistency with other `const fn`. Consistency between syntactic path forms.
This should also ensure that constructors implement `const Fn` traits and can be coerced to `const fn` function pointers, if they are introduced.
## Tests
* [ui/consts/const_constructor/const-construct-call.rs](https://github.com/rust-lang/rust/blob/0d75ab2293a106eb674ac01860910cfc1580837e/src/test/ui/consts/const_constructor/const-construct-call.rs) - Tests various syntactic forms, use in both `const fn` and `const` items, and constructors in both the current and extern crates.
* [ui/consts/const_constructor/const_constructor_qpath.rs](https://github.com/rust-lang/rust/blob/1850dfcdabf8258a1f023f26c2c59e96b869dd95/src/test/ui/consts/const_constructor/const_constructor_qpath.rs) - Tests that type qualified paths to enum variants are also considered to be `const fn`.(#64247)
Rollup merge of #65880 - Nadrieril:gather-usefulness-tests, r=varkor
Gather together usefulness tests
I took most tests that were testing only for match exhaustiveness, pattern refutability or match arm reachability, and put them in the same test folder. I found it helpful to have them all in the same place when working on the usefulness algorithm.
Rollup merge of #65849 - popzxc:document-librustc_lexer, r=petrochenkov
librustc_lexer: Enhance documentation
This PR enhances documentation state of the `librustc_lexer` (as initiative caused by [rustc-guide#474](https://github.com/rust-lang/rustc-guide/issues/474)), by adding:
- Module documentation.
- Doc-comments (and a bit of usual comments) in non-obvious (as for me) places.
@eddyb suggested doing this intrinsic implementation ahead of actually implementing the `#[track_caller]` attribute so that there's an easily tested intermediate step between adding the shim and wiring up the attribute.
I took most tests that were testing only for match exhaustiveness,
pattern refutability or match arm reachability, and put them in
the same test folder.
bors [Sun, 27 Oct 2019 16:15:40 +0000 (16:15 +0000)]
Auto merge of #65869 - Centril:rollup-bzlo74f, r=Centril
Rollup of 6 pull requests
Successful merges:
- #65566 (Use heuristics to suggest assignment)
- #65738 (Coherence should allow fundamental types to impl traits when they are local)
- #65777 (Don't ICE for completely unexpandable `impl Trait` types)
- #65834 (Remove lint callback from driver)
- #65839 (Clean up `check_consts` now that new promotion pass is implemented)
- #65855 (Add long error explaination for E0666)
Rollup merge of #65839 - ecstatic-morse:promo-sanity-fixes, r=eddyb
Clean up `check_consts` now that new promotion pass is implemented
`check_consts::resolver` contained a layer of abstraction (`QualifResolver`) to allow the existing, eager style of qualif propagation to work with either a dataflow results cursor or by applying the transfer function directly (if dataflow was not needed e.g. for promotion). However, #63812 uses a different, lazy paradigm for checking promotability, which makes this unnecessary. This PR cleans up `check_consts::validation` to use `FlowSensitiveResolver` directly, instead of through the now obselete `QualifResolver` API.
Also, this contains a few commits (the first four) that address some FIXMEs in #63812 regarding code duplication. They could be split out, but I think they will be relatively noncontroversial? Notably, `validation::Mode` is renamed to `ConstKind` and used in `promote_consts` to denote what kind of item we are in.
This is best reviewed commit-by-commit and is low priority.
Rollup merge of #65834 - Mark-Simulacrum:driver-clean, r=nikomatsakis
Remove lint callback from driver
This is leftover from a restructuring of lint registration for drivers; it should now happen via the register_lints field on Config rather than this function.
This is not used by anyone to my knowledge (including the compiler itself); it was introduced in an abandoned refactor in #65193.
Rollup merge of #65738 - ohadravid:re-rebalance-coherence-allow-fundamental-local, r=nikomatsakis
Coherence should allow fundamental types to impl traits when they are local
After #64414, `impl<T> Remote for Box<T> { }` is disallowed, but it is also disallowed in liballoc, where `Box` is a local type!
Enabling `#![feature(re_rebalance_coherence)]` in `liballoc` results in:
```
error[E0210]: type parameter `F` must be used as the type parameter for some local type (e.g., `MyStruct<F>`)
--> src\liballoc\boxed.rs:1098:1
|
1098 | impl<F: ?Sized + Future + Unpin> Future for Box<F> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ type parameter `F` must be used as the type parameter for some local type
```
This PR relaxes `uncover_fundamental_ty` to skip local fundamental types.
I didn't add a test since `liballoc` already fails to compile, but I can add one if needed.
bors [Sun, 27 Oct 2019 09:35:12 +0000 (09:35 +0000)]
Auto merge of #65519 - pnkfelix:issue-63438-trait-based-structural-match, r=matthewjasper
trait-based structural match implementation
Moves from using a `#[structural_match]` attribute to using a marker trait (or pair of such traits, really) instead.
Fix #63438.
(This however does not remove the hacks that I believe were put into place to support the previous approach of injecting the attribute based on the presence of both derives... I have left that for follow-on work.)
bors [Sat, 26 Oct 2019 19:35:59 +0000 (19:35 +0000)]
Auto merge of #65167 - hermitcore:rusty-hermit, r=alexcrichton
Redesign the interface to the unikernel HermitCore
We are developing the unikernel HermitCore, where the kernel is written in Rust and is already part of the Rust Standard Library. The interface between the standard library and the kernel based on a small C library. With this pull request, we remove completely the dependency to C and use lld as linker. Currently, the kernel will be linked to the application as static library, which is published at https://github.com/hermitcore/libhermit-rs.
We don’t longer support the C interface to the kernel. Consequently, we remove this part from the Rust Standard Library.
bors [Sat, 26 Oct 2019 16:14:16 +0000 (16:14 +0000)]
Auto merge of #65845 - Centril:rollup-28jtjfc, r=Centril
Rollup of 8 pull requests
Successful merges:
- #65743 (rustc_typeck: don't record direct callees in generator_interior.)
- #65761 (libsyntax: Enhance documentation of the AST module)
- #65772 (Remove the last remaining READMEs)
- #65773 (Increase spacing for suggestions in diagnostics)
- #65791 (Adding doc on keyword continue)
- #65824 (rustc: make DefPathData (and friends) Copy (now that it uses Symbol).)
- #65828 (Derive Eq and Hash for SourceInfo again)
- #65842 (Add more information on rustdoc search)
Failed merges:
- #65825 (rustc: use IndexVec<DefIndex, T> instead of Vec<T>.)
Rollup merge of #65828 - bjorn3:add_source_info_eq_hash, r=petrochenkov
Derive Eq and Hash for SourceInfo again
In https://github.com/bjorn3/rustc_codegen_cranelift/blob/75c24b9c9677600422ec86fa9f4c78fe3678d2ce/src/common.rs#L368 I store it in a `indexmap::IndexSet`, which requires `Eq` and `Hash`. Unfortunately they were removed in https://github.com/rust-lang/rust/pull/65647, so I can't update to latest nightly.
Rollup merge of #65761 - popzxc:document-ast, r=petrochenkov
libsyntax: Enhance documentation of the AST module
This PR enhances documentation state to the `libsyntax/ast.rs` (as initiative caused by [rustc-guide#474](https://github.com/rust-lang/rustc-guide/issues/474)), by adding:
- Module documentation.
- Doc-comments (and a bit of usual comments) in non-obvious (as for me) places.
- Minor style fixes to improve module readability.
Rollup merge of #65743 - eddyb:generator-on-call, r=matthewjasper
rustc_typeck: don't record direct callees in generator_interior.
For expressions like `f(g().await)` we were recording `f` as needing to be kept in a temporary (and therefore be tracked by the generator type) across the suspend, even if a function/method path.
However, this is never needed, and can cause issues with complex function types (see #65244).