-
Notifications
You must be signed in to change notification settings - Fork 12.6k
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
Decorators normative changes #52582
Decorators normative changes #52582
Conversation
Do we have a test that verifies that you can't have decorators both before and after |
// @filename: file5.ts | ||
|
||
// ok | ||
export default @dec class C5 {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about @dec export default @dec
and @dec export @dec
?
Does this PR fix #52578?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this PR fix #52578?
Yes, I'll add it.
Also, do we have tests which test emit for a potential es2023 which includes this syntax? I know you had mentioned that we need extra logic to make sure we emit it into the right place, but I couldn't find a test which shows that we do that. |
I thought I had, but I will add one. We do report an error currently, but the error is |
For
|
Doh, I didn't find it because it was a test that only tested |
@DanielRosenwasser, your feedback on the diagnostic messages would be appreciated as well. |
I'm also working on tightening up the types for |
Let's also add a test for the
|
e9817ff
to
9ba73ed
Compare
Done. |
export default @dec abstract class C12 {} | ||
|
||
==== tests/cases/conformance/esDecorators/classDeclaration/file13.ts (2 errors) ==== | ||
// error |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
aside - I don't like the // ok
vs. // error
comments because it is possible for them to change over time. I would prefer the baselines be the source of truth.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm torn, because on one hand, the baselines are the source of truth, but on the other, if I didn't write the baselines, I don't have any indication as to what the original intended behavior was...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They were, at the very least, useful to verify that I was getting errors where I expected them when running the tests initially. I can remove the comments, or make them more detailed to explain why an error is expected at these locations.
We may want to wait until pzuraq/ecma262#4 has merged into the official ecma262 PR for decorators before we merge this. |
pzuraq/ecma262#4 has merged. I will merge this shortly. |
These changes reflect the consensus on normative changes for
context.access
in decorators, and allowing decorators before OR afterexport
.Fixes #52540
Fixes #52578