feat: add parsing support for algebraic effect declarations

[qxlsz]

No description provided.

[rustbot]

Some changes occurred in compiler/rustc_passes/src/check_attr.rs

cc @jdonszelmann

[rustbot]

r? @jackh726

rustbot has assigned @jackh726.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rust-log-analyzer]

The job aarch64-gnu-llvm-20-1 failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

   Compiling cc v1.2.0
error: expected identifier, found keyword `with`
    --> library/core/src/ptr/non_null.rs:1231:36
     |
1231 |     pub const unsafe fn swap(self, with: NonNull<T>)
     |                                    ^^^^ expected identifier, found keyword
     |
help: escape `with` to use it as an identifier
     |
1231 |     pub const unsafe fn swap(self, r#with: NonNull<T>)
     |                                    ++

error: expected expression, found keyword `with`
    --> library/core/src/ptr/non_null.rs:1236:43
     |
1236 |         unsafe { ptr::swap(self.as_ptr(), with.as_ptr()) }
     |                                           ^^^^ expected expression

error: expected identifier, found keyword `with`
    --> library/core/src/ptr/mut_ptr.rs:1504:36
     |
1504 |     pub const unsafe fn swap(self, with: *mut T)
     |                                    ^^^^ expected identifier, found keyword
     |
help: escape `with` to use it as an identifier
     |
1504 |     pub const unsafe fn swap(self, r#with: *mut T)
     |                                    ++

error: expected expression, found keyword `with`
    --> library/core/src/ptr/mut_ptr.rs:1509:29
     |
1509 |         unsafe { swap(self, with) }
     |                             ^^^^ expected expression

[RUSTC-TIMING] build_script_build test:false 0.138
   Compiling std v0.0.0 (/checkout/library/std)
[RUSTC-TIMING] build_script_build test:false 0.230

[fmease]

I am not aware of any official motions to add algebraic effects to the language, not even experimentally.

View changes since this review

[jdonszelmann]

No same, was taking a quick look because of the ping I got but this is not something we should merge. Though I welcome you to experiment with this in a fork for example, I think we should close this

[fmease]

@qxlsz Not to discourage you from future contributions to rustc but adding new features to the language and the compiler, especially large and non-trivial ones like algebraic effects, isn't as simple as opening a PR to this repo.

For comparison, even medium-sized features need at least an approved lang experiment (see). However, for large ones like this one, at the very least you should definitely seek contact with Rust project members first (e.g., on Zulip in the #t-lang or in the #t-lang/effects channel) to get a rough vibe check and since this needs a bunch of design questions answered first (parsing is the least of our worries). I would say it doesn't need an RFC upfront but at least a somewhat thought out design document or pre-RFC would be highly beneficial and customary if you really want to pursue this.

All that said, I want to warn you that it's probably not going to be easy to convince enough relevant people to make this an immediate project goal but that's just my personal hunch. Last time this was proposed was in rust-lang/rfcs#73 and even 10 years later, rust-lang/rfcs#73 (comment) is still relevant in a way.

Okay, to be totally honest, T-lang did have a bunch of meetings pertaining to effects in the last year as part of the "effects initiative". However, I don't remember the current stance being anywhere close to "let's introduce algebraic effects". We're trying to make const trait impls happen as soon as possible, that's our priority in that area.

For the general feature of algebraic effects, you'd need to be able to explain how they're supposed to be represented in Rust's type system and what their runtime semantics should be (cc zero-overhead abstractions, etc.).

[fmease]

Since this won't be actionable anytime soon, I'll close this PR now. Thanks for your understanding!

[qxlsz]

Agreed.