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

Use discriminated unions for node categories #18285

Closed

Conversation

weswigham
Copy link
Member

@weswigham weswigham commented Sep 6, 2017

As mentioned in this comment, we can remove a lot of casts by using a discriminated union for Node. This does so, and should be considered a breaking change as such. This only removes casts from locations which needed to be changed due to invalid casts/new required casts - many unneeded casts still remain and can be removed mechanically.

While this should not affect our runtime performance (as it just changes our types, mostly) this does cause us to take significantly longer to compile ourselves. I hope that if it is not acceptably fast that this can drive us to make the features slowing this down faster, as we really want the extra safety offered by discrimination and exhaustiveness checks.

@weswigham weswigham added the Breaking Change Would introduce errors in existing code label Sep 6, 2017
@ajafff
Copy link
Contributor

ajafff commented Sep 7, 2017

Fixes #13634

export type BinaryOperatorToken = Token<BinaryOperator>;

export interface BinaryExpression extends Expression, Declaration {
export type BinaryOperatorToken =
Copy link

Choose a reason for hiding this comment

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

Don't see why we need unions for the tokens; it would be easier to write Token<BinaryOperator>.

Copy link
Member Author

Choose a reason for hiding this comment

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

Token is not assignable to the union of all tokens of the binary operator kinds because we do not multiply out/canonicalize unions prior to comparison checking. As such, it must be written this way to work around that.

Copy link

@ghost ghost Sep 7, 2017

Choose a reason for hiding this comment

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

I actually tried this out myself and it compiled successfully. We're not depending anywhere on discriminating a Token by its kind; the only thing that matters is the kind and they're otherwise identical.

@ghost
Copy link

ghost commented Sep 7, 2017

This branch takes 156 seconds to run gulp local; master takes 59 seconds which is already far too long. (This is on my 16GB power-hungry workstation; on my laptop it is even longer.) I think we should fix our build system before adding anything more to our already large compile times. It's not going to be easy to make performance improvements if it takes so long to test out a simple change.

Migration WIP

More betterness

Unions, unions everywhere

Full type action

Finish updating services layer

Just change the type
weswigham added a commit that referenced this pull request Oct 11, 2017
Found while updating #18285 to latest master. Not sure what this fixes, but it was definitely incorrect - `node` must be a `Block` at this point, so this cast must have been intended for `node.parent`, which was checked against `TryStatement` right before it.
weswigham added a commit that referenced this pull request Oct 11, 2017
Found while updating #18285 to latest master. Not sure what this fixes, but it was definitely incorrect - `node` must be a `Block` at this point, so this cast must have been intended for `node.parent`, which was checked against `TryStatement` right before it.
@mhegazy
Copy link
Contributor

mhegazy commented Nov 9, 2017

We have captured this as a test already. I will keep the branch for experimentation, but closing the PR since we have no plans to do this in the short/medium term.

@mhegazy mhegazy closed this Nov 9, 2017
@weswigham
Copy link
Member Author

I'll be monitoring the perf of the capture and when it becomes subjectively acceptable, I will propose it again. 🌞

@microsoft microsoft locked and limited conversation to collaborators Jun 14, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Breaking Change Would introduce errors in existing code
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants