Also make minor updates to the skeletal design in
docs/design/name_lookup.md following #2113, as there are no longer any prelude names that are made available to unqualified name lookup by default.
Add `type` to the keyword list in
docs/design/lexical_conventions/words.md, following #2360.
Features:
* Add basic support for `impl` virtual methods (override virtual method)
* Error on invalid declaration for `impl` and `virtual`, covering simple use cases
* Add `abstract` fn parser-only support
Changes:
* Modify parser to handle new function specifiers, resolve conflicts
* Group `virtual_override` and `FN`, and group `impl_kind` and `IMPL` to avoid ambiguities with around `impl` token parsing
* Add new `VirtualOverride` enum for function declarations, and matching `virt_override() -> VirtualOverride` getter
* Update function declaration logic
Depends on #2462
Features:
* Add `virtual` virtual override keyword for functions
* Support `virtual` class methods using dynamic dispatch
Changes:
* Add `vtable` in `NominalClassType`,
* Add `NominalClassValue**` in class values pointing to descendant-most class
* Resolve virtual methods during member lookup
Limitations:
* Does not include yet `impl`, `abstract` virtual override keywords, or the complete logic for virtual function declaration
Depends on #2460
Relates to #1881
Relates to #2493
In particular, this means that a type can implement `ImplicitAs(Type)` and have values of that type behave like types.
This implies that `()` and `{}` are no longer types. They are now values whose type is the result of converting `()` or `{}` to type `Type`, as has been discussed recently and seems to be the supported direction. This fixes various cases where these types were previously mishandled.
Adds a simple script to merge stdout/stderr and put on labels. This is hidden to the RUN line using lit.cfg.py.
This is my solution to addressing how errors printed by the toolchain break sorting of stdout output; just put stdout first. We could also have toggles for interleaving output or such, which might help test whether we do it properly.
This also moves some previous-distributed replacement logic into lit_autoupdate_base.py: I think having that adjacent to lit.cfg.py is probably the better choice, and it reduces duplication in toolchain scripts. It happens here because I need to change the resulting commands to include the merge.
On #2224 @zygoloid pointed out we needed --implicit-check-not to ensure we were correctly matching output. This is the standard way we're writing explorer tests, so I was looking at unifying our lit approaches.
This is one take on it, making more use of substitutions to bring various testing into alignment, as well as symlinks to avoid config skew (maybe I'll eventually figure out a better solution than symlinks).
Makes a couple small fixes in explorer to remove end-of-line whitespace on output.
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 works by splitting the constraint up into interfaces and checking
that each of them is implemented in turn.
Also check that the parameters of the impl are deducible from each of
the resulting (type, interface) pairs.
* initial implementation of new and delete
* remove requirement for empty heap from trace.carbon
* more tests
* fixed substitution for generic function types
This change updated a test to use a different example to make sure a
diagnostic was still being exercised, but as a consequence lost test
coverage of the situation the test was originally intended to cover.
Add back the old test and put the new test into a different file.
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.
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.
- 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
Adrien Leravat
josh11b
Jon Ross-Perkins
micttyl
Jeremy G. Siek
pk19604014