Skip to content

Fixed const reverse mapped types themselves to be treated as const - #55794

Merged
Wesley Wigham (weswigham) merged 3 commits into
microsoft:mainfrom
Andarist:fix/const-reverse-mapped-types
Nov 27, 2023
Merged

Fixed const reverse mapped types themselves to be treated as const#55794
Wesley Wigham (weswigham) merged 3 commits into
microsoft:mainfrom
Andarist:fix/const-reverse-mapped-types

Conversation

@Andarist

Copy link
Copy Markdown
Contributor

No description provided.

// @strict: true
// @noEmit: true

declare function test1<const T>(obj: {

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

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

The first 3 test cases are testing objects and how readonly, -readonly, and lack of them impact the T and the fresh object that is created by mapping over T.

Those objects today would be constified for the most part but their properties wouldn't always be marked as readonly when they should be. When readonly modifier is used on the mapped type then that result (typeof obj) hasreadonly properties but the const type parameter itself doesn't have them. This is consistent with #12589 . You might also want to recheck when/how readonly is preserved/stripped on members of the reverse mapped type here

[K in keyof T]: T[K];
}): T;

const result4 = test4(["1", 2]);

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

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

This is an especially important part of the fix. Currently T is inferred as (2 | "1")[] but it really should be readonly ["1", 2]

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

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

There are also some other test cases that I'd like to add here but I'm not entirely sure what should be the expected results for them

  1. const T, P extends keyof T - this might iterate over P which might be the subset of keyof T. Should we still assign constness to T in such a case? See the playground TS playground. Note that it's not really possible to gather P across from different mapped types and somehow different mapped type to build up a "combined" reverse mapped type: TS playground
  2. K in keyof T | "extra" - what should happen with a non-homomorphic case like this? TS playground

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

  1. Probably? I'm not a huge fan of overuse of const type variables, but if they're in-use, there a strong signal that const-ness is desired somewhere related to that type parameter. The workflow is usually "does this do what I want? No? Add a const.", so the const normally only gets added by people if it's meant to be meaningful to inference.
  2. Eh, I'd leave that as whatever it falls out as from being not homomorphic. It'll get unified if and when we ever adjust the logic to consider something like that as homomorphic-enough to get the homomorphic type variable treatment.

@weswigham

Copy link
Copy Markdown
Member

@typescript-bot

TypeScript Bot (typescript-bot) commented Oct 4, 2023

Copy link
Copy Markdown
Contributor

Heya Wesley Wigham (@weswigham), I've started to run the diff-based top-repos suite on this PR at d6d1604. You can monitor the build here.

Update: The results are in!

@typescript-bot

TypeScript Bot (typescript-bot) commented Oct 4, 2023

Copy link
Copy Markdown
Contributor

Heya Wesley Wigham (@weswigham), I've started to run the parallelized Definitely Typed test suite on this PR at d6d1604. You can monitor the build here.

Update: The results are in!

@typescript-bot

TypeScript Bot (typescript-bot) commented Oct 4, 2023

Copy link
Copy Markdown
Contributor

Heya Wesley Wigham (@weswigham), I've started to run the regular perf test suite on this PR at d6d1604. You can monitor the build here.

Update: The results are in!

@typescript-bot

Copy link
Copy Markdown
Contributor

Wesley Wigham (@weswigham)
The results of the perf run you requested are in!

Here they are:

Compiler

