Repository navigation
Emit issue with member access dot operator and parentheses usually in conjunction with type assertion #15444
Description
Code
a.foo()
(b).foo()
Expected emit:
a.foo();
(b).foo();
Actual emit:
a.foo()(b).foo();
This becomes an issue when using type assertions inline:
Code
a.foo()
(b as Bar).foo()
Expected emit:
a.foo();
b.foo();
Actual emit:
a.foo()(b).foo();
Angle brackets type assertion have a similar issue:
Code
a.foo()
<Bar>b.foo()
Actual emit:
a.foo()
< Bar > b.foo();
Activity
mhegazy commentedon Apr 28, 2017
Unfortunately these are the JavaScript Automatic SemiColon Insertion rules.
TypeScript is a super-set of JavaScript, and the samples above are valid JS code samples, and they have valid semantics. the emitted code has to match these semantics.
gdelmas commentedon Apr 28, 2017
thanks for your reply Mohamed Hegazy (@mhegazy). i thought that it is a tricky case, as sometimes a multiline expression might be intended.
i might create a tslint warning to detect it in conjunction with assertions. or might this be a case where
tsccan warn itself?RyanCavanaugh commentedon Apr 28, 2017
I believe there's already a TSLint rule for missing semicolons
gdelmas commentedon Apr 28, 2017
do you mean this
tslintcore rule:the rule does not warn if a semicolon in conjunction with a type assertion might be required. it also fails in some other cases, and warns. for example:
RyanCavanaugh commentedon Apr 28, 2017
Sorry, I totally misread that. Disregard.
Mohamed Hegazy (@mhegazy) perhaps we should disallow
booleanas an operand to>/<, even if the other operand isany?ajafff commentedon Apr 28, 2017
Gerard Delmàs (@gdelmas) you can use the
no-unexpected-multilineprovided bytslint-eslint-rulesmhegazy commentedon May 1, 2017
👍
mhegazy commentedon May 1, 2017
Filed #15506 to track it.
mhegazy commentedon May 19, 2017
Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.
semicolon: split walker implementation, make "never" spec compliant (#…