We switched to the released version to minimize rebuildds of the
toolchain, but with downloading the toolchain this isn't a significant
issue any more. And without this, Bazel doesn't run on ARM macOS.
This may hit issues with broken Bazel builds and have to be reverted.
Added a TODO to reverse this as soon as we can anyways.
Also cleans up the old `.bazelversion` in favor of just using
`.bazeliskrc`. They both work, but the RC file comes first in the
sequence so happy to prefer it here.
* add command-line flag to enable/disable tracing output
* adding missing exit for pattern variable in wrong context and a test case for it (#324)
* Update executable_semantics/interpreter/interpreter.cpp
comment on separate line as code
Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com>
* fix interpreter's handling of optional else of if statement (#323)
* Update pattern_variable_fail.golden due to error (#334)
* Use llvm's CommandLine for parsing (#332)
* GitHub testing action (#331)
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
* add copyright
* Create a Dictionary abstraction over the raw Cons list. (#327)
* Create a Dictionary abstraction over the raw Cons list.
* renamed Cons and some methods of Dictionary, various other cleanup
* Update executable_semantics/tracing_flag.cpp
added namespace comment
Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com>
* added a comment to cpp file
Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com>
Co-authored-by: Dave Abrahams <dabrahams@google.com>
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
* 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
This change creates an unpleasant amount of boilerplate where `Declaration` is declared, in exchange for being able to—very pleasantly—treat it as a simple value that composes with other values everywhere it is used. Applying this technique broadly will pay off in code comprehensibility; once it has been done for all things being new'd, pointers disappear and references are only needed as an idiomatic approximation of inout. The unpleasant code grows only when new polymorphic operations are added, and then only a bit, and is an idiom whose details can readily be ignored once in place. The pleasant code pervades the codebase.
Too bad we don't have existential types in C++ ;-)
* 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.
* [executable semantics] class-ify Declaration
NFC (no functional change).
Proof of concept that we can simplify code by replacing unions with safer, more
regular types. Hand-rolled existentials (type-erasing CoW wrappers) are a follow-on
step that will further simplify usage.
Began adding `const` where possible, and replacing `std::string*` with
`std::string`. Most `const`s can disappear as we replace reference semantics
with value semantics, but in the meantime it's an important step in the right
direction.
Use a safer return type for the Lex* functions, that requires us to
provide a Token as proof that we lexed something.
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
* Make parentheses optional for alternatives with no arguments.
* Use `,` instead of `;` as separator for alternatives, and make the trailing separator optional.
Replaces low-level uses of `Cons` with a first-class `Stack` data structure. Also removes an unused algorithm.
Co-authored-by: Jeremy Siek <jsiek@indiana.edu>
Possible next step: use `std::stack` instead.
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.
Tested on Ubuntu 20.04 and macOS (both Intel and M1 BigSur).
The bootstrap option is still available with `--config=force_local_bootstrap`.
Note that while this works on the ARM M1 for macOS, it is using the x86-based
toolchain and Rosetta, not doing an ARM build at the moment.
You can also point at a locally installed Clang and LLVM toolchain by using
the `--override_repository` flag to Bazel.
Co-authored-by: Matthew Riley <mdriley@gmail.com>
Require a space after a `//`, and recognize but reject a `//` that follows non-whitespace text in the same line. Remove DocComment token kind that ended up not being part of the design.
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.
Per chandlerc's comment:
First, this builds inside the Bazel tree rather than in the source
repository. This ensures we start in a clean directory each time the
repository rule is run again. We don't need to detect an existing build
with this, and it will only be rebuilt when the workspace file or the
repository rule implementation is changed. This can be forced by using:
```
bazel sync --configure
```
Second, we use an implicit dependency on the `WORKSPACE` file to locate
the workspace directory automatically, and the `HEAD` file from the
`llvm-project` submodule to trigger a rebuild if the submodule is
updated.
Third, teach the CMake script to try to use a system-installed `clang`
if installed and not overridden by the `CC` environment variable. This
is very different from the prior logic -- this is only used with the
CMake build, and so should work with any system C++ compiler that can
build Clang and LLVM.
Lastly, this tweaks the CMake options to tune this build given that we
now fully control it and it will only be used in this context. This
still results in a 1.5gb build for me. =/ But its as small as I can make
it really. It's a frustrating long list, but I couldn't find a more
brief way of representing this.
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Chandler Carruth
Dave Abrahams
Jon Meow
Geoff Romer
Richard Smith
Jeremy G. SiekandJon Meow