Arguably missed in #769
Note, this is reminding me we have more class members to rename for `_`, but I felt it's best to use the new naming instead of adding more to clean up.
Rationale: Based on the status of #478 and #505, Carbon won't have this feature for a while, and it will be simpler not to support it on spec in the meantime.
`// NOLINT` is added on type aliases in stack.h and dictionary.h to allow lower_snake_case naming -- this didn't feel like a check worth disabling in spite of false positives.
Co-authored-by: Geoff Romer <gromer@google.com>
I should emphasize that I am **completely cheating** here. This PR does not add support for actually _performing_ implicit conversions at run time, because the AST doesn't yet contain the necessary type information. At run time, code like `var p: Point = {.x = 1, .y = 2};` directly initializes the name `p` with the _struct_ value `{.x = 1, .y = 2}`; no object of type `Point` is actually created. I'm only getting away with this because we don't yet have any tests that can tell the difference.
Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com>
Prior to this change, `__await` would make a deep copy of the continuation stack, but shallow-copy the individual stack frames within it. As a result, continuations appeared to have shallow semantics so long as the continuation stack had only a single frame.
This change also removes an obsolete test from the brief period when we intended continuations to have deep-copy semantics, which has been passing basically by accident.
The LLVM-13 release is now on Homebrew, so switch to it. This is
important because our CI only installs the latest version currently.
If you hit issues after this, make sure to update your Homebrew install
to get the latest Clang release. You can always directly set `CC` in
your environment to use a specific `clang` compiler.
This list was extracted from currently-approved proposals and
corresponding design documents. This is intended to be a summary of the
status quo, not a change.
- Replace obsolete references to the arbiters, and clarify that the appeals process will be available once the leads are separate from the conduct team.
- Document that leads, like conduct team members, will be excluded from discussions/decisions that concern them.
Previously, the program exit was triggered by the destructor.
Unfortunately, C++ doesn't make it precisely clear where the destructor
is run, and Clang doesn't generate reliable debug information for that
to give good backtraces. Among other things, when combining separate
cleanup regions in Clang there may be no single canonical location.
Instead, move the ExitingStream system to use an explicit
low-precedence operator overload to flush the output and exit. This
ensures the stream and other actions are completed first but then
immediately exits the program in a way that has a definitive source
location and produces reliable backtraces.
I've tried to add comments and helpers to make this as clear as possible
given that it is a subtle and surprising issue.
Co-authored-by: Geoff Romer <gromer@google.com>
This does a mass rename of:
- `SourceLoc()` -> `source_loc()` for property naming
- `loc` -> `source_loc_` for underscore+consistency
- Generally changing function args to `source_loc` for consistency
- `Tag()` -> `kind()` for property naming and `Kind` parity
- `tag` -> `kind_` for underscore
Also renames `Pos` and `Results` on `Action`. These are a bit of an exception in that most base classes only have `Tag` and maybe `SourceLoc`, whereas `Action` has a little more. I felt okay having `source_loc()` and `kind()` on the base class where children do `Exp()` and the like, but it felt weird to me to mix it on the same class.
The reason for doing this cross-class in one PR is so that I can do it efficiently with a global replace in the codebase, rather than e.g. changing `Expression` but having to read through compiler errors to determine where it's calling `Expression`'s `Tag` versus a different `Tag`. The end result should be equivalent.
This proposed style change allows C++ classes in the Carbon project to provide methods that are named like variables, so long as they behave like _properties_ of the class. It also requires data member names to have a trailing `_`.
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
This implements #826, I think covering everything important there.
Regarding ReturnTypeContext, I broke that out because it started feeling like a significant number of args to be passing around, and I think this makes the association inside type checking clearer.
Co-authored-by: Geoff Romer <gromer@google.com>
The code is pretty intertwined: having the AST be truly mutable means (to me) changing parser.ypp to return non-const values, but then the way things are passed around between objects should be non-const (particularly an issue with lists), which then creates issues with construction of lists in the TypeChecker, which then TypeChecker needs to mostly be non-const.
Due to the difficulties in breaking this apart, whereas I'd previously considering refactoring accessor naming in the same PR, I've largely avoided doing so. The intent is then that this PR focuses mainly on const -> non-const AST behavior.
call_main moves out of interpreter.cpp so that interpreter.cpp can receive a fully const AST.
Revives BisonWrap because this seems a reasonable use of it (avoiding the need to have an std::optional or pointer for Alternative, both of which I thought could be unclear about the intent).
This proposal provides semantics for numeric literals.
* Numeric literals have a type derived from their value, and can be converted to any type that can represent that value.
* Simple operations such as arithmetic that involve only literals also produce values of literal types.
* Literals implicitly convert to types that can represent them.
* The Carbon prelude provides:
* An arbitrary-precision integer type `BigInt`.
* A rational number type `Rational(T:! Type)` with constraints on `T` not yet determined.
* A family of integer literal types, `IntLiteral(N:! BigInt)`.
* A family of real literal types, `RealLiteral(N:! Rational(BigInt))`.
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com>
Allow `auto` as a return type for functions. Only support functions with one `return` statement for now (open question).
This explicitly suggests removing the executable semantics `fn name(args) => expression` syntax, and is motivated by reconciling executable semantics with approved Carbon state. [example](https://github.com/carbon-language/carbon-lang/blob/3d1716f6c692a840d8b4b513ddfb8119432a5150/executable_semantics/testdata/fun_named_params.carbon) This aspect is a decision that may be affected by lambda syntax, but we might also choose to keep lambda syntax and function syntax separate -- I don't think there's enough benefit to providing the alternate function syntax right now.
Co-authored-by: Geoff Romer <gromer@google.com>
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Jon Meow
josh11b
Geoff Romer
Chandler Carruth
Richard Smith