```
Fix ICE in `missing_errors_doc`
Update License
Migrate Clippy to GitHub Actions
redundant_clone: Migrate to new dataflow framework
Move unneeded_field_pattern to pedantic group
Rustup to rust-lang/rust#69325
Rustup to rust-lang/rust#69072
```
bors [Fri, 21 Feb 2020 06:43:40 +0000 (06:43 +0000)]
Auto merge of #69290 - wesleywiser:speed_up_ctfe_stress_4, r=RalfJung
Check `RUSTC_CTFE_BACKTRACE` much less by generating fewer errors
Before this change, `get_size_and_align()` calls `get_fn_alloc()` *a
lot* in CTFE heavy code. This previously returned an `Error` which would
check if `RUSTC_CTFE_BACKTRACE` was set on construction. Doing this
turned out to be a performance hotspot as @nnethercote discovered in
#68792.
This is an alternate take on that PR which resolves the performance
issue by generating *many* fewer errors. Previously, `ctfe-stress-4`
would generate over 5,000,000 errors each of which would check for the
presence of the environment variable. With these changes, that number is
reduced to 30.
bors [Thu, 20 Feb 2020 22:44:01 +0000 (22:44 +0000)]
Auto merge of #69072 - ecstatic-morse:associated-items, r=petrochenkov
O(log n) lookup of associated items by name
Resolves #68957, in which compile time is quadratic in the number of associated items. This PR makes name lookup use binary search instead of a linear scan to improve its asymptotic performance. As a result, the pathological case from that issue now runs in 8 seconds on my local machine, as opposed to many minutes on the current stable.
Currently, method resolution must do a linear scan through all associated items of a type to find one with a certain name. This PR changes the result of the `associated_items` query to a data structure that preserves the definition order of associated items (which is used, e.g., for the layout of trait object vtables) while adding an index of those items sorted by (unhygienic) name. When doing name lookup, we first find all items with the same `Symbol` using binary search, then run hygienic comparison to find the one we are looking for. Ideally, this would be implemented using an insertion-order preserving, hash-based multi-map, but one is not readily available.
Someone who is more familiar with identifier hygiene could probably make this better by auditing the uses of the `AssociatedItems` interface. My goal was to preserve the current behavior exactly, even if it seemed strange (I left at least one FIXME to this effect). For example, some places use comparison with `ident.modern()` and some places use `tcx.hygienic_eq` which requires the `DefId` of the containing `impl`. I don't know whether those approaches are equivalent or which one should be preferred.
bors [Thu, 20 Feb 2020 19:19:54 +0000 (19:19 +0000)]
Auto merge of #69325 - Centril:rollup-vce2ko2, r=Centril
Rollup of 5 pull requests
Successful merges:
- #68877 (On mismatched argument count point at arguments)
- #69185 (Unify and improve const-prop lints)
- #69305 (Tweak binding lifetime suggestion text)
- #69311 (Clean up E0321 and E0322)
- #69317 (Fix broken link to the rustc guide)
Rollup merge of #69185 - RalfJung:const-prop-lints, r=oli-obk
Unify and improve const-prop lints
Add a single helper method for all lints emitted by const-prop, and make that lint different from the CTFE `const_err` lint. Also consistently check overflow on *arithmetic*, not on the assertion, to make behavior the same for debug and release builds.
See [this summary comment](https://github.com/rust-lang/rust/pull/69185#issuecomment-587924754) for details and the latest status.
In terms of lint formatting, I went for what seems to be the better style: have a general message above the code, and then a specific message at the span:
```
error: this arithmetic operation will overflow
--> $DIR/const-err2.rs:21:18
|
LL | let a_i128 = -std::i128::MIN;
| ^^^^^^^^^^^^^^^ attempt to negate with overflow
```
We could also just have the specific message above and no text at the span if that is preferred.
I also converted some of the existing tests to use compiletest revisions, so that the same test can check a bunch of different compile flags.
Fixes https://github.com/rust-lang/rust/issues/69020.
Helps with https://github.com/rust-lang/rust/issues/69021: debug/release are now consistent, but the assoc-const test in that issue still fails (there is a FIXME in the PR for this). The reason seems to be that const-prop notices the assoc const in `T::N << 42` and does not even bother calling `const_prop` on that operation.
Has no effect on https://github.com/rust-lang/rust/issues/61821; the duplication there has entirely different reasons.
Dylan DPC [Thu, 20 Feb 2020 09:49:13 +0000 (10:49 +0100)]
Rollup merge of #69266 - Zoxc:fix-source-map-race, r=wesleywiser
Fix race condition when allocating source files in SourceMap
This makes allocating address space in the source map an atomic operation. `rustc` does not currently do this in parallel, so this bug can't trigger, but parsing files in parallel could trigger it, and that is something we want to do.
Dylan DPC [Thu, 20 Feb 2020 09:49:12 +0000 (10:49 +0100)]
Rollup merge of #68978 - ecstatic-morse:const-int-pow, r=oli-obk
Make integer exponentiation methods unstably const
cc #53718
This makes the following inherent methods on integer primitives into unstable `const fn`:
- `pow`
- `checked_pow`
- `wrapping_pow`
- `overflowing_pow`
- `saturating_pow`
- `next_power_of_two`
- `checked_next_power_of_two`
- `wrapping_next_power_of_two`
Only two changes were made to the implementation of these methods. First, I had to switch from the `?` operator, which is not yet implemented in a const context, to a `try_opt` macro. Second, `next_power_of_two` was using `ops::Add::add` (see the first commit) to "get overflow checks", so I switched to `#[rustc_inherit_overflow_checks]`. I'm not quite sure why the attribute wasn't used in the first place.
Dylan DPC [Thu, 20 Feb 2020 09:49:10 +0000 (10:49 +0100)]
Rollup merge of #68945 - mjbshaw:once_is_completed, r=LukasKalbertodt
Stabilize Once::is_completed
Closes #54890
This function has been around for some time. I haven't seen anyone raise any objections to it. I've personally found it useful myself. It would be nice to finally stabilize it and
bors [Thu, 20 Feb 2020 08:41:17 +0000 (08:41 +0000)]
Auto merge of #68847 - ecstatic-morse:const-impl, r=oli-obk
Allow trait methods to be called on concrete types in a const context
This partially implements [RFC 2632](https://github.com/rust-lang/rfcs/pull/2632) by const-checking methods inside an `impl const` block and allowing those methods to be called on concrete types. Calling trait methods on type parameters in a const context is not yet allowed. Implementing this will require much more work. Since we are only concerned with methods on concrete types, we are able to take advantage of the machinery in `Instance::resolve`, which is doing most of the work.
This also propagates `#[rustc_const_unstable]` from parent items to child items, making that attribute behave like `#[stable]` and `#[unstable]` do. This allows trait methods to be marked as unstably const.
cc #67792 #57563
cc @rust-lang/wg-const-eval
r? @oli-obk
Wesley Wiser [Wed, 19 Feb 2020 12:59:21 +0000 (07:59 -0500)]
Check `RUSTC_CTFE_BACKTRACE` much less by generating fewer errors
Before this change, `get_size_and_align()` calls `get_fn_alloc()` *a
lot* in CTFE heavy code. This previously returned an `Error` which would
check if `RUSTC_CTFE_BACKTRACE` was set on construction. Doing this
turned out to be a performance hotspot as @nnethercote discovered in
#68792.
This is an alternate take on that PR which resolves the performance
issue by generating *many* fewer errors. Previously, `ctfe-stress-4`
would generate over 5,000,000 errors each of which would check for the
presence of the environment variable. With these changes, that number is
reduced to 30.
Dylan DPC [Wed, 19 Feb 2020 17:12:13 +0000 (18:12 +0100)]
Rollup merge of #69284 - jumbatm:openoptions-create-doc, r=Dylan-DPC
Reword OpenOptions::{create, create_new} doc.
Closes #69254.
Currently, the doc comment for `fs::OpenOptions::create` doesn't mention its behaviour when opening an existing file, and `fs::OpenOptions::create_new`'s doc comment is worded in a way that doesn't make it clear that it actually _fails_ if the file already exists, not overwrite the existing file with a new one.
This PR addresses addresses this by rewording the doc comments to be more explicit.
Dylan DPC [Wed, 19 Feb 2020 17:12:09 +0000 (18:12 +0100)]
Rollup merge of #69142 - ehuss:linkcheck-script, r=alexcrichton
Add shared script for linkchecking books.
This adds a script that can be used on each book's CI to ensure they don't break local links.
I've been running something similar on the reference CI. The intent here is to add this to all the external books' CI scripts. This will help avoid dealing with broken links when updating submodules on rust-lang/rust.
Dylan DPC [Wed, 19 Feb 2020 17:12:07 +0000 (18:12 +0100)]
Rollup merge of #68863 - pietroalbini:azure-macos-10.15, r=Mark-Simulacrum
ci: switch macOS builders to 10.15
Azure Pipelines is deprecating the macOS 10.13 image we're currently running, [and they plan to remove them](https://devblogs.microsoft.com/devops/removing-older-images-in-azure-pipelines-hosted-pools/) on March 23, 2020. This PR switches our macOS builders to macOS 10.15.
Changes:
````
Rustup to rust-lang/rust#69194
Rustup to rust-lang/rust#69181
Add `LOG2_10` and `LOG10_2` to `approx_const` lint
Clean up imports
Use `Vec::with_capacity()` as possible
needless_doctest_main: False positive for async fn
Remove use of `TyKind`.
Use `if_chain`.
Fix ICE.
Add tests and improve checks.
Add `Future` detection for `missing_errors_doc`.
````
bors [Wed, 19 Feb 2020 08:07:42 +0000 (08:07 +0000)]
Auto merge of #69265 - ehuss:update-cargo, r=Dylan-DPC
Update cargo
9 commits in 3c53211c3d7fee4f430f170115af5baad17a3da9..e02974078a692d7484f510eaec0e88d1b6cc0203
2020-02-07 15:35:03 +0000 to 2020-02-18 15:24:43 +0000
- Set an environment variable for tests to find executables. (rust-lang/cargo#7697)
- Rework internal errors. (rust-lang/cargo#7896)
- Improvements to StringList config handling. (rust-lang/cargo#7891)
- Add new/old rustflags to fingerprint log. (rust-lang/cargo#7890)
- Fix inaccurate doc comment on `env_args`. (rust-lang/cargo#7889)
- Add some extra fingerprint debug information. (rust-lang/cargo#7888)
- Link the licenses into crates/cargo-platform (rust-lang/cargo#7886)
- Modify test to make `rustc` PR mergeable (rust-lang/cargo#7883)
- Keep environment variables in a BTreeMap to preserve sort order (rust-lang/cargo#7877)
bors [Wed, 19 Feb 2020 04:57:10 +0000 (04:57 +0000)]
Auto merge of #69113 - ecstatic-morse:unified-dataflow-borrowed, r=wesleywiser
Combine `HaveBeenBorrowedLocals` and `IndirectlyMutableLocals` into one dataflow analysis
This PR began as an attempt to port `HaveBeenBorrowedLocals` to the new dataflow framework (see #68241 for prior art). Along the way, I noticed that it could share most of its code with `IndirectlyMutableLocals` and then found a few bugs in the two analyses:
- Neither one marked locals as borrowed after an `Rvalue::AddressOf`.
- `IndirectlyMutableLocals` was missing a minor fix that `HaveBeenBorrowedLocals` got in #61069. This is not a problem today since it is only used during const-checking, where custom drop glue is forbidden. However, this may change some day.
I decided to combine the two analyses so that they wouldn't diverge in the future while ensuring that they remain distinct types (called `MaybeBorrowedLocals` and `MaybeMutBorrowedLocals` to be consistent with the `Maybe{Un,}InitializedPlaces` naming scheme). I fixed the bugs and switched to exhaustive matching where possible to make them less likely in the future. Finally, I added comments explaining some of the finer points of the transfer function for these analyses (see #61069 and #65006).
Changes:
````
Rustup to rust-lang/rust#69194
Rustup to rust-lang/rust#69181
Add `LOG2_10` and `LOG10_2` to `approx_const` lint
Clean up imports
Use `Vec::with_capacity()` as possible
needless_doctest_main: False positive for async fn
Remove use of `TyKind`.
Use `if_chain`.
Fix ICE.
Add tests and improve checks.
Add `Future` detection for `missing_errors_doc`.
````
bors [Tue, 18 Feb 2020 22:29:06 +0000 (22:29 +0000)]
Auto merge of #69271 - Centril:rollup-iupsol6, r=Centril
Rollup of 6 pull requests
Successful merges:
- #69146 (Always const qualify literals by type)
- #69159 (Select an appropriate unused lifetime name in suggestion)
- #69194 (parse: fuse associated and extern items up to defaultness)
- #69211 (parser: Simplify treatment of macro variables in `Parser::bump`)
- #69217 (Do not emit note suggesting to implement operation trait to foreign type)
- #69236 (parse: recover `mut (x @ y)` as `(mut x @ mut y)`.)
Rollup merge of #69236 - Centril:mut-parens-at-recovery, r=estebank
parse: recover `mut (x @ y)` as `(mut x @ mut y)`.
Follow up to https://github.com/rust-lang/rust/pull/68992#discussion_r376829749 and https://github.com/rust-lang/rust/pull/63945.
Specifically, when given `let mut (x @ y)` we recover with `let (mut x @ mut y)` as the suggestion:
```rust
error: `mut` must be attached to each individual binding
--> $DIR/mut-patterns.rs:12:9
|
LL | let mut (x @ y) = 0;
| ^^^^^^^^^^^ help: add `mut` to each binding: `(mut x @ mut y)`
|
= note: `mut` may be followed by `variable` and `variable @ pattern`
```
Rollup merge of #69217 - LeSeulArtichaut:remove-lint-impl-op, r=estebank
Do not emit note suggesting to implement operation trait to foreign type
When a binary operation isn't valid, you will get a lint proposing to add a trait implementation to make the operation possible. However, this cannot be done for foreign types, such as types from `core` or `std`.
For example:
```
= note: an implementation of `std::ops::Add` might be missing for `std::option::Option<i8>`
```
As mentioned in https://github.com/rust-lang/rust/issues/60497#issuecomment-562665539:
> The note suggesting implementing Add<i8> should only be emitted if Option<i8> were local to the current crate, which it isn't, so in this case it shouldn't be emitted.
(I will use the CI to check tests for me, or my computer will just burn... and running IDEs is not possible on a pile of ashes)
Rollup merge of #69211 - petrochenkov:prevtok, r=Centril
parser: Simplify treatment of macro variables in `Parser::bump`
Follow-up to https://github.com/rust-lang/rust/pull/69006.
Token normalization for `$ident` and `$lifetime` is merged directly into `bump`.
Special "unknown macro variable" diagnostic for unexpected `$`s is removed as preventing legal code from compiling (as a result `bump` also doesn't call itself recursively anymore and can't make `prev_token` inconsistent).
Rollup merge of #69194 - Centril:assoc-extern-fuse, r=petrochenkov
parse: fuse associated and extern items up to defaultness
Language changes:
- The grammar of extern `type` aliases is unified with associated ones, and becomes:
```rust
TypeItem = "type" ident generics {":" bounds}? where_clause {"=" type}? ";" ;
```
Semantic restrictions (`ast_validation`) are added to forbid any parameters in `generics`, any bounds in `bounds`, and any predicates in `where_clause`, as well as the presence of a type expression (`= u8`).
(Work still remains to fuse this with free `type` aliases, but this can be done later.)
- The grammar of constants and static items (free, associated, and extern) now permits the absence of an expression, and becomes:
- A semantic restriction is added to enforce the presence of the expression (the body).
- A semantic restriction is added to reject `const _` in associated contexts.
Together, these changes allow us to fuse the grammar of associated items and extern items up to `default`ness which is the main goal of the PR.
-----------------------
We are now very close to fully fusing the entirely of item parsing and their ASTs. To progress further, we must make a decision: should we parse e.g. `default use foo::bar;` and whatnot? Accepting that is likely easiest from a parsing perspective, as it does not require using look-ahead, but it is perhaps not too onerous to only accept it for `fn`s (and all their various qualifiers), `const`s, `static`s, and `type`s.