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.
Most of these were fixed automatically (including things like adding
`[[nodiscard]]` and such). A number of others required manual edits.
I think all of them were pretty nice improvements.
There were a few places where the issues really stem from external
constraints and I've disabled the checks: GoogleTest macros or the
specific LibFuzzer entry points.
The only other places I disabled are the implicit conversions to
a private `enum` in the classes wrapping those `enum`s. These implicit
conversions are necessarily implicit to serve their only purpose:
enabling their use in `switch` statements and `case` labels. When these
were highlighted, it showed that one of these was actually converting to
an *`int`*. I've switched that to use the private `enum` instead as
doing so is important to enable warnings on non-covering `switch`
statements over than `enum`. And indeed, there is a `switch` that was
was implicitly relying on falling through in this way, so I've added the
explicit documentation of the intentional pattern to address that
warning.
Sorry this is so large, all of this somewhat fell out of enabling the
`clang-tidy` checks. If it is too difficult to review as lump, I can
work on breaking it apart as needed. Just let me know.
The rationale and rule for this was added in #194 to the C++ style guide
we are using for Carbon.
I've applied the automated fixes from running `clang-tidy` over all the
code, and then run `clang-format` afterward.
There are a few places where `clang-format` fixed a formatting issue
that snuck through in prior commits. These were rare enough that it
didn't seem worth splitting them out into a separate change.
This library manages buffers of source code, either in-memory or mapped
from the filesystem. At the moment it is a bit simplistic and assumes
`mmap` is available in its implementation details. We should make this
more portable in the future, but this is currently just a direct copy
from the toolchain repository.
Chandler Carruth