Commit Graph

1339 Commits

Author SHA1 Message Date
Jubilee
9e11d1cca4
Rollup merge of #89148 - estebank:used-type-param, r=oli-obk
Suggest `_` in turbofish if param will be inferred from fn argument
2021-09-23 17:31:43 -07:00
bors
2b862bed98 Auto merge of #89024 - oli-obk:lazy_tait_is_not_limited_to_being_used_in_return_position, r=nikomatsakis
Lazy TAIT preparation cleanups

Check that TAIT generics are fully generic in mir typeck instead of wf-check, as wf-check can by definition only check TAIT in return position and not account for TAITs defined in the body of the function

r? `@spastorino` `@nikomatsakis`
2021-09-23 19:38:30 +00:00
Esteban Kuber
affea730e9 Suggest _ in turbofish if param will be inferred from fn argument 2021-09-23 14:08:47 +00:00
Oli Scherer
6067eadb65 Check that TAIT generics are fully generic in mir typeck instead of wf-check, as wf-check can by definition only check TAIT in return position and not account for TAITs defined in the body of the function 2021-09-23 13:35:16 +00:00
Aaron Hill
94b19fac26
Support #[track_caller] on closures and generators
This PR allows applying a `#[track_caller]` attribute to a
closure/generator expression. The attribute as interpreted as applying
to the compiler-generated implementation of the corresponding trait
method (`FnOnce::call_once`, `FnMut::call_mut`, `Fn::call`, or
`Generator::resume`).

This feature does not have its own feature gate - however, it requires
`#![feature(stmt_expr_attributes)]` in order to actually apply
an attribute to a closure or generator.

This is implemented in the same way as for functions - an extra
location argument is appended to the end of the ABI. For closures,
this argument is *not* part of the 'tupled' argument storing the
parameters - the final closure argument for `#[track_caller]` closures
is no longer a tuple.

For direct (monomorphized) calls, the necessary support was already
implemented - we just needeed to adjust some assertions around checking
the ABI and argument count to take closures into account.

For calls through a trait object, more work was needed.
When creating a `ReifyShim`, we need to create a shim
for the trait method (e.g. `FnOnce::call_mut`) - unlike normal
functions, closures are never invoked directly, and always go through a
trait method.

Additional handling was needed for `InstanceDef::ClosureOnceShim`. In
order to pass location information throgh a direct (monomorphized) call
to `FnOnce::call_once` on an `FnMut` closure, we need to make
`ClosureOnceShim` aware of `#[tracked_caller]`. A new field
`track_caller` is added to `ClosureOnceShim` - this is used by
`InstanceDef::requires_caller` location, allowing codegen to
pass through the extra location argument.

Since `ClosureOnceShim.track_caller` is only used by codegen,
we end up generating two identical MIR shims - one for
`track_caller == true`, and one for `track_caller == false`. However,
these two shims are used by the entire crate (i.e. it's two shims total,
not two shims per unique closure), so this shouldn't a big deal.
2021-09-22 15:19:33 -05:00
bors
ce45663e14 Auto merge of #88865 - guswynn:must_not_suspend, r=oli-obk
Implement `#[must_not_suspend]`

implements #83310

Some notes on the impl:

1. The code that searches for the attribute on the ADT is basically copied from the `must_use` lint. It's not shared, as the logic did diverge
2. The RFC does specify that the attribute can be placed on fn's (and fn-like objects), like `must_use`. I think this is a direct copy from the `must_use` reference definition. This implementation does NOT support this, as I felt that ADT's (+ `impl Trait` + `dyn Trait`) cover the usecase's people actually want on the RFC, and adding an imp for the fn call case would be significantly harder. The `must_use` impl can do a single check at fn call stmt time, but `must_not_suspend` would need to answer the question: "for some value X with type T, find any fn call that COULD have produced this value". That would require significant changes to `generator_interior.rs`, and I would need mentorship on that. `@eholk` and I are discussing it.
3. `@estebank` do you know a way I can make the user-provided `reason` note pop out? right now it seems quite hidden

Also, I am not sure if we should run perf on this

r? `@nikomatsakis`
2021-09-22 06:43:33 +00:00
bors
77f4143fa2 Auto merge of #88846 - jackh726:issue-88360, r=nikomatsakis
In suggest_missing_return_type, erase late bound regions after normalizing

Fixes #88360

There might be some hardening that could be done to not error or avoid erroring with LUBing `ReErased` with `ReEmpty`, but this was the most simple fix for this particular case.

