One implication here is that both proposals/README.md and the website should use basically the same format for their proposal lists. Another subtle change is that the website sidebar was previously sorted by *filename*, and is now sorted by *title*, which seems better because it's something that readers can see.
Enumerating why files change:
- gen_sidebar.py is the centerpiece, with a couple helpful functions for re-use elsewhere
- Delete the old sidebar html includes
- Modify the Makefile to handle gen_sidebar.py reasonably well (let's be honest... I'm not great at Makefiles)
- Move proposal listing out to its own file (proposals.py) for re-use
- Add a few PYTHONPATH things + `__init__.py` files to get modules importing correctly (may be a better way at this, I've hit a wall though).
* first draft of proposal for basic syntax
* rename proposal
* formating
* fixing typos
* precendence and associativity
* minor edit
* added abstract syntax
* some revisions based on feedback from meeting today
* optional return type
* oops, not optional for function declarations
* replacing abbreviations with full names
* name changes
* Update proposals/p0162.md
Co-authored-by: Dmitri Gribenko <gribozavr@gmail.com>
* removed = from precedence table
* for fun decl, back to optional return type, shorthand for void return
* more fiddling with return types
* change base case of statement_list to empty
* added pattern non-terminal
* added expression style function definitions
* change && to and, || to or
* change and to have equal precedence
* updating text to match grammar, fix typo in grammar regarding pattern
* adding trailing comma thing to tuples
* removed 'alt' keyword, not necessary
* flipped expression and pattern
* added period for named arguments and documented the reason
* change alternative syntax to use tuple instead of expression
* comment about abstract syntax
* code block language annotations
* added alternative designs, some cleanup for pre-commit
* spell checking
* filled out the TOC
* minor edits
* minor edit
* trying to fix pre-commit error
* changes from pre-commit?
* changes based on meeting today
* describe alternatives regarding methods
* more rationale in discussion of alternatives
* addressing comments
* typo fix, added text about next steps
* removed *, changed a ! to not
* Update proposals/p0162.md
Co-authored-by: Geoff Romer <gromer@google.com>
* edits from feedback
* pre-commit
* added second reason for period in field initializer
* added executable semantics, fixed misunderstanding regarding associativity
* update README
* added a paragraph about tuples and tuple types
* Update proposals/p0162.md
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
* addressing comments from josh11b
* Update executable-semantics/README.md
Co-authored-by: Dmitri Gribenko <gribozavr@gmail.com>
* link to implicit parameters in generics proposal
* added non-terminal for designator as per geoffromer's suggestion
* changed handling of tuples in function call and similar places as per josh11b and zygoloid
* moving code to separate PR
Co-authored-by: Dmitri Gribenko <gribozavr@gmail.com>
Co-authored-by: Geoff Romer <gromer@google.com>
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
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>
Factored out of the Lexical Conventions proposal (https://github.com/carbon-language/carbon-lang/pull/173). This proposal covers only the encoding aspect: Carbon text is Unicode, source files are encoded in UTF-8, and we will follow the Unicode Consortium's recommendations to the extent that they make sense to us.
* Decision for proposal #42 (Create code review guidelines)
This is a recreation of PR #137 that got stuck in git merge hell.
* Results of running pre-commit
* Create Overview proposal decision
Create the proposal decision for the proposal in PR83: An incomplete, early, and in-progress overview of the language design
* Update proposals/p0083-decision.md
Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com>
* Rerun pre-commit
Adjusted some spaces.
* Rename decision to use _ instead of -
Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com>
Caught by black stable change, done by `pre-commit autoupdate`
`pre-commit autoupdate` also wanted to update pre-commit-hooks, but that gave me some pyenv errors so I'm leaving it alone for now.
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.
Co-authored by: chandlerc
- Based on [PR 22](https://github.com/carbon-language/carbon-lang/pull/83)
- [Idea topic](https://forums.carbon-lang.dev/t/proposal-for-an-incomplete-rough-high-level-overview-ready-for-early-feedback/52)
- [RFC](https://forums.carbon-lang.dev/t/rfc-an-incomplete-early-and-in-progress-overview-of-the-language-design/73)
- [Decision announcement](https://forums.carbon-lang.dev/t/accepted-an-incomplete-early-and-in-progress-overview-of-the-language-design/110)
This proposal should be considered a starting point of the language design. It's not intended to be final; language details may change. This is intended to offer a reasonable starting point for:
- Example code.
- Conceptualizing Carbon at a high level.
- Reasonable, but not necessarily final, approaches to features in README.md.
- If any idea is obviously bad, we can clean it up here.
This proposal is not intended to achieve:
- A whole language design.
- This is way too much work for a single proposal; this is a skeletal framework only.
- As we work on feature-specific designs, we may decide to use other approaches. That's fine: we only need somewhere to start.
- The summaries in README.md may be expected to change over time.
- Feature-specific files aren't intended to be well-written or comprehensive. They are a quick jot of prior thoughts.
- We want to avoid getting stuck on language details that we should consider
more carefully regardless. If you're passionate about a feature, please feel
free to start a new proposal for it.
- Each and every aspect of the suggested overview should be subject to careful
examination and justification before it becomes a settled plan of record.
Chandler started this with https://github.com/carbon-language/carbon-lang/pull/22. I've taken it over with the following changes:
- More of a directory hierarchy.
- Trying to thin out the main file (now README.md) to lighter summaries of features.
- Details/rationale/alternatives should be in feature-specific files.
- Draft files are linked as references where added.
For an example of how we may proceed with feature-specific designs, see https://github.com/carbon-language/carbon-lang/pull/80. In this structure:
- docs/design/README.md mentions interoperability, with a light overview.
- The light overview is not yet in https://github.com/carbon-language/carbon-lang/pull/80.
- docs/design/interoperability/README.md goes into more depth on interoperability, covering key points of the approach.
- Individual files in docs/design/interoperability/* go into more depth on interoperability.
Simple designs may not have a subdirectory. All current feature-specific designs do not -- they may be moved later.
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
This sentence feels like a hold-over from the Google Doc, which still feels useful in that context. Especially because it's so easy to copy/share Docs outside the shared drive. However, for things going to GitHub, it seems like we should either have it everywhere or nowhere, and it doesn't feel helpful enough to have in every file.
My feeling would be different about a notice on the website -- that could be done centrally for all pages, and may be more useful. However, I haven't bothered there because we restrict access to docs, and I think the login flow should make it clearer that a lack of re-sharing is the intent.
* Proposal timeline proposal
As this proposal was started and approved before the PR-based process was in place, this PR will be used to put the old proposal Doc that was approved into Markdown.
* Update p00xx.md
* Rename the proposal file to match the PR
Also update the reference inside the file.
* Update proposals/p0074.md
Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com>
* Update proposals/p0074.md
Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com>
Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com>
Jon Meow
Sidney HummertandJon Meow
Bryce Adelstein Lelbach aka wash
Richard Smith