-
Notifications
You must be signed in to change notification settings - Fork 12.8k
Consistently use '...args' for diagnostic args #53193
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
Consistently use '...args' for diagnostic args #53193
Conversation
@typescript-bot test this |
Heya @jakebailey, I've started to run the parallelized Definitely Typed test suite on this PR at ce2d704. You can monitor the build here. Update: The results are in! |
Heya @jakebailey, I've started to run the diff-based top-repos suite on this PR at ce2d704. You can monitor the build here. Update: The results are in! |
Heya @jakebailey, I've started to run the perf test suite on this PR at ce2d704. You can monitor the build here. Update: The results are in! |
Heya @jakebailey, I've started to run the diff-based user code test suite on this PR at ce2d704. You can monitor the build here. Update: The results are in! |
Heya @jakebailey, I've started to run the extended test suite on this PR at ce2d704. You can monitor the build here. |
@@ -9118,7 +9119,7 @@ namespace Parser { | |||
|
|||
function parseReturnTag(start: number, tagName: Identifier, indent: number, indentText: string): JSDocReturnTag { | |||
if (some(tags, isJSDocReturnTag)) { | |||
parseErrorAt(tagName.pos, scanner.getTokenStart(), Diagnostics._0_tag_already_specified, tagName.escapedText); | |||
parseErrorAt(tagName.pos, scanner.getTokenStart(), Diagnostics._0_tag_already_specified, unescapeLeadingUnderscores(tagName.escapedText)); |
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.
Here's one example of accidentally using an escaped name in an error message.
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.
True - though it's always going to be the text return
anyhow.
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.
This is probably a bad example, yeah, it's just the first one shown in the unhidden diff.
@jakebailey Here are the results of running the user test suite comparing Everything looks good! |
@jakebailey Here are the results of running the top-repos suite comparing Everything looks good! |
Hey @jakebailey, the results of running the DT tests are ready. Branch only errors:Package: dom-mediacapture-transform
Package: dom-screen-wake-lock
Package: web-animations-js
Package: webappsec-credential-management
Package: dom-webcodecs
Package: w3c-css-typed-object-model-level-1
Package: use-color-scheme
Package: dom-mediacapture-record
Package: ramda
|
@jakebailey Here they are:
CompilerComparison Report - main..53193
System
Hosts
Scenarios
TSServerComparison Report - main..53193
System
Hosts
Scenarios
StartupComparison Report - main..53193
System
Hosts
Scenarios
Developer Information: |
Perf seems unchanged, seems like the usual noise. |
src/compiler/types.ts
Outdated
@@ -6908,6 +6908,9 @@ export interface Diagnostic extends DiagnosticRelatedInformation { | |||
/** @internal */ skippedOn?: keyof CompilerOptions; | |||
} | |||
|
|||
/** @internal */ | |||
export type DiagnosticArguments = (string | number | undefined)[]; |
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.
Allowing undefined
feels too permissive to be honest.
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.
You're totally right, but, the bottommost calls already accepted undefined
, and if I don't keep it, it's not possible to write a function which abstracts over a message and optional argumentss. To make that work, we'd need to strictly type our diagnostics to encode how many arguments they take, which technically sounds good but I'm guessing will be annoying.
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.
But, let me try and make that change again and see how bad it is.
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.
Well, I gave it a shot, but I'd probably want to split some of it into another PR.
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.
FYI I did this; it was slightly more invasive than I hoped because tokenToString
may return undefined
, so I had to give it a stronger overload and fix up other code to make sure that we do it right.
I noticed this was inconsistent and somewhat annoying when I was working on the deprecation errors. I had to make a lot of changes to add a single arg, when the actual core infrastructure for diagnostics supports arbitrary arguments.
Along the way, this shows that we have accidentally been using escaped names in some error messages because some of these functions had their args typed as
any
.But, no changes to any baselines.
Hopefully this isn't any slower given the bottommost level of this chain already uses variadic args.