profile
viewpoint
Anders Hejlsberg ahejlsberg Microsoft Redmond, WA, USA Microsoft Technical Fellow and lead architect of TypeScript. Original designer of C#, Delphi, and Turbo Pascal.

DefinitelyTyped/DefinitelyTyped 26634

The repository for high quality TypeScript type definitions.

ahejlsberg/typescript-build2016-demos 75

Collection of TypeScript demo projects form //build 2016

pull request commentmicrosoft/TypeScript

Properly handle control flows from returns in try/catch within IIFE

RWC is clean. Everything else has failures (why?), but it all looks like preexisting conditions.

ahejlsberg

comment created time in 14 hours

pull request commentmicrosoft/TypeScript

Cache results of isGenericObjectType and isGenericIndexType

How do these predicates relate to couldContainTypeVariables? Is there a reason these are ObjectFlags and that uses a property?

The isGenericObjectType and isGenericIndexType functions are used to determine whether conditional types, indexed access types, and index types should be resolved, or whether resolution should be deferred in a higher-order type of the particular kind. It is possible for these functions to return false even if the given type references type variables, e.g. for the type { foo: T } where T is a type variable.

The couldContainTypeVariables function computes whether a type possibly contains type variables, i.e. whether it possibly could be affected by instantiation. This function may return true even when the type references no type variables because it isn't possible to explore all types fully in depth. There's no good reason for this function to use a dedicated property. An ObjectFlags flag would be better.

In scenarios that are heavy on union and intersection type instantiation, it might make sense to first call couldContainTypeVariables since the cached result would allow us to bail out quicker.

ahejlsberg

comment created time in a day

issue commentmicrosoft/TypeScript

Flow analysis fails when using try catch block in IIFEs

@RyanCavanaugh We should consider pulling this into 3.8.

SanderRonde

comment created time in a day

PR opened microsoft/TypeScript

Properly handle control flows from returns in try/catch within IIFE

Fixes #36828.

+879 -105

0 comment

11 changed files

pr created time in 2 days

create barnchmicrosoft/TypeScript

branch : fix36828

created branch time in 2 days

pull request commentmicrosoft/TypeScript

Reduce intersections by discriminants

Do we need a getReducedType call in inferTypes?

Yeah, we probably do.

ahejlsberg

comment created time in 3 days

Pull request review commentmicrosoft/TypeScript

Reduce intersections by discriminants

 namespace ts {                         spread = getSpreadType(spread, createJsxAttributesType(), attributes.symbol, objectFlags, /*readonly*/ false);
                         attributesTable = createSymbolTable();
                     }
-                    const exprType = checkExpressionCached(attributeDecl.expression, checkMode);
+                    const exprType = getReducedType(checkExpressionCached(attributeDecl.expression, checkMode));

No, getReducedType itself also caches, so it is cheap the second time around.

ahejlsberg

comment created time in 3 days

Pull request review commentmicrosoft/TypeScript

Reduce intersections by discriminants

-/// <reference path='fourslash.ts' />
-
-//@Filename: file.tsx
-// @jsx: preserve
-// @skipLibCheck: true
-
-//// declare module JSX {
-////     interface Element { }
-////     interface IntrinsicElements {
-////     }
-////     interface ElementAttributesProperty { props; }
-//// }
-//// function SFC1(prop: { x: number }) {
-////     return <div>hello </div>;
-//// };
-//// function SFC2(prop: { x: boolean }) {
-////     return <h1>World </h1>;
-//// }
-//// var SFCComp = SFC1 || SFC2;
-//// <SFCComp /**/ />
-
-verify.completions({ marker: "", exact: ["x"] });

I suppose. Doesn't seem like a particularly useful test though.

ahejlsberg

comment created time in 3 days

Pull request review commentmicrosoft/TypeScript

Reduce intersections by discriminants

-/// <reference path='fourslash.ts'/>-// #32708--////interface I<T> {-////    /** only once please */-////    t: T-////}-////interface C<T> extends I<T> {-////    t: T-////}-////declare var cnsb: C<number> & C<string> & C<boolean>;-////cnsb.t/**/--verify.quickInfoAt("", "(property) C<T>.t: never", "only once please");

What's the fourslash incantation needed to verify there's no quick info?

ahejlsberg

comment created time in 3 days

Pull request review commentmicrosoft/TypeScript

