Skip to content

Migrated decorator checks to call resolution#3249

Merged
rbuckton merged 7 commits into
masterfrom
resolveDecoratorAsCall
Jun 24, 2015
Merged

Migrated decorator checks to call resolution#3249
rbuckton merged 7 commits into
masterfrom
resolveDecoratorAsCall

Conversation

@rbuckton
Copy link
Copy Markdown
Contributor

Rather than checking assignability, I've instead added a resolveDecorator function which acts in a similar fashion to resolveTaggedTemplateExpression and resolveCallExpression, and I resolve the decorator as a call.

Unlike a regular call expression, a decorator would be resolved using a set of synthetic arguments based on the target being decorated. This is similar to how call resolution works for a TaggedTemplateExpression, which injects a synthetic TemplateStringsArray type as the first argument.

I pulled out this synthetic argument from checkApplicableSignature and added it and the generation of synthetic arguments for decorators to a getSyntheticArgumentType function.

This fixes #3246, as well as some other cases where we were doing the wrong thing when checking decorators.

@rbuckton rbuckton mentioned this pull request May 22, 2015
Comment thread src/compiler/utilities.ts Outdated
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.

Just make this a CallExpression | Decorator cast.

@DanielRosenwasser
Copy link
Copy Markdown
Member

We should have a couple of funky little tests like this:

type ClassDecoratableWhenTagged = (ts: TemplateStringsArray, ...blah: any[]) => ClassDecorator;

declare let tag: ClassDecoratableWhenTagged;

@tag `Implicit call resolution in call resolution makes me feel ${ "extremely" } dizzy.`
class C {
    constructor() { 
    }
}

Comment thread src/compiler/checker.ts Outdated
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.

Sorry, the part that I originally found "gross" was that this call was ever in the if in the first place, not your changes; now that you've moved the parameter out though, it's at least a lot cleaner.

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.

Use of decorator factories as decorators is not flagged as an error

5 participants