Comparison Report - baseline..pr
MetricbaselineprDeltaBestWorstp-value
Angular - node (v18.15.0, x64)
Memory used295,072k (± 0.01%)295,055k (± 0.01%)~295,015k295,102kp=0.575 n=6
Parse Time2.63s (± 0.81%)2.64s (± 0.28%)~2.63s2.65sp=0.368 n=6
Bind Time0.84s (± 0.90%)0.84s (± 1.23%)~0.83s0.85sp=0.664 n=6
Check Time8.05s (± 0.26%)8.06s (± 0.17%)~8.05s8.09sp=0.279 n=6
Emit Time7.04s (± 0.29%)7.03s (± 0.34%)~7.00s7.07sp=0.224 n=6
Total Time18.57s (± 0.20%)18.57s (± 0.15%)~18.55s18.61sp=0.870 n=6
Compiler-Unions - node (v18.15.0, x64)
Memory used192,611k (± 1.56%)191,624k (± 1.22%)~190,627k196,408kp=0.378 n=6
Parse Time1.34s (± 1.29%)1.34s (± 0.41%)~1.34s1.35sp=0.154 n=6
Bind Time0.73s (± 0.00%)0.73s (± 0.00%)~0.73s0.73sp=1.000 n=6
Check Time9.19s (± 0.68%)9.21s (± 0.66%)~9.17s9.33sp=0.617 n=6
Emit Time2.64s (± 0.50%)2.63s (± 0.67%)~2.60s2.64sp=0.266 n=6
Total Time13.90s (± 0.36%)13.91s (± 0.47%)~13.86s14.04sp=0.872 n=6
Monaco - node (v18.15.0, x64)
Memory used347,287k (± 0.01%)347,303k (± 0.00%)~347,288k347,315kp=0.108 n=6
Parse Time2.46s (± 0.31%)2.46s (± 0.31%)~2.45s2.47sp=1.000 n=6
Bind Time0.94s (± 0.00%)0.94s (± 0.00%)~0.94s0.94sp=1.000 n=6
Check Time6.88s (± 0.44%)6.89s (± 0.61%)~6.83s6.95sp=1.000 n=6
Emit Time4.02s (± 0.49%)4.03s (± 0.37%)~4.01s4.05sp=0.373 n=6
Total Time14.30s (± 0.27%)14.31s (± 0.36%)~14.25s14.40sp=0.808 n=6
TFS - node (v18.15.0, x64)
Memory used302,537k (± 0.01%)302,552k (± 0.00%)~302,548k302,556kp=0.172 n=6
Parse Time2.00s (± 0.80%)2.00s (± 0.66%)~1.98s2.02sp=0.801 n=6
Bind Time1.00s (± 0.75%)1.00s (± 0.81%)~1.00s1.02sp=1.000 n=6
Check Time6.24s (± 0.33%)6.26s (± 0.22%)~6.24s6.28sp=0.142 n=6
Emit Time3.57s (± 0.49%)3.58s (± 0.42%)~3.56s3.59sp=0.933 n=6
Total Time12.82s (± 0.18%)12.84s (± 0.32%)~12.80s12.90sp=0.629 n=6
material-ui - node (v18.15.0, x64)
Memory used470,506k (± 0.00%)470,520k (± 0.00%)~470,481k470,552kp=0.173 n=6
Parse Time2.57s (± 0.52%)2.57s (± 0.53%)~2.55s2.59sp=0.452 n=6
Bind Time0.99s (± 0.76%)1.00s (± 1.21%)+0.01s (+ 1.52%)0.99s1.02sp=0.045 n=6
Check Time16.62s (± 0.26%)16.66s (± 0.36%)~16.60s16.76sp=0.227 n=6
Emit Time0.00s (± 0.00%)0.00s (± 0.00%)~0.00s0.00sp=1.000 n=6
Total Time20.18s (± 0.26%)20.24s (± 0.35%)~20.16s20.36sp=0.148 n=6
xstate - node (v18.15.0, x64)
Memory used512,588k (± 0.02%)512,567k (± 0.01%)~512,502k512,669kp=0.873 n=6
Parse Time3.27s (± 0.17%)3.27s (± 0.47%)~3.24s3.28sp=0.859 n=6
Bind Time1.55s (± 0.48%)1.55s (± 0.41%)~1.54s1.56sp=0.718 n=6
Check Time2.87s (± 0.68%)2.89s (± 0.68%)~2.85s2.91sp=0.193 n=6
Emit Time0.08s (± 5.21%)0.08s (± 4.99%)~0.08s0.09sp=0.218 n=6
Total Time7.77s (± 0.26%)7.78s (± 0.27%)~7.75s7.81sp=0.518 n=6
System info unknown
Hosts
  • node (v18.15.0, x64)
Scenarios
  • Angular - node (v18.15.0, x64)
  • Compiler-Unions - node (v18.15.0, x64)
  • Monaco - node (v18.15.0, x64)
  • TFS - node (v18.15.0, x64)
  • material-ui - node (v18.15.0, x64)
  • xstate - node (v18.15.0, x64)
BenchmarkNameIterations
Currentpr6
Baselinebaseline6

tsserver

Comparison Report - baseline..pr
MetricbaselineprDeltaBestWorstp-value
Compiler-UnionsTSServer - node (v18.15.0, x64)
Req 1 - updateOpen2,396ms (± 1.25%)2,384ms (± 1.57%)~2,331ms2,427msp=0.422 n=6
Req 2 - geterr5,330ms (± 1.38%)5,324ms (± 1.42%)~5,276ms5,476msp=0.688 n=6
Req 3 - references329ms (± 0.68%)331ms (± 1.60%)~326ms338msp=0.685 n=6
Req 4 - navto278ms (± 1.31%)278ms (± 0.80%)~274ms280msp=0.607 n=6
Req 5 - completionInfo count1,356 (± 0.00%)1,356 (± 0.00%)~1,3561,356p=1.000 n=6
Req 5 - completionInfo77ms (± 8.20%)78ms (± 7.79%)~75ms90msp=0.356 n=6
CompilerTSServer - node (v18.15.0, x64)
Req 1 - updateOpen2,472ms (± 1.17%)2,485ms (± 1.20%)~2,427ms2,507msp=0.298 n=6
Req 2 - geterr4,132ms (± 1.87%)4,087ms (± 1.45%)~4,058ms4,207msp=0.470 n=6
Req 3 - references338ms (± 1.62%)340ms (± 1.31%)~333ms343msp=1.000 n=6
Req 4 - navto284ms (± 0.43%)285ms (± 0.29%)~284ms286msp=0.276 n=6
Req 5 - completionInfo count1,518 (± 0.00%)1,518 (± 0.00%)~1,5181,518p=1.000 n=6
Req 5 - completionInfo81ms (± 7.72%)83ms (± 7.14%)~75ms87msp=0.438 n=6
xstateTSServer - node (v18.15.0, x64)
Req 1 - updateOpen2,596ms (± 0.44%)2,574ms (± 0.61%)-22ms (- 0.83%)2,561ms2,605msp=0.037 n=6
Req 2 - geterr1,707ms (± 2.50%)1,692ms (± 2.93%)~1,638ms1,741msp=0.470 n=6
Req 3 - references106ms (± 1.10%)114ms (± 8.60%)~106ms127msp=0.054 n=6
Req 4 - navto359ms (± 0.29%)358ms (± 0.65%)~353ms359msp=0.121 n=6
Req 5 - completionInfo count2,071 (± 0.00%)2,071 (± 0.00%)~2,0712,071p=1.000 n=6
Req 5 - completionInfo308ms (± 1.27%)304ms (± 3.13%)~295ms315msp=0.629 n=6
System info unknown
Hosts
  • node (v18.15.0, x64)
Scenarios
  • CompilerTSServer - node (v18.15.0, x64)
  • Compiler-UnionsTSServer - node (v18.15.0, x64)
  • xstateTSServer - node (v18.15.0, x64)
BenchmarkNameIterations
Currentpr6
Baselinebaseline6

Startup

Comparison Report - baseline..pr
MetricbaselineprDeltaBestWorstp-value
tsc-startup - node (v18.15.0, x64)
Execution time152.28ms (± 0.18%)152.41ms (± 0.20%)+0.13ms (+ 0.09%)151.16ms155.20msp=0.000 n=600
tsserver-startup - node (v18.15.0, x64)
Execution time227.78ms (± 0.18%)227.71ms (± 0.16%)-0.08ms (- 0.03%)226.43ms233.07msp=0.018 n=600
tsserverlibrary-startup - node (v18.15.0, x64)
Execution time228.56ms (± 0.19%)228.61ms (± 0.18%)~226.93ms235.82msp=0.329 n=600
typescript-startup - node (v18.15.0, x64)
Execution time228.80ms (± 0.16%)228.89ms (± 0.19%)~227.15ms237.69msp=0.100 n=600
System info unknown
Hosts
  • node (v18.15.0, x64)
Scenarios
  • tsc-startup - node (v18.15.0, x64)
  • tsserver-startup - node (v18.15.0, x64)
  • tsserverlibrary-startup - node (v18.15.0, x64)
  • typescript-startup - node (v18.15.0, x64)
BenchmarkNameIterations
Currentpr6
Baselinebaseline6

Developer Information:

Download Benchmarks

@typescript-bot

Copy link
Copy Markdown
Contributor

Wesley Wigham (@weswigham) Here are the results of running the top-repos suite comparing main and refs/pull/55794/merge:

Everything looks good!

@typescript-bot

Copy link
Copy Markdown
Contributor

Hey Wesley Wigham (@weswigham), the results of running the DT tests are ready.
Everything looks the same!
You can check the log here.

@sandersnNathan Shively-Sanders (sandersn) added the For Uncommitted Bug PR for untriaged, rejected, closed or missing bug label Oct 25, 2023
Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

For Uncommitted BugPR for untriaged, rejected, closed or missing bug

Projects

Archived in project

Development

Successfully merging this pull request may close these issues.

5 participants

@Andarist@weswigham@typescript-bot@sandersn@ahejlsberg