Reduce intersections by discriminants

 namespace ts { 
         const target = getTargetOfBindingOrAssignmentElement(bindingElement);
         if (target && isPropertyName(target)) {
-            return isComputedPropertyName(target) && isStringOrNumericLiteral(target.expression)

Not sure what your question is here? With the improved precision of intersections, the checker was proving that this expression could never be true.

ahejlsberg

comment created time in 3 days

push eventmicrosoft/TypeScript

Anders Hejlsberg

commit sha 7741085ca9a1987e316d003d1ad75c9d033e9ed9

Fix comment in tests

view details

push time in 4 days

pull request commentmicrosoft/TypeScript

Reduce intersections by discriminants

DT tests have four new failures. Two are legitimate errors caused by empty intersections being turned into never. One is simply an error elaboration change caused by us displaying an alias instead of the literal type.

The last failure (in ramda) is caused by a type in ts-toolbelt that depends on keyof (A & B) producing the same type as keyof A | keyof B when A & B is an empty intersection. It is a simple (and backwards compatible) change to fix this.

ahejlsberg

comment created time in 4 days

pull request commentmicrosoft/TypeScript

Reduce intersections by discriminants

RWC tests have improved error baselines in fp-ts because a number of empty intersections are being reduced away. Otherwise no change in RWC.

ahejlsberg

comment created time in 4 days

pull request commentmicrosoft/TypeScript

Reduce intersections by discriminants

@typescript-bot run dt

ahejlsberg

comment created time in 5 days

push eventmicrosoft/TypeScript

Anders Hejlsberg

commit sha fbf13dc269ee8ac9e5a9c2a40fe60a999a4a0e45

Add tests

view details

Anders Hejlsberg

commit sha 85447a5e1505adb9e6ff345b91f248d00bd75b82

Accept new baselines

view details

push time in 5 days

push eventmicrosoft/TypeScript

Anders Hejlsberg

commit sha aa8d227880b90c10724670f5d33ef62b879cfc31

Ensure reduced and unreduced forms of a type can compare identical

view details

Anders Hejlsberg

commit sha 8907e92ef986047ca43af48b42b514bf56ca2ec1

Reduce types before converting them to string representation

view details

Anders Hejlsberg

commit sha 04facee1e878c212a9f1f66e8a68794819b927a0

Accept new baselines

view details

Anders Hejlsberg

commit sha 88be5ea6fb9a1fc1751fd1246be1c437686a9d83

Reduce intersections before obtaining keyof X

view details

push time in 5 days

PR closed microsoft/TypeScript

Reduce intersections by discriminant

Experiment for now.

+99 -33

14 comments

9 changed files

ahejlsberg

pr closed time in 6 days

pull request commentmicrosoft/TypeScript

Reduce intersections by discriminant

Closing in favor of #36696.

ahejlsberg

comment created time in 6 days

pull request commentmicrosoft/TypeScript

Never-like intersections

@weswigham @RyanCavanaugh Please review when you get a chance (as usual the GitHub reviewers suggestion list doesn't work).

ahejlsberg

comment created time in 6 days

Pull request review commentmicrosoft/TypeScript

Never-like intersections

 tests/cases/conformance/types/union/discriminatedUnionTypes2.ts(132,11): error T         }
         else {
             x.value;  // Error, x is never

This is an expected effect. After reducing away empty intersections, x is no longer a union type and therefore we don't do control flow based narrowing. It is similar to what you'd see if x just had the type { type: number, value: number }.

ahejlsberg

comment created time in 6 days

pull request commentmicrosoft/TypeScript

Never-like intersections

@typescript-bot perf test this @typescript-bot run dt

ahejlsberg

comment created time in 9 days

push eventmicrosoft/TypeScript

Anders Hejlsberg

commit sha 49302f2cc75400364152cb2fa30310764717af54

Don't call getReducedType in getIndexType

view details

push time in 9 days

push eventmicrosoft/TypeScript

Anders Hejlsberg

commit sha 7a1c5b7a20886d7e08e03fa333e078f29f400ca5

Avoid expensive relationship checking in mapped type member resolution (#36754) * Avoid expensive relationship checking in mapped type member resolution * Accept new baselines

view details

push time in 9 days

PR merged microsoft/TypeScript

Avoid expensive relationship checking in mapped type member resolution

This PR removes an expensive isTypeAssignableTo check from mapped type member resolution and replaces it with a shallower maybeTypeOfKind. The full relationship check can generate a lot of work exploring simplifications and constraints. Replacing it with the shallow check improves total compile time of the repro in #36564 by 8-10% and also resolves circularities I'm seeing in another PR.

+23 -23

12 comments

6 changed files

ahejlsberg

pr closed time in 9 days

pull request commentmicrosoft/TypeScript

Avoid expensive relationship checking in mapped type member resolution

@amcasey I saw one more match, but it's fine for that to stay as is.

ahejlsberg

comment created time in 9 days

pull request commentmicrosoft/TypeScript

Avoid expensive relationship checking in mapped type member resolution

The "worst case" is that we mix in an extra undefined that's already expressed in the property type's constraint

Yup, that's exactly it.

Maybe an inline comment on why we're making this change on the appropriate line is relevant

Don't think we need a comment. With this change the code is actually more consistent with what we do on the next line to shallowly remove undefined from the type.

But, for this an other reasons, it definitely would make sense to add the repro from #36564 as a performance test case. That way we'll see a 10% regression if someone messes with it.

ahejlsberg

comment created time in 10 days

Pull request review commentmicrosoft/TypeScript

Avoid expensive relationship checking in mapped type member resolution

 class C<T extends Options> { >method : () => void
 
         let { a, b } = this.foo;
->a : T["a"]
+>a : T["a"] | undefined
 >b : T["b"]
 >this.foo : { [P in keyof T]: T[P]; }
 >this : this
 >foo : { [P in keyof T]: T[P]; }
 
         !(a && b);
->!(a && b) : false

I believe it's the old issue of not having a good representation for the falsy parts of a higher-order type. For example:

interface Options {
    a: unknown;
    b: unknown;
}

function foo<T extends Options>(a: T['a'], b: T['b']) {
    const x = a && b;  // Type T['b']
}

The type of x really should be T['b'] unioned with the falsy parts of T['a'], but even with negated types this would be a pretty ugly type. IIRC we previously decided to leave this as a known design limitation.

ahejlsberg

comment created time in 10 days

pull request commentmicrosoft/TypeScript

Never-like intersections

@typescript-bot perf test this @typescript-bot run dt

ahejlsberg

comment created time in 10 days

push eventmicrosoft/TypeScript

Arpad Borsos

commit sha 72c0961071a29ab41e011b59bc50046c04b4d21e

Force a gc before printing diagnostics Use this together with `node --expose-gc` to get more stable results

view details

Arpad Borsos

commit sha 391a3c8791a8c56e283d39dd0f291156ed304d52

Separate Tokens and Identifiers from other Nodes With some further optimization to their properties, this shrinks the objects by quite a bit.

view details

Nathan Shively-Sanders

commit sha 2cc585668d604c454e41cd006a222c3c7299acf1

Support property declarations in jsdoc template generation (#36658) * Support property declarations in jsdoc template generation * fix lint and add test

view details

Nathan Shively-Sanders

commit sha 1e48cbe2c92d4e0338179f1ac512ae3bbb6f5c40

Fix jsdoc comment parsing initial state (#36661) * Fix jsdoc comment parsing initial state Jsdoc comment parsing can be invoked in two modes: 1. top-level parsing, for comments not inside a tag. 2. tag parsing, for comment that occur after the semantic parts of a tag. Top-level parsing skips an initial * because it assumes that it is starting at the very beginning of a JSDoc comment. Tag parsing does not. The two modes are distinguished by an optional second parameter named `margin`. When `margin` is provided, it provides an initial indent used for comment alignment. Previously, the check for `margin` was a truthy check `if (margin)`. This check incorrectly treats `margin=""` the same as `margin=undefined`. This PR changes the check to `if (margin !== undefined)`, which correctly treats `margin=""` the same as `margin=" "`. * Fixes for broken tests 1. Use SawAsterisk start state. 2. @template needs to skip asterisk in addition to whitespace while parsing type parameter names. * undo code move

view details

Nathan Shively-Sanders

commit sha 71c1da020f310ece5297e506233c839c8dd55cf5

redo #28564 (#36665)

view details

TypeScript Bot

commit sha 909672450dd01a4242a53be31e0ff8b3a162673f

Update user baselines (#36669)

view details

Jack Bates

commit sha fa3173f8f6443307739fc7c41f2bdd680f56a844

Either clone or pull, don't do both (#35230) Co-authored-by: Nathan Shively-Sanders <293473+sandersn@users.noreply.github.com>

view details

Sheetal Nandi

commit sha 70e6f5b8a09d72a15c8bedc4380f7be62f0b6013

Handle walkThroughSnippet:/ and untitled:/ as dynamic files (#36722) Handle walkThroughSnippet:/ and untitled:/ as dynamic files Fixes #36681

view details

Wesley Wigham

commit sha aece8c06b0768671488de54e2f1d8a20e7cc82ef

Allow intersections (and substitutions) to be checks against discriminable unions (#36663)

view details

Andrew Branch

commit sha ad8c209fc24eb1e35a571871776ce9455464813e

Use type-only imports in auto-imports when it would be an error not to, and use auto-imports in “implement interface” fix (#36615) * Refactor fix-all-missing-imports to be reusable by other codefixes * Migrate infer-from-usage to use ImportAdder * Add infer from usage test importing more than one thing in a single fix * Migrate implement interface / abstract members fixes to use ImportAdder * Update old tests * Use type-only imports when it would be an error not to * Add another test * Rename stuff

view details

Brad Zacher

commit sha 348c4dddc68b84148b753b48ecf9b97cc2d07ebb

Throw syntax error for `}` and `>` in JSX text (#36636) * Throw syntax error for `}` and `>` in JSX text Fixes #36341 * Add codefix for error

view details

Nathan Shively-Sanders

commit sha a772c26a71704114742717a7beb63978e56b51c0

Error when property is specified more than once via a spread (#36727) * add tests but not baselines or fixes * Update original change Still probably wrong; probably doesn't even compile beacuse I'm just typing on my laptop. * fix error code ok * notes to self * Error: property is specified more than once via spread * make jsx tests stricter * update semicolon error message * use ?. because it is great * use maybeTypeOfKind in new code * restore jsx error * add tests

view details

Wesley Wigham

commit sha 8481bc1d98dd0b87abca6f2ebfe67df8fac24f07

Do not report errors when we fail to find a module symbol at an import specifier when invoked via API (#36742)

view details

Wesley Wigham

commit sha 1fd0e8f9a6f4f7f8510948ea1e4545009503195a

Bump package.json version to reflect reality

view details

Wesley Wigham

commit sha 6f079a4ebcb78489eabb523faaf1b69f88e80bd7

Update versionMajorMinor to match package.json

view details

Ron Buckton

commit sha cf6b641709e2b40030a6845f8c144a73267fb41b

Merge branch 'master' into separate-nodetypes

view details

Nathan Shively-Sanders

commit sha 01c86c749d95496b9fcbd0301543cd3501a59877

Fix get candidate for overload failure checking (#36744) * getCandidateForOverloadFailure:call resolveUntypedCall This re-adds the missed errors and marks as used missed nodes from the user and RWC baselines. * Update baselines and remove new test It was redundant with the old tests * Defer resolveUntypedCall on resolution failure to give priority to parameter types fixed by overload signatures Co-authored-by: Wesley Wigham <wwigham@gmail.com>

view details

Ron Buckton

commit sha 195f6bb2ab64ea149205b7a4c78c18d5f3632dd4

Merge branch 'separate-nodetypes' of https://github.com/Swatinem/TypeScript into Swatinem-separate-nodetypes

view details

Ron Buckton

commit sha 54102336f2ccd90f783057cd8989c3416eedf9db

Merge branch 'Swatinem-separate-nodetypes'

view details

Anders Hejlsberg

commit sha aeab6afcf3be519495271339f7c824110d9ba4ae

Merge branch 'master' into neverLikeIntersections # Conflicts: # src/compiler/checker.ts

view details

push time in 10 days

push eventmicrosoft/TypeScript

Anders Hejlsberg

commit sha f17019153898641a77c80cc6a36a799c7141948e

Don't reduce in getApparentType

view details

Anders Hejlsberg

commit sha 6b2f3a2cbeb9c8483fb7af1a729bee29368f5d48

Avoid relationship check in resolveMappedTypeMembers

view details

push time in 10 days

pull request commentmicrosoft/TypeScript

Avoid expensive relationship checking in mapped type member resolution

@amcasey @RyanCavanaugh Can't add you as reviewers (the usual GitHub issue), but please tak a look when you can.

ahejlsberg

comment created time in 10 days

pull request commentmicrosoft/TypeScript

Avoid expensive relationship checking in mapped type member resolution

RWC and DT tests are clean (errors are preexisting conditions in master). Only positive effects on performance. I think this one is good to go.

ahejlsberg

comment created time in 10 days

push eventmicrosoft/TypeScript

Anders Hejlsberg

commit sha 283118cf970f0f10fdedebcc4dd7eaa121efbe05

Accept new baselines

view details

push time in 10 days

pull request commentmicrosoft/TypeScript

Avoid expensive relationship checking in mapped type member resolution

@typescript-bot test this @typescript-bot user test this @typescript-bot run dt @typescript-bot perf test this

ahejlsberg

comment created time in 10 days

PR opened microsoft/TypeScript

Avoid expensive relationship checking in mapped type member resolution

This PR removes an expensive isTypeAssignableTo check from mapped type member resolution and replaces it with a shallower maybeTypeOfKind. The full relationship check can generate a lot of work exploring simplifications and constraints. Replacing it with the shallow check improves total compile time of the repro in #36564 by 8-10% and also resolves circularities I'm seeing in another PR.

+2 -2

0 comment

1 changed file

pr created time in 10 days

create barnchmicrosoft/TypeScript

branch : mappedTypeMemberResolution

created branch time in 10 days

pull request commentmicrosoft/TypeScript

Never-like intersections

@typescript-bot run dt @typescript-bot perf test this

ahejlsberg

comment created time in 11 days

push eventmicrosoft/TypeScript

Anders Hejlsberg

commit sha dba1043a23b2ffff07af6a468f98f4cc87d31a8f

Introduce getReducedType for union and intersection types

view details

push time in 11 days

pull request commentmicrosoft/TypeScript

Never-like intersections

@typescript-bot perf test this

ahejlsberg

comment created time in 12 days

pull request commentmicrosoft/TypeScript

Never-like intersections

@typescript-bot run dt

ahejlsberg

comment created time in 12 days

push eventmicrosoft/TypeScript

Anders Hejlsberg

commit sha e1434a56967dbf05d8c3dd0302a6f5b2fd47fe4e

Add comments

view details

Anders Hejlsberg

commit sha 37c62802ff2bb3b06b99f9c359bab61b49d6c372

Revert isNeverLikeType check in getIndexType (keyof shouldn't resolve member types)

view details

push time in 12 days

pull request commentmicrosoft/TypeScript

Never-like intersections

@typescript-bot run dt

ahejlsberg

comment created time in 12 days

push eventmicrosoft/TypeScript

Anders Hejlsberg

commit sha 3a1ba484e62f13636e98977c8199056763c341ad

Check that base types are not never-like

view details

push time in 12 days

push eventmicrosoft/TypeScript

Anders Hejlsberg

commit sha 7ae4a215e0c8f4f2b0bce445a8f5217a3bd3c5bf

Erase never-like types in several more places

view details

push time in 12 days

pull request commentmicrosoft/TypeScript

Never-like intersections

@typescript-bot run dt

ahejlsberg

comment created time in 13 days

push eventmicrosoft/TypeScript

Anders Hejlsberg

commit sha acd3feca5419e7d7591fa042dca9ca47ffecfde7

Include isNeverLikeIntersection check in getNormalizedType

view details

push time in 13 days

pull request commentmicrosoft/TypeScript

Never-like intersections

@typescript-bot test this @typescript-bot user test this @typescript-bot run dt @typescript-bot perf test this

ahejlsberg

comment created time in 14 days

push eventmicrosoft/TypeScript

Anders Hejlsberg

commit sha 346ec30e32b4be81e82bba6d565fe60a5549728d

Delete fourslash tests that are no longer applicable

view details

push time in 14 days

pull request commentmicrosoft/TypeScript

Never-like intersections

@typescript-bot test this @typescript-bot user test this @typescript-bot run dt @typescript-bot perf test this

ahejlsberg

comment created time in 14 days

push eventmicrosoft/TypeScript

Anders Hejlsberg

commit sha 94353d2b26a8ffdeefaf747838ff377ac776c364

Fix compiler issues revealed by increased intersection correctness

view details

push time in 14 days

PR opened microsoft/TypeScript

Never-like intersections

Experiment for now.

+71 -29

0 comment

10 changed files

pr created time in 14 days

create barnchmicrosoft/TypeScript

branch : neverLikeIntersections

created branch time in 14 days

pull request commentmicrosoft/TypeScript

Reduce intersections by discriminant

@typescript-bot run dt @typescript-bot user test this @typescript-bot perf test this

ahejlsberg

comment created time in 14 days

push eventmicrosoft/TypeScript

Anders Hejlsberg

commit sha ef939c53884da2f40cdd4e4f833a2f779586a990

Conservative inspection of type annotations to avoid circularities

view details

Anders Hejlsberg

commit sha aaeaeab9eb27c2df0f01d30411f66f7262247e82

Fix bugs in compiler uncovered by better intersections

view details

push time in 14 days

pull request commentmicrosoft/TypeScript

Reduce intersections by discriminant

@typescript-bot test this @typescript-bot run dt @typescript-bot user test this @typescript-bot perf test this

ahejlsberg

comment created time in 15 days

PR opened microsoft/TypeScript

Reduce intersections by discriminant

Experiment for now.

+62 -29

0 comment

7 changed files

pr created time in 15 days

create barnchmicrosoft/TypeScript

branch : reduceIntersectionsByDiscriminant

created branch time in 15 days

push eventmicrosoft/TypeScript

Anders Hejlsberg

commit sha b8b59489e1040c288d6cf4593bd561d14770bbe7

Cache results of isGenericObjectType and isGenericIndexType (#36622)

view details

push time in 16 days

PR merged microsoft/TypeScript

Reviewers
Cache results of isGenericObjectType and isGenericIndexType

With this PR we cache the results of isGenericObjectType and isGenericIndexType for unions and intersections. This improves total compile time of the repro in #36564 by about 6.5%.

+27 -8

3 comments

2 changed files

ahejlsberg

pr closed time in 16 days

push eventmicrosoft/TypeScript

Anders Hejlsberg

commit sha de37c87252fba0275da28891ca813c9afc59348e

Optimize deferred type references (#36607) * Improve reasoning about when to create deferred type references * Accept new baselines * Fix minor issues * Handle default type arguments case in isDeferredTypeReferenceNode

view details

push time in 16 days

PR merged microsoft/TypeScript

Reviewers
Optimize deferred type references

This PR improves our reasoning about when to (and, more importantly, when not to) create deferred type references. We now create fewer deferred type references which improves overall compile times for the repro in #36566 by around 4%.

Fixes #36566.

+57 -17

16 comments

4 changed files

ahejlsberg

pr closed time in 16 days

issue closedmicrosoft/TypeScript

Performance regressions from recursive type reference support

The extra work done in #33050 and follow-up PR #33678 is valuable, but maybe it doesn't need to be so expensive.

Setup:

  1. Clone https://github.com/amcasey/material-ui.git
  2. Check out Benchmark
  3. yarn to restore packages
  4. yarn typescript to prebuild and run some TS tests

Repro

  1. tsc -p docs

On a random Mac Mini:

For #33050

  • 10-run avg on https://github.com/microsoft/TypeScript/commit/4ee251b053eb2d419ce5304b309c5e4e1cd7ad1c: 33,685ms
  • 10-run avg on https://github.com/microsoft/TypeScript/commit/250d5a8229e17342f36fe52545bb68140db96a2e: 34,223ms (2% slower)

For #33678

  • 10-run avg on https://github.com/microsoft/TypeScript/commit/7f3c03d4414939bb48758c0f957babed830df48c: 34,403ms
  • 10-run avg on https://github.com/microsoft/TypeScript/commit/7ce793c5b8c621af5ce50af0ca3958c7bd6541bf: 35,488ms (3% slower)

Note: to build old TS commits, you probably need to change const { default: chalk } to const chalk in scripts/build/utils.js.

closed time in 16 days

amcasey

push eventmicrosoft/TypeScript

Anders Hejlsberg

commit sha 0a160323dfc16c55b38ac9a59bc3cb6a85afa222

Faster exit from isTypeRelatedTo with identityRelation (#36590) * Faster exit from isTypeRelatedTo with identityRelation * Reorganize a bit

view details

push time in 16 days

PR merged microsoft/TypeScript

Reviewers
Faster exit from isTypeRelatedTo with identityRelation

Reduces the total compile time of the test in #36564 by about 6%.

Fixes #36564.

+27 -20

8 comments

2 changed files

ahejlsberg

pr closed time in 16 days

issue closedmicrosoft/TypeScript

Performance regression in #33252

The extra work done in #33252 is valuable, but maybe it doesn't need to be so expensive.

Setup:

  1. Clone https://github.com/amcasey/material-ui.git
  2. Check out Benchmark
  3. yarn to restore packages
  4. yarn typescript to prebuild and run some TS tests

Repro

  1. tsc -p docs

On a random Mac Mini:

  • 10-run avg on https://github.com/microsoft/TypeScript/commit/72bb4c2bdcb0cb245c397cd9a8f1f0d1158c6a5d: 30,872ms
  • 10-run avg on https://github.com/microsoft/TypeScript/commit/c5e6d95e930048a033868d72440a9296904a33ec: 33,268ms (8% slower)

Note: to build old TS commits, you probably need to change const { default: chalk } to const chalk in scripts/build/utils.js.

closed time in 16 days

amcasey

pull request commentmicrosoft/TypeScript

Cache results of isGenericObjectType and isGenericIndexType

@typescript-bot perf test this

ahejlsberg

comment created time in 17 days

PR opened microsoft/TypeScript

Cache results of isGenericObjectType and isGenericIndexType

With this PR we cache the results of isGenericObjectType and isGenericIndexType for unions and intersections. This helps performance of the repro in #36564.

+27 -8

0 comment

2 changed files

pr created time in 17 days

create barnchmicrosoft/TypeScript

branch : optimizeGenericTypeCheck

created branch time in 17 days

pull request commentmicrosoft/TypeScript

Optimize deferred type references

Tests look clean. Only change is a minor type ordering difference in a few error messages in RWC.

ahejlsberg

comment created time in 17 days

pull request commentmicrosoft/TypeScript

Optimize deferred type references

@typescript-bot run dt

ahejlsberg

comment created time in 18 days

push eventmicrosoft/TypeScript

Anders Hejlsberg

commit sha 6ebc9e34217db3e898f46d6219fc131baf093d70

Handle default type arguments case in isDeferredTypeReferenceNode

view details

push time in 18 days

pull request commentmicrosoft/TypeScript

Optimize deferred type references

@typescript-bot test this @typescript-bot user test this @typescript-bot run dt @typescript-bot perf test this

ahejlsberg

comment created time in 18 days

push eventmicrosoft/TypeScript

Anders Hejlsberg

commit sha e1fd56a719bff9b632084917f03931a8c3697ded

Fix minor issues

view details

push time in 18 days

pull request commentmicrosoft/TypeScript

Optimize deferred type references

@typescript-bot test this @typescript-bot user test this @typescript-bot run dt @typescript-bot perf test this

ahejlsberg

comment created time in 18 days

PR opened microsoft/TypeScript

Optimize deferred type references

This PR improves our reasoning about when to create deferred type references.

+57 -17

0 comment

4 changed files

pr created time in 18 days

create barnchmicrosoft/TypeScript

branch : optimizeDeferredTypeReferences

created branch time in 18 days

push eventmicrosoft/TypeScript

Anders Hejlsberg

commit sha d6d9dd771e561eaa4ce295bab05c2f167433b1ca

Reorganize a bit

view details

push time in 18 days

pull request commentmicrosoft/TypeScript

Flatten immediately nested conditional types in the false position

@weswigham Beyond fixing the depth limiter issue on large conditional types, the PR makes resolution faster by virtue of its shortened code path and reduces memory consumption by not storing resolved types in the caches associated with the each nested type's ConditionalRoot. The effects are not dramatic, but every little bit counts. I disagree that the loop greatly complicates the code. I think it is perfectly meaningful to think of a series of immediately nested conditionals as a single construct, and the loop reflects that.

ahejlsberg

comment created time in 18 days

pull request commentmicrosoft/TypeScript

Faster exit from isTypeRelatedTo with identityRelation

@typescript-bot run dt @typescript-bot perf test this

ahejlsberg

comment created time in 18 days

create barnchmicrosoft/TypeScript

branch : optimizeIdentityRelation

created branch time in 18 days

push eventmicrosoft/TypeScript

Anders Hejlsberg

commit sha 3712faa63b3087884d81c953b8cf838a4781726d

Handle nested distributive types with different checkType

view details

push time in 19 days

push eventmicrosoft/TypeScript

Anders Hejlsberg

commit sha 89e65b3ff70d751bf17c0b0e6c33fe3ca26336b2

Add test

view details

Anders Hejlsberg

commit sha c3864515f9fe49708833e30f3e8f4880967b7c05

Accept new baselines

view details

push time in 19 days

PR opened microsoft/TypeScript

Flatten immediately nested conditional types in the false position

With this PR we flatten immediately nested conditional types in the false position, effectively treating types of the form

type Foo<...> =
    A extends B ? X :
    C extends D ? Y :
    E extends F ? Z :
    ...;

as a single construct for purposes of resolution. This should meaningfully improve the cost of resolving such types, plus it means they aren't subject to the instatiation depth limiter (they basically count as a single level).

I'm pretty sure we have bug for this somewhere (because we'd hit the instantiation limiter after about 50 levels), but I can't seen to find it right now.

+71 -58

0 comment

1 changed file

pr created time in 19 days

create barnchmicrosoft/TypeScript

branch : nestedConditionalTypes

created branch time in 19 days

pull request commentmicrosoft/TypeScript

Use objects instead of closures for type mappers

@typescript-bot perf test this

ahejlsberg

comment created time in 20 days

push eventmicrosoft/TypeScript

Anders Hejlsberg

commit sha 979bc6a2d5235ab1e196084057d0337185a6bfd6

Flatten combined type mappers

view details

push time in 20 days

pull request commentmicrosoft/TypeScript

Use objects instead of closures for type mappers

@typescript-bot perf test this

ahejlsberg

comment created time in 20 days

PR opened microsoft/TypeScript

Use objects instead of closures for type mappers

Experiment for now.

+54 -42

0 comment

2 changed files

pr created time in 20 days

create barnchmicrosoft/TypeScript

branch : typeMappersAsObjects

created branch time in 20 days

push eventmicrosoft/TypeScript

Anders Hejlsberg

commit sha d62f677807eeced55aed7fbc3a3dad2fb9674c9f

Also loop for instantiations with checkType=any

view details

push time in 20 days

pull request commentmicrosoft/TypeScript

Various optimizations in type instantiation

@typescript-bot run dt @typescript-bot test this

ahejlsberg

comment created time in 20 days

pull request commentmicrosoft/TypeScript

Various optimizations in type instantiation

@typescript-bot perf test this

ahejlsberg

comment created time in 20 days

push eventmicrosoft/TypeScript

Anders Hejlsberg

commit sha 33f20adfabf549ef19acd67a59b7f60325dc692a

Optimize instantiation of conditional types

view details

push time in 20 days

pull request commentmicrosoft/TypeScript

Various optimizations in type instantiation

@typescript-bot perf test this

ahejlsberg

comment created time in 21 days

push eventmicrosoft/TypeScript

Anders Hejlsberg

commit sha 7eeb6001995e2aad5d08df9467b88c50e4962ca3

Accept new baselines

view details

push time in 21 days

PR opened microsoft/TypeScript

Various optimizations in type instantiation

Experiment for now.

+34 -26

0 comment

3 changed files

pr created time in 21 days

create barnchmicrosoft/TypeScript

branch : optimizeInstantiation

created branch time in 21 days

push eventmicrosoft/TypeScript

Anders Hejlsberg

commit sha 8a0b8822b20eab9737eb9b0bbf862a5a1a6ad5c8

Fix contextually typed parameter issues (#36476) * Fix multiple issues with contextually typed parameters * Accept new baselines * Fix lint error * Add tests * Address CR feedback * Add fourslash tests

view details

push time in 23 days

PR merged microsoft/TypeScript

Reviewers
Fix contextually typed parameter issues

This PR fixes multiple issues related to contextually typed parameters:

  • Previously we'd consider a parameter of a function expression, arrow function, or object literal method to be contextually typed if any contextual type could be found for the function. We now consider a parameter to be contextually typed only if the contextual type of the function provides a call signature and that call signature has a parameter in the corresponding position.
  • Previously, in checkFunctionExpressionOrObjectLiteralMethod, we'd only assign types to contextually sensitive parameters if a contextual type was found. We now always assign types to contextually sensitive parameters, thus also recording the fact that there was no contextual type. This matters because different phases of overload resolution may change the contextual type, causing inconsistent results depending on when the type of a parameter is resolved. For example, we might see different types in quick info vs. batch compilation.

Some examples:

const f1 = (x = 1) => 0;  // x: number
const f2: any = (x = 1) => 0;  // x: number (previously implicit any error)
const f3: unknown = (x = 1) => 0;  // x: number (previously implicit any error)
const f4: Function = (x = 1) => 0;  // x: number (previously implicit any error)
const f5: (...args: any[]) => any = (x = 1) => 0;  // x: any
const f6: () => any = (x = 1) => 0;  // x: number (previously any)
const f7: () => any = (x?) => 0;  // Implicit any error (previously any and no error)
const f8: () => any = (...x) => 0;  // x: []

declare function memoize<F extends Function>(func: F): F;

// Type (x: number, y?: number) => number
const add = (x: number, y = 0): number => x + y;

// Type (x: number, y?: number) => number
const memoizedAdd1 = memoize(add);

// Type (x: number, y?: number) => number (previously implicit any error on y)
const memoizedAdd2 = memoize((x: number, y = 0): number => x + y);

Related to this PR, I discovered an issue caused by #25937 and #31574:

declare function foo<T>(obj: T, settings: (row: T) => { value: string, func?: Function }): void;

foo(new Error(),
    o => ({
        value: o.name,
        func: x => 'foo'
    })
);

Above, hovering over the call to foo correctly shows T was inferred as Error, but hovering over o shows type any because of a circularity error (which isn't displayed by quick info). The issue is caused by code in #31574 that I have now removed. Furthermore, I have restricted the functionality introduced by #25937 to only kick in for parameterless arrow functions (because the functionality is safe only so long as there are no parameters that can be referenced in the return type).

Fixes #28816. Fixes #30840. Fixes #36052.

+861 -179

11 comments

11 changed files

ahejlsberg

pr closed time in 23 days

more