Commit Graph

517 Commits

Author SHA1 Message Date
Amanieu d'Antras
56074b5231 Rewrite implementation of #[alloc_error_handler]
The new implementation doesn't use weak lang items and instead changes
`#[alloc_error_handler]` to an attribute macro just like
`#[global_allocator]`.

The attribute will generate the `__rg_oom` function which is called by
the compiler-generated `__rust_alloc_error_handler`. If no `__rg_oom`
function is defined in any crate then the compiler shim will call
`__rdl_oom` in the alloc crate which will simply panic.

This also fixes link errors with `-C link-dead-code` with
`default_alloc_error_handler`: `__rg_oom` was previously defined in the
alloc crate and would attempt to reference the `oom` lang item, even if
it didn't exist. This worked as long as `__rg_oom` was excluded from
linking since it was not called.

This is a prerequisite for the stabilization of
`default_alloc_error_handler` (#102318).
2022-10-31 16:32:57 +00:00
Michael Howell
9911229650
Rollup merge of #97971 - Soveu:varargs, r=jackh726
Enable varargs support for calling conventions other than C or cdecl

This patch makes it possible to use varargs for calling conventions,
which are either based on C (efiapi) or C is based on them (sysv64 and win64).

Also pinging ``@phlopsi,`` because he noticed first this oversight when writing a library for UEFI.
2022-10-30 19:31:36 -07:00
Dylan DPC
b4cf523cb5
Rollup merge of #93582 - WaffleLapkin:rpitirpit, r=compiler-errors
Allow `impl Fn() -> impl Trait` in return position

_This was originally proposed as part of #93082 which was [closed](https://github.com/rust-lang/rust/pull/93082#issuecomment-1027225715) due to allowing `impl Fn() -> impl Trait` in argument position._

This allows writing the following function signatures:
```rust
fn f0() -> impl Fn() -> impl Trait;
fn f3() -> &'static dyn Fn() -> impl Trait;
```

These signatures were already allowed for common traits and associated types, there is no reason why `Fn*` traits should be special in this regard.

`impl Trait` in both `f0` and `f3` means "new existential type", just like with `-> impl Iterator<Item = impl Trait>` and such.

Arrow in `impl Fn() ->` is right-associative and binds from right to left, it's tested by [this test](a819fecb8d/src/test/ui/impl-trait/impl_fn_associativity.rs).

There even is a test that `f0` compiles:
2f004d2d40/src/test/ui/impl-trait/nested_impl_trait.rs (L25-L28)

But it was changed in [PR 48084 (lines)](https://github.com/rust-lang/rust/pull/48084/files#diff-ccecca938872d65ffe8cd1c3ef1956e309fac83bcda547d8b16b89257e53a437R37)  to test the opposite, probably unintentionally given [PR 48084 (lines)](https://github.com/rust-lang/rust/pull/48084/files#diff-5a02f1ed43debed1fd24f7aad72490064f795b9420f15d847bac822aa4621a1cR476-R477).

r? `@nikomatsakis`

----

This limitation is especially annoying with async code, since it forces one to write this:
```rust
trait AsyncFn3<A, B, C>: Fn(A, B, C) -> <Self as AsyncFn3<A, B, C>>::Future {
    type Future: Future<Output = Self::Out>;

    type Out;
}

impl<A, B, C, Fut, F> AsyncFn3<A, B, C> for F
where
    F: Fn(A, B, C) -> Fut,
    Fut: Future,
{
    type Future = Fut;

    type Out = Fut::Output;
}

fn async_closure() -> impl AsyncFn3<i32, i32, i32, Out = u32> {
    |a, b, c| async move { (a + b + c) as u32 }
}
```
Instead of:
```rust
fn async_closure() -> impl Fn(i32, i32, i32) -> impl Future<Output = u32> {
    |a, b, c| async move { (a + b + c) as u32 }
}
```
2022-10-30 11:50:26 +05:30
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
Maybe Waffle
cc752f5665 Feature gate impl_trait_in_fn_trait_return 2022-10-25 13:25:52 +00:00
Yuki Okushi
779418deb4
Rollup merge of #99939 - saethlin:pre-sort-tests, r=thomcc,jackh726
Sort tests at compile time, not at startup

Recently, another Miri user was trying to run `cargo miri test` on the crate `iced-x86` with `--features=code_asm,mvex`. This configuration has a startup time of ~18 minutes. That's ~18 minutes before any tests even start to run. The fact that this crate has over 26,000 tests and Miri is slow makes a lot of code which is otherwise a bit sloppy but fine into a huge runtime issue.

Sorting the tests when the test harness is created instead of at startup time knocks just under 4 minutes out of those ~18 minutes. I have ways to remove most of the rest of the startup time, but this change requires coordinating changes of both the compiler and libtest, so I'm sending it separately.

(except for doctests, because there is no compile-time harness)
2022-10-24 19:32:25 +09:00
Soveu
ba847cad6d Enable varargs support for calling conventions other than C or cdecl
This patch makes it possible to use varargs for calling conventions,
which are either based on C (like efiapi) or C is based
on them (for example sysv64 and win64).
2022-10-23 18:46:16 -04:00
Deadbeef
988e75bb65 Stabilize arbitrary_enum_discriminant, take 2 2022-10-22 13:54:39 +08:00
Guillaume Gomez
ae5108a1ed Add code comments and documentation 2022-10-20 22:44:10 +00:00
Guillaume Gomez
b12b65c1b7 Add missing @local_only on attributes 2022-10-20 22:44:10 +00:00
Amanieu d'Antras
430bd6200d Stabilize asm_sym 2022-10-17 22:38:37 +01:00
bors
c0983a9aac Auto merge of #102975 - Dylan-DPC:rollup-vzuwsh2, r=Dylan-DPC
Rollup of 7 pull requests

Successful merges:

 - #102623 (translation: eager translation)
 - #102719 (Enforce alphabetical sorting with tidy)
 - #102830 (Unify `tcx.constness` query and param env constness checks)
 - #102883 (Fix stabilization of `feature(half_open_range_patterns)`)
 - #102927 (Fix `let` keyword removal suggestion in structs)
 - #102936 (rustdoc: remove unused CSS `nav.sum`)
 - #102940 (Update books)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
2022-10-12 17:48:31 +00:00
Ralf Jung
2b50cd1877 rename rustc_allocator_nounwind to rustc_nounwind 2022-10-11 22:47:31 +02:00
Urgau
d17a69e453 Fix stabilization of feature(half_open_range_patterns) 2022-10-10 15:45:57 +02:00
Urgau
5ae73634dc Stabilize half_open_range_patterns 2022-10-08 11:00:13 +02:00
Urgau
c084c26397 Split slice part of feature(half_open_range_patterns) to [...]_in_slices 2022-10-08 11:00:13 +02:00
Yuki Okushi
7874976762
Stabilize the instruction_set feature
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
2022-09-29 17:27:03 +09:00
reez12g
9a4c5abe45 Remove from compiler/ crates 2022-09-29 16:49:04 +09:00
Arthur Cohen
0ab2c91a2d attributes: Add #[rustc_safe_intrinsic] builtin 2022-09-27 15:55:42 +02:00
Pietro Albini
d0305b3d00
replace stabilization placeholders 2022-09-26 10:13:44 +02:00
Matthias Krüger
5d7937de8c
Rollup merge of #100734 - ComputerDruid:afit_feature, r=compiler-errors
Split out async_fn_in_trait into a separate feature

PR #101224 added support for async fn in trait desuraging behind the `return_position_impl_trait_in_trait` feature.

Split this out so that it's behind its own feature gate, since async fn in trait doesn't need to follow the same stabilization schedule.
2022-09-23 04:29:15 +02:00
bors
7a8636c843 Auto merge of #100982 - fee1-dead-contrib:const-impl-requires-const-trait, r=oli-obk
Require `#[const_trait]` on `Trait` for `impl const Trait`

r? `@oli-obk`
2022-09-22 04:22:24 +00:00
Dan Johnson
d0a07495be Split out async_fn_in_trait into a separate feature
PR #101224 added support for async fn in trait desuraging behind the
return_position_impl_trait_in_trait feature.

Split this out so that it's behind its own feature gate, since async fn
in trait doesn't need to follow the same stabilization schedule.
2022-09-21 19:26:23 -07:00
Matthias Krüger
a6b34cd928
Rollup merge of #101713 - Bryanskiy:AccessLevels, r=petrochenkov
change AccessLevels representation

Part of RFC (https://github.com/rust-lang/rust/issues/48054). This patch implements effective visibility table with basic methods and change AccessLevels table representation according to it.

r? ``@petrochenkov``
2022-09-17 23:30:49 +02:00
Deadbeef
07608bd60e fix const_trait unstable message 2022-09-16 11:48:43 +08:00
est31
bca3cf7e86 Stabilize the let_else feature 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
Bryanskiy
d7b9221405 change AccessLevels representation 2022-09-14 18:11:00 +03: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
bors
0df1ddc185 Auto merge of #99556 - davidtwco:collapse-debuginfo, r=wesleywiser
ssa: implement `#[collapse_debuginfo]`

cc #39153 rust-lang/compiler-team#386

Debuginfo line information for macro invocations are collapsed by default - line information are replaced by the line of the outermost expansion site. Using `-Zdebug-macros` disables this behaviour.

When the `collapse_debuginfo` feature is enabled, the default behaviour is reversed so that debuginfo is not collapsed by default. In addition, the `#[collapse_debuginfo]` attribute is available and can be applied to macro definitions which will then have their line information collapsed.

r? rust-lang/wg-debugging
2022-09-13 01:19:05 +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
Wim Looman
72cf46aa72
Feature gate the rustdoc::missing_doc_code_examples lint 2022-09-12 21:20:24 +02:00
Charles Lew
0f367a9be8 Use current rustc version. 2022-09-11 14:04:18 +08:00
Andrew Cann
1bc9453aa8 Add tracking issue number to feature(generator_clone) 2022-09-11 14:04:17 +08:00
Andrew Cann
8aa30dd3cb move generator_clone feature definition
Move it to the list of features with no tracking issue, since it has no
tracking issue.
2022-09-11 14:04:16 +08:00
Andrew Cann
0228c073e0 add generator_clone feature gate 2022-09-11 14:04:12 +08:00
bors
cedd26b1ea Auto merge of #99916 - dpaoliello:stablizerawdylib, r=wesleywiser
Stabilize raw-dylib for non-x86

This stabilizes the `raw-dylib` and `link_ordinal` features (#58713) for non-x86 architectures (i.e., `x86_64`, `aarch64` and `thumbv7a`):
* Marked the `raw_dylib` feature as `active`.
* Marked the `link_ordinal` attribute as `ungated`.
* Added new errors if either feature is used on x86 targets without the `raw_dylib` feature being enabled.
* Updated tests to only set the `raw_dylib` feature when building for x86.
2022-09-10 04:14:34 +00:00
Daniel Paoliello
c7475011a3 Stabilze raw-dylib for non-x86 2022-09-09 15:38:15 -07:00
Michael Goulet
d34cb98fb0 Lower RPITIT to ImplTraitPlaceholder item 2022-09-09 01:31:44 +00:00
David Wood
38958aa8bd ssa: implement #[collapse_debuginfo]
Debuginfo line information for macro invocations are collapsed by
default - line information are replaced by the line of the outermost
expansion site. Using `-Zdebug-macros` disables this behaviour.

When the `collapse_debuginfo` feature is enabled, the default behaviour
is reversed so that debuginfo is not collapsed by default. In addition,
the `#[collapse_debuginfo]` attribute is available and can be applied to
macro definitions which will then have their line information collapsed.

Signed-off-by: David Wood <david.wood@huawei.com>
2022-09-07 13:54:51 +01:00
yukang
00b10a5552 get_attr should check that no duplicates are allowed 2022-09-06 14:16:54 +08:00
bors
8c6ce6b91b Auto merge of #97802 - Enselic:add-no_ignore_sigkill-feature, r=joshtriplett
Support `#[unix_sigpipe = "inherit|sig_dfl"]` on `fn main()` to prevent ignoring `SIGPIPE`

When enabled, programs don't have to explicitly handle `ErrorKind::BrokenPipe` any longer. Currently, the program

```rust
fn main() { loop { println!("hello world"); } }
```

will print an error if used with a short-lived pipe, e.g.

    % ./main | head -n 1
    hello world
    thread 'main' panicked at 'failed printing to stdout: Broken pipe (os error 32)', library/std/src/io/stdio.rs:1016:9
    note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

by enabling `#[unix_sigpipe = "sig_dfl"]` like this

```rust
#![feature(unix_sigpipe)]
#[unix_sigpipe = "sig_dfl"]
fn main() { loop { println!("hello world"); } }
```

there is no error, because `SIGPIPE` will not be ignored and thus the program will be killed appropriately:

    % ./main | head -n 1
    hello world

The current libstd behaviour of ignoring `SIGPIPE` before `fn main()` can be explicitly requested by using `#[unix_sigpipe = "sig_ign"]`.

With `#[unix_sigpipe = "inherit"]`, no change at all is made to `SIGPIPE`, which typically means the behaviour will be the same as `#[unix_sigpipe = "sig_dfl"]`.

See https://github.com/rust-lang/rust/issues/62569 and referenced issues for discussions regarding the `SIGPIPE` problem itself

See the [this](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Proposal.3A.20First.20step.20towards.20solving.20the.20SIGPIPE.20problem) Zulip topic for more discussions, including about this PR.

Tracking issue: https://github.com/rust-lang/rust/issues/97889
2022-09-02 21:08:08 +00:00
Ben Kimock
df6221adc6 Sort tests at compile time, not at startup
Recently, another Miri user was trying to run `cargo miri test` on the
crate `iced-x86` with `--features=code_asm,mvex`. This configuration has
a startup time of ~18 minutes. That's ~18 minutes before any tests even
start to run. The fact that this crate has over 26,000 tests and Miri is
slow makes a lot of code which is otherwise a bit sloppy but fine into a
huge runtime issue.

Sorting the tests when the test harness is created instead of at startup
time knocks just under 4 minutes out of those ~18 minutes. I have ways
to remove most of the rest of the startup time, but this change requires
coordinating changes of both the compiler and libtest, so I'm sending it
separately.
2022-09-01 09:04:25 -04:00
Bryanskiy
0111fb00da add TestReachabilityVisitor 2022-08-31 14:23:07 +03:00
Jack Huey
3cf0e98dc9 Stabilize GATs 2022-08-30 23:06:24 -04:00
bors
0631ea5d73 Auto merge of #101183 - Dylan-DPC:rollup-6kewixv, r=Dylan-DPC
Rollup of 9 pull requests

Successful merges:

 - #95376 (Add `vec::Drain{,Filter}::keep_rest`)
 - #100092 (Fall back when relating two opaques by substs in MIR typeck)
 - #101019 (Suggest returning closure as `impl Fn`)
 - #101022 (Erase late bound regions before comparing types in `suggest_dereferences`)
 - #101101 (interpret: make read-pointer-as-bytes a CTFE-only error with extra information)
 - #101123 (Remove `register_attr` feature)
 - #101175 (Don't --bless in pre-push hook)
 - #101176 (rustdoc: remove unused CSS selectors for `.table-display`)
 - #101180 (Add another MaybeUninit array test with const)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
2022-08-30 08:29:42 +00: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
Martin Nordholts
ddee45e1d7 Support #[unix_sigpipe = "inherit|sig_dfl|sig_ign"] on fn main()
This makes it possible to instruct libstd to never touch the signal
handler for `SIGPIPE`, which makes programs pipeable by default (e.g.
with `./your-program | head -n 1`) without `ErrorKind::BrokenPipe`
errors.
2022-08-28 19:46:45 +02:00
Yuki Okushi
76dd5c58a0
Remove register_attr feature
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
2022-08-28 21:23:23 +09:00
est31
4caedbae86 Adjust label break value stabilization version to CURRENT_RUSTC_VERSION 2022-08-27 17:36:13 +02:00
Daniel Paoliello
cc49c3e582 Implementation of import_name_type 2022-08-26 09:15:35 -07: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
5225225
09ea9f0a87 Add diagnostic translation lints to crates that don't emit them 2022-08-18 19:29:02 +01:00
Rageking8
ba2c2a6500
Add missing closing quote
fixes #100563
2022-08-15 15:57:55 +08: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
David Wood
7bab769b58 lint: add bad opt access internal lint
Some command-line options accessible through `sess.opts` are best
accessed through wrapper functions on `Session`, `TyCtxt` or otherwise,
rather than through field access on the option struct in the `Session`.

Adds a new lint which triggers on those options that should be accessed
through a wrapper function so that this is prohibited. Options are
annotated with a new attribute `rustc_lint_opt_deny_field_access` which
can specify the error message (i.e. "use this other function instead")
to be emitted.

A simpler alternative would be to simply rename the options in the
option type so that it is clear they should not be used, however this
doesn't prevent uses, just discourages them. Another alternative would
be to make the option fields private, and adding accessor functions on
the option types, however the wrapper functions sometimes rely on
additional state from `Session` or `TyCtxt` which wouldn't be available
in an function on the option type, so the accessor would simply make the
field available and its use would be discouraged too.

Signed-off-by: David Wood <david.wood@huawei.com>
2022-07-27 11:24:27 +01:00
Augie Fackler
130a1df71e codegen: use new {re,de,}allocator annotations in llvm
This obviates the patch that teaches LLVM internals about
_rust_{re,de}alloc functions by putting annotations directly in the IR
for the optimizer.

The sole test change is required to anchor FileCheck to the body of the
`box_uninitialized` method, so it doesn't see the `allocalign` on
`__rust_alloc` and get mad about the string `alloca` showing up. Since I
was there anyway, I added some checks on the attributes to prove the
right attributes got set.

While we're here, we also emit allocator attributes on
__rust_alloc_zeroed. This should allow LLVM to perform more
optimizations for zeroed blocks, and probably fixes #90032. [This
comment](https://github.com/rust-lang/rust/issues/24194#issuecomment-308791157)
mentions "weird UB-like behaviour with bitvec iterators in
rustc_data_structures" so we may need to back this change out if things
go wrong.

The new test cases require LLVM 15, so we copy them into LLVM
14-supporting versions, which we can delete when we drop LLVM 14.
2022-07-26 09:43:28 -04: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
Caio
3266460749 Stabilize let_chains 2022-07-16 20:17:58 -03:00
bors
24699bcbad Auto merge of #95956 - yaahc:stable-in-unstable, r=cjgillot
Support unstable moves via stable in unstable items

part of https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/moving.20items.20to.20core.20unstably and a blocker of https://github.com/rust-lang/rust/pull/90328.

The libs-api team needs the ability to move an already stable item to a new location unstably, in this case for Error in core. Otherwise these changes are insta-stable making them much harder to merge.

This PR attempts to solve the problem by checking the stability of path segments as well as the last item in the path itself, which is currently the only thing checked.
2022-07-14 13:42:09 +00:00
Dylan DPC
e5a86d7358
Rollup merge of #98705 - WaffleLapkin:closure_binder, r=cjgillot
Implement `for<>` lifetime binder for closures

This PR implements RFC 3216 ([TI](https://github.com/rust-lang/rust/issues/97362)) and allows code like the following:

```rust
let _f = for<'a, 'b> |a: &'a A, b: &'b B| -> &'b C { b.c(a) };
//       ^^^^^^^^^^^--- new!
```

cc ``@Aaron1011`` ``@cjgillot``
2022-07-14 14:14:21 +05:30
Dylan DPC
f5e9cb53ab
Rollup merge of #97720 - cjgillot:all-fresh, r=petrochenkov
Always create elided lifetime parameters for functions

Anonymous and elided lifetimes in functions are sometimes (async fns) --and sometimes not (regular fns)-- desugared to implicit generic parameters.

This difference of treatment makes it some downstream analyses more complicated to handle.  This step is a pre-requisite to perform lifetime elision resolution on AST.

There is currently an inconsistency in the treatment of argument-position impl-trait for functions and async fns:
```rust
trait Foo<'a> {}
fn foo(t: impl Foo<'_>) {} //~ ERROR missing lifetime specifier
async fn async_foo(t: impl Foo<'_>) {} //~ OK
fn bar(t: impl Iterator<Item = &'_ u8>) {} //~ ERROR missing lifetime specifier
async fn async_bar(t: impl Iterator<Item = &'_ u8>) {} //~ OK
```

The current implementation reports "missing lifetime specifier" on `foo`, but **accepts it** in `async_foo`.
This PR **proposes to accept** the anonymous lifetime in both cases as an extra generic lifetime parameter.
This change would be insta-stable, so let's ping t-lang.
Anonymous lifetimes in GAT bindings keep being forbidden:
```rust
fn foo(t: impl Foo<Assoc<'_> = Bar<'_>>) {}
                         ^^        ^^
                       forbidden   ok
```
I started a discussion here: https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Anonymous.20lifetimes.20in.20universal.20impl-trait/near/284968606

r? ``@petrochenkov``
2022-07-14 14:14:19 +05:30
Ralf Jung
07fe9882cc add array tests, cleanup, tidy, and bless 2022-07-13 18:31:29 -04:00
Ralf Jung
5bf6017b87 remove untagged_union feature gate 2022-07-13 18:27:28 -04:00
Camille GILLOT
5a20834884 Add feature gate. 2022-07-13 14:17:09 +02: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
Jane Lusby
b55453dbad add opt in attribute for stable-in-unstable items 2022-07-08 21:18:15 +00:00
Oli Scherer
2a899dc1cf UnsafeCell now has no niches, ever. 2022-07-07 10:46:22 +00:00
Maybe Waffle
c1a2db3372 Move/rename lazy::Sync{OnceCell,Lazy} to sync::{Once,Lazy}Lock 2022-06-16 19:54:42 +04:00
Jacob Pratt
fb05b53745
Remove rustc_deprecated diagnostics 2022-06-14 19:46:13 -04:00
Dylan DPC
d8333a7b59
Rollup merge of #97948 - davidtwco:diagnostic-translation-lints, r=oli-obk
lint: add diagnostic translation migration lints

Introduce allow-by-default lints for checking whether diagnostics are written in
`SessionDiagnostic` or `AddSubdiagnostic` impls and whether diagnostics are translatable. These lints can be denied for modules once they are fully migrated to impls and translation.

These lints are intended to be temporary - once all diagnostics have been changed then we can just change the APIs we have and that will enforce these constraints thereafter.

r? `````@oli-obk`````
2022-06-14 10:35:31 +02:00
Matthias Krüger
f758b4f4a0
Rollup merge of #97999 - compiler-errors:type_changin_struct_update_is_probably_complete, r=oli-obk
Make `type_changing_struct_update` no longer an incomplete feature

After #97705, I don't see what would make it incomplete anymore. `check_expr_struct_fields` seems to now implement the RFC to the letter.

r? ``````@nikomatsakis``````
cc ``````@rust-lang/types``````
2022-06-13 21:35:56 +02:00
Matthias Krüger
89249b199e
Rollup merge of #97875 - JohnTitor:rm-infer-static-outlives-requirements, r=pnkfelix
Remove the `infer_static_outlives_requirements` feature

Closes #54185
r? ``@pnkfelix``
2022-06-13 21:35:54 +02:00
Michael Goulet
2f923c4d37 Make type_changing_struct_update no longer incomplete 2022-06-11 11:15:44 -07:00
Dylan DPC
f1f44b9e4d
Rollup merge of #96868 - nrc:turbo-stable, r=jhpratt,nbdd0121,nagisa
Stabilize explicit_generic_args_with_impl_trait

This is a stabilisation PR for `explicit_generic_args_with_impl_trait`.

* [tracking issue](https://github.com/rust-lang/rust/issues/83701)
  - [Stabilisation report](https://github.com/rust-lang/rust/issues/83701#issuecomment-1109949897)
  - [FCP entered](https://github.com/rust-lang/rust/issues/83701#issuecomment-1120285703)
* [implementation PR](https://github.com/rust-lang/rust/pull/86176)
* [Reference PR](https://github.com/rust-lang/reference/pull/1212)
* There is no mention of using the turbofish operator in the book (other than an entry in the operator list in the appendix), so there is no documentation to change/add there, unless we felt like we should add a section on using turbofish, but that seems orthogonal to `explicit_generic_args_with_impl_trait`
2022-06-11 07:42:12 +02:00
David Wood
5ba81faba6 lint: add diagnostic translation migration lints
Introduce allow-by-default lints for checking whether diagnostics are
written in `SessionDiagnostic`/`AddSubdiagnostic` impls and whether
diagnostics are translatable. These lints can be denied for modules once
they are fully migrated to impls and translation.

Signed-off-by: David Wood <david.wood@huawei.com>
2022-06-10 15:50:06 +01:00
Vadim Petrochenkov
a8ee1f3a4f Stabilize the bundle native library modifier 2022-06-09 23:12:58 +04:00
Yuki Okushi
153f01e42c
Remove the infer_static_outlives_requirements feature 2022-06-08 21:11:15 +09: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
Nick Cameron
640a461388 Deactivate feature gate explicit_generic_args_with_impl_trait
Signed-off-by: Nick Cameron <nrc@ncameron.org>
2022-06-06 12:21:49 +01:00
Jack Huey
410dcc9674 Fully stabilize NLL 2022-06-03 17:16:41 -04:00
bors
44e9516c85 Auto merge of #97654 - Dylan-DPC:rollup-w6zrzxf, r=Dylan-DPC
Rollup of 5 pull requests

Successful merges:

 - #97420 (Be a little nicer with casts when formatting `fn` pointers)
 - #97450 ([RFC 2011] Basic compiler infrastructure)
 - #97599 (Fix JSON reexport ICE)
 - #97617 (Rustdoc anonymous reexports)
 - #97636 (Revert #96682.)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
2022-06-02 16:04:42 +00:00
Caio
aa115eba12 Basic compiler infra 2022-06-02 09:00:04 -03:00
est31
cfc21deebd Add #[rustc_box]
This commit adds an alternative content boxing syntax,
and uses it inside alloc.

The usage inside the very performance relevant code in
liballoc is the only remaining relevant usage of box syntax
in the compiler (outside of tests, which are comparatively
easy to port).

box syntax was originally designed to be used by all Rust
developers. This introduces a replacement syntax more tailored
to only being used inside the Rust compiler, and with it,
lays the groundwork for eventually removing box syntax.
2022-06-01 02:28:34 +02:00
bors
5c780b98d1 Auto merge of #96964 - oli-obk:const_trait_mvp, r=compiler-errors
Replace `#[default_method_body_is_const]` with `#[const_trait]`

pulled out of #96077

related issues:  #67792 and #92158

cc `@fee1-dead`

This is groundwork to only allowing `impl const Trait` for traits that are marked with `#[const_trait]`. This is necessary to prevent adding a new default method from becoming a breaking change (as it could be a non-const fn).
2022-05-30 09:19:03 +00:00
Deadbeef
257f06587c Remove #[default..] and add #[const_trait] 2022-05-30 08:52:24 +00: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
bors
bef2b7cd1c Auto merge of #97214 - Mark-Simulacrum:stage0-bump, r=pietroalbini
Finish bumping stage0

It looks like the last time had left some remaining cfg's -- which made me think
that the stage0 bump was actually successful. This brings us to a released 1.62
beta though.

This now brings us to cfg-clean, with the exception of check-cfg-features in bootstrap;
I'd prefer to leave that for a separate PR at this time since it's likely to be more tricky.

cc https://github.com/rust-lang/rust/pull/97147#issuecomment-1132845061

r? `@pietroalbini`
2022-05-29 16:28:21 +00:00
Guillaume Gomez
239287f013
Rollup merge of #97028 - ridwanabdillahi:pretty-printer, r=michaelwoerister
Add support for embedding pretty printers via `#[debugger_visualizer]` attribute

Initial support for [RFC 3191](https://github.com/rust-lang/rfcs/pull/3191) in PR https://github.com/rust-lang/rust/pull/91779 was scoped to supporting embedding NatVis files using a new attribute. This PR implements the pretty printer support as stated in the RFC mentioned above.

This change includes embedding pretty printers in the `.debug_gdb_scripts` just as the pretty printers for rustc are embedded today. Also added additional tests for embedded pretty printers. Additionally cleaned up error checking so all error checking is done up front regardless of the current target.

RFC: https://github.com/rust-lang/rfcs/pull/3191
2022-05-29 01:12:30 +02:00
Mark Rousskov
b454991ac4 Finish bumping stage0
It looks like the last time had left some remaining cfg's -- which made me think
that the stage0 bump was actually successful. This brings us to a released 1.62
beta though.
2022-05-27 07:36:17 -04:00
Dylan DPC
c12a36adc6
Rollup merge of #96913 - Urgau:rfc3239-part2, r=petrochenkov
RFC3239: Implement `cfg(target)` - Part 2

This pull-request implements the compact `cfg(target(..))` part of [RFC 3239](https://github.com/rust-lang/rust/issues/96901).

I recommend reviewing this PR on a per commit basics, because of some moving parts.

cc `@GuillaumeGomez`
r? `@petrochenkov`
2022-05-25 10:48:28 +02:00
ridwanabdillahi
60458b97e7 Add support for embedding pretty printers via the #[debugger_visualizer] attribute. Add tests for embedding pretty printers and update documentation.
Ensure all error checking for `#[debugger_visualizer]` is done up front and not when the `debugger_visualizer` query is run.

Clean up potential ODR violations when embedding pretty printers into the `__rustc_debug_gdb_scripts_section__` section.

Respond to PR comments and update documentation.
2022-05-24 11:14:48 -07:00
Loïc BRANSTETT
8345571cd0 RFC3239: Implement compact cfg(target(..)) 2022-05-24 13:51:36 +02:00
Jacob Pratt
8cece636b2
Remove feature: crate visibility modifier 2022-05-21 14:22:06 -04:00
lcnr
7cf9f1ab91 change some attrs to only_local 2022-05-10 12:07:36 +02:00
lcnr
6c8265dc56 only_local: always check for misuse 2022-05-10 12:07:35 +02:00
lcnr
fc128b6764 add check and don't encode #[inline] 2022-05-10 08:09:37 +02:00
lcnr
74b6d296db don't encode only locally used attrs 2022-05-10 08:09:37 +02:00
bors
8a2fe75d0e Auto merge of #95960 - jhpratt:remove-rustc_deprecated, r=compiler-errors
Remove `#[rustc_deprecated]`

This removes `#[rustc_deprecated]` and introduces diagnostics to help users to the right direction (that being `#[deprecated]`). All uses of `#[rustc_deprecated]` have been converted. CI is expected to fail initially; this requires #95958, which includes converting `stdarch`.

I plan on following up in a short while (maybe a bootstrap cycle?) removing the diagnostics, as they're only intended to be short-term.
2022-05-09 04:47:30 +00:00
Arseniy Pendryak
02ac4a4e02 Remove adx_target_feature feature from active features list
The feature was stabilized in https://github.com/rust-lang/rust/pull/93745
2022-05-06 13:12:45 +03:00
bors
74cea9fdb9 Auto merge of #96520 - lcnr:general-incoherent-impls, r=petrochenkov
generalize "incoherent impls" impl for user defined types

To allow the move of `trait Error` into core.

continues the work from #94963, finishes https://github.com/rust-lang/compiler-team/issues/487

r? `@petrochenkov` cc `@yaahc`
2022-05-05 23:24:36 +00:00
lcnr
209dd2cb0a generalize "incoherent impls" impl for custom types 2022-05-05 10:53:00 +02:00
ridwanabdillahi
175a4eab84 Add support for a new attribute #[debugger_visualizer] to support embedding debugger visualizers into a generated PDB.
Cleanup `DebuggerVisualizerFile` type and other minor cleanup of queries.

Merge the queries for debugger visualizers into a single query.

Revert move of `resolve_path` to `rustc_builtin_macros`. Update dependencies in Cargo.toml for `rustc_passes`.

Respond to PR comments. Load visualizer files into opaque bytes `Vec<u8>`. Debugger visualizers for dynamically linked crates should not be embedded in the current crate.

Update the unstable book with the new feature. Add the tracking issue for the debugger_visualizer feature.

Respond to PR comments and minor cleanups.
2022-05-03 10:53:54 -07:00
Scott McMurray
e094ee5f10 Add do yeet expressions to allow experimentation in nightly
Using an obviously-placeholder syntax.  An RFC would still be needed before this could have any chance at stabilization, and it might be removed at any point.

But I'd really like to have it in nightly at least to ensure it works well with try_trait_v2, especially as we refactor the traits.
2022-04-30 17:40:27 -07:00
Dylan DPC
27e2d811e6
Rollup merge of #94457 - jhpratt:stabilize-derive_default_enum, r=davidtwco
Stabilize `derive_default_enum`

This stabilizes `#![feature(derive_default_enum)]`, as proposed in [RFC 3107](https://github.com/rust-lang/rfcs/pull/3107) and tracked in #87517. In short, it permits you to `#[derive(Default)]` on `enum`s, indicating what the default should be by placing a `#[default]` attribute on the desired variant (which must be a unit variant in the interest of forward compatibility).

```````@rustbot``````` label +S-waiting-on-review +T-lang
2022-04-15 20:50:43 +02:00
Jacob Pratt
0b3db4e4ee
Use native duplicate attribute check 2022-04-14 21:19:48 -04:00
Eric Huss
be23ead9a4 Fix crate_type attribute to not warn on duplicates 2022-04-10 16:35:37 -07:00
niluxv
98a4834237 Split fuzzy_provenance_casts into lossy and fuzzy, feature gate and test it
* split `fuzzy_provenance_casts` into a ptr2int and a int2ptr lint
* feature gate both lints
* update documentation to be more realistic short term
* add tests for these lints
2022-04-08 17:41:28 +02:00
Jacob Pratt
abf2b4c04d
Stabilize derive_default_enum 2022-04-07 20:03:19 -04:00
Dylan DPC
e08ab08a2e
Rollup merge of #94869 - jackh726:gats_extended, r=compiler-errors
Add the generic_associated_types_extended feature

Right now, this only ignore obligations that reference new placeholders in `poly_project_and_unify_type`. In the future, this might do other things, like allowing object-safe GATs.

**This feature is *incomplete* and quite likely unsound. This is mostly just for testing out potential future APIs using a "relaxed" set of rules until we figure out *proper* rules.**

Also drive by cleanup of adding a `ProjectAndUnifyResult` enum instead of using a `Result<Result<Option>>`.

r? `@nikomatsakis`
2022-03-31 00:26:29 +02:00
Jack Huey
4e570a68a1 Add the generic_associated_types_extended feature 2022-03-30 17:41:11 -04:00
Vadim Petrochenkov
1004783ef9 Stabilize native library modifier syntax and the whole-archive modifier specifically 2022-03-30 23:53:21 +03:00
lcnr
bef6f3e895 rework implementation for inherent impls for builtin types 2022-03-30 11:23:58 +02:00
lcnr
e8890aad62 move adt_const_params to its own tracking issue 2022-03-21 16:33:42 +01:00
Dylan DPC
0c73b252eb
Rollup merge of #94982 - skippy10110:deprecated_safe, r=Dylan-DPC
Add deprecated_safe feature gate and attribute, cc #94978
2022-03-17 22:55:06 +01:00
skippy10110
e4f1179fa6 Add deprecated_safe feature gate and attribute, cc #94978 2022-03-15 19:48:52 -03:00
Tony Arcieri
78567df575 Stabilize ADX target feature
This is a continuation of #60109, which noted that while the ADX
intrinsics were stabilized, the corresponding target feature never was.

This PR follows the same general structure and stabilizes the ADX target
feature.
2022-03-14 18:56:39 -06:00
Matthias Krüger
0e423932f8
Rollup merge of #90621 - adamgemmell:dev/stabilise-target-feature, r=Amanieu
Stabilise `aarch64_target_feature`

This PR stabilises `aarch64_target_feature` - see https://github.com/rust-lang/rust/issues/90620
2022-03-14 17:24:56 +01:00
Adam Gemmell
5a5621791f Stabilise aarch64_target_feature 2022-03-14 11:02:50 +00:00
Dylan DPC
634a6b0d25
Rollup merge of #94368 - c410-f3r:metaaaaaaaaaaaaaaaaaaaaaaaaaaa, r=petrochenkov
[1/2] Implement macro meta-variable expressions

See https://github.com/rust-lang/rust/pull/93545#issuecomment-1050963295

The logic behind `length`, `index` and `count` was removed but the parsing code is still present, i.e., everything is simply ignored like `ignored`.

r? ``@petrochenkov``
2022-03-10 23:12:58 +01:00
Dylan DPC
1ed2a94fd2
Rollup merge of #94274 - djkoloski:unknown_unstable_lints, r=tmandry
Treat unstable lints as unknown

This change causes unstable lints to be ignored if the `unknown_lints`
lint is allowed. To achieve this, it also changes lints to apply as soon
as they are processed. Previously, lints in the same set were processed
as a batch and then all simultaneously applied.

Implementation of https://github.com/rust-lang/compiler-team/issues/469
2022-03-10 23:12:57 +01:00
Matthias Krüger
313a668234
Rollup merge of #94635 - jhpratt:merge-deprecated-attrs, r=davidtwco
Merge `#[deprecated]` and `#[rustc_deprecated]`

The first commit makes "reason" an alias for "note" in `#[rustc_deprecated]`, while still prohibiting it in `#[deprecated]`.

The second commit changes "suggestion" to not just be a feature of `#[rustc_deprecated]`. This is placed behind the new `deprecated_suggestion` feature. This needs a tracking issue; let me know if this PR will be approved and I can create one.

The third commit is what permits `#[deprecated]` to be used when `#![feature(staged_api)]` is enabled. This isn't yet used in stdlib (only tests), as it would require duplicating all deprecation attributes until a bootstrap occurs. I intend to submit a follow-up PR that replaces all uses and removes the remaining `#[rustc_deprecated]` code after the next bootstrap.

`@rustbot` label +T-libs-api +C-feature-request +A-attributes +S-waiting-on-review
2022-03-10 12:20:51 +01:00
Jacob Pratt
5636655d0f
New deprecated_suggestion feature, use in tests 2022-03-09 16:32:47 -05:00
Caio
8073a88f35 Implement macro meta-variable expressions 2022-03-09 16:46:23 -03:00
David Koloski
8852752078 Treat unstable lints as unknown
This change causes unstable lints to be ignored if the `unknown_lints`
lint is allowed. To achieve this, it also changes lints to apply as soon
as they are processed. Previously, lints in the same set were processed
as a batch and then all simultaneously applied.

Implementation of https://github.com/rust-lang/compiler-team/issues/469
2022-03-08 19:06:40 +00:00
Matthias Krüger
e4a3627c24
Rollup merge of #94586 - sunfishcode:sunfishcode/io-lifetimes-tests, r=davidtwco
Generalize `get_nullable_type` to allow types where null is all-ones.

Generalize get_nullable_type to accept types that have an all-ones bit
pattern as their sentry "null" value.

This will allow [`OwnedFd`], [`BorrowedFd`], [`OwnedSocket`], and
[`BorrowedSocket`] to be marked with
`#[rustc_nonnull_optimization_guaranteed]`, which will allow
`Option<OwnedFd>`, `Option<BorrowedFd>`, `Option<OwnedSocket>`, and
`Option<BorrowedSocket>` to be used in FFI declarations, as described
in the [I/O safety RFC].

For example, it will allow a function like `open` on Unix and `WSASocketW`
on Windows to be declared using `Option<OwnedFd>` and `Option<OwnedSocket>`
return types, respectively.

The actual change to add `#[rustc_nonnull_optimization_guaranteed]`
to the abovementioned types will be a separate PR, as it'll depend on
having this patch in the stage0 compiler.

Also, update the diagnostics to mention that "niche optimizations" are
used in libstd as well as libcore, as `rustc_layout_scalar_valid_range_start`
and `rustc_layout_scalar_valid_range_end` are already in use in libstd.

[`OwnedFd`]: c9dc44be24/library/std/src/os/fd/owned.rs (L49)
[`BorrowedFd`]: c9dc44be24/library/std/src/os/fd/owned.rs (L29)
[`OwnedSocket`]: c9dc44be24/library/std/src/os/windows/io/socket.rs (L51)
[`BorrowedSocket`]: c9dc44be24/library/std/src/os/windows/io/socket.rs (L29)
[I/O safety RFC]: https://github.com/rust-lang/rfcs/blob/master/text/3128-io-safety.md#ownedfd-and-borrowedfdfd-1
2022-03-08 11:04:53 +01:00
Eric Holk
1afbf3e4b1 Bump stabilization version to 1.61.0 2022-03-07 08:47:18 -08:00
Eric Holk
8700b45b67 Stabilize const_impl_trait as well 2022-03-07 08:47:18 -08:00
Eric Holk
7723506d13 Stabilize const_fn_fn_ptr_basics and const_fn_trait_bound 2022-03-07 08:47:15 -08:00
Jacob Pratt
6efc8e34d8
Change rustc_deprecated to use note
This keeps `reason` around for the time being. This is necessary to
avoid breakage during the bootstrap process. This change, as a whole,
brings `#[rustc_deprecated]` more in line with `#[deprecated]`.
2022-03-04 18:15:49 -05:00
bors
65f6d33b77 Auto merge of #94096 - cjgillot:ensure-stability, r=lcnr
Ensure stability directives are checked in all cases

Split off  #93017

Stability and deprecation were not checked in all cases, for instance if a type error happened.
This PR moves the check earlier in the pipeline to ensure the errors are emitted in all cases.

r? `@lcnr`
2022-03-04 05:49:14 +00:00
Dan Gohman
86b4658c56 Generalize get_nullable_type to allow types where null is all-ones.
Generalize get_nullable_type to accept types that have an all-ones bit
pattern as their sentry "null" value.

This will allow [`OwnedFd`], [`BorrowedFd`], [`OwnedSocket`], and
[`BorrowedSocket`] to be marked with
`#[rustc_nonnull_optimization_guaranteed]`, which will allow
`Option<OwnedFd>`, `Option<BorrowedFd>`, `Option<OwnedSocket>`, and
`Option<BorrowedSocket>` to be used in FFI declarations, as described
in the [I/O safety RFC].

For example, it will allow a function like `open` on Unix and `WSASocketW`
on Windows to be declared using `Option<OwnedFd>` and `Option<OwnedSocket>`
return types, respectively.

The actual change to add `#[rustc_nonnull_optimization_guaranteed]`
to the abovementioned types will be a separate PR, as it'll depend on
having this patch in the stage0 compiler.

Also, update the diagnostics to mention that "niche optimizations" are
used in libstd as well as libcore, as `rustc_layout_scalar_valid_range_start`
and `rustc_layout_scalar_valid_range_end` are already in use in libstd.

[`OwnedFd`]: c9dc44be24/library/std/src/os/fd/owned.rs (L49)
[`BorrowedFd`]: c9dc44be24/library/std/src/os/fd/owned.rs (L29)
[`OwnedSocket`]: c9dc44be24/library/std/src/os/windows/io/socket.rs (L51)
[`BorrowedSocket`]: c9dc44be24/library/std/src/os/windows/io/socket.rs (L29)
[I/O safety RFC]: https://github.com/rust-lang/rfcs/blob/master/text/3128-io-safety.md#ownedfd-and-borrowedfdfd-1
2022-03-03 16:20:13 -08:00
Camille GILLOT
fbcf7d415b Move the set of features to the features query. 2022-03-03 18:08:30 +01:00
xFrednet
9fef3d9e0a
Added Expect lint level and attribute (RFC-2383)
* Also added the `LintExpectationId` which will be used in future commits
2022-03-02 17:46:05 +01:00
Michael Goulet
bb548a918a Remove in-band lifetimes 2022-02-24 18:50:33 -08:00
Mario Carneiro
c1d75a27b2
fix names in feature(...) suggestion 2022-02-21 01:17:37 -08:00
Matthias Krüger
f19adc7acc
Rollup merge of #93658 - cchiw:issue-77443-fix, r=joshtriplett
Stabilize `#[cfg(panic = "...")]`

[Stabilization PR](https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#stabilization-pr) for #77443
2022-02-19 06:45:29 +01:00
Matthias Krüger
67331708e8
Rollup merge of #93337 - Amanieu:asm_tracking, r=tmiasko
Update tracking issue numbers for inline assembly sub-features

The main tracking issue for inline assembly is [closed](https://github.com/rust-lang/rust/issues/72016#issuecomment-1022332954), further tracking of the remaining sub-features has been moved to separate tracking issues.
2022-02-17 23:00:55 +01:00
Mark Rousskov
fc01d2b854 Destabilize cfg(target_has_atomic_load_store = ...)
This was not intended to be stabilized yet.
2022-02-16 10:28:12 -05:00
Mara Bos
bf2a9dc375
Update unsafe_pin_internals unstable version. 2022-02-14 19:17:21 +00:00
Daniel Henry-Mantilla
c93968aee8 Mark unsafe_pin_internals as incomplete.
This thus still makes it technically possible to enable the feature, and thus
to trigger UB without `unsafe`, but this is fine since incomplete features are
known to be potentially unsound (labelled "may not be safe").

This follows from the discussion at https://github.com/rust-lang/rust/pull/93176#discussion_r799413561
2022-02-14 17:27:37 +01:00
Charisee
4404a4e365 updating the feature-gate listing and do not require the feature-gate to use the feature 2022-02-10 21:52:08 +00:00
Matthias Krüger
aa2095936a
Rollup merge of #93824 - Amanieu:stable_cfg_target_has_atomic, r=davidtwco
Stabilize cfg_target_has_atomic

`target_has_atomic_equal_alignment` is now tracked separately in #93822.

Closes #32976
2022-02-10 12:10:00 +01:00
Matthias Krüger
84c28041b4
Rollup merge of #93753 - jeremyBanks:main-conflict, r=petrochenkov
Complete removal of #[main] attribute from compiler

resolves #93786

---

The `#[main]` attribute was mostly removed from the language in #84217, but not completely. It is still recognized as a builtin attribute by the compiler, but it has no effect. However, this no-op attribute is no longer gated by `#[feature(main)]` (which no longer exists), so it's possible to include it in code *on stable* without any errors, which seems unintentional. For example, the following code is accepted ([playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&code=%23%5Bmain%5D%0Afn%20main()%20%7B%0A%20%20%20%20println!(%22hello%20world%22)%3B%0A%7D%0A)).

```rust
#[main]
fn main() {
    println!("hello world");
}
```

Aside from that oddity, the existence of this attribute causes code like the following to fail ([playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&code=use%20tokio%3A%3Amain%3B%0A%0A%23%5Bmain%5D%0Afn%20main()%20%7B%0A%20%20%20%20println!(%22hello%20world%22)%3B%0A%7D%0A)). According https://github.com/rust-lang/rust/pull/84062#issuecomment-825038275, the removal of `#[main]` was expected to eliminate this conflict (previously reported as #62127).

```rust
use tokio::main;

#[main]
fn main() {
    println!("hello world");
}
```

```
error[E0659]: `main` is ambiguous
 --> src/main.rs:3:3
  |
3 | #[main]
  |   ^^^^ ambiguous name
  |
  = note: ambiguous because of a name conflict with a builtin attribute
  = note: `main` could refer to a built-in attribute
```

[This error message can be confusing](https://stackoverflow.com/q/71024443/1114), as the mostly-removed `#[main]` attribute is not mentioned in any documentation.

Since the current availability of `#[main]` on stable seems unintentional, and to needlessly block use of the `main` identifier in the attribute namespace, this PR finishes removing the `#[main]` attribute as described in https://github.com/rust-lang/rust/issues/29634#issuecomment-274951753 by deleting it from `builtin_attrs.rs`, and adds two test cases to ensure that the attribute is no longer accepted and no longer conflicts with other attributes imported as `main`.
2022-02-09 23:29:57 +01:00
Matthias Krüger
3f4aaf4f2e
Rollup merge of #91504 - cynecx:used_retain, r=nikic
`#[used(linker)]` attribute

See https://github.com/dtolnay/linkme/issues/41#issuecomment-927255631.
2022-02-09 23:29:56 +01:00
Amanieu d'Antras
49d4823112 Stabilize cfg_target_has_atomic
Closes #32976
2022-02-09 18:45:44 +00:00
Nikita Popov
933963e10a Add tracking issue 2022-02-09 11:21:25 +01:00
Jeremy Banks
475e4eeb65 Remove obsolete no-op #[main] attribute from compiler. 2022-02-08 00:46:16 +00:00
Mara Bos
f4377a8932
Rollup merge of #93682 - PatchMixolydic:where-in-the-world-is-const_fn_trait_bound, r=oli-obk
Update tracking issue for `const_fn_trait_bound`

It previously pointed to #57563, the conglomerate issue for `const fn` (presumably under the feature gate `const_fn`). This tracking issue doesn't mention anything about `const_fn_trait_bound`(the only occurrence of "trait bound" is for the now-removed `?const Trait` syntax), which can be confusing to people who want to find out more about trait bounds on `const fn`s. This pull request changes the tracking issue to one meant specifically for `const_fn_trait_bound`, #93706, which can help collect information on this feature's stabilization and point users towards `const_trait_impl` if they're looking for const-in-const-contexts trait bounds.

Fixes #93679.

`````@rustbot````` modify labels +A-const-fn +F-const_trait_impl
2022-02-07 14:08:37 +00:00