Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support modifiers on namespace, in theory. #3462

Merged
merged 1 commit into from
Dec 6, 2023

Conversation

jonmeow
Copy link
Contributor

@jonmeow jonmeow commented Dec 6, 2023

In theory because none are allowed. This is to improve consistency in handle_decl_name_scope's modifier handling, removing the namespace special-case.

I noticed there's a crash bug on impl <declaration> which I'll address separately.

This builds on #3461.

@jonmeow jonmeow force-pushed the namespace-mods branch 2 times, most recently from 6ae2963 to dae2600 Compare December 6, 2023 22:00
@jonmeow jonmeow added this pull request to the merge queue Dec 6, 2023
Merged via the queue into carbon-language:trunk with commit 9b194a3 Dec 6, 2023
6 checks passed
@jonmeow jonmeow deleted the namespace-mods branch December 6, 2023 23:12
github-merge-queue bot pushed a commit that referenced this pull request Dec 8, 2023
Building on #3462, trying to make the flow easier to see, also making a
little more use of macros for boilerplate modifier handling.

---------

Co-authored-by: josh11b <[email protected]>
Co-authored-by: Richard Smith <[email protected]>
github-merge-queue bot pushed a commit that referenced this pull request Dec 13, 2023
Note #3486 rewrites the macro behavior, and is already approved: so this
PR is only for the changed enforcement during error. Also, #3493 already
changed several things to allow any token while this PR was awaiting
review, but this still changes enforcement for `For` and `If`.

This was brought up on
[#toolchain](https://discord.com/channels/655572317891461132/655578254970716160/1182066616456970251),
and I think this any-on-error approach gets at least some support. We
could try setting it to the introducer, but it's quite possible we want
it to be something like the token which led to the parse error, rather
than a static token. That leads to a conclusion that, most typically,
we'll expect arbitrary tokens when error conditions may lead to tokens
which aren't the expected token.

A couple related, recent `CARBON_IF_ERROR` crash fixes can be found in
#3404 and #3424. Something like #3404 would've been needed regardless
because `namespace` didn't have `CARBON_IF_ERROR` before, although I
might've missed the underlying issue with declarations because only
`namespace` had a relevant test (that is, if #3404 had added
`CARBON_ANY_TOKEN_ON_ERROR`, I wouldn't have had a crash in #3462).
#3424 would've been avoided with this change because there was a
`CARBON_IF_ERROR`, and it was just too restrictive.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants