The most significant change here is that explorer now uses the chosen spelling
rather than the old `Bool` spelling. Also update a few documentation examples
and some skeletal design docs to use the chosen spelling.
Basic support for declaring, specifying the values of, and using associated constants.
This is incomplete in various ways. For example, when checking whether a type satisfies a constraint, there is no check that its associated constants match those in the constraint, and name lookup into a value whose type is an associated constant is not supported yet.
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
This causes compile-time evaluation to give the same result as runtime
evaluation wherever possible. In particular, referencing a generic
parameter at compile time will resolve to the actual value if we're
evaluating a call to the enclosing function so a value for the
parameter is available in the call frame.
Clean up recently-added support for `SymbolicWitness`es using this.
This renames `Witness` to `ImplWitness` and adds a new form, `SymbolicWitness`, that holds an expression by which a witness can be computed. A common base class `Witness` is provided.
We form the new kind of witness when evaluation of a witness expression fails because the witness is not in scope, as happens when evaluating a subexpression such as a type expression in isolation, and retry evaluation in the larger context when the interpreter performs type instantiation when running the code.
This allows us to properly handle compile-time evaluation of constructs involving witness table lookups when the witness can be statically determined. The intent is that we will eventually also form symbolic witness table references when impl selection finds a non-final witness, in order to support specialization.
Simplify `NominalClassValue`: it can now always store a witness map rather than either a witness map or a witness-or-witness-expression map.
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.
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
pk19604014
josh11bandJon Meow