This is to support converting the code to Carbon. My theory with the setup is:
- Have the code available to build in C++ under `third_party/<project>/original`.
- Created a `third_party/<project>/carbon` for the converted version.
Having the existing code building should, I think, make it easier to run analysis on said code. Using a submodule means we should be aiming to keep it pristine, for easy comparison / updates.
In support of #426. There's still a little bit of surrounding framework that expects these decision files, but I'm trying to split out changes.
Note I'm dropping affirming/abstaining, as well as the accepted date -- I'd be happy to copy-paste decisions into comments on PRs if it'd be helpful, but I thought maybe we could drop those from the repo given they aren't asked for in on new proposals. If we change our minds, we can always look at git history too.
This proposal revamps Carbon's governance structure and evolution
process to try to make it significantly more efficient, friendly,
welcoming, and effective. Proposal process and RFCs are structured much
closer to a traditional code review. The review is driven by a Carbon
lead, although they may delegate some aspects and anyone in the
community is encouraged to participate. Resolving issues in order to
make a decision is handled with GitHub issues and through consensus
among a very small, focused team of leads. It also tries to encourage
explicitly showing interest and enthusiasm in Carbon proposals.
See the proposal text for all the details!
Many thanks to @KateGregory, @jonmeow, @mmdriley, and @zygoloid for
their early ideas and suggestions that ended leading to the direction of
this proposal. I also want to specifically thank them for challenging my
initial direction. 🙂
My plan is to update documentation, `CODEOWNERS`, and other
implementation details in follow-up PRs, but I'm happy to roll any of
them into this one where useful.
Landing as this was accepted by the core team, and reviewed by both a
Carbon lead and review manager so is covered in both processes.
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com>
* Allow configuration of start point.
* Use git switch --create.
* Maybe fix string type.
* Fix wrong flag.
* Add --dry_run flag.
* Not sure if this is needed.
* Dry run should be safe even with uncommitted changes.
* Remove side effects with --dry_run.
* Checkpoint progress.
* Make `dry_run` parameter optional so tests pass.
* Implement suggestions from code review.
* Checkpoint progress.
* Remove new dry_run_pr_number option.
* Rename --start_point to --branch_start_point.
Adds all the necessary machinery to our toolchain and Bazel
configuration to support ASan. This includes ensuring sufficient debug
information is available for backtraces, etc.
As part of ASan, it enables UBSan to catch more basic undefined behavior
in C++. It also enables more complete checking in ASan for lifetime
bugs.
These configs can be enabled in any build mode with `--config=asan`.
They are also enabled by default in `-c fastbuild` where asserts are
also enabled. The goal is to have a single build mode that catches the
overwhelming majority of correctness issues.
Leak checking is part of ASan and finds leaks in `executable_semantics`
code that probably aren't interesting to fix right now. I've disabled
leak checking in the `BUILD` file for the test that showed this --
everything else passed. If more things need this disabled, the same
`BUILD` change should be easily replicated.
If you see unsymbolized backtraces, you may need to either put
`llvm-symbolizer` on your path, or point the `ASAN_SYMBOLIZER_PATH`
environment variable at it. For example, in the project root you could
do something like the following to use the downloaded toolchain's
symbolizer:
```bash export
ASAN_SYMBOLIZER_PATH=$PWD/bazel-clang-toolchain/bin/llvm-symbolizer
```
I'll try to update documentation soon with this as well.
This probably isn't exactly right, but it at least gives *some* low
latency way to update when all the dependencies have been addressed.
Right now, I think only the cron run will unblock dependent PRs.
There was a lot of redundant noise in the older form. It also had
several issues that made the ordering and mixing together of different
flags much less obvious.
With this change, the user-provided flags are reliably placed in
a useful position, along with fundamental flags like the source file and
output.
All of this is largely in preparation for trying to add the first
sanitizer configurations (as well as enabling them by default).
- Give unary `-` and `not` the same precedence as in C++
- Add detail to parse error messages, and make the --trace flag also enable parser debug tracing
- Make any new shift-reduce conflicts into build errors
- Use `%precedence` rather than `%nonassoc` where possible, in order to catch more grammar bugs at build time
This supports tracking PR-to-issue and issue-to-issue dependencies in
addition to PR-to-PR, and this seems likely to be increasingly important
as we have decisions being made via issues.
* Move nontrivial logic out of `parser.ypp` into `FieldList`, rename it to `ParenContents`, make it a class, and add tests
* Use a `FieldInitializer` struct instead of `std::pair<std::string, Expression*>` to represent the fields of a tuple
* AST and syntax for delimited control
* stashing for later
* a little more progress
* progress on delimited continuations
* delimit, suspend, and resume implemented (draft)
* example that generates the natural numbers
* fixes
* tinkering
* changed demo to experimental
* comments and name changes
* describe delimited continuations in the README
* renamed Snapshot to Continuation, edits to comments
* Update executable_semantics/ast/statement.h
improve comment for MakeDelimitStmt
Co-authored-by: Dave Abrahams <dabrahams@google.com>
* Update executable_semantics/interpreter/interpreter.cpp
remove snake_case
Co-authored-by: Dave Abrahams <dabrahams@google.com>
* edits to comments, change name of variable
* updates to handle review edits
* trailing whitespace
* fixes to delimited continuations, added more tests, also fixed assignment to do a copy
* improvements from Geoffrey
* new test from Geoffrey, fix for empty blocks
* more suggestions from Geoffrey
* more tests for delimited continuations, renaming some of them
* renamed test files
* improve a comment
* sketch of creating continuation
* initial implementation of shift/reset style continuations
* more documentation
* fix some camel case
* implemented deep copy of continuations, added a test case for it
* fixed a bug and got the recursive test case working
* removed __delimit, polished up __continuation
* back to shallow copy for continuations
* suggestions from Geoffrey
* removed structured binding (for now)
* Update executable_semantics/ast/expression.cpp
Co-authored-by: Geoff Romer <gromer@google.com>
* responses to Geoffrey
Co-authored-by: Dave Abrahams <dabrahams@google.com>
Co-authored-by: Geoff Romer <gromer@google.com>
Instead of exposing a stateful Parser type, expose only the result of
its parsing action. This also makes the numeric literal code better
mirror the string literal code.
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.
* separate the alive flag from the Value class
* restored KillValue, added KillAddress
* added comments
* Update executable_semantics/interpreter/interpreter.cpp
Co-authored-by: Dave Abrahams <dabrahams@google.com>
* Update executable_semantics/interpreter/interpreter.cpp
Co-authored-by: Dave Abrahams <dabrahams@google.com>
* Update executable_semantics/interpreter/interpreter.cpp
Co-authored-by: Dave Abrahams <dabrahams@google.com>
* finish edits from Dave
Co-authored-by: Dave Abrahams <dabrahams@google.com>
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>
Richard Smith
Jeremy G. Siek
Jon Meow
Richard Smith
Geoff Romer
Matthew Riley