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??
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.
r? @wesleywiser
doc: introduce `once` in `iter::chain` document
I find it hard to find which one to use with `chain` when I only need to
chain one value. Also [`once`][1] talks about `chain`.
[1]: https://doc.rust-lang.org/nightly/std/iter/fn.once.html
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)
rustc: use IndexVec<DefIndex, T> instead of Vec<T>.
Now that `DefIndex` is a proper index type, we can do that.
There was also an unnecessary `Option` I removed, I wonder if that has perf implications.
Use heuristics to recover parsing of missing `;`
- Detect `,` and `:` typos where `;` was intended.
- When the next token could have been the start of a new statement,
detect a missing semicolon.
Fix#48160, fix#44767 (after adding note about statements).
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
````
Fixes ##65888
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.
Signed-off-by: David Wood <david@davidtw.co>
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
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.
Stabilize `const_constructor`
# Stabilization proposal
I propose that we stabilize `#![feature(const_constructor)]`.
Tracking issue: https://github.com/rust-lang/rust/issues/61456
Version target: 1.40 (2019-11-05 => beta, 2019-12-19 => stable).
## What is stabilized
### User guide
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](0d75ab2293/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](1850dfcdab/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)
r? @oli-obk
Closes#61456
Closes #64247
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.
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.
r? @petrochenkov
cc @Centril
