diff options
| author | Tim Foley <tfoley@nvidia.com> | 2017-10-30 08:54:09 -0700 |
|---|---|---|
| committer | Tim Foley <tfoley@nvidia.com> | 2017-10-30 09:40:04 -0700 |
| commit | 42f1cff5c1471e6bc3988a9810c20b8bcc1c84dd (patch) | |
| tree | 95ce50d87fb26c7cc2f41e6afd518cfab6a91ef9 /docs/api-users-guide.md | |
| parent | 4ab545bcd0716cc3f2da432a921c1f53fdce7925 (diff) | |
Support explicit `this` expressions
This is the first step towards supporting traditional object-oriented method definitions; the second step will be to allow `this` expressions to be implicit.
- Add a test case using explicit `this`, and expected output
- Update parsing logic for expressions so that it handled identifiers similarly to the declaration and statement logic: first try to parse using a syntax declaration looked up in the curent scope, and otherwise fall back to the ordinary `VarExpr` case.
* As long as I'm making that change: switch `true` and `false` to be parsed via the callback mechanism rather than be special-cased.
* This change will also help out if we ever wanted to add `super`/`base` expressions, `new`, `sizeof`/`alignof` or any other expression keywords.
- Add a `ThisExpr` node and register a parser callback for it.
- Add semantic checks for `ThisExpr`: basically just look upwards through scopes until we find either an aggregate type declaration or an `extension` declaration, and then use that as the type of the expression.
- TODO: eventually we need to guard against a `this` expression inside of a `static` member.
- The IR generation logic already handled creation of `this` parameters in function signatures; the missing piece was to register the appropriate parameter in the context, so that we can use it as the lowering of a `this` expression.
Diffstat (limited to 'docs/api-users-guide.md')
0 files changed, 0 insertions, 0 deletions
