Provide an initial rough structure for the specification so we can add things
as they are decided.
Split the specification into a language and a library section. In the language
section, use one file per broad area of functionality. Divide the language up
based on the intended layering of the language design.
Roadmap updates for 2022. Key goals:
* Reach the point where the first draft of the core language design is complete, with some test programs and an approximate implementation in executable semantics.
* Go public, and improve public participation.
Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com>
This proposal addresses the question of whether we should perform a fully top-down compilation (like in C), a mostly top-down compilation (like in C++), or whether we should allow information from later in the same source file to be used in earlier program constructs (like in Rust, Swift, Java, C#, Haskell, and so on).
The proposed direction is:
- Entities declared later in the same source file cannot be used earlier; top-down semantics apply everywhere.
- As an exception, class member function bodies are parsed as if they appeared after the class.
- Forward declarations can be used to separate interface from implementation and to allow entities to be used before they are defined.
- The behavior of the program is nonetheless required to be the same as if we had a globally-consistent rule: it's always a hard error to depend on any information that is not known or that is provided later.
Note the use of an enum allows for the operator to be defined for formatting. This reduces the custom formatting required, which is a simplification carrying over to error handling changes I'm working on too.
Also, I kind of feel the code's now clearer about what's supported; I'm dropping CHECKs that seemed redundant with the enum.
* Modify parser and AST nodes to include let statement
* Implement let variables
* Remove redundant code in fail_match_choice test
* Add comment for has_value_category()
* Apply suggestions from code review
Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com>
* clang-format changes
* Update comments for new BindingPattern methods
* Implement nested vars in patterns
* Apply suggestions from @geoffromer's code review
Co-authored-by: Geoff Romer <gromer@google.com>
* Implement changes from code review.
* Remove maybe_var_pattern grammar rule
Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com>
Co-authored-by: Geoff Romer <gromer@google.com>
* Fixed a couple simple crashes surfaced by running a structured fuzzer on executable_semantics parse/type-check/execute logic.
* var a: b: auto; -> var a: auto;
In the process, switch to an unambiguous grammar, using the
precedence-climbing method for operator precedence (suitably modified to
handle a partial precedence order) rather than Bison %precedence /
%prec.
Note I've added a few TODOs, particularly that multi-line strings should only consume until the dedent.
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
There's currently a bug with empty files, in that it initializes SourceBuffer with an invalid StringRef that results in a crash. That got me looking at the std::optional TODO, but the issue is that there are really three states:
- Buffered
- mmapped (not buffered)
- Moved out of (no longer initialized)
Technically an optional could work if we initialize the buffer on move out, indicating the mmap is gone. But the mode setup felt better to me.
And then this also adds the size check. Which is really how I started looking at this.
Support for member access expressions with syntax `container.member`, covering cases such as:
* `object.field`
* `object.method(args)`
* `package.namespace.class.member`
* `object.(interface.member)`
* `object.(class.member)`
... and so on. Includes the rule for template name lookup as decided in #949.
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
I'm wondering if my issue all along was parallel script executions (I reproduced the error message locally with `pre-commit run -a`, and I think in my case that's what happened).
Adding the file size to errors for sanity checking, since part of what had me looking again was checksum mismatches, and actually the parallel execution offers a consistent story there (checksum mismatch due to file being modified by another download mid-stream).
This is intended to be a more iterative edit to the chart:
- Adding `if` and struct literals, since it came up in arithmetic.
- Adding links to address a comment of mine about wanting references
- Rephrasing slightly to reduce the implication that it's only for operators (particularly since I don't think we want to call `if` an operator)
- Shifting operators below because similar
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
I was mainly looking at keywords trying to figure out what needs work and the amount to which it doesn't reflect the design confused me (including some things that we've decided not to include, and some things I'm not aware of discussion about). I figured this cleanup would at least make it somewhat clearer why things are in there.
I'm treating https://github.com/carbon-language/carbon-lang/blob/trunk/docs/design/lexical_conventions/words.md as canonical, with `_` and `xor` as presumably deliberate exceptions. Similarly avoiding symbol tokens because I assume you'll push proposals for the difference.
I dropped the `Keyword` qualifier because `is` makes `IsKeyword` a name conflict, and dropping the qualifier seemed like the more consistent solution (it doesn't do `AmpSymbol`, after all). If we need clarity I might lean towards a separate namespace to avoid naming conflicts.
Moves common script logic into utils.py (not a great name, but couldn't come up with better). This is in particular to make the buildifier.py script really trivial, allowing that pre-commit to be easily added. However, scripts have also been diverging on how we find bazel, so I'm trying to unify that.
The advantage of reimplementing buildifier's pre-commit is that (a) we can now run buildifier server-side, and (b) we can stop advising installing it manually. Then the only Linux-specific package manager is Cargo, which is only used for watchman, which is optional -- so stop highlighting Linux-specific package managers in the tool instructions.
Line 91 has:
```
source_loc_(type_expression->source_loc()) {}
```
Which requires the Expression definition. This probably compiles accidentally due to #include ordering, but I ran into a case that needs correct #includes.
Jon Meow
josh11b
Richard Smith
pk19604014
Richard Smith
