Commit Graph

119629 Commits

Author SHA1 Message Date
Dylan DPC
34421fd1af
Rollup merge of #71844 - flip1995:subtree_clippy_doc, r=oli-obk
List Clippy as a subtree, instead of a submodule

r? @oli-obk
2020-05-04 03:15:01 +02:00
Dylan DPC
911bf89468
Rollup merge of #71801 - matthewjasper:operator-subtyping, r=varkor
Correctly check comparison operator in MIR typeck

The subtyping for comparisons between pointers was reversed in MIR typeck.
There also wasn't a check that comparisons between numeric types had matching types.
2020-05-04 03:14:57 +02:00
Dylan DPC
ccc123a1e2
Rollup merge of #71645 - ecstatic-morse:readme-build-doc, r=Mark-Simulacrum
Direct contributors to try stage 0 rustdoc first

After #71458, `./x.py doc --stage 0 src/libstd` is (empirically) able to build the standard library docs using the `rustdoc` packaged with the bootstrap compiler. This means that new contributors don't need to build the compiler to locally inspect small documentation fixes. This was a roadblock for me when I first started contributing to rust and something that still regularly annoys people. We should recommend that contributors give bootstrap `rustdoc` a try before building the whole compiler.
2020-05-04 03:14:53 +02:00
Esteban Küber
3c872e2dc7 review comments: move logic to their own methods 2020-05-03 16:42:54 -07:00
bors
a0c61a9044 Auto merge of #71631 - RalfJung:miri-unleash-the-gates, r=oli-obk
Miri: unleash all feature gates

IMO it is silly to unleash features that do not even have a feature gate yet, but not unleash features that do. The only thing this achieves is making unleashed mode annoying to use as we have to figure out the feature flags to enable (and not always do the error messages say what that flag is).

Given that the point of `-Z unleash-the-miri-inside-of-you` is to debug the Miri internals, I see no good reason for this extra hurdle. I cannot imagine a situation where we'd use that flag, realize the program also requires some feature gate, and then be like "oh I guess if this feature is unstable I will do something else". Instead, we'll always just add that flag to the code as well, so requiring the flag achieves nothing.

r? @oli-obk @ecstatic-morse
Fixes https://github.com/rust-lang/rust/issues/71630
2020-05-03 22:54:55 +00:00
Michael
bdbd218b1f
Update link in contributing.md 2020-05-04 00:40:15 +02:00
Esteban Küber
de3b4d4dae fix rebase 2020-05-03 14:23:20 -07:00
bors
65b448273d Auto merge of #71006 - ecstatic-morse:dataflow-bidi, r=ecstatic-morse
Use existing framework for backward dataflow analyses

This PR adds support for backward analyses to the dataflow framework and adds a new live variable analysis (based on the existing one in `librustc_mir/util/liveness.rs`). By adding these to the framework instead of having a separate API, all newly implemented backward dataflow analyses get cursors/visitors, `rustc_peek` tests, and graphviz visualizations for free. In the near-term, this makes it much easier to implement global dead-store elimination, and I believe that this will enable even more MIR optimizations in the future.

