-
Notifications
You must be signed in to change notification settings - Fork 37
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
Disallow attributes on "type aliases" in parser #1898
Comments
Just as a minor point: This would result in an error in parsing that's just "unexpected token" which seems unintuitive when it really looks like these attributes apply to types. There would have to be a little extra handling to give a nice error message, which is exactly what the validator does. I kind of prefer that, but it's not impossible to get a nice error there in parsing. From what I can tell, units have the attributes apply to the type (hence that workaround), but enums have it apply to the decl, so there is another edge case I think? |
I chatted with @rsmmr about this yesterday and he framed this in a way which made this click for me. Paraphrasing:
#1890 was about disallowing attributes on bindings which are only allowed on declarations (roughly: RHS things with More practically, since |
I know this is possibly a pretty big change, but it's still unintuitive for users that these attributes apply to the
Then you get the idea that This is confounded because putting an attribute in a field looks extremely close to applying to the type:
I got that from the documentation, which does say this applies to the field, not the type:
So it's not like it's unclear, but I can't help but feel a kind of dissonance between what the syntax looks like and what actually happens, which comes up as multiple real examples of user confusion. The other attempts to solve this seem like they just kick the can down the road. Even the fix in #1890, which adds a decent error, would be confusing to a new user:
ok... but attributes are still allowed on types? Well, it kind of looks like it, but only kind of. That would be pretty hard to convey without an outrageously long error or some helpful diagnostic notes. All that to say, I fully agree that attributes should apply to So what if we make it more explicit?:
now it makes a lot more sense to me. Obviously, Sorry, this is teetering on off topic for this issue, but this has caused me a lot of confusion and I've already seen multiple instances of this confusing other users, so I thought I'd throw in an extension. This may be better discussed another place, though. I didn't mean to write a wall :) |
With #1890 we added a validator to reject any attributes on "type alias". To detect such type aliases we used a pretty nasty hack,
spicy/spicy/toolchain/src/compiler/validator.cc
Lines 360 to 363 in 500f285
We should clean this up by instead disallowing attributes on any declaration which is not a enum or unit (not sure there are more entities on the RHS where even with #1890 we support attributes). A way to do that would be to push the parsing of attributes from
type_decl
into e.g.,unit_type
; in fact the parser already has special handling for units,spicy/spicy/toolchain/src/compiler/parser/parser.yy
Lines 381 to 385 in 500f285
With that the added validator would become redundant.
The text was updated successfully, but these errors were encountered: