Use `"` for simple string literals and `'''` for block string literals.
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Our "Getting Started" section doesn't mention the Compiler Explorer as a first step. Compiler Explorer already has the Carbon explorer installed, so it would save interested folks a lot of time if they just want to try code out before installing a lot of tools to build from scratch.
This is a repeat link of the status section, but given the title of this section ("Getting Started") it's quite possible visitors end up here before they read the status section.
codespell now sees "falsy" as a mis-spelling of either "false" or "falsely"; adding it since I think this it's occasionally used this way in programming. e.g., https://developer.mozilla.org/en-US/docs/Glossary/Falsy
Adjusts to use the new check-copyright support for lines starting with a dash.
This PR fixes issue #298. I am attempting to build Carbon using Bazel on Windows, without the need to go through WSL. This is still a work in progress, below is a list of issues I have discovered and my fixes for them.
- Windows does not support Homebrew; however, I was able to properly install all of the required packages through [Chocolatey](https://chocolatey.org/). This was my first time using the Chocolatey package manager, yet it was fairly easy to use. I believe there are other options as well for Windows.
- As is mentioned in issue #298, your Windows installation must be running in [Developer Mode](https://docs.microsoft.com/en-us/windows/apps/get-started/enable-your-device-for-development). This will allow unprivileged users to create symlinks during the build process.
- As it currently stands in trunk, clang_configuration.bzl will fail when attempting to run the method `_compute_clang_cpp_include_search_paths` on Windows. I have discovered that this is because Clang++.exe fails to execute if you provide it with an input file that does not exist. Thus, I have the build script generate an empty temp file in the Bazel repo for Clang to use when running the above method.
- A cc toolchain specifically for Windows was created in clang_toolchain.BUILD. I simply mimicked what was done for other platforms, I apologize if this is incorrect since I am fairly new to Bazel.
As I understand it, the next step is to configure clang_cc_toolchain_config.bzl to support the new Windows toolchain. I intend to continue working on this, however as I stated I am quite new so help is seriously appreciated!
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
This removes the separate data files, which have been failing to load properly ([example](https://github.com/carbon-language/carbon-lang/runs/7957047892?check_suite_focus=true)). This one wasn't working previously, but hopefully will with these changes (and it might've also just been a pull_request_target issue, but the silent "Resource not accessible by integration" failures aren't great).
Wiki can either be "require push access" or "everyone" -- apparently there's no other option. I've set it to "everyone" so that contributors can make edits without needing push access. So the options as I see it are:
- Leave wiki as "everyone" can edit, use this for notifications.
- GitHub doesn't give notifications for wiki edits. This is trying a different approach for notifications.
- Grant push access to a larger group (contributors), don't add CODEOWNERS.
- Not sure this is the right choice because of the implications around merges, but again maybe it'd be fine and we can expect the approval requirement to work out.
- Grant push access to contributors, add CODEOWNERS.
- This causes the auto-assignment to CODEOWNERS that we don't want. (details in https://github.com/carbon-language/carbon-lang/pull/1367)
- Create a separate wiki repo so that we can differently handle push access.
- This seems overly complex a solution though.
I'm hoping this approach works.
The approach uses a RecursiveASTVisitor rather than matchers. Matchers
and callbacks do not compose neatly and introduce significant runtime overhead
over RecursiveASTVisitor when an action needs to be performed on most nodes.
Summary:
An `llvm::APInt` is always treated as a signed value by `operator<<`;
check [1]. This resulted in printing incorrect values for tokens that
have their MSB set to 1. For example, a value 9 would be printed as -7
since its `APInt` object would be 4-bits wide. However, integer literals
are always tokenized without the sign character so it is safe to treat
the values as unsigned for printing pruposes.
[1] https://llvm.org/doxygen/APInt_8h_source.html
Co-authored-by: ergawy <kareem.ergawy@guardsquare.com>
- Since VS Code Dev container extention has a non-interactive shell, user
cannot select a specific image if there are multiple images under same
named authors.
- This fix ensures that images are only pulled from Docker Hub and no
interactive menu is presented.
- References: #1816, #1817
- Fixes#2043
Signed-off-by: Avinal Kumar <avinal.xlvii@gmail.com>
- Added detection of unformed usage with `return var`, control-flow statements and member access.
- Refactored the work flow: made flow facts a class and moved operations of flow facts into the class.
- Added, cleaned and renamed test cases. Some test cases for the dynamic unformed check were suppressed by the static check. They are now added back.
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
Summary:
Fixes a small compilation error where an llvm::Error variable was being
returned by copy rather than by move. The llvm::Error copy constructor
is deleted.
Co-authored-by: ergawy <kareem.ergawy@guardsquare.com>
To pick up proto updates (field renames etc.) and new carbon source samples added to testdata.
```
$ rm explorer/fuzzing/fuzzer_corpus/*
$ explorer/fuzzing/regen_corpus.py
```
This is being done because Projects v1 requires repo write access, a serious limitation for letting people use it. Projects v2 isn't a great option because it lacks event support. Labels are pretty stable in GitHub, so this switches to that.
Note this assumes we're fine renaming "decision: accepted" -> "proposal accepted", etc. There are two reasons for this:
1) To make it clear that this is a proposal-specific label, versus something like an issue for leads label.
2) Removing the colon because it was causing trouble with yaml syntax.
This also adds the "proposal draft" label, mainly to complete the taxonomy.
I was considering whether this should be a proposal itself, but it feels like maybe it's not necessary because it's a fairly low-key infrastructure change, and I'm not sure how much people were relying on the project board anyways.
I tested this in a personal repo, basically just poking at https://github.com/jonmeow/test/pull/2
Also references were added to clarify that some features are not provisional.
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
Co-authored-by: Geoff Romer <gromer@google.com>
Note, partly writing this down to make sure everyone's in agreement with what's written.
Co-authored-by: Geoff Romer <gromer@google.com>
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
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.