-
Notifications
You must be signed in to change notification settings - Fork 12.9k
Fully resolve aliases when checking symbol flags #50853
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
Conversation
…ged with an alias that resolves to a value 😵
@typescript-bot user test inline |
Heya @andrewbranch, I've started to run the parallelized Definitely Typed test suite on this PR at a97a11e. You can monitor the build here. |
Heya @andrewbranch, I've started to run the diff-based top-repos suite on this PR at a97a11e. You can monitor the build here. Update: The results are in! |
Heya @andrewbranch, I've started to run the perf test suite on this PR at a97a11e. You can monitor the build here. Update: The results are in! |
@andrewbranch Here are the results of running the top-repos suite comparing Everything looks good! |
@andrewbranch Here they are:
CompilerComparison Report - main..50853
System
Hosts
Scenarios
TSServerComparison Report - main..50853
System
Hosts
Scenarios
Developer Information: |
|
||
==== tests/cases/conformance/externalModules/a.ts (0 errors) ==== | ||
function A() {} | ||
export type { A }; |
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 is this not an error? Since we're exporting as type-only something that is not a type.
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.
Someone who imports this is allowed to use type ASignature = typeof A
export const displayName = "A"; | ||
} | ||
|
||
A(); |
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.
to check my own understanding, this is an error because we don't allow the function value to merge with the namespace?
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.
That’s right, but only because A
is an alias. Normally, slightly disconcerting though it is, we allow a function to merge with an instantiated namespace: playground. I only learned this in the course of my PR, but the rules are stricter for merges across module boundaries (thankfully). Two values are just not allowed to merge across modules.
@@ -2225,8 +2225,8 @@ namespace ts { | |||
!checkAndReportErrorForExtendingInterface(errorLocation) && | |||
!checkAndReportErrorForUsingTypeAsNamespace(errorLocation, name, meaning) && | |||
!checkAndReportErrorForExportingPrimitiveType(errorLocation, name) && | |||
!checkAndReportErrorForUsingNamespaceAsTypeOrValue(errorLocation, name, meaning) && |
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 think that's covered in the tests, but what's the consequence of changing this check's order?
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.
It’s been a while, but I believe it’s this:
A namespace is a value if it exports values. If it’s not a value, it’s not a type per se, but it’s fairly typey. I believe after tweaking the meaning
flag checks in these functions to be a bit easier to read, the checkAndReportErrorForUsingTypeAsValue
started reporting an error on typey (uninstantiated) namespaces, which was stepping on the toes of checkAndReportErrorForUsingNamespaceModuleAsValue
, which wanted to issue essentially the same error, but slightly more precise in mentioning that the non-valuey thing is a namespace. So I simply moved that check first so it would take precedence. So I actually think this order change isn’t reflected in the tests, because it just neutralizes the effect of another readability change. (I also renamed checkAndReportErrorForUsingNamespaceModuleAsValue
to checkAndReportErrorForUsingNamespaceAsTypeOrValue
because nobody knows what a “namespace module” is, and it was already issuing errors when using a namespace as a type.)
@typescript-bot perf test this faster |
Heya @andrewbranch, I've started to run the abridged perf test suite on this PR at fcefb22. You can monitor the build here. Update: The results are in! |
@andrewbranch Here they are:Comparison Report - main..50853
System
Hosts
Scenarios
Developer Information: |
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.
LGTM, though I'm not sure I'm a massive fan of the ?? -1
; it seems like most call sites do that but I don't know if I have any better method, besides maybe SymbolFlags.All
or something, but that still requires the ??
.
I might look at making |
68b3b16
to
72ff9e5
Compare
Fixes #44896
Fixes #50455
I actually don’t think this is a breaking change in any meaningful way. I do have one test that exhibits new errors, but the scenario is extremely contrived and didn’t exactly work before. Mostly, this removes false errors and false import elisions. The most visible and understandable example is the one from #44896: