This follows #1274 and #1325 and fills in the "safety" section. It only covers our approach in general terms.
Co-authored-by: Chandler Carruth <chandlerc@gmail.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 follows #1274 . It mainly fills in the "generics" section, with smaller updates to other section.
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
* initial implementation of new and delete
* remove requirement for empty heap from trace.carbon
* more tests
* fixed substitution for generic function types
Prior to this change, the section headings for the 7 main goals are visually indistinguishable (in GitHub's rendering) from the boldfaced paragraph headings in those sections. This makes the doc hard to navigate because the structure is hidden.
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.
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.
Reorganizes the sections, and makes a pass filling in and updating the first sections including: types, functions, user-defined types. The following sections are left for part 2, including names, generics, and interop.
Also some smaller updates to, not revisiting the text: `pattern_matching.md`, `control_flow/return.md`, and `lexical_conventions/numeric_literals.md`
Co-authored-by: Geoff Romer <gromer@google.com>
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
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
Tiny nit: Line 63 similarly links "modern generics system". Line 250 links 'generics', but doesn't include "modern ... system." So I think this approach is consistent (and subtly, implies the link is about the modern ... system, not just "generics").
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.
Some review feedback from outside the team directly working on Carbon suggested
two pretty significant updates here. First, we didn't do a good job of
motivating Carbon. This takes two parts, first explaining what we'd like to
accomplish with this approach generally, and second explaining why alternative
approaches don't work. A particularly difficult case here is articulating
effectively the difficulties that motivate an approach other than improving C++
incrementally.
Co-authored-by: Jon Meow <jperkins@google.com>
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
* 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
This is to help with frequent build breakages cased by proto changes.
Fuzzer corpus can be periodically auto-regenerated.
Crashing samples from the fuzzer are better 'preserved' in the form of fail_xx.carbon tests.
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>
josh11bandChandler Carruth
Richard Smith
Jeremy G. Siek
Jon Ross-Perkins
pk19604014
Darshal Shetty