Commit Graph

338 Commits

Author SHA1 Message Date
Lieselotte
c440a5b814
Add ErrorGuaranteed to ast::ExprKind::Err 2024-02-25 22:24:31 +01:00
Lieselotte
a3fce72a27
Add ast::ExprKind::Dummy 2024-02-25 22:22:09 +01:00
Guillaume Gomez
c73aa787f6
Rollup merge of #121109 - nnethercote:TyKind-Err-guar-2, r=oli-obk
Add an ErrorGuaranteed to ast::TyKind::Err (attempt 2)

This makes it more like `hir::TyKind::Err`, and avoids a `has_errors` assertion in `LoweringContext::lower_ty_direct`.

r? ```@oli-obk```
2024-02-16 00:27:32 +01:00
Nicholas Nethercote
25ed6e43b0 Add ErrorGuaranteed to ast::LitKind::Err, token::LitKind::Err.
This mostly works well, and eliminates a couple of delayed bugs.

One annoying thing is that we should really also add an
`ErrorGuaranteed` to `proc_macro::bridge::LitKind::Err`. But that's
difficult because `proc_macro` doesn't have access to `ErrorGuaranteed`,
so we have to fake it.
2024-02-15 14:46:08 +11:00
Nicholas Nethercote
5233bc91da Add an ErrorGuaranteed to ast::TyKind::Err.
This makes it more like `hir::TyKind::Err`, and avoids a
`span_delayed_bug` call in `LoweringContext::lower_ty_direct`.

It also requires adding `ast::TyKind::Dummy`, now that
`ast::TyKind::Err` can't be used for that purpose in the absence of an
error emission.

There are a couple of cases that aren't as neat as I would have liked,
marked with `FIXME` comments.
2024-02-15 09:35:11 +11:00
Frank King
2b04ca94bb Add #[derive(Clone, Copy)] to anonymous adts
Fix the `AssertBoundIsClone` error for anonymous adts.
2024-02-12 12:47:32 +08:00
Frank King
879a1e5713 Lower anonymous structs or unions to HIR 2024-02-12 12:47:23 +08:00
Michael Goulet
0eb2adb7e8 Add async bound modifier to enable async Fn bounds 2024-01-31 16:59:19 +00:00
Josh Stone
33e0422826 Pack the u128 in LitKind::Int 2024-01-19 20:10:39 -08:00
Matthew Maurer
dbff90c2a7 LLVM 18 x86 data layout update
With https://reviews.llvm.org/D86310 LLVM now has i128 aligned to
16-bytes on x86 based platforms. This will be in LLVM-18. This patch
updates all our spec targets to be 16-byte aligned, and removes the
alignment when speaking to older LLVM.

This results in Rust overaligning things relative to LLVM on older LLVMs.

This alignment change was discussed in rust-lang/compiler-team#683

See #54341 for additional information about why this is happening and
where this will be useful in the future.

This *does not* stabilize `i128`/`u128` for FFI.
2024-01-19 10:52:01 +01:00
Lieselotte
7889e99b55
Add PatKind::Err 2024-01-17 03:14:16 +01:00
Bryanskiy
d69cd6473c Delegation implementation: step 1 2024-01-12 14:11:16 +03:00
bjorn3
47936b4813 Avoid specialization for AttrId deserialization 2023-12-31 20:48:15 +00:00
Nilstrieb
ffafcd8819 Update to bitflags 2 in the compiler
This involves lots of breaking changes. There are two big changes that
force changes. The first is that the bitflag types now don't
automatically implement normal derive traits, so we need to derive them
manually.

Additionally, bitflags now have a hidden inner type by default, which
breaks our custom derives. The bitflags docs recommend using the impl
form in these cases, which I did.
2023-12-30 18:17:28 +01:00
León Orell Valerian Liehr
3eb48a35c8
Introduce const Trait (always-const trait bounds) 2023-12-27 12:51:32 +01:00
Matthias Krüger
bdc4480914
Rollup merge of #119231 - aDotInTheVoid:PatKind-struct-bool-docs, r=compiler-errors
Clairify `ast::PatKind::Struct` presese of `..` by using an enum instead of a bool

