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
Stabilize `Option::flatten`
- PR: https://github.com/rust-lang/rust/pull/60256
- Tracking issue: https://github.com/rust-lang/rust/issues/60258
@elahn
> I was trying to `flat_map()` and found `map().flatten()` does the trick. This has been on nightly for 4 months, can we stabilise it?
@ethanboxx
> @Centril Helped me get this merged. What is the stabilization process?
@Centril
> @ethanboxx I'd just file a PR to stabilize it and we'll ask T-libs to FCP.
So here I am.
I am was unsure what number to put in `since = "-"` so I copied what someone had done in a recent PR.
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.
This allows us to remove `static_panic_msg` from the SSA<->LLVM
boundary, along with its fat pointer representation for &str.
Also changes the signature of PanicInfo::internal_contructor to
avoid copying.
Closes#65856.
