Commit Graph

684 Commits

Author SHA1 Message Date
Bryan Garza
673ab17c7f Add separate feature gate for async fn track caller
This patch adds a feature gate `async_fn_track_caller` that is separate from `closure_track_caller`. This is to allow enabling `async_fn_track_caller` separately.

Fixes #110009
2023-08-02 14:18:21 -07:00
Michael Goulet
4b58ae0bb8 Mark lazy_type_alias as incomplete 2023-07-29 19:47:15 +00:00
León Orell Valerian Liehr
afd009a8d8
Parse generic const items 2023-07-28 22:21:33 +02:00
Georg Semmler
5b576665e5
Introduce the #[diagnostic] attribute namespace
Co-authored-by: est31 <est31@users.noreply.github.com>

Co-authored-by: Esteban Kuber <estebank@users.noreply.github.com>

Co-authored-by: Vadim Petrochenkov <vadim.petrochenkov@gmail.com>
2023-07-28 13:28:02 +02:00
许杰友 Jieyou Xu (Joe)
08c77a6eb4
Add infrastructure #[rustc_confusables] attribute to allow targeted
"no method" errors on standard library types

The standard library developer can annotate methods on e.g.
`BTreeSet::push` with `#[rustc_confusables("insert")]`. When the user
mistypes `btreeset.push()`, `BTreeSet::insert` will be suggested if
there are no other candidates to suggest.
2023-07-16 19:22:03 +08:00
Mahdi Dibaiee
e55583c4b8 refactor(rustc_middle): Substs -> GenericArg 2023-07-14 13:27:35 +01:00
Mark Rousskov
0d93d787ba Replace version placeholder to 1.72 2023-07-12 21:24:05 -04:00
Deadbeef
2d5d56bb59 Add feature and attribute definition 2023-07-04 11:47:45 +00:00
Matthias Krüger
42a495da7e
Rollup merge of #112670 - petrochenkov:typriv, r=eholk
privacy: Type privacy lints fixes and cleanups

See individual commits.
Follow up to https://github.com/rust-lang/rust/pull/111801.
2023-06-29 05:48:39 +02:00
Guillaume Gomez
009d72b3ae
Rollup merge of #112853 - GuillaumeGomez:type_alias_type, r=oli-obk
Add `lazy_type_alias` feature gate

Add the `type_alias_type` to be able to have the weak alias used without restrictions.

Part of #112792.

cc `@compiler-errors`
r? `@oli-obk`
2023-06-21 15:45:16 +02:00
Guillaume Gomez
60ec8405eb Add lazy_type_alias feature gate 2023-06-21 13:45:00 +02:00
Nilstrieb
c6710d15f1
Rollup merge of #112790 - WaffleLapkin:syntactically, r=Nilstrieb
Syntactically accept `become` expressions (explicit tail calls experiment)

This adds `ast::ExprKind::Become`, implements parsing and properly gates the feature.

cc `@scottmcm`
2023-06-21 07:37:02 +02:00
Michael Goulet
ca68cf0d46 Merge attrs, better validation 2023-06-20 04:38:55 +00:00
Michael Goulet
91e5c3f2e5 Make rustc_deny_explicit_impl only local as well 2023-06-20 04:38:46 +00:00
Michael Goulet
657d3f43a9 Add rustc_do_not_implement_via_object 2023-06-20 04:38:46 +00:00
Maybe Waffle
d7713feb99 Syntatically accept become expressions 2023-06-19 12:54:34 +00:00
Vadim Petrochenkov
d326aed46f privacy: Feature gate new type privacy lints 2023-06-15 21:25:47 +03:00
bors
23f93a1266 Auto merge of #103877 - oli-obk:const_eval_step_limit, r=fee1-dead
Replace const eval limit by a lint and add an exponential backoff warning

The lint triggers at the first power of 2 that comes after 1 million function calls or traversed back-edges (takes less than a second on usual programs). After the first emission, an unsilenceable warning is repeated at every following power of 2 terminators, causing it to get reported less and less the longer the evaluation runs.

cc `@rust-lang/wg-const-eval`

fixes #93481
closes #67217
2023-06-01 05:32:00 +00:00
Oli Scherer
05eae08233 Remove const eval limit and implement an exponential backoff lint instead 2023-05-31 10:24:17 +00:00
Mark Rousskov
4f9b394c8a Swap out CURRENT_RUSTC_VERSION to 1.71.0 2023-05-30 07:54:29 -04:00
Maybe Waffle
307799a711 Use is_some_and/is_ok_and in less obvious spots 2023-05-24 14:33:43 +00:00
Maybe Waffle
fb0f74a8c9 Use Option::is_some_and and Result::is_ok_and in the compiler 2023-05-24 14:20:41 +00:00
klensy
9799fb1ddc fixup version placeholder for cfi_encoding feature 2023-05-15 19:19:13 +03:00
AngelicosPhosphoros
7c263adb2a Add support for cfg(overflow_checks)
This PR adds support for detecting if overflow checks are enabled in similar fashion as debug_assertions are detected.
Possible use-case of this, for example, if we want to use checked integer casts in builds with overflow checks, e.g.

```rust
pub fn cast(val: usize)->u16 {
    if cfg!(overflow_checks) {
        val.try_into().unwrap()
    }
    else{
        vas as _
    }
}
```

Resolves #91130.
Tracking issue: #111466.
2023-05-11 18:06:31 +04:00
Dylan DPC
dbd090c655
Rollup merge of #110694 - est31:builtin, r=petrochenkov
Implement builtin # syntax and use it for offset_of!(...)

Add `builtin #` syntax to the parser, as well as a generic infrastructure to support both item and expression position builtin syntaxes. The PR also uses this infrastructure for the implementation of the `offset_of!` macro, added by #106934.

cc `@petrochenkov` `@DrMeepster`

cc #110680 `builtin #` tracking issue
cc #106655 `offset_of!` tracking issue
2023-05-09 12:33:45 +05:30
Yuki Okushi
923a5a2ca7
Rollup merge of #109677 - dpaoliello:rawdylib, r=michaelwoerister,wesleywiser
Stabilize raw-dylib, link_ordinal, import_name_type and -Cdlltool

This stabilizes the `raw-dylib` feature (#58713) for all architectures (i.e., `x86` as it is already stable for all other architectures).

Changes:
* Permit the use of the `raw-dylib` link kind for x86, the `link_ordinal` attribute and the `import_name_type` key for the `link` attribute.
* Mark the `raw_dylib` feature as stable.
* Stabilized the `-Zdlltool` argument as `-Cdlltool`.
* Note the path to `dlltool` if invoking it failed (we don't need to do this if `dlltool` returns an error since it prints its path in the error message).
* Adds tests for `-Cdlltool`.
* Adds tests for being unable to find the dlltool executable, and dlltool failing.
* Fixes a bug where we were checking the exit code of dlltool to see if it failed, but dlltool always returns 0 (indicating success), so instead we need to check if anything was written to `stderr`.

NOTE: As previously noted (https://github.com/rust-lang/rust/pull/104218#issuecomment-1315895618) using dlltool within rustc is temporary, but this is not the first time that Rust has added a temporary tool use and argument: https://github.com/rust-lang/rust/pull/104218#issuecomment-1318720482

Big thanks to ``````@tbu-`````` for the first version of this PR (#104218)
2023-05-06 09:09:30 +09:00
est31
83b4df4e61 Add feature gate 2023-05-05 21:44:48 +02:00
Dylan DPC
4891f02cff
Rollup merge of #108801 - fee1-dead-contrib:c-str, r=compiler-errors
Implement RFC 3348, `c"foo"` literals

RFC: https://github.com/rust-lang/rfcs/pull/3348
Tracking issue: #105723
2023-05-05 18:40:33 +05:30
Manish Goregaokar
38bbc39895
Rollup merge of #105452 - rcvalle:rust-cfi-3, r=bjorn3
Add cross-language LLVM CFI support to the Rust compiler

This PR adds cross-language LLVM Control Flow Integrity (CFI) support to the Rust compiler by adding the `-Zsanitizer-cfi-normalize-integers` option to be used with Clang `-fsanitize-cfi-icall-normalize-integers` for normalizing integer types (see https://reviews.llvm.org/D139395).

It provides forward-edge control flow protection for C or C++ and Rust -compiled code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code share the same virtual address space). For more information about LLVM CFI and cross-language LLVM CFI support for the Rust compiler, see design document in the tracking issue #89653.

Cross-language LLVM CFI can be enabled with -Zsanitizer=cfi and -Zsanitizer-cfi-normalize-integers, and requires proper (i.e., non-rustc) LTO (i.e., -Clinker-plugin-lto).

Thank you again, ``@bjorn3,`` ``@nikic,`` ``@samitolvanen,`` and the Rust community for all the help!
2023-05-03 16:42:48 -07:00
Ramon de C Valle
004aa15b47 Add cross-language LLVM CFI support to the Rust compiler
This commit adds cross-language LLVM Control Flow Integrity (CFI)
support to the Rust compiler by adding the
`-Zsanitizer-cfi-normalize-integers` option to be used with Clang
`-fsanitize-cfi-icall-normalize-integers` for normalizing integer types
(see https://reviews.llvm.org/D139395).

It provides forward-edge control flow protection for C or C++ and Rust
-compiled code "mixed binaries" (i.e., for when C or C++ and Rust
-compiled code share the same virtual address space). For more
information about LLVM CFI and cross-language LLVM CFI support for the
Rust compiler, see design document in the tracking issue #89653.

Cross-language LLVM CFI can be enabled with -Zsanitizer=cfi and
-Zsanitizer-cfi-normalize-integers, and requires proper (i.e.,
non-rustc) LTO (i.e., -Clinker-plugin-lto).
2023-05-03 22:41:29 +00:00
Michael Goulet
6e01e910cb Implement negative bounds 2023-05-02 22:36:24 +00:00
Deadbeef
a49570fd20 fix TODO comments 2023-05-02 10:32:07 +00:00
Deadbeef
76d1f93896 update and add a few tests 2023-05-02 10:30:09 +00:00
Dylan DPC
2e3373c231
Rollup merge of #111048 - compiler-errors:rpitit-not-incomplete, r=jackh726
Mark`feature(return_position_impl_trait_in_trait)` and`feature(async_fn_in_trait)` as not incomplete

I think they've graduated, since as far as I'm aware, they don't cause compiler crashes or unsoundness anymore.
2023-05-02 11:44:53 +05:30
Dylan DPC
f379a58bf2
Rollup merge of #108668 - gibbyfree:stabilizedebuggervisualizer, r=wesleywiser
Stabilize debugger_visualizer

This stabilizes the `debugger_visualizer` attribute (#95939).

* Marks the `debugger_visualizer` feature as `accepted`.
* Marks the `debugger_visualizer` attribute as `ungated`.
* Deletes feature gate test, removes feature gate from other tests.

Closes #95939
2023-05-02 11:44:51 +05:30
Michael Goulet
7411468ff8 Mark RPITIT and AFIT as no longer incomplete 2023-05-02 05:04:50 +00:00
bors
1cb63572d2 Auto merge of #106075 - nbdd0121:ffi-unwind, r=joshtriplett
Partial stabilisation of `c_unwind`

The stabilisation report is at https://github.com/rust-lang/rust/issues/74990#issuecomment-1363473645

cc `@rust-lang/wg-ffi-unwind`
2023-05-02 00:45:04 +00:00
Gary Guo
723aee2e56 Partial stabilisation of c_unwind 2023-04-29 13:01:44 +01:00
Guillaume Gomez
344dd0e828 Make repr attribute local_only 2023-04-29 11:50:16 +02:00
bors
572c0d553f Auto merge of #110643 - pietroalbini:pa-bump-stage0, r=Mark-Simulacrum
[master] Bump stage0

r? `@Mark-Simulacrum`
2023-04-29 02:29:14 +00:00
bors
f495605381 Auto merge of #110901 - GuillaumeGomez:inlined-repr-rustdoc, r=notriddle
rustdoc: Fix missing `repr` attribute in doc(inline) on foreign items

Fixes https://github.com/rust-lang/rust/issues/110698.

r? `@notriddle`
2023-04-28 20:33:33 +00:00
Pietro Albini
4e04da6183 replace version placeholders 2023-04-28 08:47:55 -07:00
Guillaume Gomez
adee37a080 repr attribute needs to be stored to be used in doc(inline) by rustdoc 2023-04-27 16:40:59 +02:00
Matthias Krüger
f54dbe6e31 Revert "Remove #[alloc_error_handler] from the compiler and library"
This reverts commit abc0660118.
2023-04-25 00:08:35 +02:00
bors
39cf520299 Auto merge of #109507 - Amanieu:panic-oom-payload, r=davidtwco
Report allocation errors as panics

OOM is now reported as a panic but with a custom payload type (`AllocErrorPanicPayload`) which holds the layout that was passed to `handle_alloc_error`.

This should be review one commit at a time:
- The first commit adds `AllocErrorPanicPayload` and changes allocation errors to always be reported as panics.
- The second commit removes `#[alloc_error_handler]` and the `alloc_error_hook` API.

ACP: https://github.com/rust-lang/libs-team/issues/192

Closes #51540
Closes #51245
2023-04-22 12:27:45 +00:00
Daniel Paoliello
1ece1ea48c Stablize raw-dylib, link_ordinal and -Cdlltool 2023-04-18 11:01:07 -07:00
Josh Soref
e09d0d2a29 Spelling - compiler
* account
* achieved
* advising
* always
* ambiguous
* analysis
* annotations
* appropriate
* build
* candidates
* cascading
* category
* character
* clarification
* compound
* conceptually
* constituent
* consts
* convenience
* corresponds
* debruijn
* debug
* debugable
* debuggable
* deterministic
* discriminant
* display
* documentation
* doesn't
* ellipsis
* erroneous
* evaluability
* evaluate
* evaluation
* explicitly
* fallible
* fulfill
* getting
* has
* highlighting
* illustrative
* imported
* incompatible
* infringing
* initialized
* into
* intrinsic
* introduced
* javascript
* liveness
* metadata
* monomorphization
* nonexistent
* nontrivial
* obligation
* obligations
* offset
* opaque
* opportunities
* opt-in
* outlive
* overlapping
* paragraph
* parentheses
* poisson
* precisely
* predecessors
* predicates
* preexisting
* propagated
* really
* reentrant
* referent
* responsibility
* rustonomicon
* shortcircuit
* simplifiable
* simplifications
* specify
* stabilized
* structurally
* suggestibility
* translatable
* transmuting
* two
* unclosed
* uninhabited
* visibility
* volatile
* workaround

Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>
2023-04-17 16:09:18 -04:00
Amanieu d'Antras
abc0660118 Remove #[alloc_error_handler] from the compiler and library 2023-04-16 08:35:50 -07:00
Matthias Krüger
214e4ef4ef
Rollup merge of #110237 - oli-obk:impl_trait_in_assoc_tys, r=jackh726
Split out a separate feature gate for impl trait in associated types

in https://github.com/rust-lang/rust/issues/107645 it was decided that we'll take a new route for type alias impl trait. The exact route isn't clear yet, so while I'm working on implementing some of these proposed changes (e.g. in https://github.com/rust-lang/rust/pull/110010) to be able to experiment with them, I will also work on stabilizing another sugar version first: impl trait in associated types. Similarly I'll look into creating feature gates for impl trait in const/static types.

This PR does nothing but split the feature gate, so that you need to enable a different feature gate for

```rust
impl Trait for Type {
    type Assoc = impl SomeTrait;
}
```

than what you need for `type Foo = impl SomeTrait;`
2023-04-12 20:56:24 +02:00
Oli Scherer
f263f88bea Split out a separate feature gate for impl trait in associated types 2023-04-12 16:17:31 +00:00
DaniPopes
677357d32b
Fix typos in compiler 2023-04-10 22:02:52 +02:00
bors
af06dce64b Auto merge of #106281 - JulianKnodt:transmute_const_generics, r=b-naber
Add ability to transmute (somewhat) with generic consts in arrays

Previously if the expression contained generic consts and did not have a directly equivalent type, transmuting the type in this way was forbidden, despite the two sizes being identical. Instead, we should be able to lazily tell if the two consts are identical, and if so allow them to be transmuted.

This is done by normalizing the forms of expressions into sorted order of multiplied terms, which is not generic over all expressions, but should handle most cases.

This allows for some _basic_ transmutations between types that are equivalent in size without requiring additional stack space at runtime.

I only see one other location at which `SizeSkeleton` is being used, and it checks for equality so this shouldn't affect anywhere else that I can tell.

See [this Stackoverflow post](https://stackoverflow.com/questions/73085012/transmute-nested-const-generic-array-rust) for what was previously necessary to convert between types. This PR makes converting nested `T -> [T; 1]` transmutes possible, and `[uB*2; N] -> [uB; N * 2]` possible as well.

I'm not sure whether this is something that would be wanted, and if it is it definitely should not be insta-stable, so I'd add a feature gate.
2023-04-08 19:47:22 +00:00
kadmin
b76dd8c807 Add feature gate 2023-04-07 11:18:07 -07:00
bors
5e1d3299a2 Auto merge of #109824 - GuillaumeGomez:rollup-i5r4uts, r=GuillaumeGomez
Rollup of 7 pull requests

Successful merges:

 - #109104 (rustdoc: Fix invalid suggestions on ambiguous intra doc links v2)
 - #109443 (Move `doc(primitive)` future incompat warning to `invalid_doc_attributes`)
 - #109680 (Fix subslice capture in closure)
 - #109798 (fluent_messages macro: don't emit the OS error in a note)
 - #109805 (Source map cleanups)
 - #109818 (rustdoc: Add GUI test for jump to collapsed item)
 - #109820 (rustdoc-search: update docs for comma in `?` help popover)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
2023-03-31 20:38:06 +00:00
bors
7402519c63 Auto merge of #109010 - compiler-errors:rtn, r=eholk
Initial support for return type notation (RTN)

See: https://smallcultfollowing.com/babysteps/blog/2023/02/13/return-type-notation-send-bounds-part-2/

1. Only supports `T: Trait<method(): Send>` style bounds, not `<T as Trait>::method(): Send`. Checking validity and injecting an implicit binder for all of the late-bound method generics is harder to do for the latter.
    * I'd add this in a follow-up.
3. ~Doesn't support RTN in general type position, i.e. no `let x: <T as Trait>::method() = ...`~
    * I don't think we actually want this.
5. Doesn't add syntax for "eliding" the function args -- i.e. for now, we write `method(): Send` instead of `method(..): Send`.
    * May be a hazard if we try to add it in the future. I'll probably add it in a follow-up later, with a structured suggestion to change `method()` to `method(..)` once we add it.
7. ~I'm not in love with the feature gate name 😺~
    * I renamed it to `return_type_notation` ✔️

Follow-up PRs will probably add support for `where T::method(): Send` bounds. I'm not sure if we ever want to support return-type-notation in arbitrary type positions. I may also make the bounds require `..` in the args list later.

r? `@ghost`
2023-03-31 18:04:12 +00:00
Guillaume Gomez
f40aa598e9 Rename doc(primitive) into rustc_doc_primitive 2023-03-30 22:56:52 +02:00
Trevor Gross
dc4ba57566 Stabilize a portion of 'once_cell'
Move items not part of this stabilization to 'lazy_cell' or 'once_cell_try'
2023-03-29 18:04:44 -04:00
Michael Goulet
fb9ca9223d Feature gate 2023-03-28 01:02:15 +00:00
Matthias Krüger
5a017d3a57
Rollup merge of #108549 - clubby789:fix-link-cfg-issue, r=eholk
Remove issue number for `link_cfg`

Fixes #72059

Per #37406 and its [unstable book entry](https://doc.rust-lang.org/beta/unstable-book/language-features/link-cfg.html), this is an internal feature, and therefore perma-unstable and not being tracked
2023-03-23 19:55:44 +01:00
Mark Rousskov
01d7af11e1 Bump version placeholders 2023-03-15 08:55:22 -04:00
clubby789
0932452fa4 Remove box_syntax from AST and use in tools 2023-03-12 13:19:46 +00:00
Caleb Zulawski
d3cbedd49e Stabilize movbe target feature 2023-03-02 17:14:47 -05:00
Gibby Free
5c34f7788f whitespace, delete unstable book page 2023-03-02 10:41:08 -08:00
Léo Lanteri Thauvin
bfe5189904 Revert "Stabilize #![feature(target_feature_11)]"
This reverts commit b379d216ee.
2023-03-02 13:41:17 +01:00
Gibby Free
05c1e6b1db stabilize debugger visualizer attribute 2023-03-01 18:56:29 -08:00
Matthias Krüger
78f9bb11fe
Rollup merge of #108550 - clubby789:remove-disjoint, r=compiler-errors
Remove the `capture_disjoint_fields` feature

As best I can tell, this was stabilized for Edition 2021 in #88126 but the feature was never removed.
2023-03-01 01:20:24 +01:00
bors
fd1f1fa0d1 Auto merge of #106774 - Nugine:master, r=Amanieu
Stabilize cmpxchg16b_target_feature

Tracking issue for target features
+ #44839

stdarch issue
+ https://github.com/rust-lang/stdarch/issues/827

stdarch PR
+ https://github.com/rust-lang/stdarch/pull/1358

reference PR
+ https://github.com/rust-lang/reference/pull/1331

It's my first time contributing to rust-lang/rust. Please tell me if I missed something.
2023-02-28 04:12:34 +00:00
clubby789
f83ce99c32 Remove the capture_disjoint_fields feature 2023-02-28 01:21:15 +00:00
bors
b583ede652 Auto merge of #99767 - LeSeulArtichaut:stable-target-feature-11, r=estebank
Stabilize `#![feature(target_feature_11)]`

## Stabilization report

### Summary

Allows for safe functions to be marked with `#[target_feature]` attributes.

Functions marked with `#[target_feature]` are generally considered as unsafe functions: they are unsafe to call, cannot be assigned to safe function pointers, and don't implement the `Fn*` traits.

However, calling them from other `#[target_feature]` functions with a superset of features is safe.

```rust
// Demonstration function
#[target_feature(enable = "avx2")]
fn avx2() {}

fn foo() {
    // Calling `avx2` here is unsafe, as we must ensure
    // that AVX is available first.
    unsafe {
        avx2();
    }
}

#[target_feature(enable = "avx2")]
fn bar() {
    // Calling `avx2` here is safe.
    avx2();
}
```

### Test cases

Tests for this feature can be found in [`src/test/ui/rfcs/rfc-2396-target_feature-11/`](b67ba9ba20/src/test/ui/rfcs/rfc-2396-target_feature-11/).

### Edge cases

- https://github.com/rust-lang/rust/issues/73631

Closures defined inside functions marked with `#[target_feature]` inherit the target features of their parent function. They can still be assigned to safe function pointers and implement the appropriate `Fn*` traits.

```rust
#[target_feature(enable = "avx2")]
fn qux() {
    let my_closure = || avx2(); // this call to `avx2` is safe
    let f: fn() = my_closure;
}
```

This means that in order to call a function with `#[target_feature]`, you must show that the target-feature is available while the function executes *and* for as long as whatever may escape from that function lives.

### Documentation

- Reference: https://github.com/rust-lang/reference/pull/1181

---
cc tracking issue #69098
r? `@ghost`
2023-02-28 01:14:56 +00:00
clubby789
e7c8af431b Remove issue number for link_cfg 2023-02-28 00:48:05 +00:00
Michael Goulet
fded2e95ab Adjust tracking issue for non_lifetime_binders 2023-02-18 02:42:43 +00: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
BelovDV
b488508c17 note issue for feature(packed_bundled_libs) 2023-02-16 14:09:55 +03:00
Michael Goulet
262a344d72 Add feature gate for non_lifetime_binders 2023-02-16 03:39:58 +00:00
lcnr
a2f03037b4 change the marker attribute to only_local 2023-02-14 12:18:33 +01:00
lcnr
646e667200 add a #[rustc_coinductive] attribute 2023-02-14 11:53:22 +01:00
Daniil Belov
601fc8b36b [link] enable packed bundled lib in non stable cases 2023-02-10 12:51:12 +03:00
Léo Lanteri Thauvin
b379d216ee Stabilize #![feature(target_feature_11)] 2023-02-01 08:53:02 +01:00
Nugine
a4f2d14875
Stabilize cmpxchg16b_target_feature 2023-02-01 10:54:43 +08:00
bors
dc1d9d50fb Auto merge of #107297 - Mark-Simulacrum:bump-bootstrap, r=pietroalbini
Bump bootstrap compiler to 1.68

This also changes our stage0.json to include the rustc component for the rustfmt pinned nightly toolchain, which is currently necessary due to rustfmt dynamically linking to that toolchain's librustc_driver and libstd.

r? `@pietroalbini`
2023-01-31 19:24:29 +00:00
Gary Guo
66f3ab90a1 Reintroduce multiple_supertrait_upcastable lint 2023-01-28 15:08:07 +00:00
Mark Rousskov
3653254f91 Set version placeholders to 1.68 2023-01-25 09:44:29 -05:00
Dylan DPC
9e6873f788
Rollup merge of #106767 - chbaker0:disable-unstable-features, r=Mark-Simulacrum
Allow setting CFG_DISABLE_UNSTABLE_FEATURES to 0

Two locations check whether this build-time environment variable is defined. Allowing it to be explicitly disabled with a "0" value is useful, especially for integrating with external build systems.
2023-01-25 17:01:41 +05:30
bors
279f1c9d8c Auto merge of #106004 - fee1-dead-contrib:const-closures, r=oli-obk
Const closures

cc https://github.com/rust-lang/rust/issues/106003
2023-01-13 05:04:48 +00:00
Yuki Okushi
fa8f77a1de
Rollup merge of #105795 - nicholasbishop:bishop-stabilize-efiapi, r=joshtriplett
Stabilize `abi_efiapi` feature

Tracking issue: https://github.com/rust-lang/rust/issues/65815
Closes #65815
2023-01-13 05:47:21 +09:00
Collin Baker
0a03d1c9ca Allow setting CFG_DISABLE_UNSTABLE_FEATURES to 0
Two locations check whether this build-time environment variable is
defined. Allowing it to be explicitly disabled with a "0" value is
useful, especially for integrating with external build systems.
2023-01-12 05:36:04 -05:00
Michael Goulet
244b90edee
Rollup merge of #106323 - starkat99:stabilize-f16c_target_feature, r=petrochenkov
Stabilize f16c_target_feature

Resolves https://github.com/rust-lang/stdarch/issues/1234

Library PR for stabilizing corresponding intrinsics: https://github.com/rust-lang/stdarch/pull/1366

See also #44839 tracking issue for target_feature
2023-01-11 22:25:48 -08:00
Deadbeef
e7fea8c7e6 gate const closures 2023-01-12 02:28:37 +00:00
Nicholas Bishop
46f9e878f6 Stabilize abi_efiapi feature
Tracking issue: https://github.com/rust-lang/rust/issues/65815
2023-01-11 20:42:13 -05:00
Caio
c43faf110d [RFC 2397] Initial implementation 2023-01-09 20:51:01 -03:00
nils
fd7a159710 Fix uninlined_format_args for some compiler crates
Convert all the crates that have had their diagnostic migration
completed (except save_analysis because that will be deleted soon and
apfloat because of the licensing problem).
2023-01-05 19:01:12 +01:00
Léo Lanteri Thauvin
6289fe2cf1 Use the correct tracking issue for dyn_star 2023-01-01 19:56:10 +01:00
Kathryn Long
a29425c6d4
Stabilize f16c_target_feature 2022-12-30 23:56:18 -05:00
David Tolnay
06ec0bf8b0
Revert "Implement allow-by-default multiple_supertrait_upcastable lint"
This reverts commit 5e44a65517.
2022-12-29 00:47:23 -08:00
Pietro Albini
f6762c2035 update stabilization version numbers 2022-12-28 09:18:42 -05:00
fee1-dead
8b3d0c4cf9
Rollup merge of #105484 - nbdd0121:upcast, r=compiler-errors
Implement allow-by-default `multiple_supertrait_upcastable` lint

The lint detects when an object-safe trait has multiple supertraits.

Enabled in libcore and liballoc as they are low-level enough that many embedded programs will use them.

r? `@nikomatsakis`
2022-12-28 15:51:41 +08:00
bors
bbb9cfbbc5 Auto merge of #102318 - Amanieu:default_alloc_error_handler, r=oli-obk
Stabilize default_alloc_error_handler

Tracking issue: #66741

This turns `feature(default_alloc_error_handler)` on by default, which causes the compiler to automatically generate a default OOM handler which panics if `#[alloc_error_handler]` is not provided.

The FCP completed over 2 years ago but the stabilization was blocked due to an issue with unwinding. This was fixed by #88098 so stabilization can be unblocked.

Closes #66741
2022-12-16 21:08:45 +00:00
Matthias Krüger
947fe7e341
Rollup merge of #105109 - rcvalle:rust-kcfi, r=bjorn3
Add LLVM KCFI support to the Rust compiler

This PR adds LLVM Kernel Control Flow Integrity (KCFI) support to the Rust compiler. It initially provides forward-edge control flow protection for operating systems kernels for Rust-compiled code only by aggregating function pointers in groups identified by their return and parameter types. (See llvm/llvm-project@cff5bef.)

Forward-edge control flow protection for C or C++ and Rust -compiled code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code share the same virtual address space) will be provided in later work as part of this project by identifying C char and integer type uses at the time types are encoded (see Type metadata in the design document in the tracking issue #89653).

LLVM KCFI can be enabled with -Zsanitizer=kcfi.

Thank you again, `@bjorn3,` `@eddyb,` `@nagisa,` and `@ojeda,` for all the help!
2022-12-10 09:24:43 +01:00
Gary Guo
5e44a65517 Implement allow-by-default multiple_supertrait_upcastable lint 2022-12-09 02:29:51 +00:00
Ramon de C Valle
65698ae9f3 Add LLVM KCFI support to the Rust compiler
This commit adds LLVM Kernel Control Flow Integrity (KCFI) support to
the Rust compiler. It initially provides forward-edge control flow
protection for operating systems kernels for Rust-compiled code only by
aggregating function pointers in groups identified by their return and
parameter types. (See llvm/llvm-project@cff5bef.)

Forward-edge control flow protection for C or C++ and Rust -compiled
code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code
share the same virtual address space) will be provided in later work as
part of this project by identifying C char and integer type uses at the
time types are encoded (see Type metadata in the design document in the
tracking issue #89653).

LLVM KCFI can be enabled with -Zsanitizer=kcfi.

Co-authored-by: bjorn3 <17426603+bjorn3@users.noreply.github.com>
2022-12-08 17:24:39 -08:00
Vadim Petrochenkov
5b0e80ecf3 Stabilize native library modifier verbatim 2022-11-27 22:36:32 +03:00
bors
7fe6f36224 Auto merge of #103491 - cjgillot:self-rpit, r=oli-obk
Support using `Self` or projections inside an RPIT/async fn

I reuse the same idea as https://github.com/rust-lang/rust/pull/103449 to use variances to encode whether a lifetime parameter is captured by impl-trait.

The current implementation of async and RPIT replace all lifetimes from the parent generics by `'static`.  This PR changes the scheme
```rust
impl<'a> Foo<'a> {
    fn foo<'b, T>() -> impl Into<Self> + 'b { ... }
}

opaque Foo::<'_a>::foo::<'_b, T>::opaque<'b>: Into<Foo<'_a>> + 'b;
impl<'a> Foo<'a> {
    // OLD
    fn foo<'b, T>() -> Foo::<'static>::foo::<'static, T>::opaque::<'b> { ... }
                             ^^^^^^^ the `Self` becomes `Foo<'static>`

    // NEW
    fn foo<'b, T>() -> Foo::<'a>::foo::<'b, T>::opaque::<'b> { ... }
                             ^^ the `Self` stays `Foo<'a>`
}
```

There is the same issue with projections. In the example, substitute `Self` by `<T as Trait<'b>>::Assoc` in the sugared version, and `Foo<'_a>` by `<T as Trait<'_b>>::Assoc` in the desugared one.

This allows to support `Self` in impl-trait, since we do not replace lifetimes by `'static` any more.  The same trick allows to use projections like `T::Assoc` where `Self` is allowed.  The feature is gated behind a `impl_trait_projections` feature gate.

The implementation relies on 2 tweaking rules for opaques in 2 places:
- we only relate substs that correspond to captured lifetimes during TypeRelation;
- we only list captured lifetimes in choice region computation.

For simplicity, I encoded the "capturedness" of lifetimes as a variance, `Bivariant` vs `Invariant` for unused vs captured lifetimes. The `variances_of` query used to ICE for opaques.

Impl-trait that do not reference `Self` or projections will have their variances as:
- `o` (invariant) for each parent type or const;
- `*` (bivariant) for each parent lifetime --> will not participate in borrowck;
- `o` (invariant) for each own lifetime.

Impl-trait that does reference `Self` and/or projections will have some parent lifetimes marked as `o` (as the example above), and participate in type relation and borrowck.  In the example above, `variances_of(opaque) = ['_a: o, '_b: *, T: o, 'b: o]`.

r? types
cc `@compiler-errors` , as you asked about the issue with `Self` and projections.
2022-11-21 12:17:03 +00:00
Deadbeef
bc51f8783c rename to string_deref_patterns 2022-11-18 06:16:20 +00:00
Deadbeef
0537d301c5 Add feature gate 2022-11-17 12:46:43 +00:00
Matthias Krüger
55ff8bf847
Rollup merge of #104339 - compiler-errors:rustc_deny_explicit_impl, r=cjgillot
Add `rustc_deny_explicit_impl`

Also adjust `E0322` error message to be more general, since it's used for `DiscriminantKind` and `Pointee` as well.

Also add `rustc_deny_explicit_impl` on the `Tuple` and `Destruct` marker traits.
2022-11-15 10:44:12 +01:00
Matthias Krüger
5763fa74f0
Rollup merge of #104349 - rustaceanclub:master, r=oli-obk
fix some typos in comments
2022-11-14 19:26:18 +01:00
Michael Goulet
b5b6467810 Add rustc_deny_explicit_impl 2022-11-14 03:23:41 +00:00
bors
338cfd3cce Auto merge of #103858 - Mark-Simulacrum:bump-bootstrap, r=pietroalbini
Bump bootstrap compiler to 1.66

This PR:

- Bumps version placeholders to release
- Bumps to latest beta
- cfg-steps code

r? `@pietroalbini`
2022-11-14 00:07:19 +00:00
cui fliter
442f848d74 fix some typos in comments
Signed-off-by: cui fliter <imcusg@gmail.com>
2022-11-13 15:26:17 +08:00
Guillaume Gomez
bef2da0629
Rollup merge of #104117 - crlf0710:update_feature_gate, r=jackh726
Mark `trait_upcasting` feature no longer incomplete.

This marks the `trait_upcasting` feature no longer incomplete since #101336 has been settled for a little while.

r? ``````@jackh726``````
2022-11-12 17:25:01 +01:00
Camille GILLOT
af06960b2a Add tracking issue number. 2022-11-12 10:02:26 +00:00
Camille GILLOT
b77674d254 Make impl_trait_projections a feature gate. 2022-11-12 10:01:07 +00:00
Charles Lew
3074678cd1 Mark trait_upcasting feature no longer incomplete. 2022-11-11 00:35:08 +08:00
Jakob Degen
ba359d8a51 Add support for custom MIR parsing 2022-11-08 23:13:15 -08:00
Mark Rousskov
455a7bc685 Bump version placeholders to release 2022-11-06 17:11:02 -05:00
bors
1286ee23e4 Auto merge of #102458 - JohnTitor:stabilize-instruction-set, r=oli-obk
Stabilize the `instruction_set` feature

Closes https://github.com/rust-lang/rust/issues/74727
FCP is complete on https://github.com/rust-lang/rust/issues/74727#issuecomment-1242773253
r? `@pnkfelix` and/or `@nikomatsakis`
cc `@xd009642`

Signed-off-by: Yuki Okushi <jtitor@2k36.org>
2022-11-05 20:39:06 +00:00
Amanieu d'Antras
f5e0b760d0 Stabilize default_alloc_error_handler
Closes #66741
2022-11-03 07:12:58 +00:00
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