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>
Revs are from `pre-commit autoupdate --freeze` (jlebar isn't providing versions, thus the sha, but this does silence a warning from pre-commit).
The migration to the new prettier location is manual, but noted at https://github.com/prettier/pre-commit
Manually validated with pre-commit run --all-files
We'd tried to skip this before, but VSCode keeps wanting to create the directory for me, and I think both you and I are using it (maybe me more than you right now?). I'd like to just ignore it -- seems like a cheap add.
Just a minor refresh, and trying to make the contribution tools link a bit more general (I'll be updating that separately, but it's already more generic than indicated).
- bazel/bazelisk because it's kinda needed
- buildifier per #236
- Clang/LLVM I know a number of people are familiar with, but I wasn't...
- `go get` and `pip` because it's feeling more and more appropriate to separate out package managers vs other tools
This updates the Bazel toolchain logic to work on macOS. Much like on
Linux, I'm not testing this against a *released* LLVM, but against
a from-source build. You can build and install LLVM from top-of-tree
locally with CMake, or on macOS maybe use Homebrew like:
```
brew install llvm --HEAD
```
You then need to point Bazel to the installed `clang` executable if it
is not placed onto your PATH (Homebrew doesn't):
```
bazel test --repo_env=CC=$HOME/homebrew/opt/llvm/bin/clang //parser:all
```
This builds and passes tests for me at least.
The fuzzer feature may not work (yet) with this setup, but that can be
improved incrementally as we proceed.
Create a team to oversee the implementation of Carbon. This team is
responsible for code reviews as well as handling any implementation-specific
decisions.
Originally, it was suggested to call this a "toolchain" team. During
discussion, it became clear that the scope wasn't easily limited to
implementation efforts that were necessarily part of the toolchain. There are
many different aspects of implementation, and we anticipate code sharing
between them that make it unhelpful to try to separate these. Instead, this
team is chartered with broadly covering all of the implementation concerns in
Carbon. If someone is concerned that an issue is larger than that, perhaps
impacting the design of the language, the project, or the community, the
standard process already provides for easy escalation to the core team.
Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com>
Co-authored-by: austern <austern@google.com>
Co-authored-by: Geoff Romer <gromer@google.com>
- Shift some things around to adjust to being in bazel.
- Add separate build/serve/publish scripts for use by bazel (not set up for direct execution, but bazel requires +x).
- Fix some tests I noticed not running unittest.main as a result of the switch.
- Move md files into filegroups for build reuse.
- Disable automatic site publishing (now `bazel run //website/jekyll:publish`)
Site publishing seems like it'd be too much trouble to keep automated... The C++ toolchain essentially needs to be set up due to the repo config, along with syncing the LLVM submodules, etc. That seems a bit annoying to do on each run of the publish-docs action, and not something I really want to maintain. If we get a CI, we can focus on it more there, but this feels like it'd just be a one-off to maintain as a github workflow.
Richard SmithandChandler Carruth
Jon Meow
Dave Abrahams
Geoff Romer
Jeremy G. Siek
Jeremy G. SiekandJon Meow
Matt Godbolt
Sidney Hummert
