Commit Graph

655 Commits

Author SHA1 Message Date
lcnr
43ebac119b extract ConstKind::Unevaluated into a struct 2021-03-20 17:21:44 +01:00
bors
41b315a470 Auto merge of #83271 - SparrowLii:simd_neg, r=Amanieu
Add simd_neg platform intrinsic

Stdarch needs to add simd_neg to support the implementation of vneg neon instructions. Look [here](https://github.com/rust-lang/stdarch/pull/1087)
2021-03-20 09:01:35 +00:00
bors
cd82e451a8 Auto merge of #83293 - osa1:82436_perf, r=varkor
Revert performance-sensitive change in #82436

This change was done in #82436, as an "optimization". Unfortunately I
missed that this code is not always executed, because of the "continue"
in the conditional above it.

This commit should solve the perf regressions introduced by #82436 as I
think there isn't anything else that could affect runtime performance in
that PR. The `Pick` type grows only one word, which I doubt can cause up
to 8.8% increase in RSS in some of the benchmarks.

---

Could someone with the rights start a perf job please?
2021-03-20 03:49:10 +00:00
Ömer Sinan Ağacan
f9257576db Revert performance-sensitive change in #82436
This change was done in #82436, as an "optimization". Unfortunately I
missed that this code is not always executed, because of the "continue"
in the conditional above it.

This commit should solve the perf regressions introduced by #82436 as I
think there isn't anything else that could affect runtime performance in
that PR. The `Pick` type grows only one word, which I doubt can cause up
to 8.8% increase in RSS in some of the benchmarks.
2021-03-19 11:37:52 +03:00
Jennifer Wills
52dba13e41 Replace closures_captures and upvar_capture with closure_min_captures
make changes to liveness to use closure_min_captures

use different span

borrow check uses new structures

rename to CapturedPlace

stop using upvar_capture in regionck

remove the bridge

cleanup from rebase + remove the upvar_capture reference from mutability_errors.rs

remove line from livenes test

make our unused var checking more consistent

update tests

adding more warnings to the tests

move is_ancestor_or_same_capture to rustc_middle/ty

update names to reflect the closures

add FIXME

check that all captures are immutable borrows before returning

add surrounding if statement like the original

move var out of the loop and rename

Co-authored-by: Logan Mosier <logmosier@gmail.com>
Co-authored-by: Roxane Fruytier <roxane.fruytier@hotmail.com>
2021-03-18 20:45:49 -04:00
SparrowLii
0fa158b38f Add simd_neg platform intrinsic 2021-03-19 02:16:21 +08:00
Vadim Petrochenkov
b48530bf8b Report missing cases of bare_trait_objects 2021-03-18 03:02:44 +03:00
Vadim Petrochenkov
38ed36bba4 hir: Preserve used syntax in TyKind::TraitObject 2021-03-18 03:02:32 +03:00
Vadim Petrochenkov
dac96d45af Fix use of bare trait objects everywhere 2021-03-18 02:18:58 +03:00
bors
b4adc21c4f Auto merge of #83188 - petrochenkov:field, r=lcnr
ast/hir: Rename field-related structures

I always forget what `ast::Field` and `ast::StructField` mean despite working with AST for long time, so this PR changes the naming to less confusing and more consistent.

- `StructField` -> `FieldDef` ("field definition")
- `Field` -> `ExprField` ("expression field", not "field expression")
- `FieldPat` -> `PatField` ("pattern field", not "field pattern")

Various visiting and other methods working with the fields are renamed correspondingly too.

The second commit reduces the size of `ExprKind` by boxing fields of `ExprKind::Struct` in preparation for https://github.com/rust-lang/rust/pull/80080.
2021-03-17 16:49:46 +00:00
Yuki Okushi
70edab895d
Rollup merge of #83092 - petrochenkov:qspan, r=estebank
More precise spans for HIR paths

`Ty::assoc_item` is lowered to `<Ty>::assoc_item` in HIR, but `Ty` got span from the whole path.
This PR fixes that, and adjusts some diagnostic code that relied on `Ty` having the whole path span.

This is a pre-requisite for https://github.com/rust-lang/rust/pull/82868 (we cannot report suggestions like `Tr::assoc` -> `<dyn Tr>::assoc` with the current imprecise spans).
r? ````@estebank````
2021-03-17 15:20:54 +09:00
bors
f5d8117c33 Auto merge of #82536 - sexxi-goose:handle-patterns-take-2, r=nikomatsakis
2229: Handle patterns within closures correctly when `capture_disjoint_fields` is enabled

This PR fixes several issues related to handling patterns within closures when `capture_disjoint_fields` is enabled.
1. Matching is always considered a use of the place, even with `_` patterns
2. Compiler ICE when capturing fields in closures through `let` assignments

To do so, we

- Introduced new Fake Reads
- Delayed use of `Place` in favor of `PlaceBuilder`
- Ensured that `PlaceBuilder` can be resolved before attempting to extract `Place` in any of the pattern matching code

Closes rust-lang/project-rfc-2229/issues/27
Closes rust-lang/project-rfc-2229/issues/24
r? `@nikomatsakis`
2021-03-16 19:19:06 +00:00
Vadim Petrochenkov
b25d3ba781 ast/hir: Rename field-related structures
StructField -> FieldDef ("field definition")
Field -> ExprField ("expression field", not "field expression")
FieldPat -> PatField ("pattern field", not "field pattern")

Also rename visiting and other methods working on them.
2021-03-16 11:41:24 +03:00
bors
195ad4830e Auto merge of #82898 - oli-obk:tait_🧊, r=nikomatsakis
Add a `min_type_alias_impl_trait` feature gate

This new feature gate only permits type alias impl trait to be constrained by function and trait method return types. All other possible constraining sites like const/static types, closure return types and binding types are now forbidden and gated under the `type_alias_impl_trait` and `impl_trait_in_bindings` feature gates (which are both marked as incomplete, as they have various ways to ICE the compiler or cause query cycles where they shouldn't).

r? `@nikomatsakis`

This is best reviewed commit-by-commit
2021-03-16 04:24:48 +00:00
Vadim Petrochenkov
7e66e9d6b0 More precise spans for HIR paths 2021-03-15 22:13:45 +03:00
Oli Scherer
c2683aa569 Explain each variant of TAIT usage with examples 2021-03-15 17:39:18 +00:00
Oli Scherer
4a6dc8e203 Only allow tait defining uses in function and method return position 2021-03-15 17:36:57 +00:00
Oli Scherer
cdbb0ff8ca Special case type aliases from impl trait in const/static types 2021-03-15 17:33:28 +00:00
Roxane
22eaffe71a Add comments with examples and tests 2021-03-15 13:16:04 -04:00
Dylan DPC
8ec9b2a0ac
Rollup merge of #83113 - osa1:refactor_try_index_step, r=jonas-schievink
Minor refactoring in try_index_step

Merges `if-let` and `if x.is_some() { ... }` blocks
2021-03-15 16:22:56 +01:00
bors
3963c3da02 Auto merge of #83074 - Aaron1011:new-sort-fix, r=jackh726
Avoid sorting predicates by `DefId`

Fixes issue #82920

Even if an item does not change between compilation sessions, it may end
up with a different `DefId`, since inserting/deleting an item affects
the `DefId`s of all subsequent items. Therefore, we use a `DefPathHash`
in the incremental compilation system, which is stable in the face of
changes to unrelated items.

In particular, the query system will consider the inputs to a query to
be unchanged if any `DefId`s in the inputs have their `DefPathHash`es
unchanged. Queries are pure functions, so the query result should be
unchanged if the query inputs are unchanged.

Unfortunately, it's possible to inadvertantly make a query result
incorrectly change across compilations, by relying on the specific value
of a `DefId`. Specifically, if the query result is a slice that gets
sorted by `DefId`, the precise order will depend on how the `DefId`s got
assigned in a particular compilation session. If some definitions end up
with different `DefId`s (but the same `DefPathHash`es) in a subsequent
compilation session, we will end up re-computing a *different* value for
the query, even though the query system expects the result to unchanged
due to the unchanged inputs.

It turns out that we have been sorting the predicates computed during
`astconv` by their `DefId`. These predicates make their way into the
`super_predicates_that_define_assoc_type`, which ends up getting used to
compute the vtables of trait objects. This, re-ordering these predicates
between compilation sessions can lead to undefined behavior at runtime -
the query system will re-use code built with a *differently ordered*
vtable, resulting in the wrong method being invoked at runtime.

This PR avoids sorting by `DefId` in `astconv`, fixing the
miscompilation. However, it's possible that other instances of this
issue exist - they could also be easily introduced in the future.

To fully fix this issue, we should
1. Turn on `-Z incremental-verify-ich` by default. This will cause the
   compiler to ICE whenver an 'unchanged' query result changes between
   compilation sessions, instead of causing a miscompilation.
2. Remove the `Ord` impls for `CrateNum` and `DefId`. This will make it
   difficult to introduce ICEs in the first place.
2021-03-15 06:20:24 +00:00
Roxane
74fc64303f Only borrow place for matching under specific conditions 2021-03-14 19:42:00 -04:00
Roxane
685a4c6b6b Use the correct FakeReadCause 2021-03-14 19:28:57 -04:00
Roxane
b6cf070eb4 Attempt to deal with nested closures properly 2021-03-14 17:07:59 -04:00
Roxane
ec10b71d42 Introduce new fake reads 2021-03-14 16:31:26 -04:00
Ömer Sinan Ağacan
6ddd840f36 Minor refactoring in try_index_step
Merges `if-let` and `if x.is_some() { ... }` blocks
2021-03-14 16:00:07 +03:00
Aaron Hill
06546d4b40
Avoid sorting predicates by DefId
Fixes issue #82920

Even if an item does not change between compilation sessions, it may end
up with a different `DefId`, since inserting/deleting an item affects
the `DefId`s of all subsequent items. Therefore, we use a `DefPathHash`
in the incremental compilation system, which is stable in the face of
changes to unrelated items.

In particular, the query system will consider the inputs to a query to
be unchanged if any `DefId`s in the inputs have their `DefPathHash`es
unchanged. Queries are pure functions, so the query result should be
unchanged if the query inputs are unchanged.

Unfortunately, it's possible to inadvertantly make a query result
incorrectly change across compilations, by relying on the specific value
of a `DefId`. Specifically, if the query result is a slice that gets
sorted by `DefId`, the precise order will depend on how the `DefId`s got
assigned in a particular compilation session. If some definitions end up
with different `DefId`s (but the same `DefPathHash`es) in a subsequent
compilation session, we will end up re-computing a *different* value for
the query, even though the query system expects the result to unchanged
due to the unchanged inputs.

It turns out that we have been sorting the predicates computed during
`astconv` by their `DefId`. These predicates make their way into the
`super_predicates_that_define_assoc_type`, which ends up getting used to
compute the vtables of trait objects. This, re-ordering these predicates
between compilation sessions can lead to undefined behavior at runtime -
the query system will re-use code built with a *differently ordered*
vtable, resulting in the wrong method being invoked at runtime.

This PR avoids sorting by `DefId` in `astconv`, fixing the
miscompilation. However, it's possible that other instances of this
issue exist - they could also be easily introduced in the future.

To fully fix this issue, we should
1. Turn on `-Z incremental-verify-ich` by default. This will cause the
   compiler to ICE whenver an 'unchanged' query result changes between
   compilation sessions, instead of causing a miscompilation.
2. Remove the `Ord` impls for `CrateNum` and `DefId`. This will make it
   difficult to introduce ICEs in the first place.
2021-03-13 13:45:12 -05:00
bors
178bd9130e Auto merge of #82878 - sexxi-goose:repr_packed, r=nikomatsakis
2229: Handle capturing a reference into a repr packed struct

RFC 1240 states that it is unsafe to capture references into a
packed-struct. This PR ensures that when a closure captures a precise
path, we aren't violating this safety constraint.

To acheive so we restrict the capture precision to the struct itself.

An interesting edge case where we decided to restrict precision:
```rust
struct Foo(String);

let foo: Foo;
let c = || {
    println!("{}", foo.0);
    let x = foo.0;
}
```

Given how closures get desugared today, foo.0 will be moved into the
closure, making the `println!`, safe. However this can be very subtle
and also will be unsafe if the closure gets inline.

Closes: https://github.com/rust-lang/project-rfc-2229/issues/33

r? `@nikomatsakis`
2021-03-13 09:47:07 +00:00
bors
f42888c15f Auto merge of #82436 - osa1:issue80258, r=nikomatsakis
Allow calling *const methods on *mut values

This allows `*const` methods to be called on `*mut` values.

TODOs:

- [x] ~~Remove debug logs~~ Done.
- [x] ~~I haven't tested, but I think this currently won't work when the `self` value has type like `&&&&& *mut X` because I don't do any autoderefs when probing. To fix this the new code in `rustc_typeck::check::method::probe` needs to reuse `pick_method` somehow as I think that's the function that autoderefs.~~ This works, because autoderefs are done before calling `pick_core`, in `method_autoderef_steps`, called by `probe_op`.
- [x] ~~I should probably move the new `Pick` to `pick_autorefd_method`. If not, I should move it to its own function.~~ Done.
- [ ] ~~Test this with a `Pick` with `to_ptr = true` and `unsize = true`.~~ I think this case cannot happen, because we don't have any array methods with `*mut [X]` receiver. I should confirm that this is true and document this. I've placed two assertions about this.
- [x] ~~Maybe give `(Mutability, bool)` a name and fields~~ I now have a `to_const_ptr` field in `Pick`.
- [x] ~~Changes in `adjust_self_ty` is quite hacky. The problem is we can't deref a pointer, and even if we don't have an adjustment to get the address of a value, so to go from `*mut` to `*const` we need a special case.~~ There's still a special case for `to_const_ptr`, but I'm not sure if we can avoid this.
- [ ] Figure out how `reached_raw_pointer` stuff is used. I suspect only for error messages.

Fixes #80258
2021-03-13 04:38:39 +00:00
bors
17a07d71bf Auto merge of #76570 - cratelyn:implement-rfc-2945-c-unwind-abi, r=Amanieu
Implement RFC 2945: "C-unwind" ABI

## Implement RFC 2945: "C-unwind" ABI

This branch implements [RFC 2945]. The tracking issue for this RFC is #74990.

The feature gate for the issue is `#![feature(c_unwind)]`.

This RFC was created as part of the ffi-unwind project group tracked at rust-lang/lang-team#19.

### Changes

Further details will be provided in commit messages, but a high-level overview
of the changes follows:

* A boolean `unwind` payload is added to the `C`, `System`, `Stdcall`,
and `Thiscall` variants, marking whether unwinding across FFI boundaries is
acceptable. The cases where each of these variants' `unwind` member is true
correspond with the `C-unwind`, `system-unwind`, `stdcall-unwind`, and
`thiscall-unwind` ABI strings introduced in RFC 2945 [3].

* This commit adds a `c_unwind` feature gate for the new ABI strings.
Tests for this feature gate are included in `src/test/ui/c-unwind/`, which
ensure that this feature gate works correctly for each of the new ABIs.
A new language features entry in the unstable book is added as well.

* We adjust the `rustc_middle::ty::layout::fn_can_unwind` function,
used to compute whether or not a `FnAbi` object represents a function that
should be able to unwind when `panic=unwind` is in use.

* Changes are also made to
`rustc_mir_build::build::should_abort_on_panic` so that the function ABI is
used to determind whether it should abort, assuming that the `panic=unwind`
strategy is being used, and no explicit unwind attribute was provided.

[RFC 2945]: https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md
2021-03-10 16:44:04 +00:00
bors
dff1edf919 Auto merge of #79519 - cjgillot:noattr, r=wesleywiser
Store HIR attributes in a side table

Same idea as #72015 but for attributes.
The objective is to reduce incr-comp invalidations due to modified attributes.
Notably, those due to modified doc comments.

Implementation:
- collect attributes during AST->HIR lowering, in `LocalDefId -> ItemLocalId -> &[Attributes]` nested tables;
- access the attributes through a `hir_owner_attrs` query;
- local refactorings to use this access;
- remove `attrs` from HIR data structures one-by-one.

Change in behaviour:
- the HIR visitor traverses all attributes at once instead of parent-by-parent;
- attribute arrays are sometimes duplicated: for statements and variant constructors;
- as a consequence, attributes are marked as used after unused-attribute lint emission to avoid duplicate lints.

~~Current bug: the lint level is not correctly applied in `std::backtrace_rs`, triggering an unused attribute warning on `#![no_std]`. I welcome suggestions.~~
2021-03-10 08:40:51 +00:00
Aman Arora
612a9b2f95 2229: Handle capturing a reference into a repr packed struct
RFC 1240 states that it is unsafe to capture references into a
packed-struct. This PR ensures that when a closure captures a precise
path, we aren't violating this safety constraint.

To acheive so we restrict the capture precision to the struct itself.

An interesting edge case:
```rust
struct Foo(String);

let foo: Foo;
let c = || {
    println!("{}", foo.0);
    let x = foo.0;
}
```

Given how closures get desugared today, foo.0 will be moved into the
closure, making the `println!`, safe. However this can be very subtle
and also will be unsafe if the closure gets inline.

Closes: https://github.com/rust-lang/project-rfc-2229/issues/33
2021-03-09 20:23:02 -05:00
Yuki Okushi
9dc82face3
Rollup merge of #82942 - m-ou-se:diagnostics-hardcoded-prelude-v1, r=estebank
Don't hardcode the `v1` prelude in diagnostics, to allow for new preludes.

Instead of looking for `std::prelude::v1`, this changes the two places where that was hardcoded to look for `std::prelude::<anything>` instead.

This is needed for https://github.com/rust-lang/rust/pull/82217.

r? `@estebank`
2021-03-10 08:01:37 +09:00
katelyn a. martin
df45c579de rustc_target: add "unwind" payloads to Abi
### Overview

    This commit begins the implementation work for RFC 2945. For more
    information, see the rendered RFC [1] and tracking issue [2].

    A boolean `unwind` payload is added to the `C`, `System`, `Stdcall`,
    and `Thiscall` variants, marking whether unwinding across FFI
    boundaries is acceptable. The cases where each of these variants'
    `unwind` member is true correspond with the `C-unwind`,
    `system-unwind`, `stdcall-unwind`, and `thiscall-unwind` ABI strings
    introduced in RFC 2945 [3].

 ### Feature Gate and Unstable Book

    This commit adds a `c_unwind` feature gate for the new ABI strings.
    Tests for this feature gate are included in `src/test/ui/c-unwind/`,
    which ensure that this feature gate works correctly for each of the
    new ABIs.

    A new language features entry in the unstable book is added as well.

 ### Further Work To Be Done

    This commit does not proceed to implement the new unwinding ABIs,
    and is intentionally scoped specifically to *defining* the ABIs and
    their feature flag.

 ### One Note on Test Churn

    This will lead to some test churn, in re-blessing hash tests, as the
    deleted comment in `src/librustc_target/spec/abi.rs` mentioned,
    because we can no longer guarantee the ordering of the `Abi`
    variants.

    While this is a downside, this decision was made bearing in mind
    that RFC 2945 states the following, in the "Other `unwind` Strings"
    section [3]:

    >  More unwind variants of existing ABI strings may be introduced,
    >  with the same semantics, without an additional RFC.

    Adding a new variant for each of these cases, rather than specifying
    a payload for a given ABI, would quickly become untenable, and make
    working with the `Abi` enum prone to mistakes.

    This approach encodes the unwinding information *into* a given ABI,
    to account for the future possibility of other `-unwind` ABI
    strings.

 ### Ignore Directives

    `ignore-*` directives are used in two of our `*-unwind` ABI test
    cases.

    Specifically, the `stdcall-unwind` and `thiscall-unwind` test cases
    ignore architectures that do not support `stdcall` and
    `thiscall`, respectively.

    These directives are cribbed from
    `src/test/ui/c-variadic/variadic-ffi-1.rs` for `stdcall`, and
    `src/test/ui/extern/extern-thiscall.rs` for `thiscall`.

    This would otherwise fail on some targets, see:
    fcf697f902

 ### Footnotes

[1]: https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md
[2]: https://github.com/rust-lang/rust/issues/74990
[3]: https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md#other-unwind-abi-strings
2021-03-09 14:38:29 -05:00
Mara Bos
1e4d8042fc Don't hardcode the v1 prelude in diagnostics.
Instead of looking for `std::prelude::v1`, this changes it to look for
`std::prelude::<anything>`.
2021-03-09 19:41:04 +01:00
Camille GILLOT
c701872a6c Remove hir::Item::attrs. 2021-03-09 19:27:50 +01:00
Camille GILLOT
8e816056a5 Do not store attrs in FnKind. 2021-03-09 19:09:33 +01:00
Ömer Sinan Ağacan
98fbc09f02 Allow calling *const methods on *mut values
Fixes #80258
2021-03-09 13:40:08 +03:00
Dylan DPC
041bc04be4
Rollup merge of #82755 - osa1:confirm_builtin_call_refactor, r=petrochenkov
Refactor confirm_builtin_call, remove partial if

Pass callee expr to `confirm_builtin_call`. This removes a partial
pattern match in `confirm_builtin_call` and the `panic` in the `else`
branch. The diff is large because of indentation changes caused by
removing the if-let.
2021-03-08 13:13:25 +01:00
Yuki Okushi
a5a825e6a3
Rollup merge of #82720 - henryboisdequin:fix-79040, r=oli-obk
Fix diagnostic suggests adding type `[type error]`

Fixes #79040

### Unresolved questions:

<del>Why does this change output the diagnostic twice (`src/test/ui/79040.rs`)?</del> Thanks `````@oli-obk`````
2021-03-07 10:41:15 +09:00
bors
dfe519b344 Auto merge of #82738 - estebank:tail-expr-check-is-too-slow, r=oli-obk
Move check only relevant in error case out of critical path

Move the check for potentially forgotten `return` in a tail expression
of arbitrary expressions into the coercion error branch to avoid
computing unncessary coercion checks on successful code.

Follow up to #81458.
2021-03-06 21:02:53 +00:00
Henry Boisdequin
7d3a6f1655 address comments 2021-03-06 08:21:08 +05:30
Mara
e6a6df5daa
Rollup merge of #80723 - rylev:noop-lint-pass, r=estebank
Implement NOOP_METHOD_CALL lint

Implements the beginnings of https://github.com/rust-lang/lang-team/issues/67 - a lint for detecting noop method calls (e.g, calling `<&T as Clone>::clone()` when `T: !Clone`).

This PR does not fully realize the vision and has a few limitations that need to be addressed either before merging or in subsequent PRs:
* [ ] No UFCS support
* [ ] The warning message is pretty plain
* [ ] Doesn't work for `ToOwned`

The implementation uses [`Instance::resolve`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/instance/struct.Instance.html#method.resolve) which is normally later in the compiler. It seems that there are some invariants that this function relies on that we try our best to respect. For instance, it expects substitutions to have happened, which haven't yet performed, but we check first for `needs_subst` to ensure we're dealing with a monomorphic type.

Thank you to ```@davidtwco,``` ```@Aaron1011,``` and ```@wesleywiser``` for helping me at various points through out this PR ❤️.
2021-03-05 10:57:14 +01:00
Ömer Sinan Ağacan
c8a0e8d61b Refactor confirm_builtin_call, remove partial if
Pass callee expr to `confirm_builtin_call`. This removes a partial
pattern match in `confirm_builtin_call` and the `panic` in the `else`
branch. The diff is large because of indentation changes caused by
removing the if-let.
2021-03-04 13:39:41 +03:00
Esteban Küber
c6c243ae1e Move check only relevant in error case out of critical path
Move the check for potentially forgotten `return` in a tail expression
of arbitrary expressions into the coercion error branch to avoid
computing unncessary coercion checks on successful code.

Follow up to #81458.
2021-03-03 18:28:53 -08:00
Henry Boisdequin
d9d69212c3 Fix diagnostic suggests adding type [type error]
Fixes #79040

Unresolved questions:

Why does this change output the diagnostic twice?

Why does the CI fail when the errors are pointed out (UI tests)?
2021-03-03 16:50:07 +05:30
Ryan Levick
a6d926d80d Fix tests 2021-03-03 11:22:44 +01:00
Yuki Okushi
64b76da4b6
Rollup merge of #82695 - XAMPPRocky:remove-non-power-of-two-limit, r=nagisa
Revert non-power-of-two vector restriction

Removes the power of two restriction from rustc. As discussed in https://github.com/rust-lang/stdsimd/issues/63

r? ```@calebzulawski```

cc ```@workingjubilee``` ```@thomcc```
2021-03-03 16:27:44 +09:00
Yuki Okushi
2c40e13b84
Rollup merge of #82627 - JohnTitor:issue-82612, r=estebank
Erase late bound regions to avoid ICE

Fixes #82612, which is caused by #81769.

r? `@estebank`
2021-03-02 21:23:20 +09:00
Yuki Okushi
5e68c60406
Rollup merge of #82516 - PoignardAzur:inherent-impl-ty, r=oli-obk
Add incomplete feature gate for inherent associate types.

Mentored by ``````@oli-obk``````

So far the only change is that instead of giving an automatic error, the following code compiles:

```rust
struct Foo;

impl Foo {
    type Bar = isize;
}
```

The backend work to make it actually usable isn't there yet. In particular, this:

```rust
let x : Foo::Bar;
```

will give you:

```sh
error[E0223]: ambiguous associated type
  --> /$RUSTC_DIR/src/test/ui/assoc-inherent.rs:15:13
   |
LL |     let x : Foo::Bar;
   |             ^^^^^^^^ help: use fully-qualified syntax: `<Foo as Trait>::Bar`
```
2021-03-02 21:23:15 +09:00