* Make `field_list` always a list.
* Create separate `paren_expression` and `tuple` nonterminals
* Rename expression_or_field_list.* to field_list.*
Co-authored-by: Jeremy G. Siek <jsiek@indiana.edu>
* improve abstraction for AssocList, fix bug in optional else
* add flag for tracing output, clean up code for output
* turned off tracing by default, updated goldens, removed two examples that use pointers, shouldn't have been there yet
* Add assertion to detect UB in interpreter.cpp
This change, applied to 6e5070d ("Adapting jsiek's executable semantics tooling
for commit. (#237)"), causes the if2.6c test to segfault. Becase the assertion
fires only when `stmt == nullptr` and no code has permission to change `stmt`
(it is `const`) before it is dereferenced in the `switch`, and nothiing in
`PrintStatement` is supposed to exit the program, the assertion is a valid
change that detects a bug.
The crash was originally manifest in 29a5994 ("Executable Semantics: 1st-class
stacks (#296)").
* Temporarily disable the if2 test pending #311
See https://github.com/carbon-language/carbon-lang/issues/311
* [executable semantics] Record exit code on expected error.
This will prevent a final segfault from sneaking by, detected as a passing test.
A more principled follow-up commit would bottleneck detected error exit
reporting and have it write something to std::cerr that can be recognized.
This makes executable semantics build and pass tests for me without
installing either Bison or Flex. We just use the primitive toolchain
with the existing genrule as the packaged rules don't quite fit how
we're building and organizing the code.
Currently, this points at forks of the upstream rule repositories while
PRs I have sent there are going through, but this should be functional
for now and there doesn't seem to be any reason to wait for those PRs to
go through.
Notes versus what jsiek wrote:
- This adopts Bazel for building.
- System-local versions of bison/flex are used. I found https://github.com/jmillikin/rules_bison, but those print a lot of warnings (things like -Wsign-compare IIRC) which makes builds hard to read. Plus I think the underlying bison_cc_library rule didn't work, so this would really only get a hermetic bison/flex build (helpful, but didn't seem worth more time).
- I'm adding in a .bazeliskrc to push a somewhat more standard choice of bazel versions. I noticed I was getting unstable versions by default, possible Google-specific, but seemed good to include.
- The `-lpthread` kludge.
- Turn all of the examples into golden tests.
- Including adding a golden test rule.
- Fixed various style guide issues. For example:
- Fixing function names to be CamelCase instead of snake_case (https://google.github.io/styleguide/cppguide.html#Function_Names)
- Removed exception use (https://google.github.io/styleguide/cppguide.html#Exceptions)
- File name fixes (https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/cpp_style_guide.md#file-names)
- Dropped `using` of `std` names -- I believe this is preferred (maybe we should be explicit about this in the Carbon style guide)
- Switched `enum` uses to `enum class` for ease-of-identification.
- Spent some time breaking out files to hopefully be easier to read/edit pieces, and understand relations between structs.
- Added `code requires` to `syntax.ypp` to address include issues
Possibly other things -- but the fundamental structure is, I believe, unchanged. I put in the golden tests pretty early to ensure I wasn't mutating output/results.
Dave Abrahams
Geoff RomerandJeremy G. Siek
Chandler Carruth
Jon Meow