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>
- 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
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>
This simply requires braces and doesn't allow single-line `if`s. There
is some minor readability loss here, but it seems minor and provides
extremely simple rules which I'd value.
I can also trivially get clang-tidy to both check for this and
automatically fix code to conform.
Just sending this as a code review as it seems fully in the direction of
the style guide approved by the core team and I've heard no real
objections. That said, if anyone is concerned, I'm happy to take it
through the proposal process.
Adopts new copyright and markdown toc checks.
The new toc check generates the toc header, so that's why all the md files changed (this had felt better to me for the long-term, more auto-generated content)
When writing C++ code for Carbon, we want to keep all of our code consistent,
easy to learn, and help avoid spending undue code review time arguing about
the same core style and idiomatic issues.
This adopts the Google C++ style guide as a baseline, and then makes minimal,
focused additions and adjustments to it to suit the needs of Carbon.
Co-authored-by: Thomas Köppe <tkoeppe@google.com>
Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com>
Co-authored-by: Geoff Romer <gromer@google.com>
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Co-authored-by: austern <austern@google.com>
Co-authored-by: Dmitri Gribenko <gribozavr@gmail.com>
There is limited direct or obvious support for working with a stack of
dependent pull requests with clean code review of each incremental
change.
Carbon needs to support high-latency asynchronous code review due to
timezones, schedule differences (especially in an open source project),
and the delays imposed by our proposal process. To this end we need some
solution for doing stacked pull requests with a reasonable code review
experience. This suggests a compromise flow that seems to minimize the
costs of doing this.
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
Co-authored-by: Dmitri Gribenko <gribozavr@gmail.com>
Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com>
Co-authored-by: austern <austern@google.com>
The pull request workflow was supposed to connect to the review guidance
anyways, but the link hadn't been added.
Also adds a TOC to the pull request workflow document as it was missing
one.
Carbon needs a strong code review process to handle code (and other)
changes that are not significant proposals. This attempts to provide
clear guidance on the process, structure, and scope of code review.
It also gives detailed guidance on how to effectively do code review
for both reviewers and authors.
This proposal was accepted on 2020-08-04.
This had been causing me issues when writing a test for pr-comments.py, which I then renamed so that I could import. It's had me mulling that I should really write tests for other scripts, but the name gets in the way.
The decision files are just an exception, so trying to reach consistency.
- Add mentions of new "comment deadline" label.
- Link to review manager doc from evolution doc.
- Standardize evolution doc on "topic" instead of "forum topic" (use was mixed).
We're running into issues with md handlers that expect this kind of 4-space indent. It should be cross-compatible with GH, so switch, even though it feels a little churny.
Manual edits are to:
- .prettierrc.yaml:
- rename from .prettierrc
- add tabWidth (primary change)
- add trailingComma (fix vimPrettier skew)
- contribution_tools.md: Fix remarks about .prettierrc.yaml
- pre-commit-toc.js: indent, bullets
- pre-commit-proposal-list.py: indent of output
The rest is the result of `pre-commit run --all-files`
Unfortunately this'll probably depend on the change being propagated into PR branches, so I wouldn't be surprised if we see regressions for a bit. We'll also need to nudge people to update .vimrc's. Hopefully the pre-commit GH action helps catch issues.
* Proposal for an explicit GitHub workflow.
This suggests a GitHub workflow that uses pull requests, produces linear
history, and both incentivizes and encourages small, incremental changes
(both at the pull request and commit granularity). It tries to follow
general best practices around software engineering at scale and GitHub
workflows. It also tries to ensure the workflow is very well supported
by tooling and automation built into GitHub.
Of note, this proposal should match precisely the current enforced flow
on our GitHub repositories. But we need to actually decide we like this,
write up the rationale behind it, and document what we're doing.
I've added an abbreviated version of the proposal as a documentation
update to the contributing file. Happy to restructure or find a better
home for this. I've tried to focus on the parts that contributors
actually would need to care about as opposed to the things that are
simply and fully enforced mechanically.
My hope after this is to suggest more detailed code review guidelines.
* Addressing review comments.
Notably, I really was giving too much weight to multi-commit PRs which
shouldn't be the common or default. I've tried to restructure everything
to make it much more clear what is going on here.
* Minor tweaks
* Fix typo in CONTRIBUTING.md
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
* Extract workflow description and remove redundancies.
* remove tracking issue template field
* Update proposals/p0029.md with reviewer suggsetion.
Co-authored-by: Dmitri Gribenko <gribozavr@gmail.com>
* Continue to address review feedback.
* Apply suggestions from code review
Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com>
Co-authored-by: austern <austern@google.com>
* Incorporate code review feedback and begin moving toward "trunk" based terminology
* Tweak the wording and make it a bit more consistent.
* Update docs/project/pull_request_workflow.md
Co-authored-by: Dmitri Gribenko <gribozavr@gmail.com>
* Address more review comments.
* Correct the rationale.
* Tweak wording based on discussion in review.
* Improve the rationale around the default branch to avoid overstating or
misstatig things.
* Apply suggestions from code review
Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com>
* Clean up formatting and address a couple of comments on grammar from review.
* Update docs/project/pull_request_workflow.md
Co-authored-by: austern <austern@google.com>
* Add to proposal list.
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
Co-authored-by: Dmitri Gribenko <gribozavr@gmail.com>
Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com>
Co-authored-by: austern <austern@google.com>
This catches some common spelling errors, but is *not* an exhaustive spell-checker. The only false positive is "rouge" in Gemfile.lock, which is why I'm excluding that file.
True positives are in the change, and it does catch the "langauge" typo I keep making, which zygoloid fixed for me in a few spots. False negatives are:
- virmc
- Announcemented
- propsal
For comparison:
- cspell (https://www.npmjs.com/package/cspell) is too aggressive and has a small dictionary
- Caught the false negatives, but many false positives, including 'LLVM', 'roadmap', 'Carruth'
- https://github.com/lorenzwalthert/precommit has a spellcheck, but config looks ruby-specific
Added here:
- .pre-commit-config.yaml
- docs/project/contribution_tools.md
- src/scripts/pre-commit-toc.js
- CONTRIBUTING.md
- proposals/* (just to switch TOC formats)
The rest consists of auto-generated fixes.
The switch from doctoc to markdown-toc is because doctoc wants to put a TOC in every file, whereas markdown-toc only does it if you have an insertion point.
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
- Sentence case headers: https://developers.google.com/style/headings
- Remove parentheticals where possible: https://developers.google.com/style/parentheses
- Avoid latin abbreviations: https://developers.google.com/style/abbreviations#dont-use
Also some evolution-specific changes:
- Remove obsolete PDF references
- "decision is to accept the proposal" instead of "decision is to approve the change"
- Adjust review manager actions for accepted/declined/deferred decisions.
- Rephrase arbiter decisions, particularly to avoid 1-0 being considered a "majority".
- I think this was always intended, and does not reflect a substantive change.
* First draft of a README for the principles/ directory.
* More closely mirror the relevant section from the goals doc.
* Reword bit about excluding using chandlerc@'s suggested text.
* Link to goals doc.
* Update docs/project/principles/README.md
Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com>
Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com>
Dave Abrahams
Jon Meow
Matt Godbolt
Matthew Riley
Bryce Adelstein Lelbach aka wash
Richard Smith
George Kulakowski
sidney13