r? `@nikomatsakis`
2021-09-22 04:02:01 +00:00
bors
ac2d9fc509 Auto merge of #89103 - Mark-Simulacrum:migrate-2021, r=estebank
Migrate in-tree crates to 2021

This replaces #89075 (cherry picking some of the commits from there), and closes #88637 and fixes #89074.

It excludes a migration of the library crates for now (see tidy diff) because we have some pending bugs around macro spans to fix there.

I instrumented bootstrap during the migration to make sure all crates moved from 2018 to 2021 had the compatibility warnings applied first.

Originally, the intent was to support cargo fix --edition within bootstrap, but this proved fairly difficult to pull off. We'd need to architect the check functionality to support running cargo check and cargo fix within the same x.py invocation, and only resetting sysroots on check. Further, it was found that cargo fix doesn't behave too well with "not quite workspaces", such as Clippy which has several crates. Bootstrap runs with --manifest-path ... for all the tools, and this makes cargo fix only attempt migration for that crate. We can't use e.g. --workspace due to needing to maintain sysroots for different phases of compilation appropriately.

It is recommended to skip the mass migration of Cargo.toml's to 2021 for review purposes; you can also use `git diff d6cd2c6c87 -I'^edition = .20...$'` to ignore the edition = 2018/21 lines in the diff.
2021-09-21 19:25:49 +00:00
Mark Rousskov
f338900826 Remove Drop-caused migration-added captures
All of these were added due to insignificant Drop types being present.
2021-09-20 22:21:43 -04:00
Mark Rousskov
c746be2219 Migrate to 2021 2021-09-20 22:21:42 -04:00
Mark Rousskov
45b989a033 Enable 2021 compatibility lints for all in-tree code
This just applies the suggested fixes from the compatibility warnings,
leaving any that are in practice spurious in. This is primarily intended to
provide a starting point to identify possible fixes to the migrations (e.g., by
avoiding spurious warnings).

A secondary commit cleans these up where they are false positives (as is true in
many of the cases).
2021-09-20 08:45:39 -04:00
Mark Rousskov
440d9372a2 Workaround ICE with if-let and RFC 2229 2021-09-20 08:45:39 -04:00
Camille GILLOT
d7795d302a Do not store visibility in *ItemRef. 2021-09-20 00:29:53 +02:00
bors
7b5f95270f Auto merge of #88703 - cjgillot:lazymod, r=petrochenkov
Gather module items after lowering.

This avoids having a non-local analysis inside lowering.

By implementing `hir_module_items` using a visitor, we make sure that iterations and visitors are consistent.
2021-09-19 16:13:42 +00:00
Yuki Okushi
441046af97
Rollup merge of #89055 - Kobzol:wrapped-method-expr-call-parens, r=wesleywiser
Suggest better place to add call parentheses for method expressions wrapped in parentheses

I wanted to improve the suggestion a bit to both remove the wrapping parentheses **and** add call parentheses by both calling `suggest_method_call` and using `multipart_suggestion`. But I very quickly ran into a problem where multiple overlapping machine applicable suggestions cannot be properly applied together. So I applied the suggestion from the issue and only added the call parentheses directly after the expression.

Fixes: https://github.com/rust-lang/rust/issues/89044
2021-09-19 17:31:35 +09:00
Yuki Okushi
e675073e73
Rollup merge of #88855 - calebzulawski:feature/simd_shuffle, r=nagisa
Allow simd_shuffle to accept vectors of any length

cc ``@rust-lang/project-portable-simd`` ``@workingjubilee``
2021-09-19 17:31:29 +09:00
Yuki Okushi
ebd31f5f1a
Rollup merge of #87960 - hkmatsumoto:suggest-inexisting-field-for-unmentioned-field, r=estebank
Suggest replacing an inexisting field for an unmentioned field

Fix #87938

This PR adds a suggestion to replace an inexisting field for an
unmentioned field. Given the following code:
```rust
enum Foo {
    Bar { alpha: u8, bravo: u8, charlie: u8 },
}

fn foo(foo: Foo) {
    match foo {
        Foo::Bar {
            alpha,
            beta, // `bravo` miswritten as `beta` here.
            charlie,
        } => todo!(),
    }
}
```
the compiler now emits the error messages below.
```text
error[E0026]: variant `Foo::Bar` does not have a field named `beta`
 --> src/lib.rs:9:13
  |
9 |             beta, // `bravo` miswritten as `beta` here.
  |             ^^^^
  |             |
  |             variant `Foo::Bar` does not have this field
  |             help: `Foo::Bar` has a field named `bravo`: `bravo`
```

