MAP_POPULATE is a Linux mmap flag that optionally assists read-ahead on
the mapping. It is nonstandard and omission does not affect the
underlying mapping, so fall back to not including the flag, rather than
the reverse.
Part of #1902Fixes#1904
Regarding #1904, using #access-requests because I've decided I feel weird using any other channel for this (including #proposal-prs-and-process)
This will allow us to automatically create and maintain specific repos
based on the main repository here, pulling key files like the license
and other infrastructure and pushing them systematically to a narrow
repo. Things like editor plugins that are best packaged and installed
from a separate repos can still be developed in a central place, even
potentially sharing common things like grammars where useful.
Currently this will maintain a Vim plugin repository out of the
`utils/vim` directory, but can be easily expanded for other systems.
Trying to do this without affecting too much. I think we've generally considered this to be part of "refactoring tools", since large-scale refactoring is assisted by automatic formatting, but formatting is visible enough that it's probably worth addressing directly.
Fixes https://github.com/carbon-language/carbon-lang/issues/1656
The most significant change here is that explorer now uses the chosen spelling
rather than the old `Bool` spelling. Also update a few documentation examples
and some skeletal design docs to use the chosen spelling.
The toolchain embeds the assumption that `clang` and `llvm-ar` are
adjacent, which may not be true on all host platforms. Moreover,
in #1842 and #1843, we test if Homebrow LLVM is in `PATH` by checking
that `llvm-ar` is adjacent to `clang` and if it isn't, we `fail()` the
build, even if `llvm-ar` *is* in `PATH`.
Instead, actually check `PATH` with `repository_ctx.which`. This however
necessitates the assumption that `llvm-ar` and other LLVM binutils
are adjacent, and subsequently that `clang` and `ld.lld` are adjacent.
It appears that we don't seem to always be using these tools, but we
should avoid embedding wrong assumptions regardless.
Update docs to reflect this change.
- An introprocedural forward analysis that checks the may-be-formed states on local variables.
- Returns compilation error on usage of must-be-unformed variables.
- Implemented as a pass of `ASTNode` traversal.
- Currently supports detection of: function parameter, return expression and rhs of assign.
Provides a first implementation iteration towards class prefix and extension, along with user-friendly error regarding missing implementation for #1881
**Explorer behavior**
For class prefix `base` and `abstract`:
```
Class prefixes `base` and `abstract` are not supported yet
```
For extension with `extends`:
```
Class extension with `extends` is not supported yet
```
**Motivation**
* Provides user-friendly error for these unsupported features
* First implementation increment in supporting class prefix and extension.
We shouldn't allow insults even when they're directed against people who aren't "participants", or when they're directed against ideas (because that indirectly attacks the people holding those ideas).
Auto-update tries to add `CHECK: Nice!` or `CHECK: HALLO WELT` to the test case. As what's being printed is non-deterministic, the auto-update should be disabled.
The original sentence was grammatically unsound, specified the three options of copy, move or pointer binding in parenthesis and some words around it.
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
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
3405691582
Jon Ross-Perkins
cabmeurer
Chandler Carruth
Metarsit
Krishna Agarwal
pmqtt
Zenong Zhang
Adrien Leravat
Geoff Romer
Shakeel MahateandJon Ross-Perkins
josh11b
MarchMore
x2wandJon Ross-Perkins
Matt Armstrong
jkamins7andJon Ross-Perkins
Thejaswi Kadur
Calvin
Vitalii
Vaishnavi JoshiandJon Ross-Perkins
SADIK KUZU
yale
Mats Larsen
purpl3r0se
