Following #1191, add initial support for bitwise operators. Support for both
integer operations and for operator overloading via the interfaces specified in
#1191 is provided.
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
PR to add a vim syntax file to support syntax highlighting for .carbon files. Since the Carbon language specification is still in progress, a single syntax file is easier to maintain and adapt to design changes in Carbon. After the language syntax has matured and stabilized, advanced tooling such as Treesitter and Language Servers can take over the syntax highlighting in neovim.
### Highlighting Support
- comments and preprocessors (RUN, CHECK, etc)
- string and numeric literals
- primitive type names, classes, aliases
- control flow constructs
- identifier names
- package and library declarations
- most keywords mentioned in `docs/design/README.md`
### With a Dark Colorscheme:

This image is longer than I thought, so I'm not posting what it looks like in a light colorscheme, but it should look fine as long as vim highlight-groups are properly defined.
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
Replace the "why we don't want to discuss things" question with three
questions covering substantially the same topic. Try to strike a balance
between inviting participation and feedback while still making it clear
that the evolution process produces "firm" decisions.
Address issue #1833.
By adding a small, proactive safety check, the hope is that this will better point developers in the direction of a fix and reduce the volume of duplicate issues filed for this common troubleshooting question.
This change seems to be safe in the present as this check mirrors the current behavior in `clang_cc_toolchain_config.bzl`, finding these tools in the same directory beside `clang`. Non-standard builds using the same bazel toolchain config should not be affected for this reason. If that behavior ever changes in the future, this check will become out of sync.
Open to ideas for better heuristics here! However, checking for `llvm-ar` seems to satisfactory for right now. Verified this change worked locally (macOS) with and without Homebrew's LLVM in `PATH`.
Might want to wait on review from @chandlerc.
Fixes#1842.
> The only issue that I currently have with this one is that the `clangd` extension is having some hiccups, not being able to find includes like `<gmock/gmock.h>` and `<benchmark/benchmark.h>` and thus showing extra errors. However, this only affects the VSCode extension and bazel seems to work fine.
This might be an issue with the compilation database: you might try ./scripts/create_compdb.py to help.
This provides a natural place for questions about the specifics of how to
contribute effectively, which, near term, is probably where the FAQ will
grow the most near term. This allows the other headings to remain more
focused on their original questions.
Move two existing questions to the new place without changing their
content: "What are the prerequisites for contributing [...]?" and "Why
aren't people willing to discuss certain topics [...]?".
Fixes#1527
On Debian, the zlib1g-dev package is required to build and should be given as a requirement.
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
TextMate is the go-to definition language for syntax highlighting for editors lack dedicated language support for a given programming language. This patch contains a very minimal, yet functional TextMate bundle definition for Carbon.
This allows Carbon users to import the TextMate bundle into their editors to get basic syntax highlighting for Carbon code until we have a more solid specification for the language (that's when the fun with dedicated plugins/extensions begins!).
**Support**
- String literals with escape codes (currently using C highlighting rules)
- Numeric literals in decimal, hexadecimal and binary (lacks _ separator support though)
- Single and multi-line comments
- Highlighting of all? (let me know if some are missing) keywords in the language
Here is an image of the highlighting in action in IntelliJ Dracula mode

We've observed the following things cropping up regularly enough to
address as 'frequently asked':
* Why isn't there a Carbon logo?
* Where should I ask questions?
* What are the prerequisites for building Carbon?
* Why aren't people willing to discuss certain topics?
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
The previous implementation model involved the caller of a function knowing what impls the function will need. With the addition of blanket impls and specialization to the design, that is in general no longer possible. Instead the caller provides a type which is used as a key to look up the impl, which is expected to occur during monomorphization, though we allow the compiler to employ other strategies when the set of impls is predictable.
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
This allows us to combine multiple Errors together without repeating the prefix
information. Also fixes several cases where two "COMPILATION ERROR" prefixes
would be prepended to the same message when errors with prefixes and locations
were produced by the lexer and parser.
There was unnecessary checking the .svg images (anyway it did not help a lot as mentioned on the #1655#1652 issues).
Regex upgraded so it excludes all .svg.
Tested it on the other files and I think it's correct for now.
Summary of resolved issues/ changes:
1. 'our' typed twice under **Join us** heading in README.md --> 'our ' is no longer repeated, typo fixed
2. verb form and comma related errors under **Memory Safety** heading in README.md --> grammar fixed
3. missing article and hyphen related errors under **Generics** heading in README.md --> grammar fixed
4. punctuation and preposition related errors under **Why build Carbon?** heading in README.md --> grammar fixed
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>