-
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
Pr 50377 redo filter boolean overload #56357
Pr 50377 redo filter boolean overload #56357
Conversation
6fb5fd3
to
f56e8f0
Compare
f56e8f0
to
e1a72ff
Compare
Adding special magic for this in the compiler internals for what is otherwise a userland method call (that isn’t reflected in the method signature) feels like it opens a can of worms that the TS maintainers may not want to touch… |
I hadn't initially thought of the js standard lib as a userland method. The compiler type processing internals do include tests for the js |
Yeah, the methods are declared in userland - I don’t think the built-in I’m not a maintainer, so take what I say with a grain of salt, but this does feel like the kind of thing there’d be significant resistance to, based on past experience (I’ve been lurking around here for many years). |
I believe you. BTW - here is TypeScript compiler code where Array and Tuple methods are treated specially and rewritten:
It is an example (and I think probably the only example) of the built-in .d.ts files being treated differently from user-authored ones. The result of being forced into a corner, I guess. |
Yes, that was explicitly added in #53489. @typescript-bot test top200 @typescript-bot perf test this |
Heya @jakebailey, I've started to run the parallelized Definitely Typed test suite on this PR at 7afbdfa. 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 7afbdfa. 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 7afbdfa. You can monitor the build here. Update: The results are in! |
Heya @jakebailey, I've started to run the tarball bundle task on this PR at 7afbdfa. You can monitor the build here. |
Heya @jakebailey, I've started to run the regular perf test suite on this PR at 7afbdfa. You can monitor the build here. Update: The results are in! |
Hey @jakebailey, 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 |
@jakebailey Here are the results of running the user test suite comparing There were infrastructure failures potentially unrelated to your change:
Otherwise... Something interesting changed - please have a look. Details
|
@jakebailey Here they are:
CompilerComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
tsserverComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
StartupComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
Developer Information: |
Emit time improved 10+% from this? That has to be noise. |
It is, note the time granularity is only 0.01s and that test has enough problems that it doesn't emit and so runs in 0.08. |
Hey @jakebailey, the results of running the DT tests are ready. |
@jakebailey Here are the results of running the top-repos suite comparing Everything looks good! |
It turns out a problem with this idea is that Oddly, it does check the interface prototype when the prototype is a unique ES Symbol. If that gets sorted out, it might be worth considering. |
It turns out a problem with this idea is that
BooleanConstructor
is not distinguishable from(x:any)=>boolean
. Meaning TypeScript doesn't check the interface prototype when the prototype is a TypeScript Symbol for a user variable. I.e., in this caseBoolean
.Oddly, it does check the interface prototype when the prototype is a unique ES Symbol.
If that gets sorted out, it might be worth considering.
Fixes #50377 - when
Boolean
is used a predicate to Array.filter falsie types are filtered in the result.(However, this version doesn't use an overload in
lib/es5.d.ts
)Source Files changed:
src/compiler/checker.ts
Added Test Files
Related issues
filter(Boolean)
#50377 Explore adding the Boolean to filter to narrow out null/undefined in array#filter (closed pull)
#50387 Add BooleanConstructor as an overload to .filter to allow for easy type predicate filtering (inDiscussion)
#30621 narrow array type with .filter(Boolean) (marked as duplicate of #16655, although #16655 is more broad than #30621)
#56013 Adding an overload to .filter breaks specific inference with nested functions (related)
#55777
Boolean as falsey check in general
#16655 Boolean() cannot be used to perform a null check (broader than filter(Boolean))
#29955 Allow Boolean() to be used to perform a null check (accepted pull, may have reverted)
#53489 Add fallback logic for generating signatures for unions of array members
Source code changes
checker.ts
In
chooseOverload
, afterresult
is selected, when the argument is of typeBooleanConstructor
and the result signature isArray.filter
, the result signature is cloned, and itsresolvedReturnType
property is set.Regressions
None found with runtests
Discussion
In this revision, es5.d.ts is not modified at all. Instead, the return type is changed dynamically in
chooseOverload
in checker.ts.Therefore, the user won't see a completion suggesting Boolean, unlike the last revision. Obviously that is a disadvantage.
The advantage is that there are less changes overall, so the pull is easier to review. (Previously there were ~60 files changes, and that's a lot to review).