The bool is mainly used for when a `..` is present, but it is also set on recovery to avoid errors. The doc comment not describes both of these cases.

See cee794ee98/compiler/rustc_parse/src/parser/pat.rs (L890-L897) for the only place this is constructed.

r? ``@compiler-errors``
2023-12-23 16:23:54 +01:00
Alona Enraght-Moony
1349d86c72 bool->enum for ast::PatKind::Struct presence of ..
See cee794ee98/compiler/rustc_parse/src/parser/pat.rs (L890-L897) for the only place this is constructed.
2023-12-23 02:50:31 +00:00
bors
208dd2032b Auto merge of #118847 - eholk:for-await, r=compiler-errors
Add support for `for await` loops

This adds support for `for await` loops. This includes parsing, desugaring in AST->HIR lowering, and adding some support functions to the library.

Given a loop like:
```rust
for await i in iter {
    ...
}
```
this is desugared to something like:
```rust
let mut iter = iter.into_async_iter();
while let Some(i) = loop {
    match core::pin::Pin::new(&mut iter).poll_next(cx) {
        Poll::Ready(i) => break i,
        Poll::Pending => yield,
    }
} {
    ...
}
```

This PR also adds a basic `IntoAsyncIterator` trait. This is partly for symmetry with the way `Iterator` and `IntoIterator` work. The other reason is that for async iterators it's helpful to have a place apart from the data structure being iterated over to store state. `IntoAsyncIterator` gives us a good place to do this.

I've gated this feature behind `async_for_loop` and opened #118898 as the feature tracking issue.

r? `@compiler-errors`
2023-12-22 14:17:10 +00:00
bors
aaef5fe497 Auto merge of #119163 - fmease:refactor-ast-trait-bound-modifiers, r=compiler-errors
Refactor AST trait bound modifiers

Instead of having two types to represent trait bound modifiers in the parser / the AST (`parser::ty::BoundModifiers` & `ast::TraitBoundModifier`), only to map one to the other later, just use `parser::ty::BoundModifiers` (moved & renamed to `ast::TraitBoundModifiers`).

