Commit Graph

340 Commits

Author SHA1 Message Date
est31
6df5ae4fb0 Match unmatched backticks in comments in compiler/ 2023-03-03 08:39:00 +01:00
Takayuki Maeda
934c8c2299 avoid &str to String conversions 2023-02-27 14:27:13 +09:00
clubby789
885f9e72d7 Complete migrating ast_passes to derive diagnostics 2023-02-25 15:19:13 +00:00
Michael Goulet
e7c490892f Move associated type bounds check to ast lowering
This makes the check for when associated type bounds more accurate
2023-02-22 20:18:14 +00:00
David Wood
d1fcf61117 errors: generate typed identifiers in each crate
Instead of loading the Fluent resources for every crate in
`rustc_error_messages`, each crate generates typed identifiers for its
own diagnostics and creates a static which are pulled together in the
`rustc_driver` crate and provided to the diagnostic emitter.

Signed-off-by: David Wood <david.wood@huawei.com>
2023-02-22 09:15:53 +00:00
Nicholas Nethercote
1807027248 Use ThinVec in ast::AngleBracketedArgs. 2023-02-21 11:51:56 +11:00
Nicholas Nethercote
4143b101f9 Use ThinVec in various AST types.
This commit changes the sequence parsers to produce `ThinVec`, which
triggers numerous conversions.
2023-02-21 11:51:56 +11:00
Matthias Krüger
089e8c03bc
Rollup merge of #107489 - compiler-errors:non_lifetime_binders, r=cjgillot
Implement partial support for non-lifetime binders

This implements support for non-lifetime binders. It's pretty useless currently, but I wanted to put this up so the implementation can be discussed.

Specifically, this piggybacks off of the late-bound lifetime collection code in `rustc_hir_typeck::collect::lifetimes`. This seems like a necessary step given the fact we don't resolve late-bound regions until this point, and binders are sometimes merged.