Note that this suggestion is available iff the number of inexisting
fields and unmentioned fields are both 1.
2021-09-19 17:31:29 +09:00
bors
3bca7230ff Auto merge of #89028 - Aaron1011:coercion-cause, r=nagisa
Propagate coercion cause into `try_coerce`

Currently, `coerce_inner` discards its `ObligationCause`
when calling `try_coerce`. This interfers with other
diagnostc improvements I'm working on, since we will lose
the original span by the time the actual coercion occurs.

Additionally, we now use the span of the trailing expression
(rather than the span of the entire function) when performing
a coercion in `check_return_expr`. This currently has no visible
effect on any of the unit tests, but will unblock future
diagnostic improvements.
2021-09-19 04:34:16 +00:00
Gus Wynn
08e026675e deduplication 2021-09-18 13:00:36 -07:00
Gus Wynn
f1021bf054 generic test 2021-09-18 12:23:16 -07:00
Jakub Beránek
68147ebd60
Suggest better place to add call parentheses for method expressions wrapped in parentheses 2021-09-18 13:55:40 +02:00
Guillaume Gomez
6f5c09849e
Rollup merge of #88949 - FabianWolff:issue-87563, r=estebank
Fix handling of `hir::GenericArg::Infer` in `wrong_number_of_generic_args.rs`

Fixes #87563. More precisely, I have fixed the "index out of bounds" error, which is what #87563 is about. The example given there still ICEs due to running into this `todo!()`, but I'd say that this is a separate issue:
c3c0f80d60/compiler/rustc_typeck/src/astconv/mod.rs (L460-L463)
2021-09-17 17:41:17 +02:00
Guillaume Gomez
307f2ddfa4
Rollup merge of #88899 - FabianWolff:issue-88844, r=matthewjasper
Do not issue E0071 if a type error has already been reported

Fixes #88844. A suggested fix is already included in the error message for E0412, so with my changes, E0071 is simply not emitted anymore if the type in question is a "type error". This makes sense, I think, because we cannot confidently state that something is "not a struct" if we couldn't resolve it properly; and it's unnecessary to pollute the output with this additional error message, as it is a direct consequence of the former error.

I have also addressed the issue mentioned in https://github.com/rust-lang/rust/issues/88844#issuecomment-917324856 by changing the fixed example in the documentation to more closely match the erroneous code example.
2021-09-17 17:41:16 +02:00
Aaron Hill
31cdd8cdd2
Propagate coercion cause into try_coerce
Currently, `coerce_inner` discards its `ObligationCause`
when calling `try_coerce`. This interfers with other
diagnostc improvements I'm working on, since we will lose
the original span by the time the actual coercion occurs.

Additionally, we now use the span of the trailing expression
(rather than the span of the entire function) when performing
a coercion in `check_return_expr`. This currently has no visible
effect on any of the unit tests, but will unblock future
diagnostic improvements.
2021-09-16 16:53:40 -05:00
Esteban Kuber
4951e3ad9e Point at argument when evaluating Path's bounds
When evaluating an `ExprKind::Call`, we first have to `check_expr` on it's
callee. When this one is a `ExprKind::Path`, we had to evaluate the bounds
introduced for its arguments, but by the time we evaluated them we no
longer had access to the argument spans. Now we special case this so
that we can point at the right place on unsatisfied bounds. This also
allows the E0277 deduplication to kick in correctly, so we now emit
fewer errors.
2021-09-16 12:12:28 +00:00
Esteban Kuber
8a3f712518 Refactor FulfillmentError to track less data
Move the information about pointing at the call argument expression in
an unmet obligation span from the `FulfillmentError` to a new
`ObligationCauseCode`.
2021-09-16 12:12:27 +00:00
Esteban Kuber
284a8a9ce7 Point at argument instead of call for their obligations
When an obligation is introduced by a specific `fn` argument, point at
the argument instead of the `fn` call if the obligation fails to be
fulfilled.
2021-09-16 12:12:27 +00:00
bors
2b5ddf36fd Auto merge of #86809 - DevinR528:reachable-pat, r=Nadrieril
Add non_exhaustive_omitted_patterns lint related to rfc-2008-non_exhaustive

Fixes: #84332

This PR adds `non_exhaustive_omitted_patterns`, an allow by default lint that is triggered when a `non_exhaustive` type is missing explicit patterns. The warning or deny attribute can be put above the wildcard `_` pattern on enums or on the expression for enums or structs. The lint is capable of warning about multiple types within the same pattern. This lint will not be triggered for `if let ..` patterns.

