Skip to content
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

Suppress error caused by intermediate types in getTypeOfExpression #54380

Merged
merged 3 commits into from
May 26, 2023

Conversation

ahejlsberg
Copy link
Member

Fixes #46475.

@typescript-bot typescript-bot added Author: Team For Milestone Bug PRs that fix a bug with a specific milestone labels May 24, 2023
@ahejlsberg
Copy link
Member Author

@typescript-bot test this
@typescript-bot user test this inline
@typescript-bot run dt
@typescript-bot perf test faster
@typescript-bot test top100

@@ -1258,6 +1258,7 @@ export const enum CheckMode {
RestBindingElement = 1 << 6, // Checking a type that is going to be used to determine the type of a rest binding element
// e.g. in `const { a, ...rest } = foo`, when checking the type of `foo` to determine the type of `rest`,
// we need to preserve generic types instead of substituting them for constraints
TypeOnly = 1 << 7, // Called from getTypeOfExpression, diagnostics may be omitted
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

“Type-only” is an overloaded term that sounds like it refers to type-only imports. Would SkipDiagnostics be more clear?

Also, there are a number of mechanisms like this already in the checker, and it’s confusing which one to use. getSignatureApplicabilityError, compareSignaturesRelated, and checkApplicableSignatureForJsxOpeningLikeElement all take both a CheckMode and a reportErrors parameter. It now seems possible for those two to disagree. And there are surely lots of other functions that take a CheckMode but haven’t been updated to suppress errors for TypeOnly.

It seems like it might be better to add use a reportErrors parameter to checkBinaryLikeExpressionWorker, unless we’re prepared to handle this new CheckMode everywhere CheckModes are passed.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The new flag indicates that the originating call came from getTypeOfExpression, meaning that diagnostics can optionally be omitted with no ill effects. But unless we're dealing with an expression that could possibly cause new errors when operands are given narrower types than their declared types, there is no requirement that diagnostics must be omitted. It's bit of a mouthful, not sure what a good short name for that concept is.

I don't think there's an issue with disagreement between checkMode and reportErrors since the flag can be safely ignored in practically all scenarios--in fact, beyond the error for non-comparable operands, nothing needs to change as of now. But if we later discover other issues similar to this, we now have a mechanism to address them.

The only way to properly propagate the information is through a CheckMode flag.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I kinda agree with Andrew and from time to time I find myself wishing we had a better way to control when to report errors and when to not to based on whether we're actually checking things, or just getting types. But since we're nowhere close to doing this, I'm ok with the CheckMode trick for now.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, in an ideal world we'd have more separation between the process of resolving types and that of checking the types. But given that both of those processes have a lot of common code paths (i.e. the entire top-down recursive decomposition is pretty much the same), we've chosen to conflate the them. This does occasionally muddle things, but it definitely also saves a lot of code.

@gabritto
Copy link
Member

@typescript-bot test this
@typescript-bot user test this inline
@typescript-bot run dt
@typescript-bot perf test faster
@typescript-bot test top100

@typescript-bot
Copy link
Collaborator

typescript-bot commented May 25, 2023

Heya @gabritto, I've started to run the diff-based top-repos suite on this PR at 3343bae. You can monitor the build here.

Update: The results are in!

@typescript-bot
Copy link
Collaborator

typescript-bot commented May 25, 2023

Heya @gabritto, I've started to run the diff-based user code test suite on this PR at 3343bae. You can monitor the build here.

Update: The results are in!

@typescript-bot
Copy link
Collaborator

typescript-bot commented May 25, 2023

Heya @gabritto, I've started to run the parallelized Definitely Typed test suite on this PR at 3343bae. You can monitor the build here.

Update: The results are in!

@typescript-bot
Copy link
Collaborator

typescript-bot commented May 25, 2023

Heya @gabritto, I've started to run the extended test suite on this PR at 3343bae. You can monitor the build here.

@typescript-bot
Copy link
Collaborator

typescript-bot commented May 25, 2023

Heya @gabritto, I've started to run the abridged perf test suite on this PR at 3343bae. You can monitor the build here.

Update: The results are in!

@typescript-bot
Copy link
Collaborator

@gabritto Here are the results of running the user test suite comparing main and refs/pull/54380/merge:

There were infrastructure failures potentially unrelated to your change:

  • 1 instance of "Unknown failure"
  • 1 instance of "Package install failed"

Otherwise...

Everything looks good!

@typescript-bot
Copy link
Collaborator

@gabritto
The results of the perf run you requested are in!

Here they are:

Comparison Report - main..54380

Metric main 54380 Delta Best Worst p-value
Angular - node (v16.17.1, x64)
Memory used 365,204k (± 0.01%) 365,243k (± 0.01%) ~ 365,175k 365,290k p=0.173 n=6
Parse Time 3.55s (± 0.73%) 3.56s (± 0.29%) ~ 3.55s 3.58s p=0.461 n=6
Bind Time 1.19s (± 1.02%) 1.18s (± 0.00%) ~ 1.18s 1.18s p=0.293 n=6
Check Time 9.56s (± 0.46%) 9.57s (± 0.39%) ~ 9.52s 9.61s p=0.747 n=6
Emit Time 7.92s (± 0.33%) 7.91s (± 0.60%) ~ 7.85s 7.98s p=0.936 n=6
Total Time 22.21s (± 0.36%) 22.23s (± 0.34%) ~ 22.15s 22.32s p=0.747 n=6
Compiler-Unions - node (v16.17.1, x64)
Memory used 193,529k (± 0.75%) 193,444k (± 0.71%) ~ 192,867k 196,233k p=0.378 n=6
Parse Time 1.61s (± 0.47%) 1.60s (± 1.18%) ~ 1.57s 1.62s p=0.282 n=6
Bind Time 0.83s (± 0.99%) 0.83s (± 0.62%) ~ 0.82s 0.83s p=0.929 n=6
Check Time 10.19s (± 1.02%) 10.17s (± 0.41%) ~ 10.12s 10.21s p=0.809 n=6
Emit Time 3.01s (± 0.98%) 3.00s (± 0.50%) ~ 2.99s 3.03s p=0.805 n=6
Total Time 15.63s (± 0.75%) 15.60s (± 0.38%) ~ 15.52s 15.66s p=1.000 n=6
Monaco - node (v16.17.1, x64)
Memory used 345,875k (± 0.00%) 345,887k (± 0.00%) ~ 345,880k 345,896k p=0.128 n=6
Parse Time 2.74s (± 0.50%) 2.73s (± 0.52%) ~ 2.71s 2.75s p=0.510 n=6
Bind Time 1.08s (± 0.50%) 1.09s (± 1.22%) ~ 1.07s 1.11s p=0.663 n=6
Check Time 7.82s (± 0.68%) 7.84s (± 0.49%) ~ 7.79s 7.89s p=0.520 n=6
Emit Time 4.48s (± 0.72%) 4.43s (± 0.35%) -0.05s (- 1.04%) 4.41s 4.45s p=0.028 n=6
Total Time 16.12s (± 0.58%) 16.09s (± 0.36%) ~ 15.99s 16.16s p=0.688 n=6
TFS - node (v16.17.1, x64)
Memory used 299,939k (± 0.01%) 299,953k (± 0.01%) ~ 299,934k 299,976k p=0.109 n=6
Parse Time 2.16s (± 0.63%) 2.17s (± 0.29%) ~ 2.16s 2.18s p=0.070 n=6
Bind Time 1.24s (± 0.44%) 1.23s (± 0.84%) ~ 1.22s 1.25s p=0.663 n=6
Check Time 7.28s (± 0.49%) 7.26s (± 0.40%) ~ 7.22s 7.29s p=0.225 n=6
Emit Time 4.33s (± 0.72%) 4.33s (± 0.97%) ~ 4.27s 4.37s p=0.935 n=6
Total Time 15.00s (± 0.40%) 14.99s (± 0.27%) ~ 14.92s 15.03s p=0.744 n=6
material-ui - node (v16.17.1, x64)
Memory used 480,996k (± 0.01%) 480,981k (± 0.01%) ~ 480,949k 481,010k p=0.471 n=6
Parse Time 3.26s (± 0.42%) 3.26s (± 0.17%) ~ 3.25s 3.26s p=0.663 n=6
Bind Time 0.94s (± 0.55%) 0.94s (± 0.43%) ~ 0.93s 0.94s p=0.595 n=6
Check Time 17.87s (± 0.52%) 17.77s (± 0.30%) -0.10s (- 0.59%) 17.73s 17.87s p=0.020 n=6
Emit Time 0.00s (± 0.00%) 0.00s (± 0.00%) ~ 0.00s 0.00s p=1.000 n=6
Total Time 22.07s (± 0.43%) 21.96s (± 0.24%) -0.11s (- 0.49%) 21.92s 22.06s p=0.020 n=6
xstate - node (v16.17.1, x64)
Memory used 560,689k (± 0.01%) 560,644k (± 0.02%) ~ 560,521k 560,726k p=0.471 n=6
Parse Time 3.99s (± 0.26%) 4.00s (± 0.34%) ~ 3.99s 4.02s p=0.156 n=6
Bind Time 1.76s (± 0.56%) 1.76s (± 0.43%) ~ 1.75s 1.77s p=0.652 n=6
Check Time 3.05s (± 0.67%) 3.04s (± 0.38%) ~ 3.03s 3.06s p=0.511 n=6
Emit Time 0.09s (± 0.00%) 0.09s (± 0.00%) ~ 0.09s 0.09s p=1.000 n=6
Total Time 8.90s (± 0.26%) 8.90s (± 0.27%) ~ 8.86s 8.93s p=0.936 n=6
System
Machine Namets-ci-ubuntu
Platformlinux 5.4.0-148-generic
Architecturex64
Available Memory16 GB
Available Memory15 GB
CPUs4 × Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
Hosts
  • node (v16.17.1, x64)
Scenarios
  • Angular - node (v16.17.1, x64)
  • Compiler-Unions - node (v16.17.1, x64)
  • Monaco - node (v16.17.1, x64)
  • TFS - node (v16.17.1, x64)
  • material-ui - node (v16.17.1, x64)
  • xstate - node (v16.17.1, x64)
Benchmark Name Iterations
Current 54380 6
Baseline main 6

Developer Information:

Download Benchmark

@typescript-bot
Copy link
Collaborator

@gabritto Here are the results of running the top-repos suite comparing main and refs/pull/54380/merge:

Everything looks good!

@typescript-bot
Copy link
Collaborator

Hey @gabritto, the results of running the DT tests are ready.
Everything looks the same!
You can check the log here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Author: Team For Milestone Bug PRs that fix a bug with a specific milestone
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Type of variable isn't widened inside a conditional inside a loop
4 participants