Q: I'm not sure if I should go along this route, or try to modify the earlier nameres code to compute the right bound var indices for type and const binders eagerly... If so, I'll need to rename all these queries to something more appropriate (I've done this for `resolve_lifetime::Region` -> `resolve_lifetime::ResolvedArg`)

cc rust-lang/types-team#81

r? `@ghost`
2023-02-17 00:19:34 +01:00
Maybe Waffle
5bf6a46032 Replace some thens with some then_somes 2023-02-16 15:26:03 +00:00
Maybe Waffle
8751fa1a9a if $c:expr { Some($r:expr) } else { None } =>> $c.then(|| $r) 2023-02-16 15:26:00 +00:00
Michael Goulet
262a344d72 Add feature gate for non_lifetime_binders 2023-02-16 03:39:58 +00:00
mejrs
cc5af33d64 Autoderive ExternBlockSuggestion 2023-01-19 13:52:15 +01:00
Deadbeef
e7fea8c7e6 gate const closures 2023-01-12 02:28:37 +00:00
Deadbeef
5da1a04278 Allow impl ~const Trait opaque types 2022-12-15 11:26:15 +00:00
Takayuki Maeda
ee40a67cd9 remove unnecessary uses of clone 2022-12-13 02:06:24 +09:00
bors
d6c4de0fb2 Auto merge of #104861 - nnethercote:attr-cleanups, r=petrochenkov
Attribute cleanups

Best reviewed one commit at a time.

r? `@petrochenkov`
2022-12-01 07:13:45 +00:00
Maybe Waffle
07b86a94c7 rustc_ast_passes: remove ref patterns 2022-11-29 08:09:57 +00:00
Nicholas Nethercote
c9ae38c71e Avoid unnecessary MetaItem/Attribute conversions.
`check_builtin_attribute` calls `parse_meta` to convert an `Attribute`
to a `MetaItem`, which it then checks. However, many callers of
`check_builtin_attribute` start with a `MetaItem`, and then convert it
to an `Attribute` by calling `cx.attribute(meta_item)`. This `MetaItem`
to `Attribute` to `MetaItem` conversion is silly.

This commit adds a new function `check_builtin_meta_item`, which can be
called instead from these call sites. `check_builtin_attribute` also now
calls it. The commit also renames `check_meta` as `check_attr` to better
match its arguments.
2022-11-29 12:08:57 +11:00
Maybe Waffle
94470f4efd Use as_deref in compiler (but only where it makes sense) 2022-11-16 21:58:58 +00:00
León Orell Valerian Liehr
5ef85bbd7c
Visit attributes of trait impl items during AST validation 2022-11-08 13:44:07 +01:00
Dylan DPC
5b6455318a
Rollup merge of #95710 - fee1-dead-contrib:stabilize_arbitrary_enum_discriminant, r=joshtriplett
Stabilize arbitrary_enum_discriminant, take 2

Documentation has been updated in https://github.com/rust-lang/reference/pull/1055. cc #86860 for previous stabilization report.

Not yet marks https://github.com/rust-lang/rust/issues/60553 as done: need documentation in the rust reference.
2022-10-26 17:32:53 +05:30
Nilstrieb
c65ebae221
Migrate all diagnostics 2022-10-23 10:09:44 +02:00
Deadbeef
988e75bb65 Stabilize arbitrary_enum_discriminant, take 2 2022-10-22 13:54:39 +08:00
Matthias Krüger
ed430ca5fe
Rollup merge of #103351 - oli-obk:tilde_const_impls, r=fee1-dead
Require Drop impls to have the same constness on its bounds as the bounds on the struct have

r? ``@fee1-dead``
2022-10-22 00:14:02 +02:00
Oli Scherer
349ba6bb51 Remove needless special cases and dead code 2022-10-21 14:21:44 +00:00
Dylan DPC
e11511dfa6
Rollup merge of #103051 - davidtwco:translation-tidying-up, r=compiler-errors
translation: doc comments with derives, subdiagnostic-less enum variants, more derive use

- Adds support for `doc` attributes in the diagnostic derives so that documentation comments don't result in the derive failing.
- Adds support for enum variants in the subdiagnostic derive to not actually correspond to an addition to a diagnostic.
- Made use of the derive in more places in the `rustc_ast_lowering`, `rustc_ast_passes`, `rustc_lint`, `rustc_session`, `rustc_infer` - taking advantage of recent additions like eager subdiagnostics, multispan suggestions, etc.

cc #100717
2022-10-21 17:29:58 +05:30
Deadbeef
ebf5028574 Improve "~const is not allowed here" message 2022-10-20 19:32:16 +00:00
David Wood
ea5d258a75 ast_passes: use derive more
Signed-off-by: David Wood <david.wood@huawei.com>
2022-10-17 09:54:24 +01:00
David Wood
b4ac26289f errors: AddToDiagnostic::add_to_diagnostic_with
`AddToDiagnostic::add_to_diagnostic_with` is similar to the previous
`AddToDiagnostic::add_to_diagnostic` but takes a function that can be
used by the caller to modify diagnostic messages originating from the
subdiagnostic (such as performing translation eagerly).

`add_to_diagnostic` now just calls `add_to_diagnostic_with` with an
empty closure.

Signed-off-by: David Wood <david.wood@huawei.com>
2022-10-10 14:20:16 +01:00
Dylan DPC
81b9d0b1d1
Rollup merge of #102868 - compiler-errors:rename-assoc-tyalias-to-ty, r=TaKO8Ki
Rename `AssocItemKind::TyAlias` to `AssocItemKind::Type`

Thanks `@camsteffen` for catching this in ast too, cc https://github.com/rust-lang/rust/pull/102829#issuecomment-1272649247
2022-10-10 13:43:43 +05:30
Michael Goulet
d3bd6beb97 Rename AssocItemKind::TyAlias to AssocItemKind::Type 2022-10-10 02:31:37 +00:00
Urgau
c084c26397 Split slice part of feature(half_open_range_patterns) to [...]_in_slices 2022-10-08 11:00:13 +02:00
Matthias Krüger
e9bec2fdd4
Rollup merge of #102273 - woppopo:relax_const_bound, r=fee1-dead
Allow `~const` bounds on non-const functions

Makes the behavior of bound of trait-associated functions and non-associated functions consistent.
2022-09-26 19:19:21 +02:00
Pietro Albini
3975d55d98
remove cfg(bootstrap) 2022-09-26 10:14:45 +02:00
woppopo
e4b08ab241 Allow ~const bounds on non-const functions 2022-09-26 05:00:31 +00:00
khyperia
9a206a78eb Improve the help message for an invalid calling convention 2022-09-22 22:18:30 +02:00
Jhonny Bill Mena
5f91719f75 UPDATE - rename SessionSubdiagnostic macro to Subdiagnostic
Also renames:
- sym::AddSubdiagnostic to sym:: Subdiagnostic
- rustc_diagnostic_item = "AddSubdiagnostic" to rustc_diagnostic_item = "Subdiagnostic"
2022-09-21 11:39:53 -04:00
Jhonny Bill Mena
19b348fed4 UPDATE - rename DiagnosticHandler trait to IntoDiagnostic 2022-09-21 11:39:52 -04:00
est31
173eb6f407 Only enable the let_else feature on bootstrap
On later stages, the feature is already stable.

Result of running:

rg -l "feature.let_else" compiler/ src/librustdoc/ library/ | xargs sed -s -i "s#\\[feature.let_else#\\[cfg_attr\\(bootstrap, feature\\(let_else\\)#"
2022-09-15 21:06:45 +02:00
bors
6153d3cbe6 Auto merge of #101212 - eholk:dyn-star, r=compiler-errors
Initial implementation of dyn*

This PR adds extremely basic and incomplete support for [dyn*](https://smallcultfollowing.com/babysteps//blog/2022/03/29/dyn-can-we-make-dyn-sized/). The goal is to get something in tree behind a flag to make collaboration easier, and also to make sure the implementation so far is not unreasonable. This PR does quite a few things:

* Introduce `dyn_star` feature flag
* Adds parsing for `dyn* Trait` types
* Defines `dyn* Trait` as a sized type
* Adds support for explicit casts, like `42usize as dyn* Debug`
  * Including const evaluation of such casts
* Adds codegen for drop glue so things are cleaned up properly when a `dyn* Trait` object goes out of scope
* Adds codegen for method calls, at least for methods that take `&self`

Quite a bit is still missing, but this gives us a starting point. Note that this is never intended to become stable surface syntax for Rust, but rather `dyn*` is planned to be used as an implementation detail for async functions in dyn traits.

Joint work with `@nikomatsakis` and `@compiler-errors.`

r? `@bjorn3`
2022-09-14 18:10:51 +00:00
bors
a0d1df4a5d Auto merge of #101709 - nnethercote:simplify-visitors-more, r=cjgillot
Simplify visitors more

A successor to #100392.

r? `@cjgillot`
2022-09-14 05:21:14 +00:00
Eric Holk
cf04547b0b Address code review comments 2022-09-13 14:50:12 -07:00
bors
7098c181f8 Auto merge of #96709 - jackh726:gats-stabilization, r=compiler-errors
Stabilize generic associated types

Closes #44265

r? `@nikomatsakis`

#  Status of the discussion 

* [x] There have been several serious concerns raised, [summarized here](https://github.com/rust-lang/rust/pull/96709#issuecomment-1129311660).
* [x] There has also been a [deep-dive comment](https://github.com/rust-lang/rust/pull/96709#issuecomment-1167220240) explaining some of the "patterns of code" that are enabled by GATs, based on use-cases posted to this thread or on the tracking issue.
* [x] We have modeled some aspects of GATs in [a-mir-formality](https://github.com/nikomatsakis/a-mir-formality) to give better confidence in how they will be resolved in the future. [You can read a write-up here](https://github.com/rust-lang/types-team/blob/master/minutes/2022-07-08-implied-bounds-and-wf-checking.md).
* [x] The major points of the discussion have been [summarized on the GAT initiative repository](https://rust-lang.github.io/generic-associated-types-initiative/mvp.html).
* [x] [FCP has been proposed](https://github.com/rust-lang/rust/pull/96709#issuecomment-1129311660) and we are awaiting final decisions and discussion amidst the relevant team members.

# Stabilization proposal

This PR proposes the stabilization of `#![feature(generic_associated_types)]`. While there a number of future additions to be made and bugs to be fixed (both discussed below), properly doing these will require significant language design and will ultimately likely be backwards-compatible. Given the overwhelming desire to have some form of generic associated types (GATs) available on stable and the stability of the "simple" uses, stabilizing the current subset of GAT features is almost certainly the correct next step.

Tracking issue: #44265
Initiative: https://rust-lang.github.io/generic-associated-types-initiative/
RFC: https://github.com/rust-lang/rfcs/blob/master/text/1598-generic_associated_types.md
Version: 1.65 (2022-08-22 => beta, 2022-11-03 => stable).

## Motivation

There are a myriad of potential use cases for GATs. Stabilization unblocks probable future language features (e.g. async functions in traits), potential future standard library features (e.g. a `LendingIterator` or some form of `Iterator` with a lifetime generic), and a plethora of user use cases (some of which can be seen just by scrolling through the tracking issue and looking at all the issues linking to it).

There are a myriad of potential use cases for GATs. First, there are many users that have chosen to not use GATs primarily because they are not stable (some of which can be seen just by scrolling through the tracking issue and looking at all the issues linking to it). Second, while language feature desugaring isn't *blocked* on stabilization, it gives more confidence on using the feature. Likewise, library features like `LendingIterator` are not necessarily blocked on stabilization to be implemented unstably; however few, if any, public-facing APIs actually use unstable features.

This feature has a long history of design, discussion, and developement - the RFC was first introduced roughly 6 years ago. While there are still a number of features left to implement and bugs left to fix, it's clear that it's unlikely those will have backwards-incompatibility concerns. Additionally, the bugs that do exist do not strongly impede the most-common use cases.

## What is stabilized

The primary language feature stabilized here is the ability to have generics on associated types, as so. Additionally, where clauses on associated types will now be accepted, regardless if the associated type is generic or not.

```rust
trait ATraitWithGATs {
    type Assoc<'a, T> where T: 'a;
}

trait ATraitWithoutGATs<'a, T> {
    type Assoc where T: 'a;
}
```

When adding an impl for a trait with generic associated types, the generics for the associated type are copied as well. Note that where clauses are allowed both after the specified type and before the equals sign; however, the latter is a warn-by-default deprecation.

```rust
struct X;
struct Y;

impl ATraitWithGATs for X {
    type Assoc<'a, T> = &'a T
      where T: 'a;
}
impl ATraitWithGATs for Y {
    type Assoc<'a, T>
      where T: 'a
    = &'a T;
}
```

To use a GAT in a function, generics are specified on the associated type, as if it was a struct or enum. GATs can also be specified in trait bounds:

```rust
fn accepts_gat<'a, T>(t: &'a T) -> T::Assoc<'a, T>
  where for<'x> T: ATraitWithGATs<Assoc<'a, T> = &'a T> {
    ...
}
```

GATs can also appear in trait methods. However, depending on how they are used, they may confer where clauses on the associated type definition. More information can be found [here](https://github.com/rust-lang/rust/issues/87479). Briefly, where clauses are required when those bounds can be proven in the methods that *construct* the GAT or other associated types that use the GAT in the trait. This allows impls to have maximum flexibility in the types defined for the associated type.

To take a relatively simple example:

```rust
trait Iterable {
    type Item<'a>;
    type Iterator<'a>: Iterator<Item = Self::Item<'a>>;

    fn iter<'x>(&'x self) -> Self::Iterator<'x>;
    //^ We know that `Self: 'a` for `Iterator<'a>`, so we require that bound on `Iterator`
    //  `Iterator` uses `Self::Item`, so we also require a `Self: 'a` on `Item` too
}
```

A couple well-explained examples are available in a previous [blog post](https://blog.rust-lang.org/2021/08/03/GATs-stabilization-push.html).

## What isn't stabilized/implemented

### Universal type/const quantification

Currently, you can write a bound like `X: for<'a> Trait<Assoc<'a> = &'a ()>`. However, you cannot currently write `for<T> X: Trait<Assoc<T> = T>` or `for<const N> X: Trait<Assoc<N> = [usize; N]>`.

Here is an example where this is needed:

```rust
trait Foo {}

trait Trait {
    type Assoc<F: Foo>;
}

trait Trait2: Sized {
    fn foo<F: Foo, T: Trait<Assoc<F> = F>>(_t: T);
}
```

In the above example, the *caller* must specify `F`, which is likely not what is desired.

### Object-safe GATs

Unlike non-generic associated types, traits with GATs are not currently object-safe. In other words the following are not allowed:

```rust
trait Trait {
    type Assoc<'a>;
}

fn foo(t: &dyn for<'a> Trait<Assoc<'a> = &'a ()>) {}
         //^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not allowed

let ty: Box<dyn for<'a> Trait<Assoc<'a> = &'a ()>>;
          //^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not allowed
```

### Higher-kinded types

You cannot write currently (and there are no current plans to implement this):

```rust
struct Struct<'a> {}

fn foo(s: for<'a> Struct<'a>) {}
```

## Tests

There are many tests covering GATs that can be found in  `src/test/ui/generic-associated-types`. Here, I'll list (in alphanumeric order) tests highlight some important behavior or contain important patterns.

- `./parse/*`: Parsing of GATs in traits and impls, and the trait path with GATs
- `./collections-project-default.rs`: Interaction with associated type defaults
- `./collections.rs`: The `Collection` pattern
- `./const-generics-gat-in-trait-return-type-*.rs`: Const parameters
- `./constraint-assoc-type-suggestion.rs`: Emit correct syntax in suggestion
- `./cross-crate-bounds.rs`: Ensure we handles bounds across crates the same
- `./elided-in-expr-position.rs`: Disallow lifetime elision in return position
- `./gat-in-trait-path-undeclared-lifetime.rs`: Ensure we error on undeclared lifetime in trait path
- `./gat-in-trait-path.rs`: Base trait path case
- `./gat-trait-path-generic-type-arg.rs`: Don't allow shadowing of parameters
- `./gat-trait-path-parenthesised-args.rs`: Don't allow paranthesized args in trait path
- `./generic-associated-types-where.rs`: Ensure that we require where clauses from trait to be met on impl
- `./impl_bounds.rs`: Check that the bounds on GATs in an impl are checked
- `./issue-76826.rs`: `Windows` pattern
- `./issue-78113-lifetime-mismatch-dyn-trait-box.rs`: Implicit 'static diagnostics
- `./issue-84931.rs`: Ensure that we have a where clause on GAT to ensure trait parameter lives long enough
- `./issue-87258_a.rs`: Unconstrained opaque type with TAITs
- `./issue-87429-2.rs`: Ensure we can use bound vars in the bounds
- `./issue-87429-associated-type-default.rs`: Ensure bounds hold with associated type defaults, for both trait and impl
- `./issue-87429-specialization.rs`: Check that bounds hold under specialization
- `./issue-88595.rs`: Under the outlives lint, we require a bound for both trait and GAT lifetime when trait lifetime is used in function
- `./issue-90014.rs`: Lifetime bounds are checked with TAITs
- `./issue-91139.rs`: Under migrate mode, but not NLL, we don't capture implied bounds from HRTB lifetimes used in a function and GATs
- `./issue-91762.rs`: We used to too eagerly pick param env candidates when normalizing with GATs. We now require explicit parameters specified.
- `./issue-95305.rs`: Disallow lifetime elision in trait paths
- `./iterable.rs`: `Iterable` pattern
- `./method-unsatified-assoc-type-predicate.rs`: Print predicates with GATs correctly in method resolve error
- `./missing_lifetime_const.rs`: Ensure we must specify lifetime args (not elidable)
- `./missing-where-clause-on-trait.rs`: Ensure we don't allow stricter bounds on impl than trait
- `./parameter_number_and_kind_impl.rs`: Ensure paramters on GAT in impl match GAT in trait
- `./pointer_family.rs`: `PointerFamily` pattern
- `./projection-bound-cycle.rs`: Don't allow invalid cycles to prove bounds
- `./self-outlives-lint.rs`: Ensures that an e.g. `Self: 'a` is written on the traits GAT if that bound can be implied from the GAT usage in the trait
- `./shadowing.rs`: Don't allow lifetime shadowing in params
- `./streaming_iterator.rs`: `StreamingIterator`(`LendingIterator`) pattern
- `./trait-objects.rs`: Disallow trait objects for traits with GATs
- `./variance_constraints.rs`: Require that GAT substs be invariant

## Remaining bugs and open issues

A full list of remaining open issues can be found at: https://github.com/rust-lang/rust/labels/F-generic_associated_types

There are some `known-bug` tests in-tree at `src/test/ui/generic-associated-types/bugs`.

Here I'll categorize most of those that GAT bugs (or involve a pattern found more with GATs), but not those that include GATs but not a GAT issue in and of itself. (I also won't include issues directly for things listed elsewhere here.)

Using the concrete type of a GAT instead of the projection type can give errors, since lifetimes are chosen to be early-bound vs late-bound.
- #85533
- #87803

In certain cases, we can run into cycle or overflow errors. This is more generally a problem with associated types.
- #87755
- #87758

Bounds on an associatd type need to be proven by an impl, but where clauses need to be proven by the usage. This can lead to confusion when users write one when they mean the other.
- #87831
- #90573

We sometimes can't normalize closure signatures fully. Really an asociated types issue, but might happen a bit more frequently with GATs, since more obvious place for HRTB lifetimes.
- #88382

When calling a function, we assign types to parameters "too late", after we already try (and fail) to normalize projections. Another associated types issue that might pop up more with GATs.
- #88460
- #96230

We don't fully have implied bounds for lifetimes appearing in GAT trait paths, which can lead to unconstrained type errors.
- #88526

Suggestion for adding lifetime bounds can suggest unhelpful fixes (`T: 'a` instead of `Self: 'a`), but the next compiler error after making the suggested change is helpful.
- #90816
- #92096
- #95268

We can end up requiring that `for<'a> I: 'a` when we really want `for<'a where I: 'a> I: 'a`. This can leave unhelpful errors than effectively can't be satisfied unless `I: 'static`. Requires bigger changes and not only GATs.
- #91693

Unlike with non-generic associated types, we don't eagerly normalize with param env candidates. This is intended behavior (for now), to avoid accidentaly stabilizing picking arbitrary impls.
- #91762

Some Iterator adapter patterns (namely `filter`) require Polonius or unsafe to work.
- #92985

## Potential Future work

### Universal type/const quantification

No work has been done to implement this. There are also some questions around implied bounds.

###  Object-safe GATs

The intention is to make traits with GATs object-safe. There are some design work to be done around well-formedness rules and general implementation.

### GATified std lib types

It would be helpful to either introduce new std lib traits (like `LendingIterator`) or to modify existing ones (adding a `'a` generic to `Iterator::Item`). There also a number of other candidates, like `Index`/`IndexMut` and `Fn`/`FnMut`/`FnOnce`.

### Reduce the need for `for<'a>`

Seen [here](https://github.com/rust-lang/rfcs/pull/1598#issuecomment-2611378730). One possible syntax:

```rust
trait Iterable {
    type Iter<'a>: Iterator<Item = Self::Item<'a>>;
}

fn foo<T>() where T: Iterable, T::Item<let 'a>: Display { } //note the `let`!
```

### Better implied bounds on higher-ranked things

Currently if we have a `type Item<'a> where self: 'a`, and a `for<'a> T: Iterator<Item<'a> = &'a ()`, this requires `for<'a> Self: 'a`. Really, we want `for<'a where T: 'a> ...`

There was some mentions of this all the back in the RFC thread [here](https://github.com/rust-lang/rfcs/pull/1598#issuecomment-264340514).

## Alternatives

### Make generics on associated type in bounds a binder

Imagine the bound `for<'a> T: Trait<Item<'a>= &'a ()>`. It might be that `for<'a>` is "too large" and it should instead be `T: Trait<for<'a> Item<'a>= &'a ()>`. Brought up in RFC thread [here](https://github.com/rust-lang/rfcs/pull/1598#issuecomment-229443863) and in a few places since.

Another related question: Is `for<'a>` the right syntax? Maybe `where<'a>`? Also originally found in RFC thread [here](https://github.com/rust-lang/rfcs/pull/1598#issuecomment-261639969).

### Stabilize lifetime GATs first

This has been brought up a few times. The idea is to only allow GATs with lifetime parameters to in initial stabilization. This was probably most useful prior to actual implementation. At this point, lifetimes, types, and consts are all implemented and work. It feels like an arbitrary split without strong reason.

## History

* On 2016-04-30, [RFC opened](https://github.com/rust-lang/rfcs/pull/1598)
* On 2017-09-02, RFC merged and [tracking issue opened](https://github.com/rust-lang/rust/issues/44265)
* On 2017-10-23, [Move Generics from MethodSig to TraitItem and ImplItem](https://github.com/rust-lang/rust/pull/44766)
* On 2017-12-01, [Generic Associated Types Parsing & Name Resolution](https://github.com/rust-lang/rust/pull/45904)
* On 2017-12-15, [https://github.com/rust-lang/rust/pull/46706](https://github.com/rust-lang/rust/pull/46706)
* On 2018-04-23, [Feature gate where clauses on associated types](https://github.com/rust-lang/rust/pull/49368)
* On 2018-05-10, [Extend tests for RFC1598 (GAT)](https://github.com/rust-lang/rust/pull/49423)
* On 2018-05-24, [Finish implementing GATs (Chalk)](https://github.com/rust-lang/chalk/pull/134)
* On 2019-12-21, [Make GATs less ICE-prone](https://github.com/rust-lang/rust/pull/67160)
* On 2020-02-13, [fix lifetime shadowing check in GATs](https://github.com/rust-lang/rust/pull/68938)
* On 2020-06-20, [Projection bound validation](https://github.com/rust-lang/rust/pull/72788)
* On 2020-10-06, [Separate projection bounds and predicates](https://github.com/rust-lang/rust/pull/73905)
* On 2021-02-05, [Generic associated types in trait paths](https://github.com/rust-lang/rust/pull/79554)
* On 2021-02-06, [Trait objects do not work with generic associated types](https://github.com/rust-lang/rust/issues/81823)
* On 2021-04-28, [Make traits with GATs not object safe](https://github.com/rust-lang/rust/pull/84622)
* On 2021-05-11, [Improve diagnostics for GATs](https://github.com/rust-lang/rust/pull/82272)
* On 2021-07-16, [Make GATs no longer an incomplete feature](https://github.com/rust-lang/rust/pull/84623)
* On 2021-07-16, [Replace associated item bound vars with placeholders when projecting](https://github.com/rust-lang/rust/pull/86993)
* On 2021-07-26, [GATs: Decide whether to have defaults for `where Self: 'a`](https://github.com/rust-lang/rust/issues/87479)
* On 2021-08-25, [Normalize projections under binders](https://github.com/rust-lang/rust/pull/85499)
* On 2021-08-03, [The push for GATs stabilization](https://blog.rust-lang.org/2021/08/03/GATs-stabilization-push.html)
* On 2021-08-12, [Detect stricter constraints on gats where clauses in impls vs trait](https://github.com/rust-lang/rust/pull/88336)
* On 2021-09-20, [Proposal: Change syntax of where clauses on type aliases](https://github.com/rust-lang/rust/issues/89122)
* On 2021-11-06, [Implementation of GATs outlives lint](https://github.com/rust-lang/rust/pull/89970)
* On 2021-12-29. [Parse and suggest moving where clauses after equals for type aliases](https://github.com/rust-lang/rust/pull/92118)
* On 2022-01-15, [Ignore static lifetimes for GATs outlives lint](https://github.com/rust-lang/rust/pull/92865)
* On 2022-02-08, [Don't constrain projection predicates with inference vars in GAT substs](https://github.com/rust-lang/rust/pull/92917)
* On 2022-02-15, [Rework GAT where clause check](https://github.com/rust-lang/rust/pull/93820)
* On 2022-02-19, [Only mark projection as ambiguous if GAT substs are constrained](https://github.com/rust-lang/rust/pull/93892)
* On 2022-03-03, [Support GATs in Rustdoc](https://github.com/rust-lang/rust/pull/94009)
* On 2022-03-06, [Change location of where clause on GATs](https://github.com/rust-lang/rust/pull/90076)
* On 2022-05-04, [A shiny future with GATs blog post](https://jackh726.github.io/rust/2022/05/04/a-shiny-future-with-gats.html)
* On 2022-05-04, [Stabilization PR](https://github.com/rust-lang/rust/pull/96709)
2022-09-13 09:39:41 +00:00
Eric Holk
eff35e59c6 Introduce dyn_star feature flag
The primary purpose of this commit is to introduce the
dyn_star flag so we can begin experimenting with implementation.

In order to have something to do in the feature gate test, we also add
parser support for `dyn* Trait` objects. These are currently treated
just like `dyn Trait` objects, but this will change in the future.

Note that for now `dyn* Trait` is experimental syntax to enable
implementing some of the machinery needed for async fn in dyn traits
without fully supporting the feature.
2022-09-12 16:55:55 -07:00
Nicholas Nethercote
925363f13d Remove unused span argument from walk_fn. 2022-09-12 13:24:27 +10:00
Nicholas Nethercote
6568ef338e Remove path_span argument to the visit_path_segment methods.
The `visit_path_segment` method of both the AST and HIR visitors has a
`path_span` argument that isn't necessary. This commit removes it.

There are two very small and inconsequential functional changes.

- One call to `NodeCollector::insert` now is passed a path segment
  identifier span instead of a full path span. This span is only used in
a panic message printed in the case of an internal compiler bug.

- Likewise, one call to `LifetimeCollectVisitor::record_elided_anchor`
  now uses a path segment identifier span instead of a full path span.
  This span is used to make some `'_` lifetimes.
2022-09-12 13:24:25 +10:00
Dylan DPC
ae4973281b
Rollup merge of #101573 - lcnr:param-kind-ord, r=BoxyUwU
update `ParamKindOrd`

https://github.com/rust-lang/rust/pull/90207#discussion_r767160854 😁

writing comments "for future prs" sure works well :3

r? `@BoxyUwU`
2022-09-09 22:02:18 +05:30
Michael Goulet
5be30f9d79 Make async fn in traits work 2022-09-09 01:31:45 +00:00
lcnr
b79a2b3f73 update ParamKindOrd 2022-09-08 16:50:44 +02:00
Cameron Steffen
02ba216e3c Refactor and re-use BindingAnnotation 2022-09-02 12:55:05 -05:00
Oli Scherer
ee3c835018 Always import all tracing macros for the entire crate instead of piecemeal by module 2022-09-01 14:54:27 +00:00
Dezhi Wu
b1430fb7ca Fix a bunch of typo
This PR will fix some typos detected by [typos].

I only picked the ones I was sure were spelling errors to fix, mostly in
the comments.

[typos]: https://github.com/crate-ci/typos
2022-08-31 18:24:55 +08:00
Jack Huey
3cf0e98dc9 Stabilize GATs 2022-08-30 23:06:24 -04:00
Nilstrieb
01acfef1a4 Migrate stable let_chains error to session diagnostics 2022-08-29 19:49:30 +02:00
Nilstrieb
d1ef8180f9 Revert let_chains stabilization
This reverts commit 3266460749.

This is the revert against master, the beta revert was already done in #100538.
2022-08-29 19:34:11 +02:00
Yuki Okushi
f4550a6edf
Rollup merge of #99332 - jyn514:stabilize-label-break-value, r=petrochenkov
Stabilize `#![feature(label_break_value)]`

See the stabilization report in https://github.com/rust-lang/rust/issues/48594#issuecomment-1186213313.
2022-08-25 08:50:54 +09:00
Joshua Nelson
31e39446ec Stabilize #![feature(label_break_value)]
# Stabilization proposal

The feature was implemented in https://github.com/rust-lang/rust/pull/50045 by est31 and has been in nightly since 2018-05-16 (over 4 years now).
There are [no open issues][issue-label] other than the tracking issue. There is a strong consensus that `break` is the right keyword and we should not use `return`.

There have been several concerns raised about this feature on the tracking issue (other than the one about tests, which has been fixed, and an interaction with try blocks, which has been fixed).
1. nrc's original comment about cost-benefit analysis: https://github.com/rust-lang/rust/issues/48594#issuecomment-422235234
2. joshtriplett's comments about seeing use cases: https://github.com/rust-lang/rust/issues/48594#issuecomment-422281176
3. withoutboats's comments that Rust does not need more control flow constructs: https://github.com/rust-lang/rust/issues/48594#issuecomment-450050630

Many different examples of code that's simpler using this feature have been provided:
- A lexer by rpjohnst which must repeat code without label-break-value: https://github.com/rust-lang/rust/issues/48594#issuecomment-422502014
- A snippet by SergioBenitez which avoids using a new function and adding several new return points to a function: https://github.com/rust-lang/rust/issues/48594#issuecomment-427628251. This particular case would also work if `try` blocks were stabilized (at the cost of making the code harder to optimize).
- Several examples by JohnBSmith: https://github.com/rust-lang/rust/issues/48594#issuecomment-434651395
- Several examples by Centril: https://github.com/rust-lang/rust/issues/48594#issuecomment-440154733
- An example by petrochenkov where this is used in the compiler itself to avoid duplicating error checking code: https://github.com/rust-lang/rust/issues/48594#issuecomment-443557569
- Amanieu recently provided another example related to complex conditions, where try blocks would not have helped: https://github.com/rust-lang/rust/issues/48594#issuecomment-1184213006

Additionally, petrochenkov notes that this is strictly more powerful than labelled loops due to macros which accidentally exit a loop instead of being consumed by the macro matchers: https://github.com/rust-lang/rust/issues/48594#issuecomment-450246249

nrc later resolved their concern, mostly because of the aforementioned macro problems.
joshtriplett suggested that macros could be able to generate IR directly
(https://github.com/rust-lang/rust/issues/48594#issuecomment-451685983) but there are no open RFCs,
and the design space seems rather speculative.

joshtriplett later resolved his concerns, due to a symmetry between this feature and existing labelled break: https://github.com/rust-lang/rust/issues/48594#issuecomment-632960804

withoutboats has regrettably left the language team.

joshtriplett later posted that the lang team would consider starting an FCP given a stabilization report: https://github.com/rust-lang/rust/issues/48594#issuecomment-1111269353

[issue-label]: https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Aopen+label%3AF-label_break_value+

 ## Report

+ Feature gate:
    - d695a497bb/src/test/ui/feature-gates/feature-gate-label_break_value.rs
+ Diagnostics:
    - 6b2d3d5f3c/compiler/rustc_parse/src/parser/diagnostics.rs (L2629)
    - f65bf0b2bb/compiler/rustc_resolve/src/diagnostics.rs (L749)
    - f65bf0b2bb/compiler/rustc_resolve/src/diagnostics.rs (L1001)
    - 111df9e6ed/compiler/rustc_passes/src/loops.rs (L254)
    - d695a497bb/compiler/rustc_parse/src/parser/expr.rs (L2079)
    - d695a497bb/compiler/rustc_parse/src/parser/expr.rs (L1569)
+ Tests:
    - https://github.com/rust-lang/rust/blob/master/src/test/ui/label/label_break_value_continue.rs
    - https://github.com/rust-lang/rust/blob/master/src/test/ui/label/label_break_value_unlabeled_break.rs
    - https://github.com/rust-lang/rust/blob/master/src/test/ui/label/label_break_value_illegal_uses.rs
    - https://github.com/rust-lang/rust/blob/master/src/test/ui/lint/unused_labels.rs
    - https://github.com/rust-lang/rust/blob/master/src/test/ui/run-pass/for-loop-while/label_break_value.rs

 ## Interactions with other features

Labels follow the hygiene of local variables.

label-break-value is permitted within `try` blocks:
```rust
let _: Result<(), ()> = try {
    'foo: {
        Err(())?;
        break 'foo;
    }
};
```

label-break-value is disallowed within closures, generators, and async blocks:
```rust
'a: {
    || break 'a
    //~^ ERROR use of unreachable label `'a`
    //~| ERROR `break` inside of a closure
}
```

label-break-value is disallowed on [_BlockExpression_]; it can only occur as a [_LoopExpression_]:
```rust
fn labeled_match() {
    match false 'b: { //~ ERROR block label not supported here
        _ => {}
    }
}

macro_rules! m {
    ($b:block) => {
        'lab: $b; //~ ERROR cannot use a `block` macro fragment here
        unsafe $b; //~ ERROR cannot use a `block` macro fragment here
        |x: u8| -> () $b; //~ ERROR cannot use a `block` macro fragment here
    }
}

fn foo() {
    m!({});
}
```

[_BlockExpression_]: https://doc.rust-lang.org/nightly/reference/expressions/block-expr.html
[_LoopExpression_]: https://doc.rust-lang.org/nightly/reference/expressions/loop-expr.html
2022-08-23 21:14:12 -05:00
finalchild
09d495cc15 Replace #[error(..)] etc. to #[diag(..)] 2022-08-22 01:24:47 +09:00
finalchild
e331ae57df Migrate forbidden_default and *_without_body 2022-08-22 01:11:59 +09:00
finalchild
b28cc097cf Support #[fatal(..)] 2022-08-22 01:11:55 +09:00
finalchild
bfefefbcfa Migrate fn_param_forbidden_self and rename others to have prefix fn_param_ 2022-08-22 00:57:22 +09:00
finalchild
07e0bc9600 Rename c_var_args_without_named_arg to c_var_args_is_sole_param 2022-08-22 00:57:22 +09:00
finalchild
c6903c04b1 Migrate doc_comment_on_fn_param, forbidden_attr_on_fn_param 2022-08-22 00:57:21 +09:00
finalchild
269c85390c Migrate forbidden_lifetime_bound, forbidden_non_lifetime_param, too_many_params, c_var_args_without_named_arg, c_var_args_not_last 2022-08-22 00:57:21 +09:00
finalchild
8d042f4483 Migrate trait_fn_const 2022-08-22 00:57:21 +09:00
finalchild
e3d4c4039a Migrate trait_fn_async 2022-08-22 00:57:21 +09:00
finalchild
88afae5d1a Tidy 2022-08-22 00:57:21 +09:00
finalchild
e144a2367a Migrate deprecated_where_clause_location, forbidden_assoc_constraint, keyword_lifetime, invalid_label, invalid_visibility 2022-08-22 00:57:21 +09:00
finalchild
d6fdf14eb7 Migrate forbidden_let 2022-08-22 00:57:21 +09:00
Christopher Durham
767239f740 Reenable early feature-gates as future-compat warnings 2022-08-17 06:53:18 -05:00
Mark Rousskov
154a09dd91 Adjust cfgs 2022-08-12 16:28:15 -04:00
Matthias Krüger
8237efc52d
Rollup merge of #100392 - nnethercote:simplify-visitors, r=cjgillot
Simplify visitors

By removing some unused arguments.

r? `@cjgillot`
2022-08-11 22:53:08 +02:00
Nicholas Nethercote
232bd80130 Simplify rustc_ast::visit::Visitor::visit_poly_trait_ref.
It is passed an argument that is never used.
2022-08-11 11:10:01 +10:00
Nicholas Nethercote
421125f30a Simplify rustc_ast::visit::Visitor::visit_enum_def.
It's passed three arguments that are never used.
2022-08-11 10:54:01 +10:00
Michael Goulet
a2b6744af0 Use &mut Diagnostic instead of &mut DiagnosticBuilder unless needed 2022-08-10 03:45:42 +00:00
Dylan DPC
1dc4858914
Rollup merge of #96478 - WaffleLapkin:rustc_default_body_unstable, r=Aaron1011
Implement `#[rustc_default_body_unstable]`

This PR implements a new stability attribute — `#[rustc_default_body_unstable]`.

`#[rustc_default_body_unstable]` controls the stability of default bodies in traits.
For example:
```rust
pub trait Trait {
    #[rustc_default_body_unstable(feature = "feat", isssue = "none")]
    fn item() {}
}
```
In order to implement `Trait` user needs to either
- implement `item` (even though it has a default implementation)
- enable `#![feature(feat)]`

This is useful in conjunction with [`#[rustc_must_implement_one_of]`](https://github.com/rust-lang/rust/pull/92164), we may want to relax requirements for a trait, for example allowing implementing either of `PartialEq::{eq, ne}`, but do so in a safe way — making implementation of only `PartialEq::ne` unstable.

r? `@Aaron1011`
cc `@nrc` (iirc you were interested in this wrt `read_buf`), `@danielhenrymantilla` (you were interested in the related `#[rustc_must_implement_one_of]`)
P.S. This is my first time working with stability attributes, so I'm not sure if I did everything right 😅
2022-08-09 17:34:50 +05:30
Esteban Küber
939c2b6313 Provide suggestion on missing let in binding statement
Fix #78907.
2022-08-03 09:29:29 -07:00
Nicholas Nethercote
6dced80b86 Remove visit_name from the AST visitor.
Because the default is empty and it's never overridden. This means
`walk_ident` can also be removed, because it does nothing.
2022-07-29 15:28:32 +10:00
Maybe Waffle
177af47104 Implement #[rustc_default_body_unstable]
This attribute allows to mark default body of a trait function as
unstable. This means that implementing the trait without implementing
the function will require enabling unstable feature.

This is useful in conjunction with `#[rustc_must_implement_one_of]`,
we may want to relax requirements for a trait, for example allowing
implementing either of `PartialEq::{eq, ne}`, but do so in a safe way
-- making implementation of only `PartialEq::ne` unstable.
2022-07-26 15:38:03 +04:00
Deadbeef
9b75f2d498 Allow ~const on super traits 2022-07-23 14:25:55 +00:00
bors
9a7b7d5e50 Auto merge of #98180 - notriddle:notriddle/rustdoc-fn, r=petrochenkov,GuillaumeGomez
Improve the function pointer docs

This is #97842 but for function pointers instead of tuples. The concept is basically the same.

* Reduce duplicate impls; show `fn (T₁, T₂, …, Tₙ)` and include a sentence saying that there exists up to twelve of them.
* Show `Copy` and `Clone`.
* Show auto traits like `Send` and `Sync`, and blanket impls like `Any`.

https://notriddle.com/notriddle-rustdoc-test/std/primitive.fn.html
2022-07-19 19:36:57 +00:00
Matthias Krüger
4815f94c51
Rollup merge of #99401 - TaKO8Ki:avoid-symbol-to-&str-conversions, r=nnethercote
Avoid `Symbol` to `&str` conversions

`Symbol::as_str` is a slowish operation, so this patch removes some usages of it.
2022-07-19 13:30:46 +02:00
Takayuki Maeda
a22934bea1 avoid Symbol to &str conversions 2022-07-18 14:25:34 +09:00
Yuki Okushi
f3a458f735
Rollup merge of #99360 - compiler-errors:issue-99331, r=fee1-dead
Do not ICE when we have `-Zunpretty=expanded` with invalid ABI

Fixes #99331
2022-07-18 08:40:00 +09:00
Michael Howell
1169832f2f rustdoc: extend #[doc(tuple_variadic)] to fn pointers
The attribute is also renamed `fake_variadic`.
2022-07-17 16:32:06 -07:00
Michael Goulet
26ecd44160 Do not ICE when we have -Zunpretty=expand with invalid ABI 2022-07-16 20:35:54 -07:00
Caio
3266460749 Stabilize let_chains 2022-07-16 20:17:58 -03:00
Maybe Waffle
40ae7b5b8e Parse closure binders
This is first step in implementing RFC 3216.
- Parse `for<'a>` before closures in ast
  - Error in lowering
- Add `closure_lifetime_binder` feature
2022-07-12 16:25:16 +04:00
Nixon Enraght-Moony
02fb345964 Suggest using block for extern "abi" fn with no body 2022-07-06 13:27:53 +01:00
Nixon Enraght-Moony
18ca2946e0 ast: Add span to Extern 2022-07-02 23:30:03 +01:00
bors
6ec3993ef4 Auto merge of #97842 - notriddle:notriddle/tuple-docs, r=jsha,GuillaumeGomez
Improve the tuple and unit trait docs

* Reduce duplicate impls; show only the `(T,)` and include a sentence saying that there exists ones up to twelve of them.
* Show `Copy` and `Clone`.
* Show auto traits like `Send` and `Sync`, and blanket impls like `Any`.

Here's the new version:

* <https://notriddle.com/notriddle-rustdoc-test/std/primitive.tuple.html>
* <https://notriddle.com/notriddle-rustdoc-test/std/primitive.unit.html>
2022-06-16 11:13:30 +00:00
Jacob Pratt
fb05b53745
Remove rustc_deprecated diagnostics 2022-06-14 19:46:13 -04:00
Takayuki Maeda
77d6176e69 remove unnecessary to_string and String::new 2022-06-13 15:48:40 +09:00
Michael Howell
9b31323b8f Fix incorrectly spelled "variadic" 2022-06-11 09:54:20 -07:00
Michael Howell
6950f144cf rustdoc: show tuple impls as impl Trait for (T, ...)
This commit adds a new unstable attribute, `#[doc(tuple_varadic)]`, that
shows a 1-tuple as `(T, ...)` instead of just `(T,)`, and links to a section
in the tuple primitive docs that talks about these.
2022-06-08 19:26:51 -07:00
bors
91cacb3faf Auto merge of #97512 - scottmcm:add-coldcc, r=nagisa,lcnr
Add support for emitting functions with `coldcc` to LLVM

The eventual goal is to try using this for things like the internal panicking stuff, to see whether it helps.
2022-06-07 08:12:45 +00:00
xFrednet
b5eee17088
Support the #[expect] attribute on fn parameters (RFC-2383) 2022-06-04 00:50:45 +02:00
Scott McMurray
e90be842fb Add support for emitting functions with coldcc in LLVM
The eventual goal is to try using this for things like the internal panicking stuff, to see whether it helps.
2022-05-30 00:19:23 -07:00
Matthias Krüger
5fc8a8e227 clippy::complexity fixes
clone_on_copy
useless_format
bind_instead_of_map
filter_map_identity
useless_conversion
map_flatten
unnecessary_unwrap
2022-05-26 13:14:24 +02:00
Jacob Pratt
8cece636b2
Remove feature: crate visibility modifier 2022-05-21 14:22:06 -04:00