The debug flag change is discussed at https://github.com/llvm/llvm-project/issues/57637
This modifies the devcontainer Dockerfile to switch to an ubuntu and apt-based llvm-15. That was used in testing of these changes. The move away from brew is partly necessary if we want llvm-15, but also installs much faster (roughly 90s setup).
This was based in part on #1618
Note this will need to be set per-cc_binary, but I don't think there's a good way to avoid that.
I didn't try hijacking the `cc_binary` rule name because that felt a bit excessive. We probably will have a few binaries we want to run directly, but I don't think it needs to be addressed on every last one.
This is part of addressing #1404
libprotobuf_mutator and abseil have warnings that are already fixed in newer versions.
bison outputs code that hits new warnings; there I'm just silencing it because testing a newer bison version is more difficult.
Fixes#1650Fixes#1660
When checking for control flow falling off a function after a `match`, determine whether it's possible for no case to have matched. Using the same implementation, also detect whether `case`s in a `match` are unreachable.
For now, the implementation never considers a match against specific values for any type other than tuples, alternatives, and `bool` to be exhaustive. In particular, matching against the sole value `{}` of type `{}` is not considered exhaustive. This is probably best left until explorer supports matching on struct and maybe class types more generally.
This implementation closely follows the algorithm described in the paper [Warnings for pattern matching](http://moscova.inria.fr/~maranget/papers/warn/warn.pdf) by Luc Maranget. Various optimizations are possible, such as reducing the amount of copying done, but for the purposes of explorer, comprehensibility is being favored over efficiency.
The problem is, perhaps surprisingly, co-NP-hard (by reduction to the tautology problem for disjunctive normal form, which is in turn dual to the satisfaction problem for conjunctive normal form, which is well-known to be NP-hard). The algorithm is therefore exponential-time in the worst case, but seems to be well-studied and performs well enough on non-pathological examples. Nonetheless, a depth limit has been imposed to prevent pathological examples such as those generated by a fuzzer from causing long runtimes.
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
Minor Style Change: a non-auto method to auto
Change the comment to address the correct function name
Sort the Members of `TokenizedBuffer` according to the YAML format
Fix to have the preferred term, `nul` over `null`
Include the library of the added function in carbon-language#2030
Change terminology from "generics" and "templates" to "checked generics" and "template generics". Afterwards, "generics" will be an umbrella term that include templates.
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
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.
Jon Ross-Perkins
josh11b
micttyl
Andy Soffer
pmqttandm new
Kareem Ergawyandergawy
Darshal Shettyandjosh11b
Prithvi Jamadagni
pk19604014
David Sankel
