Build constraint types from `where` expressions. This is very bare-bones; there's no support for constraining `.Self` or associated types yet, but degenerate cases not involving self-reference work.
`==` constraints are syntactically supported but not semantically verified yet, and they aren't used for anything.
The syntax permitted in an `interface` is similar to, but different from, that permitted elsewhere. For example, associated constant declarations (`let T:! Type;`) with no initializers are valid in interfaces but nowhere else, and are a different kind of declaration from what a normal `let` declaration would produce both syntactically and semantically.
Because interfaces and impls permit only a very small subset of the complete set of kinds of declaration, it's simpler to list only the kinds that are permitted rather than to allow an arbitrary declaration and semantically disallow the invalid cases, and it's also likely to lead to better error messages as we won't try to parse unintended or meaningless things.
* added documentation for tracing output, changed the printing of scopes to be part of the stack, made other minor changes hoping to enhance readability
* reformat a list in the README
* minor edit
* fix the lists
* updates to the interpreter/README.md
Add scaffolding for constraints in general, and support specifically constraints formed by applying a `&` operator.
No support for constraints formed with `where` nor for named constraints at this point.
* Implement addr keyword
* Add files that were deleted during merge
Some files got deleted during merging trunk because of the executable
semantics rename.
* Implement changes from code review.
Major changes:
- Rename AddrBindingPattern to AddrPattern
- Fix AddrPattern related changes in fuzzing
* Update documentation for GetField
* Fix AddPattern according to @zygoloid's suggestions
* Apply @zygoloid's changes to method comment
* Add a multi-component field example
* Incorporate AST changes to fuzzer corpus
* Refactor the deduced_param_list grammar rule
Suggested by @zygoloid
Support is added for all of the non-type expression contexts where we currently accept built-in conversions, such as reordering the fields in a struct.
Prepend the generic class's list of parameters onto the `impl`'s list of
deduced parameters, and add the `impl` to the impl scope enclosing the
class rather than adding it to the impl scope for the class body.
When matching an impl, deduce against both the type and the interface.
This incidentally slightly improves support for nested classes in generic classes, because they have some of the same properties as `impl`s nested in generic classes, but that's still a fair way from working for various unrelated reasons.
This supports aliases for types (including interfaces), functions, parameterized types, instance member names, and interface member names.
Co-authored-by: Jon Meow <jperkins@google.com>
Implement initial support for `A.(B)` syntax, per #989. Specifically, this supports:
* `object.(Type.member)` for instance members,
* `object.(Interface.member)` for instance and non-instance members,
* `object.(Type.(Interface.member))` for instance members,
* `Type.(Interface.member)` for non-instance members.
Three new AST nodes are introduced:
* `CompoundFieldAccessExpression` represents the `A.(B)` syntax.
* `MemberName` is a `Value` that represents the result of evaluating an expression such as `Type.member` or `Interface.member` or `Type.(Interface.member)`.
* `TypeOfMemberName` is the type of a `MemberName` value.
In order to handle members of classes and interfaces which have corresponding declarations and may need substitution into their types, and members of structs which don't have declarations but also don't need substitution, a class `Member` is introduced that can refer to either of these kinds of member.
Co-authored-by: Geoff Romer <gromer@google.com>
Co-authored-by: Jon Meow <jperkins@google.com>
In order for this to work, we need to always use the argument deduction code path for function calls, instead of only using it when there is a `[...]` list, which means that argument deduction now needs to support implicit conversion.
Co-authored-by: Jon Meow <jperkins@google.com>
- Makes `Self` a keyword
- Inside `class Foo { `... `}`, `Self` means `Foo`
- Inside `class Foo(T:! Type, U:! Type) {` ...` }`, `Self` means `Foo(T, U)`
- `impl as Bar` means `impl Self as Bar`
- Inside `external impl Foo as Bar {`...`}`, not in a scope already defining `Self`, `Self` means `Foo`
Implemented by introducing a new kind of declaration, a `SelfDeclaration`, that is automatically added to class and impl declarations.
Co-authored-by: Jon Meow <jperkins@google.com>
Previously we modeled these as being class types or interface types, with special case checks to treat them as not actually being class or interface types.
Use FileCheck's `[[@LINE+n]]` mechanism to refer to the next line.
This is made awkward by a couple of things:
* We want to keep the `CHECK` lines in the original order.
* Errors are sometimes more than one line long.
The approach we use is to interleave the original lines and the check lines, putting each check line as early as possible subject to two rules:
1) Check lines never precede the 'AUTOUPDATE' line
2) Except when required by rule (1), a check line that refers to a source line by line number is never placed earlier than a source line that precedes that source line.
The actual `[[@LINE+n]]` annotations are created in a second pass after we've interleaved the lines so that we can work out the correct offsets.
Co-authored-by: Jon Meow <jperkins@google.com>
Richard Smith
Jeremy G. Siek
pk19604014
Jonathan Ross-Perkins
Darshal Shetty
josh11bandJon Meow