-
Notifications
You must be signed in to change notification settings - Fork 12.5k
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
Fix 'as const'-like behavior in JSDoc type cast #45464
Conversation
@@ -25858,7 +25858,9 @@ namespace ts { | |||
case SyntaxKind.ParenthesizedExpression: { | |||
// Like in `checkParenthesizedExpression`, an `/** @type {xyz} */` comment before a parenthesized expression acts as a type cast. | |||
const tag = isInJSFile(parent) ? getJSDocTypeTag(parent) : undefined; | |||
return tag ? getTypeFromTypeNode(tag.typeExpression.type) : getContextualType(parent as ParenthesizedExpression, contextFlags); | |||
return !tag ? getContextualType(parent as ParenthesizedExpression, contextFlags) : |
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 inverted the order here so that we have one condition per branch (i.e., !a ? x : b ? y : z
) instead of nested conditions (i.e., a ? b ? y : x : z
).
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.
Conceptually this looks OK, except for the odd baseline changes. But I could swear we discussed weather we should support const
casts in JS back when we first added const
casts, and the original answer was "no" (meaning the fix would have been properly parsing const
as a type reference/erroring on the keyword if we wanted to stick with that).
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.
Couple of things in the tests need to be changed, plus I didn't understand one branch of filterOwnedJSDocTags
7b70f43
to
db3ef67
Compare
db3ef67
to
6504a34
Compare
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.
Love it, thanks - I'll get this added to the JSDoc reference when it's in 👍🏻
@typescript-bot pack this |
Hey @orta, I've packed this into an installable tgz. You can install it for testing by referencing it in your
and then running There is also a playground for this build and an npm module you can use via |
As this is definitely going to get asked in the future, is it possible for both of these to work? e.g. sans-parens const isConst = /** @type {const} */ ({
hello: "world, not string"
})
isConst
// ^? - { readonly hello: "world, not string" }
const isString = /** @type {const} */ {
hello: "world, not string"
}
isString
// ^? - { hello: string } |
Probably yes -- but it's an expansion of the Clojure cast syntax that no other tool would recognise, so we should really consider the entire design space if we decide to make casts easier to write. |
The parens are also useful for performance reasons, otherwise we'd have to check every leading JSDoc comment of every expression in a JS file. What I'd like is a shorter cast syntax (even with the parens). Something like I'd also like a way to emulate postfix- Something like one of these: /** @type {!} */(foo.bar).baz; // just the `!` prefix
/** @notnull */(foo.bar).baz; // a keyword-like tag
/** @! */(foo.bar).baz; // or some type of shorthand
/** {!} */(foo.bar).baz; I'll have to see if there's an open issue for this and, if not, create one. |
@typescript-bot test this Checking rwc and community tests, though I don't think this should affect anything currently. |
The user suite test run you requested has finished and failed. I've opened a PR with the baseline diff from master. |
user test baselines are fine (changes are minor and unrelated) |
rwc baselines look fine. |
Any idea on when this will be available in TypeScript? It's very useful and hopefully could be released soon. |
TypeScript has a set release schedule, the next release details are here: #45418 |
Ah, I was hoping this could be released as part of a 4.4 bugfix release. |
What's the reasoning for not leveraging JSDoc's (currently unused) |
TS treats Closure cast syntax as the JSDoc cast syntax, so it's feature parity with TS If
|
can't see it in the plans for 4.5 |
@gaurav5430 Fixes don't show up in the iteration plan as far as I know. |
Not working in v4.7.4, how can i get this feature. |
Confirming that it is working in 4.7.4 I'd recommend filing a full bug report if you have a case where it is not working as expected |
I'm very sorry, It's my fault.
8 month ago I learned this feature and try a lot times not work (now I find out the reason is my ts verstion is 4.4.4 that time). And recently I tried agin, but it was in a ts enviroment, and I find this pr.
Thanks very mutch, My type programing experience in js project is perfectly satisfied.
At 2022-07-02 21:09:48, "Orta Therox" ***@***.***> wrote:
Confirming that it is working in 4.7.4
I'd recommend filing a full bug report if you have a case where it is not working as expected
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: ***@***.***>
|
I18n.pluralRulesMap keys are variable so “string” wasn’t compatible when the compiler thought we were using fixed string literals Might be worth another look at `Object.keys()` in future with: * microsoft/TypeScript#45464
I18n.pluralRulesMap keys are variable so “string” wasn’t compatible when the compiler thought we were using fixed string literals Might be worth another look at `Object.keys()` in future with: * microsoft/TypeScript#45464
I18n.pluralRulesMap keys are variable so “string” wasn’t compatible when the compiler thought we were using fixed string literals Might be worth another look at `Object.keys()` in future with: * microsoft/TypeScript#45464
I18n.pluralRulesMap keys are variable so “string” wasn’t compatible when the compiler thought we were using fixed string literals Might be worth another look at `Object.keys()` in future with: * microsoft/TypeScript#45464
I18n.pluralRulesMap keys are variable so “string” wasn’t compatible when the compiler thought we were using fixed string literals Might be worth another look at `Object.keys()` in future with: * microsoft/TypeScript#45464
I18n.pluralRulesMap keys are variable so “string” wasn’t compatible when the compiler thought we were using fixed string literals Might be worth another look at `Object.keys()` in future with: * microsoft/TypeScript#45464
I18n.pluralRulesMap keys are variable so “string” wasn’t compatible when the compiler thought we were using fixed string literals Might be worth another look at `Object.keys()` in future with: * microsoft/TypeScript#45464
I18n.pluralRulesMap keys are variable so “string” wasn’t compatible when the compiler thought we were using fixed string literals Might be worth another look at `Object.keys()` in future with: * microsoft/TypeScript#45464
I18n.pluralRulesMap keys are variable so “string” wasn’t compatible when the compiler thought we were using fixed string literals Might be worth another look at `Object.keys()` in future with: * microsoft/TypeScript#45464
I18n.pluralRulesMap keys are variable so “string” wasn’t compatible when the compiler thought we were using fixed string literals Might be worth another look at `Object.keys()` in future with: * microsoft/TypeScript#45464
I18n.pluralRulesMap keys are variable so “string” wasn’t compatible when the compiler thought we were using fixed string literals Might be worth another look at `Object.keys()` in future with: * microsoft/TypeScript#45464
I18n.pluralRulesMap keys are variable so “string” wasn’t compatible when the compiler thought we were using fixed string literals Might be worth another look at `Object.keys()` in future with: * microsoft/TypeScript#45464
I18n.pluralRulesMap keys are variable so “string” wasn’t compatible when the compiler thought we were using fixed string literals Might be worth another look at `Object.keys()` in future with: * microsoft/TypeScript#45464
I18n.pluralRulesMap keys are variable so “string” wasn’t compatible when the compiler thought we were using fixed string literals Might be worth another look at `Object.keys()` in future with: * microsoft/TypeScript#45464
We almost support
as const
like casts in JavaScript files, but end up reporting errors because we either pick up the/** @type {} */
from the parenthesized expression when looking for effective type nodes, or by not handling it at all for contextual types. This fixes both scenarios.Fixes #45463
Fixes #30445