A few changes:
- Merge content from the `primitive_types.md` design doc into the overall design `README.md` since there was so much overlap and no need for two copies.
- Consistently spell integer types `Carbon.Int(N)` and `Carbon.UInt(N)`, including the `Carbon.` prefix and avoiding `Unsigned(N)`.
- Consistently use a comprehensive set of floating-point types.
- Incorporates #2015 into the design docs.
This proposal aims to add a literal syntax for fixed-sized numeric types: integers, unsigned integers, and floating-point numbers.
Fixes#1998
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
A number of smaller changes grouped together in one proposal:
- Make `Self` a keyword.
- Clarify that `Self` refers to the current type in a base class and in impl declarations.
- Clarify when `.Self` is legal, and what type it has.
- Also specify that `where` is not an associative operator.
Summary:
Adds parsing support for the `package` directive as specified by the
`Code and name organization` design doc.
Co-authored-by: ergawy <kareem.ergawy@guardsquare.com>
* Replay changes from pre-force-push mixin branch
* Base MixinPseudoType off of the new InterfaceType
* Add more test cases.
Also removed an unnecessary check that would have already been
handled by the parser.
* WIP detect member clashes during mixing mixins
* Implement fuzzer changes
* Implement member name clash check when mixing mixins
* Modify parser and lexer for experimental mixin feature
* Add comments
* Update explorer/testdata/mixin/simple-mix-in-mixin.carbon
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
* Update explorer/testdata/mixin/use-mixin-method-in-class-method.carbon
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
* Make code review changes
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
It's taking longer to update almost 500 tests which currently exist.
Without the arguments, the command updates all tests, as before:
```
$ time explorer/update_checks.py
Updating 466 lit test(s)...
real 0m5.858s
```
With the arguments, the command updates only the specified tests:
```
$ time explorer/update_checks.py explorer/testdata/basic_syntax/fail_invalid_integer.carbon explorer/testdata/basic_syntax/fail_invalid_char.carbon
Updating 2 lit test(s)...
real 0m0.359s
```
Previous overview is changed to an introduction that includes a modified first example, and adding a brief tour of Carbon in the form of an explanation of the features demonstrated in that example. Also update to reflect that we expect `Print` to be available in some package imported by default, which we are currently calling `Carbon`.
Co-authored-by: Wolff Dobson <wolffg@users.noreply.github.com>
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
It is currently difficult to see the status of Carbon explorer and where effort
is needed. We propose creating a AreWeYet-styled dashboard to address this.
Reading through extensive problem and background documentation before seeing
what is being proposed is tedious for a reader. An abstract section at the
beginning of a document that provides a succinct summary helps a lot. We
propose adding such a section to our proposal template.
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
```
Jon Ross-Perkins
josh11b
Kareem Ergawyandergawy
Darshal Shettyandjosh11b
Prithvi Jamadagni
pk19604014
David Sankel
Enzo Venturi
ethangandJon Ross-Perkins
Vineeth B V
Andy Soffer
Uriel García-Rivas
Avinal Kumar
David Poliakoff
pseyfert
Adrien Leravat