The Bazel bits are collected into a directory and given less confusing
names (I hope). Other than names, everything is a direct copy from the
toolchain repository without any edits.
A few files needed to be merged in:
- `.gitignore`
- `.pre-commit-config.yaml`
Subsequent commits will add relevant C++ infrastructure and then the
source code itself.
The jekyll build keeps top-level without expanding them. So the site works, but the publish copy failed because some symlinks to files that aren't visible through the site (like CONTRIBUTING.md, versus the site's CONTRIBUTING.html) didn't work.
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).
This takes #175 and publishes it as interop goals. I've made a few small editorial changes, but the main addition is the "Offer equivalent support for languages other than C++" non-goal which I thought may be useful (in particular, it can be used to clarify why this directory is "interoperability" and not "interoperability_cpp").
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.
* 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)
`.tmp` -> `.tmp.md` causes the right copyright to be chosen (new issue due to the check-copyright pre-commit)
The `_get_proposals_dir` changes are to allow pytest to be run from any directory.
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.
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.
* 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.
Main reasons for doing this were:
- Add tests for update_label_access
- Reduce js reliance
- Unify handling of access tokens
- Migrate more to GH's graphql (unfortunately not everything, pygithub is rest-based)
- With pytest, reduce the number of executable scripts
Chandler Carruth
Jon Meow
Sidney HummertandJon Meow
Bryce Adelstein Lelbach aka wash
Richard Smith
Matt Godbolt