-
Notifications
You must be signed in to change notification settings - Fork 12.9k
Class emit for ES6 #2333
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
Class emit for ES6 #2333
Changes from 22 commits
033a83d
d3205ef
8576282
1b84f1d
890aa4a
da12d46
a0a506b
7ee587c
5683960
0672923
800c523
af05afd
13e55ae
2a07d3f
9bf5a11
c70385c
3bb4b50
0eeb7ce
2c7ea7f
e573461
88933d5
91c5bae
c51983d
513b45d
9b3fccd
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -157,6 +157,7 @@ module ts { | |
Catch_clause_variable_cannot_have_an_initializer: { code: 1197, category: DiagnosticCategory.Error, key: "Catch clause variable cannot have an initializer." }, | ||
An_extended_Unicode_escape_value_must_be_between_0x0_and_0x10FFFF_inclusive: { code: 1198, category: DiagnosticCategory.Error, key: "An extended Unicode escape value must be between 0x0 and 0x10FFFF inclusive." }, | ||
Unterminated_Unicode_escape_sequence: { code: 1199, category: DiagnosticCategory.Error, key: "Unterminated Unicode escape sequence." }, | ||
A_computed_property_name_cannot_reference_a_static_property: { code: 1200, category: DiagnosticCategory.Error, key: "A computed property name cannot reference a static property" }, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. you do not need this any more. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yep. It will be removed in the upcoming commit There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. also the tests. |
||
Duplicate_identifier_0: { code: 2300, category: DiagnosticCategory.Error, key: "Duplicate identifier '{0}'." }, | ||
Initializer_of_instance_member_variable_0_cannot_reference_identifier_1_declared_in_the_constructor: { code: 2301, category: DiagnosticCategory.Error, key: "Initializer of instance member variable '{0}' cannot reference identifier '{1}' declared in the constructor." }, | ||
Static_members_cannot_reference_class_type_parameters: { code: 2302, category: DiagnosticCategory.Error, key: "Static members cannot reference class type parameters." }, | ||
|
Large diffs are not rendered by default.
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -4517,6 +4517,12 @@ module ts { | |
} | ||
|
||
function parseClassDeclaration(fullStart: number, modifiers: ModifiersArray): ClassDeclaration { | ||
// In ES6 specification, All parts of a ClassDeclaration or a ClassExpression are strict mode code | ||
let savedStrictModeContext = inStrictModeContext(); | ||
if (languageVersion >= ScriptTarget.ES6) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would always enter strict mode once we're in a class. If that's ES semantics, then that's what we should follow. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That will be a breaking change. I have tried running on that mode on RWC and our compiler. Both do have non-strict-mode code in classDeclaration. So, I want to push this version in first. Then, decide if we want to extend this to all classDeclaration later. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I am surprised that stuff broke. Do you recall what the particular strict mode errors were? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Also, can we bring this to the design meeting. Technically those classes are broken, and won't work in the future. Do we want to continue 'pretending' they're ok, or should we be up frong about breaking them. Can you also possibly email us the examples of where this breaks? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, using |
||
setStrictModeContext(true); | ||
} | ||
|
||
var node = <ClassDeclaration>createNode(SyntaxKind.ClassDeclaration, fullStart); | ||
setModifiers(node, modifiers); | ||
parseExpected(SyntaxKind.ClassKeyword); | ||
|
@@ -4537,7 +4543,10 @@ module ts { | |
else { | ||
node.members = createMissingList<ClassElement>(); | ||
} | ||
return finishNode(node); | ||
|
||
var finishedNode = finishNode(node); | ||
setStrictModeContext(savedStrictModeContext); | ||
return finishedNode; | ||
} | ||
|
||
function parseHeritageClauses(isClassHeritageClause: boolean): NodeArray<HeritageClause> { | ||
|
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.
Why?
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.
Thanks for catching this!. This is from my previous implementation in which I report a parsing error for using reserve keyword so I still want to report an error in this case. @CyrusNajmabadi corrects me about reserve word. So this change is no longer necessary