Originally, I experimented with special rules for C++ builds of LLVM but
we ended up with a native build of it instead. Loading and using this
was completely unnecessary now and would have needed an update. Just
remove it.
Fixes#400
This matches the version on Ubuntu LTS and other OSes. The only problem
I found with it in our testing is that Bazel confusingly sets the locale
to use `LANG=en_US` by default which breaks UTF-8 support. We may need
to shift this on Windows, but this seems like a reasonable first step.
Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com>
This has two goals:
1) It allows us to simplify and remove special cases from the parser:
when we expect a particular token next, we can just check for it
without needing a special case for end-of-file.
2) It gives us a token to use as a position when emitting diagnostics at
the end of the file.
Centralize all updating of `position` to `Consume` and `SkipTo`, so that we can in a single place ensure that we never go past the EOF token.
This restructures the `compile_flags.txt` to use the downloaded libc++ system
headers and avoid needing a virtual include directory to be built. It still
needs _some_ Bazel build to complete before working in order to have the libc++
system headers downloaded and the symlink to the Bazel tree created.
One (very) tricky part of making this work is to work around bugs in Clang's
tooling layer that incorrectly handle `..` path components after traversing
symlinks. To avoid this, we add a custom symlinks (`bazel-execroot` and
`bazel-clang-toolchain`) that hide the relevant traversal of the Bazel layout to
find build artifacts and the downloaded toolchain. These symlinks will be broken
until a build with Bazel downloads the toolchain and creates the basic output
tree structure.
It also adds a `create_compdb.py` script. Running this script improves the
tooling fidelity by taking a few steps:
1. It queries Bazel to find all the relevant files and adds them to a
`compile_commands.json` database that allows `clangd` and other tools to
index the entire project for improved cross-references, etc.
2. It builds all the generated files with Bazel so that they can be included
successfully. This is very fast in my testing, taking only 10s of seconds. It
is also very likely to be cached effectively.
3. It translates the arguments from `compile_flags.txt` to make them
persistently use the built generated files include paths so that nothing
breaks even as different targets are built potentially with different
configurations.
There are still some limitations.
- It still requires running Bazel before anything works, even if a fast run.
- It will require re-running if new generated files are added and needed but not
built.
- It assumes that the standard Bazel symlink names are used and available.
Much of the Python here was written by @geoffromer in #384 -- I've adapted it
here after discussing to try to fill in some of the blanks and use a slightly
different approach to querying Bazel. I use the normal `bazel query` rather than
`bazel aquery`. This, for example, allows the index to reliably cover header
files in header-only libraries more directly (rather than relying on transitive
inclusion). It also seems a bit simpler too parse, but that is a pretty minor
difference.
Co-authored-by: Geoffrey Romer <gromer@google.com>
* 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
No since spending the GitHub action minutes (or waiting to merge) on
Bazel when only changing markdown or other files that aren't part of the
build and test.
This document tries to lay out a high-level roadmap for Carbon in 2021
following the [roadmap process](/docs/project/roadmap_process.md).
Co-authored-by: Dave Abrahams <dabrahams@google.com>
`clang-format-11` formats this multiple-ternary-operator expression differently than `clang-format-10` and `clang-format` at (current) trunk. Adding an extra set of parentheses brings them all in agreement, avoiding oscillation as folks check the file locally then submit to CI.
PR #280 committed the decision for #199. #199 had the proposal and no decision
and modified `README.md`. #280 had a decision but no proposal, and *didn't*
update `README.md`. However, in a tree with both the proposal *and* its
decision, another modification is necessary.
Since only one PR modified `README.md`, there wasn't a merge conflict that
required a rebase. And since there was no rebase, each PR ran its own CI
blissfully unaware of the other.
For now, committing the results of `pre-commit run --all-files` on trunk.
Later, will look into ways to make the proposal+decision workflow less likely
to break trunk.
We're now one step away from eliminating bare pointers in semantic actions.
There are plenty of other cleanups and modernizations that can be made in the
parser, but the elimination of bare pointers is the one that has the highest
impact for the codebase.
Slowly bringing this into line with Bison's C++ example parser
so we can use strong semantic values for symbols rather than
leaking pointers. First step is to thread a `ParseAndLexContext`
object through the whole syntactic analysis state, like the
example has. In the example, it's called `driver`.
Co-authored-by: Geoff Romer <gromer@google.com>
This is primarily using the configuration matrix facilities of GitHub
actions to consolidate the overall configuration. Beyond avoiding
duplication, this also allows the default and release builds to run in
parallel. The checkout time is duplicated between these, but the rest of
the time is nicely parallelized. This has the most dramatic effect on
macOS builds. Overall, this should reduce the latency on testing from
22-28 minutes to 15-20 minutes from what I've seen which seems
worthwhile.
This does reduce the detail provided in the names of the different
configurations. However, the Bazel build mode is preserved. That seems
like the most critical pieces of information.
Much of this started with me just trying to learn more about GitHub
actions, but once understanding how the job matrix worked, it seemed
worthwhile to send out as an actual change.
Distinguishes parts that come from the parser and lexer. It used to be that all
the files were called "syntax*", but lexing and parsing are distinct phases that
are easier to keep track of when distinguished. syntax.yy.cpp being the source
file generated by flex, containing the lexer was particularly confusing, because
the yy tends to indicate it is a yacc/Bison product, and the ".tab." substring,
indicating "tables" is not really useful to the developer.
These names also match up with what Bison's C++ example uses, which will make
the transition easier.
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>
Chandler Carruth
Richard Smith
Jeremy G. Siek
Dave Abrahams
Matthew Riley