What this does:
- Sets up a `migrate_cpp` tool which currently only runs `clang-tidy`.
- This is intended to have more transformations in the future.
- Sets up a `migrate_cpp.sh` script.
- This copies the original woff2 code into a `carbon` directory and runs the `migrate_cpp` tool on it there.
- Adds the initial `carbon` directory of woff2
- To be clear, this is currently only updated via `clang-tidy`.
- More transformations should be expected in the future.
- Minor related edits. For example:
- Adjust pre-commit to skip the `carbon` directory, because it's third-party code and shouldn't be edited in the same way.
- Adds `@brotli_carbon` as a local repository so that we can "build" outputs.
- Makes clang-tidy from the bootstrap toolchain accessible for BUILD dependencies, as it's then used for `migrate_cpp`.
What this does not do:
- Any actual transformation of C++ code to Carbon
Co-authored-by: Matthew Riley <mdriley@gmail.com>
To talk about generics as a programming language feature, you need a lot of
specialized terminology. We need to agree on the words we are using and their
meaning before we can meaningfully talk about the design of the feature itself.
There a number of problems a glossary solves:
Not everyone knows every term, so having a single place to look them up will
improve the ease of understanding, ease of contributing, and accessibility
of the project.
There may not be widespread agreement on the meaning of some terms. In
particular, individual programming languages tend to assign very specific
meanings to terms used within their ecosystem.
Some terms may be used in multiple ways, but we only use the term with one
specific meaning.
Some terms are our invention and we need to introduce them.
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Going through tests, funptr1.6c is the main spot I see a real change, I added parens to get around an issue parsing fnty.
Co-authored-by: Geoff Romer <gromer@google.com>
This is needed to fix issues like:
```
bazel-clang-toolchain/include/c++/v1/cstddef:44:15: fatal error: 'stddef.h' file not found
#include_next <stddef.h>
^~~~~~~~~~
```
* changed union of Statement to be private
* changed the union in Expression to be private
* changed union in Value to be private
* changed AST constructors to be static methods
* updates to syntax unit tests
I tried what I could, but I don't think this action will work while Carbon is private.
"Error: Resource not accessible by integration"
https://github.com/carbon-language/carbon-lang/runs/2441129284?check_suite_focus=true
I'd seen this mentioned on some actions:
https://github.com/marketplace/actions/github-project-automation#personal-access-token-secretsgithub_token
However, I thought it might've been a side-effect of the APIs they were using (I did have this running on a local repo), but I think fork PRs are where the problem lies...
The "generics" feature of Carbon is a large design effort that needs to be broken up into manageable steps. The first thing we need is a high-level goals document. The goals here reflect the desirable properties that we have discovered as part of considering several alternative generics designs:
- Use cases:
- Generic programming
- Upgrade path from C++ abstract interfaces
- Dependency injection
- Generics instead of open overloading and ADL
- Performance
- Better compiler experience
- Encapsulation
- Predictability
- Dispatch control
- Upgrade path from templates
- Coherence
- No novel name lookup
- Learn from others
- Interfaces are nominal
- Interop and evolution
- Bridge for C++ customization points
Goals are summarized in [this presentation](https://docs.google.com/presentation/d/12yGyu5Pvdag7CJp-_yLVkmbhyvuRIilBTNlkO0LKaHo/edit?usp=sharing&resourcekey=0-JB9yrUO4-6J8-zzGhnIyNg).
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com>
Co-authored-by: Matthew Riley <mdriley@gmail.com>
Co-authored-by: austern <austern@google.com>
Co-authored-by: Dmitri Gribenko <gribozavr@gmail.com>
Additional miscellaneous cleanup:
- Use the term "deallocate" instead of "kill" in function names, for symmetry with "allocate".
- Drop an unnecessary memory allocation in `AllocateValue`.
- Implement `PrintHeap` in terms of `PrintAddress`, so that dead values are flagged with `!!`.
- Generally replace Discourse mentions with GitHub Discussions, per #444
- Switch from "Discord Chat" to just "Discord" because there's no more ambiguity, and "Discord" is the more common term.
- Fix mentions of "core team" to "Carbon leads" (because the touched docs overlap a lot).
Co-authored-by: Matthew Riley <mdriley@gmail.com>
* more tests of tuples, especially mixing positional and explicit field names
* test of match with nested tuple
* Update executable_semantics/testdata/fun_named_params2.6c
Co-authored-by: Geoff Romer <gromer@google.com>
Co-authored-by: Geoff Romer <gromer@google.com>
* fix tuple equality, added test cases
* added a comment to an old function
* Update executable_semantics/interpreter/value.cpp
Co-authored-by: Geoff Romer <gromer@google.com>
* fix error in Geoffrey's edit
Co-authored-by: Geoff Romer <gromer@google.com>
A Carbon function that needs to report recoverable failures should return a sum type whose alternatives represent the success case and failure cases, such as Optional(T), Result(T, Error), or Bool. The function's successful return
value, and any metadata about the failure, should be embedded in the alternatives of the sum type, rather than reported by way of output parameters or other side channels. Carbon's design will prioritize making this form of error handling efficient and ergonomic.
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
* improved checking for liveness when reading and writing memory
* moving some functions to be methods of State
* finished moving functions into State
* Update executable_semantics/interpreter/interpreter.h
Co-authored-by: Geoff Romer <gromer@google.com>
* moved some comments, other minor edits
Co-authored-by: Geoff Romer <gromer@google.com>
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.
josh11bandRichard Smith
Matthew Riley
Jeremy G. Siek
Richard Smith