The struct type is more extensible and easier to deal with (see [here](https://github.com/rust-lang/rust/pull/119099/files#r1430749981) and [here](https://github.com/rust-lang/rust/pull/119099/files#r1430752116) for context) since it more closely models what it represents: A compound of two kinds of modifiers, constness and polarity. Modeling this as an enum (the now removed `ast::TraitBoundModifier`) meant one had to add a new variant per *combination* of modifier kind, which simply isn't scalable and which lead to a lot of explicit non-DRY matches.

NB: `hir::TraitBoundModifier` being an enum is fine since HIR doesn't need to worry representing invalid modifier kind combinations as those get rejected during AST validation thereby immensely cutting down the number of possibilities.
2023-12-22 02:00:55 +00:00
León Orell Valerian Liehr
5e4f12b41a
Refactor AST trait bound modifiers 2023-12-20 19:39:46 +01:00
Alona Enraght-Moony
11337805fb Give VariantData::Struct named fields, to clairfy recovered. 2023-12-20 00:07:34 +00:00
Eric Holk
27d6539a46
Plumb awaitness of for loops 2023-12-19 12:26:20 -08:00
Michael Goulet
bc1ca6b528 Fix enforcement of generics for associated items 2023-12-15 16:17:28 +00:00
Nadrieril
19e0c984d3 Don't gate the feature twice 2023-12-12 14:52:05 +01:00
Michael Goulet
8361a7288e Introduce closure_id method on CoroutineKind 2023-12-08 21:46:39 +00:00
bors
f967532a47 Auto merge of #118420 - compiler-errors:async-gen, r=eholk
Introduce support for `async gen` blocks

I'm delighted to demonstrate that `async gen` block are not very difficult to support. They're simply coroutines that yield `Poll<Option<T>>` and return `()`.

**This PR is WIP and in draft mode for now** -- I'm mostly putting it up to show folks that it's possible. This PR needs a lang-team experiment associated with it or possible an RFC, since I don't think it falls under the jurisdiction of the `gen` RFC that was recently authored by oli (https://github.com/rust-lang/rfcs/pull/3513, https://github.com/rust-lang/rust/issues/117078).

### Technical note on the pre-generator-transform yield type:

The reason that the underlying coroutines yield `Poll<Option<T>>` and not `Poll<T>` (which would make more sense, IMO, for the pre-transformed coroutine), is because the `TransformVisitor` that is used to turn coroutines into built-in state machine functions would have to destructure and reconstruct the latter into the former, which requires at least inserting a new basic block (for a `switchInt` terminator, to match on the `Poll` discriminant).

This does mean that the desugaring (at the `rustc_ast_lowering` level) of `async gen` blocks is a bit more involved. However, since we already need to intercept both `.await` and `yield` operators, I don't consider it much of a technical burden.

r? `@ghost`
2023-12-08 19:13:57 +00:00
Michael Goulet
a208bae00e Support async gen fn 2023-12-08 17:23:26 +00:00
Michael Goulet
2806c2df7b coro_kind -> coroutine_kind 2023-12-08 17:23:25 +00:00
Michael Goulet
96bb542a31 Implement async gen blocks 2023-12-08 17:23:25 +00:00
bors
2b399b5275 Auto merge of #118527 - Nadrieril:never_patterns_parse, r=compiler-errors
never_patterns: Parse match arms with no body

Never patterns are meant to signal unreachable cases, and thus don't take bodies:
```rust
let ptr: *const Option<!> = ...;
match *ptr {
    None => { foo(); }
    Some(!),
}
```
This PR makes rustc accept the above, and enforces that an arm has a body xor is a never pattern. This affects parsing of match arms even with the feature off, so this is delicate. (Plus this is my first non-trivial change to the parser).

~~The last commit is optional; it introduces a bit of churn to allow the new suggestions to be machine-applicable. There may be a better solution? I'm not sure.~~ EDIT: I removed that commit

r? `@compiler-errors`
2023-12-08 17:08:52 +00:00
Eric Holk
f9d1f922dc
Option<CoroutineKind> 2023-12-04 13:03:37 -08:00
Eric Holk
48d5f1f0f2
Merge Async and Gen into CoroutineKind 2023-12-04 12:48:01 -08:00
Eric Holk
bc0d10d4b0
Add genness to FnHeader 2023-12-04 11:22:49 -08:00
Nadrieril
a2dcb3a6d9 Disallow an arm without a body (except for never patterns)
Parsing now accepts a match arm without a body, so we must make sure to
only accept that if the pattern is a never pattern.
2023-12-03 12:25:46 +01:00
Nadrieril
80bdcbf50a Parse a pattern with no arm 2023-12-03 12:25:46 +01:00
bors
4e3dc976e7 Auto merge of #117912 - GeorgeWort:master, r=petrochenkov
Name explicit registers in conflict register errors for inline assembly
2023-12-02 13:38:47 +00:00
Matthias Krüger
c03f8917ee
Rollup merge of #118157 - Nadrieril:never_pat-feature-gate, r=compiler-errors
Add `never_patterns` feature gate

This PR adds the feature gate and most basic parsing for the experimental `never_patterns` feature. See the tracking issue (https://github.com/rust-lang/rust/issues/118155) for details on the experiment.

`@scottmcm` has agreed to be my lang-team liaison for this experiment.
2023-11-29 12:34:47 +01:00
Nadrieril
a3838c8550 Add never_patterns feature gate 2023-11-29 03:58:29 +01:00
George Wort
e0bfb615da Name explicit registers in conflict register errors for inline assembly 2023-11-28 10:37:19 +00:00
Nicholas Nethercote
d9fef774e3 Remove hir::BinOp, hir::BinOpKind, and hir::UnOp.
They're identical to the same-named types from `ast`. I find it silly
(and inefficient) to have all this boilerplate code to convert one type
to an identical type.

There is already a small amount of type sharing between the AST and HIR,
e.g. `Attribute`, `MacroDef`.

The commit adds a `pub use` to `rustc_hir` so that, for example,
`ast::BinOp` can also be referred to as `hir::BinOp`. This is so the
many existing `hir`-qualified mentions of these types don't need to
change.

The commit also moves a couple of operations from the (removed) HIR
types to the AST types, e.g. `is_by_value`.
2023-11-28 12:14:25 +11:00
Nicholas Nethercote
705b484922 Rename BinOpKind::lazy as BinOpKind::is_lazy.
To match `BinOpKind::is_comparison` and `hir::BinOpKind::is_lazy`.
2023-11-28 09:45:40 +11:00
Nicholas Nethercote
0efd2a9d8f Rework ast::BinOpKind::to_string and ast::UnOp::to_string.
- Rename them both `as_str`, which is the typical name for a function
  that returns a `&str`. (`to_string` is appropriate for functions
  returning `String` or maybe `Cow<'a, str>`.)
- Change `UnOp::as_str` from an associated function (weird!) to a
  method.
- Avoid needless `self` dereferences.
2023-11-28 09:42:07 +11:00
Deadbeef
16040a1628 Add Span to TraitBoundModifier 2023-11-24 14:32:05 +00:00
Nicholas Nethercote
7060fc8327 Replace no_ord_impl with orderable.
Similar to the previous commit, this replaces `newtype_index`'s opt-out
`no_ord_impl` attribute with the opt-in `orderable` attribute.
2023-11-22 18:38:17 +11:00
Nicholas Nethercote
3ef9d4d0ed Replace custom_encodable with encodable.
By default, `newtype_index!` types get a default `Encodable`/`Decodable`
impl. You can opt out of this with `custom_encodable`. Opting out is the
opposite to how Rust normally works with autogenerated (derived) impls.

This commit inverts the behaviour, replacing `custom_encodable` with
`encodable` which opts into the default `Encodable`/`Decodable` impl.
Only 23 of the 59 `newtype_index!` occurrences need `encodable`.

Even better, there were eight crates with a dependency on
`rustc_serialize` just from unused default `Encodable`/`Decodable`
impls. This commit removes that dependency from those eight crates.
2023-11-22 18:37:14 +11:00
Dinu Blanovschi
8de489918b feat(hir): Store the Span of the move keyword 2023-11-04 19:39:32 +01:00
bors
2cad938a81 Auto merge of #116447 - oli-obk:gen_fn, r=compiler-errors
Implement `gen` blocks in the 2024 edition

Coroutines tracking issue https://github.com/rust-lang/rust/issues/43122
`gen` block tracking issue https://github.com/rust-lang/rust/issues/117078

This PR implements `gen` blocks that implement `Iterator`. Most of the logic with `async` blocks is shared, and thus I renamed various types that were referring to `async` specifically.

An example usage of `gen` blocks is

```rust
fn foo() -> impl Iterator<Item = i32> {
    gen {
        yield 42;
        for i in 5..18 {
            if i.is_even() { continue }
            yield i * 2;
        }
    }
}
```

The limitations (to be resolved) of the implementation are listed in the tracking issue
2023-10-29 00:03:52 +00:00
Oli Scherer
621494382d Add gen blocks to ast and do some broken ast lowering 2023-10-27 13:05:48 +00:00
Oli Scherer
a61cf673cd Reserve gen keyword for gen {} blocks and gen fn in 2024 edition 2023-10-26 06:49:17 +00:00
Nicholas Nethercote
2e2e7806ab Augment stringify.rs test.
By adding tests (or placeholders, or comments) for missing AST variants.
2023-10-24 16:00:45 +11:00