```rust
// crate A
#[non_exhaustive]
pub struct Foo {
    a: u8,
    b: usize,
}
#[non_exhaustive]
pub enum Bar {
    A(Foo),
    B,
}

// crate B
#[deny(non_exhaustive_omitted_patterns)] // here
match Bar::B {
    Bar::B => {}
    #[deny(non_exhaustive_omitted_patterns)] // or here
    _ => {}
}

#[warn(non_exhaustive_omitted_patterns)] // only here
let Foo { a, .. } = Foo::default();

#[deny(non_exhaustive_omitted_patterns)]
match Bar::B {
    // triggers for Bar::B, and Foo.b
    Bar::A(Foo { a, .. }) => {}
    // if the attribute was here only Bar::B would cause a warning
    _ => {}
}
```
2021-09-16 05:29:22 +00:00
Manish Goregaokar
1bf94a156a
Rollup merge of #88841 - notriddle:notriddle/method-parens, r=estebank
feat(rustc_typeck): suggest removing bad parens in `(recv.method)()`

Fixes #88803
2021-09-15 14:56:59 -07:00
Gus Wynn
110aecd23e factor into struct, and comments 2021-09-15 11:48:34 -07:00
Fabian Wolff
2a2bfd1e59 Fix handling of hir::GenericArg::Infer in wrong_number_of_generic_args.rs 2021-09-15 01:25:51 +02:00
Devin Ragotzy
33a06b73d9 Add reachable_patterns lint to rfc-2008-non_exhaustive
Add linting on non_exhaustive structs and enum variants

Add ui tests for non_exhaustive reachable lint

Rename to non_exhaustive_omitted_patterns and avoid triggering on if let
2021-09-14 15:45:13 -04:00
bors
9bb77da74d Auto merge of #87915 - estebank:fancy-spans, r=oli-obk
Use smaller spans for some structured suggestions

Use more accurate suggestion spans for

* argument parse error
* fully qualified path
* missing code block type
* numeric casts
2021-09-13 16:31:12 +00:00
Gus Wynn
2af1ebfbdf error formatting and fix build 2021-09-13 08:19:40 -07:00
Hirochika Matsumoto
37196e3691 Suggest replacing an inexisting field for an unmentioned field
This PR adds a suggestion to replace an inexisting field for an
unmentioned field. Given the following code:
```rust
enum Foo {
    Bar { alpha: u8, bravo: u8, charlie: u8 },
}

fn foo(foo: Foo) {
    match foo {
        Foo::Bar {
            alpha,
            beta, // `bravo` miswritten as `beta` here.
            charlie,
        } => todo!(),
    }
}
```
the compiler now emits the error messages below.
```text
error[E0026]: variant `Foo::Bar` does not have a field named `beta`
 --> src/lib.rs:9:13
  |
9 |             beta, // `bravo` miswritten as `beta` here.
  |             ^^^^
  |             |
  |             variant `Foo::Bar` does not have this field
  |             help: `Foo::Bar` has a field named `bravo`: `bravo`
```

Note that this suggestion is available iff the number of inexisting
fields and unmentioned fields are both 1.
2021-09-13 21:16:05 +09:00
Michael Howell
8be729cdd6 chore: convert to a multi-part suggestion 2021-09-12 19:51:09 -07:00
Fabian Wolff
ab83d501a4 Do not issue E0071 if a type error has already been reported 2021-09-12 23:07:23 +02:00
bors
51e514c0fb Auto merge of #88759 - Amanieu:panic_in_drop, r=nagisa,eddyb
Add -Z panic-in-drop={unwind,abort} command-line option

This PR changes `Drop` to abort if an unwinding panic attempts to escape it, making the process abort instead. This has several benefits:
- The current behavior when unwinding out of `Drop` is very unintuitive and easy to miss: unwinding continues, but the remaining drops in scope are simply leaked.
- A lot of unsafe code doesn't expect drops to unwind, which can lead to unsoundness:
  - https://github.com/servo/rust-smallvec/issues/14
  - https://github.com/bluss/arrayvec/issues/3
- There is a code size and compilation time cost to this: LLVM needs to generate extra landing pads out of all calls in a drop implementation. This can compound when functions are inlined since unwinding will then continue on to process drops in the callee, which can itself unwind, etc.
  - Initial measurements show a 3% size reduction and up to 10% compilation time reduction on some crates (`syn`).

One thing to note about `-Z panic-in-drop=abort` is that *all* crates must be built with this option for it to be sound since it makes the compiler assume that dropping `Box<dyn Any>` will never unwind.

