Commit Graph
3 Commits
Author SHA1 Message Date
Dave Abrahams 102ea3ccaf Value semantics for Declaration. (#313)
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++ ;-)
2021-02-28 11:29:38 -08:00
Dave Abrahams 2205fd52ce [executable semantics] class-ify Declaration (#307)
* [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.
2021-02-27 13:32:03 -08:00
Jon Meow 6e5070de18 Adapting jsiek's executable semantics tooling for commit. (#237)
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.
2021-02-19 15:25:43 -08:00