This PR makes many changes to the dataflow API, since some concepts and terminology only make sense in forward dataflow. Below is a list of the important changes.
- ~~`entry_set` -> `fixpoint` (the fixpoint for backward dataflow problems is after the block's terminator)~~
- `seek_{before,after}` -> `seek_{before,after}_primary_effect` (the unprefixed dataflow effect is now referred to as the "primary" effect instead of the "after" effect. The "before" effect remains the same, although I considered changing it to the "antecedent" effect. In both backward and forward dataflow, the "before" effect is applied prior to the "primary" effect. I feel very strongly that this is the correct choice, as it means consumers don't have to switch between `seek_before` and `seek_after` based on the direction of their analysis.
- `seek_after_assume_call_returns` is now gone. Users can use `ResultsCursor::apply_custom_effect` to emulate it.
- `visit_{statement,terminator}_exit` -> `visit_{statement,terminator}_after_primary_effect`
- `visit_{statement,terminator}` -> `visit_{statement,terminator}_before_primary_effect`

Implementing this also required refactoring the dataflow cursor implementation so it could work in both directions. This is a large percentage of the diff, since the cursor code is rather complex. The fact that the cursor is exhaustively tested in both directions should reassure whomever is unlucky enough to review this 🤣.

In order to avoid computing the reverse CFG for forward dataflow analyses, I've added some hacks to the existing `mir::BodyAndCache` interface. I've requested changes to this interface that would let me implement this more efficiently.

r? @eddyb (feel free to reassign)
cc @rust-lang/wg-mir-opt
2020-05-03 19:46:17 +00:00
Dylan MacKenzie
21c72b6979 Update clippy lint 2020-05-03 11:41:03 -07:00
Dylan MacKenzie
1e701e5b8e Reflect API changes on current master 2020-05-03 11:36:11 -07:00
Dylan MacKenzie
f00a78e745 Use agreed upon terminology in cursor docs 2020-05-03 11:36:11 -07:00
Dylan MacKenzie
c530b2d8ef Add rustc_peek test for liveness with borrows 2020-05-03 11:36:11 -07:00
Dylan MacKenzie
a6a87e8bfc Support liveness in rustc_peek tests 2020-05-03 11:36:11 -07:00
Dylan MacKenzie
91003401c8 Use new liveness analysis during generator transform 2020-05-03 11:36:11 -07:00
Dylan MacKenzie
4c34ec6848 Live variable analysis 2020-05-03 11:36:11 -07:00
Dylan MacKenzie
20899dbd53 Initialize the cursor with an empty state 2020-05-03 11:36:11 -07:00
Dylan MacKenzie
c68d710d52 Support backward dataflow analyses 2020-05-03 11:36:11 -07:00
Dylan MacKenzie
032be94d23 Rename live_locals -> live_locals_at_any_suspension_point 2020-05-03 11:36:11 -07:00
Dylan MacKenzie
d0086166b7 Add MutatingUseContext::Yield
...emulating `MutatingUseContext::Call`
2020-05-03 11:36:11 -07:00
bors
ea733c3a59 Auto merge of #71853 - Dylan-DPC:rollup-4qi6ry9, r=Dylan-DPC
Rollup of 4 pull requests

Successful merges:

 - #71398 (Add `RefCell::take`)
 - #71663 (Fix exceeding bitshifts not emitting for assoc. consts (properly this time, I swear!))
 - #71726 (Suggest deref when coercing `ty::Ref` to `ty::RawPtr` with arbitrary mutability)
 - #71808 (Add long error explanation for E0539)

Failed merges:

r? @ghost
2020-05-03 16:38:41 +00:00
Dylan DPC
ce1dba9918
Rollup merge of #71808 - unexge:long-err-expl-for-e0539, r=GuillaumeGomez
Add long error explanation for E0539

since this error is similar to [E0551](https://github.com/rust-lang/rust/blob/master/src/librustc_error_codes/error_codes/E0551.md) most of the content was copied from it. part of #61137.
2020-05-03 18:34:50 +02:00
Dylan DPC
44e678bf9e
Rollup merge of #71726 - ldm0:ref2ptr, r=oli-obk
Suggest deref when coercing `ty::Ref` to `ty::RawPtr` with arbitrary mutability

Fixes #71676
1. Implement dereference suggestion when coercing `ty::Ref` to `ty::RawPtr` with arbitrary mutability.
2. Extract the dereference steps into `deref_steps()`, which removes all the `use` and `pub` noise introduced by last PR #71540, and makes the code more readable.
3. Use the `remove_prefix()` closure which makes the prefix removal more readable.
4. Introduce `Applicability` as a return value of `check_ref` to suggest `Applicability::Unspecified` suggestion.

**Special**: I found it is not possible to genereate `Applicability::MachineApplicable` suggestion for situation like this:
```rust
use std::ops::Deref;
use std::ops::DerefMut;
struct Bar(u8);
struct Foo(Bar);
struct Emm(Foo);
impl Deref for Bar{
    type Target = u8;
    fn deref(&self) -> &Self::Target {
        &self.0
    }
}
impl Deref for Foo {
    type Target = Bar;
    fn deref(&self) -> &Self::Target {
        &self.0
    }
}
impl Deref for Emm {
    type Target = Foo;
    fn deref(&self) -> &Self::Target {
        &self.0
    }
}
impl DerefMut for Bar{
    fn deref_mut(&mut self) -> &mut Self::Target {
        &mut self.0
    }
}
impl DerefMut for Foo {
    fn deref_mut(&mut self) -> &mut Self::Target {
        &mut self.0
    }
}
impl DerefMut for Emm {
    fn deref_mut(&mut self) -> &mut Self::Target {
        &mut self.0
    }
}
fn main() {
    let a = Emm(Foo(Bar(0)));
    let _: *mut u8 = &a; //~ ERROR mismatched types
}
```
We may suggest `&mut ***a` here, but the `a` is not declared as mutable variable. And also when processing HIR, it's not possible to check if `a` is declared as a mutable variable (currently we do borrow checking with MIR). So we cannot ensure that suggestion when coercing immutable reference to mutable pointer is always machine applicable. Therefore I added a `Applicability` return value in `check_ref()`. And move the `immutable reference -> mutable pointer` situation into a sperate test file without `run-rustfix`. (It seems that `run-rustfix` will also adopt `Applicability::Unspecified` suggestion, which is strange)
2020-05-03 18:34:46 +02:00
Dylan DPC
5b1729030a
Rollup merge of #71663 - jumbatm:caller-handles-validation-error, r=RalfJung
Fix exceeding bitshifts not emitting for assoc. consts (properly this time, I swear!)

Fixes #69021 and fixes #71353.

As described in https://github.com/rust-lang/rust/issues/71353#issuecomment-617901923, this PR:

- adds a variant of `try_validation!` called `try_validation_pat!` that allows specific failures to be turned into validation failures (but returns the rest, unchanged), and
- allows `InvalidProgram` to be returned out of validation

r? @RalfJung
2020-05-03 18:34:41 +02:00
Dylan DPC
6f5de87d3f
Rollup merge of #71398 - ThinkChaos:feat_refcell_take, r=LukasKalbertodt
Add `RefCell::take`

Add `RefCell::take` to match `Cell` and `Option`.
I also changed a couple of calls to `.replace` to `.take`.

Tracking issue is #71395.

This is my first contribution, please tell me if there's anything I could improve, thanks!
2020-05-03 18:34:34 +02:00
Ralf Jung
182133f8c8 bless caller-location test 2020-05-03 18:04:24 +02:00
Ralf Jung
a909c039b5 remove unneeded flags; exlain why we still have const_if_match 2020-05-03 17:18:46 +02:00
Ralf Jung
f7f606d9af fmt 2020-05-03 17:12:50 +02:00
Vadim Petrochenkov
5b84d5ff13 resolve: Relax fresh binding disambiguation slightly to fix regression 2020-05-03 17:39:03 +03:00
flip1995
1b155623d8
List Clippy as a subtree, instead of a submodule 2020-05-03 15:58:30 +02:00
Ralf Jung
99debecd4d warn about each skipped feature gate 2020-05-03 14:23:08 +02:00
Matthew Jasper
9e19f3a27f Correctly check comparison operators in MIR typeck 2020-05-03 13:21:40 +01:00
bors
e5f35df2c6 Auto merge of #70825 - eddyb:enum-discr-correct-generics-parent, r=nikomatsakis
typeck: always expose explicit enum discriminant `AnonConst`s' parent in `generics_of`.

This is similar to #70452 but for explicit `enum` discriminant constant expressions.
However, unlike #70452, this PR should have no effect on stable code, as while it alleviates #43408 errors, there is no way to actually compile an `enum` with generic parameters *and* explicit discriminants, without `#![feature(arbitrary_enum_discriminant)]`, as explicit discriminant expression don't count as uses of parameters (if they did, they would count as invariant uses).

<hr/>

There's also 2 other commits here, both related to #70453:
* "ty: use `delay_span_bug` in `ty::AdtDef::eval_explicit_discr`." - hides the ICEs demonstrated on #70453, when there are other errors (which the next commit adds)
* "typeck/wfcheck: require that explicit enum discriminants const-evaluate succesfully." - closes #70453 by picking alternative "2", i.e. erroring when a discriminant doesn't fully const-evaluate from the perspective of the `enum` definition

In the future, it might be possible to allow `enum` discriminants to actually depend on parameters, but that will likely require #68436 + some way to restrict the values so no two variants can end up with overlapping discriminants.

As this PR would close #70453, it shouldn't be merged until a decision is reached there.

r? @nikomatsakis
2020-05-03 12:05:46 +00:00
ThinkChaos
4a79424b74 Mention RefCell::take can panic in docs 2020-05-03 12:52:23 +02:00
Oliver Scherer
675b585931 Remove clippy from some leftover lists of "possibly failing" tools 2020-05-03 11:40:45 +02:00
bors
d626e4dadc Auto merge of #71828 - Dylan-DPC:rollup-qf5h2w5, r=Dylan-DPC
Rollup of 5 pull requests

Successful merges:

 - #71165 (`slice::fill`: use `T` instead of generic arg)
 - #71314 (Implement RFC 2523, `#[cfg(version(..))]`)
 - #71542 (Implement `confusable_idents` lint.)
 - #71806 (typo)
 - #71813 (Decode qualifs for associated const defaults)

Failed merges:

r? @ghost
2020-05-03 08:53:03 +00:00
Dylan DPC
e48a7b8d06
Rollup merge of #71813 - ecstatic-morse:issue-71734, r=tmandry
Decode qualifs for associated const defaults

Fixes #71734.

We encode qualifs for associated constants, but never expected to decode the qualifs for defaulted associated consts. Fix this, and test that associated const defaults have the correct qualifs cross-crate.

r? @tmandry
2020-05-03 14:18:08 +05:30
Dylan DPC
223194127e
Rollup merge of #71806 - lcnr:patch-3, r=jonas-schievink
typo
2020-05-03 14:18:04 +05:30
Dylan DPC
24e101c418
Rollup merge of #71542 - crlf0710:confusable_idents, r=petrochenkov
Implement `confusable_idents` lint.

This collects all identifier symbols into `ParseSession` and examines them within the non-ascii-idents lint.

The skeleton generation part needs to be added to `unicode-security` crate. Will update this PR when the crate is updated.

r? @petrochenkov

EDIT: also included the `concat_idents` part.
2020-05-03 14:18:02 +05:30
Dylan DPC
ffe0a1c9fd
Rollup merge of #71314 - mibac138:cfg-version, r=petrochenkov
Implement RFC 2523, `#[cfg(version(..))]`

Hi! This is my first contribution to rust, I hope I didn't miss anything. I tried to implement this feature so that `#[cfg(version(1.44.0))]` works but the parser was printing an error that I wasn't sure how to fix so I just opted for implementing `#[cfg(version("1.44.0"))]` (note the quotes).

Tracking issue: #64796
2020-05-03 14:18:00 +05:30
Dylan DPC
8cb8d9cfe2
Rollup merge of #71165 - lcnr:patch-2, r=Amanieu
`slice::fill`: use `T` instead of generic arg

implements https://github.com/rust-lang/rust/issues/70758#issuecomment-613994427

As the discussion in #70758 has shifted, I now use `T` instead of `&T`.
2020-05-03 14:17:53 +05:30
bors
0a675c5e02 Auto merge of #71815 - Mark-Simulacrum:no-llvm-rebuild, r=jonas-schievink
Don't bust caches on x.py check/build switches

Fixes #71152
2020-05-03 02:58:00 +00:00
Esteban Küber
74b7ed78b1 trailing newlines 2020-05-02 18:24:08 -07:00
Esteban Küber
9bb5b549aa Add docs 2020-05-02 18:24:08 -07:00
Esteban Küber
b0085c86fc Suggest constraint on impl Trait in return type
Fix #71035.
2020-05-02 18:24:07 -07:00
Esteban Küber
6648a08b30 fix rebase 2020-05-02 18:24:07 -07:00
Esteban Küber
299bd12fe5 Point at associated types when they have a default type
Associated types with a default type in a trait can't be relied upon to
remain of that default type when in use, so literals of that type can't
be used in the trait's items. Point at the associated type and state
that information.

Reduce verbosity for associated consts of the wrong type.
2020-05-02 18:24:07 -07:00
Esteban Küber
ee96b8b119 review comment: use or patterns 2020-05-02 18:24:07 -07:00
Esteban Küber
31b3566196 When a projection is expected, suggest constraining or calling method 2020-05-02 18:24:07 -07:00
Esteban Küber
3a795fba03 On type mismatch involving associated type, suggest constraint
When an associated type is found when a specific type was expected, if
possible provide a structured suggestion constraining the associated
type in a bound.

```
error[E0271]: type mismatch resolving `<T as Foo>::Y == i32`
  --> $DIR/associated-types-multiple-types-one-trait.rs:13:5
   |
LL |     want_y(t);
   |     ^^^^^^ expected `i32`, found associated type
...
LL | fn want_y<T:Foo<Y=i32>>(t: &T) { }
   |                 ----- required by this bound in `want_y`
   |
   = note:         expected type `i32`
           found associated type `<T as Foo>::Y`
help: consider constraining the associated type `<T as Foo>::Y` to `i32`
   |
LL | fn have_x_want_y<T:Foo<X=u32, Y = i32>>(t: &T)
   |                             ^^^^^^^^^
```

```
error[E0308]: mismatched types
  --> $DIR/trait-with-missing-associated-type-restriction.rs:12:9
   |
LL |     qux(x.func())
   |         ^^^^^^^^ expected `usize`, found associated type
   |
   = note:         expected type `usize`
           found associated type `<impl Trait as Trait>::A`
help: consider constraining the associated type `<impl Trait as Trait>::A` to `usize`
   |
LL | fn foo(x: impl Trait<A = usize>) {
   |                     ^^^^^^^^^^
```
2020-05-02 18:23:46 -07:00
mibac138
8a77d1ca3f Add build script to rustc_attr because of cfg(version) 2020-05-03 02:42:12 +02:00