cc https://github.com/rust-lang/lang-team/issues/97
2021-09-12 20:48:09 +00:00
Camille GILLOT
fa6f5adf73 Gather module items after lowering. 2021-09-12 16:33:16 +02:00
bors
c7dbe7a830 Auto merge of #88881 - Manishearth:rollup-alohfwx, r=Manishearth
Rollup of 7 pull requests

Successful merges:

 - #88336 ( Detect stricter constraints on gats where clauses in impls vs trait)
 - #88677 (rustc: Remove local variable IDs from `Export`s)
 - #88699 (Remove extra unshallow from cherry-pick checker)
 - #88709 (generic_const_exprs: use thir for abstract consts instead of mir)
 - #88711 (Rework DepthFirstSearch API)
 - #88810 (rustdoc: Cleanup `clean` part 1)
 - #88813 (explicitly link to external `ena` docs)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
2021-09-12 13:29:56 +00:00
Manish Goregaokar
bb5ca58d29
Rollup merge of #88677 - petrochenkov:exportid, r=davidtwco
rustc: Remove local variable IDs from `Export`s

Local variables can never be exported.
2021-09-12 03:44:53 -07:00
bors
9ef27bf7dc Auto merge of #88771 - jackh726:wf_tys_set, r=nikomatsakis
Use FxHashSet instead of Vec for well formed tys

Trying to recover perf from #88312

r? `@ghost`
2021-09-12 10:32:55 +00:00
bors
547d9374d2 Auto merge of #84373 - cjgillot:resolve-span, r=michaelwoerister,petrochenkov
Encode spans relative to the enclosing item

The aim of this PR is to avoid recomputing queries when code is moved without modification.

MCP at https://github.com/rust-lang/compiler-team/issues/443

This is achieved by :
1. storing the HIR owner LocalDefId information inside the span;
2. encoding and decoding spans relative to the enclosing item in the incremental on-disk cache;
3. marking a dependency to the `source_span(LocalDefId)` query when we translate a span from the short (`Span`) representation to its explicit (`SpanData`) representation.

Since all client code uses `Span`, step 3 ensures that all manipulations
of span byte positions actually create the dependency edge between
the caller and the `source_span(LocalDefId)`.
This query return the actual absolute span of the parent item.
As a consequence, any source code motion that changes the absolute byte position of a node will either:
- modify the distance to the parent's beginning, so change the relative span's hash;
- dirty `source_span`, and trigger the incremental recomputation of all code that
  depends on the span's absolute byte position.

With this scheme, I believe the dependency tracking to be accurate.

For the moment, the spans are marked during lowering.
I'd rather do this during def-collection,
but the AST MutVisitor is not practical enough just yet.
The only difference is that we attach macro-expanded spans
to their expansion point instead of the macro itself.
2021-09-11 23:35:28 +00:00
Gus Wynn
461a0f3da4 array comment + test for references 2021-09-11 12:24:40 -07:00
Gus Wynn
74ea16301e skip the uninhabitated check and comments 2021-09-11 12:10:06 -07:00
Gus Wynn
67ee91e77e remove attempt at fn call 2021-09-11 10:50:09 -07:00
Gus Wynn
2271376fb2 must_not_suspend impl 2021-09-11 10:45:17 -07:00
Jubilee
c2e1097f44
Rollup merge of #88849 - matthiaskrgr:clony_on_copy, r=petrochenkov
don't clone types that are Copy (clippy::clone_on_copy)
2021-09-11 08:23:45 -07:00
Jubilee
08cbb7dbe1
Rollup merge of #88757 - andrewhickman:master, r=jackh726
Suggest wapping expr in parentheses on invalid unary negation

Fixes #88701
2021-09-11 08:23:42 -07:00
Jubilee
94cbefb52a
Rollup merge of #88147 - FabianWolff:issue-88097, r=jackh726
Fix non-capturing closure return type coercion

Fixes #88097. For the example given there:
```rust
fn peculiar() -> impl Fn(u8) -> u8 {
    return |x| x + 1
}
```
which incorrectly reports an error, I noticed something weird in the debug log:
```
DEBUG rustc_typeck::check::coercion coercion::try_find_coercion_lub([closure@test.rs:2:12: 2:21], [closure@test.rs:2:12: 2:21], exprs=1 exprs)
```
Apparently, `try_find_coercion_lub()` thinks that the LUB for two closure types always has to be a function pointer (which explains the `expected closure, found fn pointer` error in #88097). There is one corner case where that isn't true, though — namely, when the two closure types are equal, in which case the trivial LUB is the type itself. This PR fixes this by inserting an explicit check for type equality in `try_find_coercion_lub()`.
2021-09-11 08:23:39 -07:00