Making Values const allows us to separate the actual mutations (search for "*&" in this change) from places where the Value is effectively passed by-value.
* global variables
* implemented type checking of global variable, added test case
* added a comment
* improvements based on Dave's suggestions
* improvements based on Jon's suggestions
* added test cases about global variable ordering
* 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++ ;-)
* [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.
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.
Jeremy G. Siek
Dave Abrahams
Jeremy G. SiekandJon Meow