The toolchain link just needed a resourcekey.
The open discussion link may just not work because it was pre-go-public, so it points at a doc that we probably copied.
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
I'm running a `bazel build //...` now and things look fine, so I'm guessing this is now correct. But it seems like GH changed something about their /archive/ downloads that just changed the checksums. Releases appear to be unaffected. I don't have any reference for what changed though.
https://github.com/bazelbuild/bazel/issues/15128 says to use /refs/tags, but I think we can't do that when we're trying to get a specific commit.
As per the `TODO` comment in the file, the `CallableDeclaration::name` property was refactored into `FunctionDeclaration`, which is currently the only namable callable declaration kind. I was able to rely on the existing `GetName` function to replace call sites of the accessor function with nearly identical swaps.
Fixes#2531
Assignment is permitted only as a complete statement, not as a subexpression.
Assignment and compound assignment syntax follow C++ in all other respects.
Pre-increment is provided. Post-increment is not. Uses of all of these operators
are translated into calls to interface members.
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Lazy allocation means that we can use a single node block for _all_ empty node blocks. The change in timing for when the definition node is emitted shouldn't affect semantic correctness; the signature is already present for recursive calls.
This change is to make it clearer what is a TODO versus unexpected behavior. I'm doing this now because I feel it's been getting a little confusing in code.
So for example if I write the code a return type `-> i32`, I get the diagnostic output plus the dump of the (invalid) IR:
```
/carbon-lang/toolchain/semantics/testdata/function/basic.carbon:37:10: Semantics TODO: HandleReturnType
cross_reference_irs_size: 1
callables: [
]
integer_literals: [
]
strings: [
]
nodes: [
{kind: CrossReference, arg0: ir0, arg1: block0, type: node0},
{kind: CrossReference, arg0: ir0, arg1: block1, type: node1},
{kind: CrossReference, arg0: ir0, arg1: block2, type: node0},
{kind: CrossReference, arg0: ir0, arg1: block3, type: node0},
]
node_blocks: [
[
],
]
```
For parameters (and in the future, arguments too; generally comma-separated lists) track two node blocks:
1. param_ir: The complete IR.
2. param_refs: Nodes within the IR that are the "root" parameter.
param_refs should allow quick counting of the # of parameters, and more efficient comparison of call args with function parameters. param_ir should be necessary to generate the actual signature.
In order to construct this, this refactors the node_block_stack into its own class, which is reused in params_stack. These carry references to the underlying SmallVector for lazy modification in order to avoid a dependency cycle with SemanticsIR (also see notes on empty node blocks below).
When finalized, the block pair is pushed onto finished_params_stack. That's because node_stack only has space for one thing, and this is two things -- so I'm essentially choosing a trade-off of adding another stack in order to avoid consuming more space in the expectation that most parse nodes have 0 or 1 things to return, and 2 will be very rare.
As factored, this currently consolidates most empty node blocks into a single canonical empty node block. This is because I think empty blocks, i.e. `()`, will be very common. In order to achieve this, SemanticsNodeBlockStack does lazy creation.
An alternative approach would have been to use 1 node block per parameter. We decided against this in order to reduce the number of vectors being created.
This was discussed in person with at least two of the leads while
drafting the text, but sadly it did not finish being typed into the
document.
Just amending the proposal text for the future as I don't think it
substantively changes the conclusions.
Thanks to @geoffromer for noticing this!
Move deallocation logic to `StepCleanUp` to have all necessary cleanup actions in the same place. Currently this means `DestroyAction` and `heap_.Deallocate`.
The comment on FunctionParameterFinish is actually correct (`1. FunctionParameter`), just a typo in the implementation. It specifically failed parsing at the comma after the 2nd param, regardless of whether there were more params.
Fix variables not being properly cleaned up if declared before an unformed variable.
### Details
Currently the following example / test
```
package ExplorerTest api;
class A {
var i: i32;
destructor[self: Self] {
Print("Destructor A {0}", self.i);
}
}
fn Main() -> i32 {
var a0: A;
var a1: A = {.i = 1};
var a2: A;
var a3: A = {.i = 3};
return 0;
}
```
prints
```
Destructor A 3
```
instead of
```
Destructor A 3
Destructor A 1
```
This PR fixes the issue in the `CleanUp` logic.
Add support for user-defined assignment, as well as compound assignment and increment, following the design direction in pending proposal #2511.
Some of this isn't fully testable yet: because explorer doesn't properly support `impl` specialization, the blanket `impl`s in the prelude prevent types from customizing assignment.
Naming this ToString within the Carbon namespace encourages incidental overloading of the function, and that doesn't seem to be intentional; this feels questionable [under overloading style](https://google.github.io/styleguide/cppguide.html#Function_Overloading). OperatorToString seems helpful in that it makes it easy to see at a glance where it's being used.
Allow explicit conversion from a tuple of `T1`, `T2`, ... to a tuple of `U1`, `U2`, ... if each element has an explicit conversion.
Also add a comment to existing `ImplicitAs` impl for tuples explaining its purpose.
Add a check to prevent creating a class from a struct with a missing parent.
This is already type-checked for carbon / user code, but not when using `Convert` manually.
Although the implementation is similar in size, I think the consistency benefits are helpful. registry.def -> kind.def is also consistent with other implementations.
Also switching int32_t -> uint16_t because I think we it might be enough space (?). We use uint8_t elsewhere, but that's certainly going to be too small. Sticking with int32_t felt inconsistent.
The parser and lexer already produce YAML, so this is fundamentally a consistency issue. I've been thinking about this, and was looking again because I'm working on adding callables, and figured I'd just fix it now.
Add a blanket `ImplicitAs` implementation to perform the conversions that explorer can perform as built-in conversions. This allows those conversions to be detected by constraints and to be used as part of other user-defined conversions. For now, a single monolithic conversion is exposed. I intend to split this up into multiple smaller conversion kinds for each kind of conversion in a follow-up change.
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
Fundamentally this `.Print()` is wrong for debug output at present because `.fixed_spelling()` can be empty. It's also inconsistent with other enums to use it. We frequently print tokens for debugging, and it's easy to forget to specify `.name()` there.
Diagnostics use formatv, so we can provide a format_provider and address it in one spot that way. It also makes it harder to just forget to do the right thing.
Add basic support for `match_first` declarations to explorer, as described in https://github.com/carbon-language/carbon-lang/blob/trunk/docs/design/generics/details.md#prioritization-rule. The concrete syntax here is not yet approved, so `match_first` is renamed to `__match_first` for now, but the semantics are necessary to implement other approved features in explorer so we're intentionally getting a little ahead of the design here.
Improves the error produced when 'Main' is declared with parameters. Resolves a TODO in the typechecker. Explorer only.
PR also adds a test for this error message.
Currently, only the action class uses the noun case (`Cleanup`), while the kind enum and functions are spelled `CleanUpAction`. Other actions use consistent casing between class and enum names. This change makes the name consistent, and unsurprising for developers. Mirrors `DestroyAction` (verb).
Currently, there's a mix of accessing node_stack_ both directly and indirectly, and there are already several Push/Pop methods to help wrap the behavior. However, there's also direct access because of shifting over time, as well as variations in _how_ the stack is used.
This migrates to a separate class in order to make a more specific contract for the API. It cleans up existing uses and adds APIs where needed.
This somewhat abuses control-flow macro handling in `clang-format` to get the behavior we want. Fortunately, I don't think we're ever likely to want this for its intended purpose so it seems harmless to co-opt it like this. If we really wanted, we can narrow it to `if`-macros, but I picked the simpler option to start.
FWIW, I tried all the other macro formatting special cases to see if one would work but it didn't. Might be worth filing a feature request to get a `TypeDefinitionMacros` setting to compliment `TypenameMacros` and format like this does, but it seems (very) low priority.
Also make minor updates to the skeletal design in
docs/design/name_lookup.md following #2113, as there are no longer any prelude names that are made available to unqualified name lookup by default.
Add `type` to the keyword list in
docs/design/lexical_conventions/words.md, following #2360.
The goal here is to (significantly) reduce the boilerplate needed when defining classes that wrap enums, especially those managed with the `.def`-file style X-macros that are common in the toolchain.
This should also provide both better and more consistent functionality to those classes once ported over to it.
Initially, only `ParserState`, `SemanticsNodeKind`, and `SemanticsBuiltinKind` are ported as these were also the three that JonMeow ported in his original pull/2453 "option 5". This is heavily based on that version of the code.
Goals I was considering that influenced the design:
- Keep the individual enum-wrapping classes as simple and easy to read as possible. Especially important is keeping the `.def` files that are often filled with really important documentation clean and easy to maintain over time.
- Don't rely on computed `#include`s as that is an especially dark corner of the preprocessor and breaks some build systems.
- Have a really good API of the enum-wrapping class, including nice constant names for the values, easy printing, and even easy debugger-callable methods to get the name (as opposed to the integer value).
- Keep the API that users interact with in the base class as clean and easy to read as possible.
- Reduce the boiler plate for each instance of these as much as possible.
- Avoid excessive inline generated code or constants that would result in steady growth in object file sizes and linker effort doing deduplication.
These goals aren't always compatible, so we end up needing to pick a compromise between them when in tension. I think this version is a pretty good compromise.
The original version I started with already pull most of the API into a CRTP-style base class. This version pulls *all* of the common API. This is the main tool for getting consistency and avoiding duplication. However, connecting this base class to the individual enum wrappers is still difficult. Some specific changes here that try to do as much as possible there:
- Use a slightly fancier macro pattern to reduce the boilerplate of defining the raw `enum class` prior to the wrapper class.
- Use a macro to simplify naming the base class.
- Move the name table to a `.cpp` file to avoid every inclusion generating a complete copy of the strings (that the linker has to deduplicate). This is done with some care to sharply reduce the boilerplate needed in that `.cpp` file.
- Sink the name _API_ fully into the CRTP base class. This requires some significant complexity in the implementation, but all of that is hidden behind a single implementation detail macro, and the API itself is simple and readable. This also makes it much more reasonable to test the entire system a single time next to the base class.
This version also moves from constant factory functions to normal constants. This requires two batches -- first a declaration, and then a definition -- but the API result is significantly better and similar to the original option, the macro structure reduces the cost of these. Unfortunately that makes the adoption a bit noisy, but I think its worth the churn.
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
Without this, some compile setups can get a missing symbol for llvm::raw_ostream; this is relying on ostream.h through other code paths at present, so should be explicit about it.
Features:
* Add basic support for `impl` virtual methods (override virtual method)
* Error on invalid declaration for `impl` and `virtual`, covering simple use cases
* Add `abstract` fn parser-only support
Changes:
* Modify parser to handle new function specifiers, resolve conflicts
* Group `virtual_override` and `FN`, and group `impl_kind` and `IMPL` to avoid ambiguities with around `impl` token parsing
* Add new `VirtualOverride` enum for function declarations, and matching `virt_override() -> VirtualOverride` getter
* Update function declaration logic
Depends on #2462
Features:
* Add `virtual` virtual override keyword for functions
* Support `virtual` class methods using dynamic dispatch
Changes:
* Add `vtable` in `NominalClassType`,
* Add `NominalClassValue**` in class values pointing to descendant-most class
* Resolve virtual methods during member lookup
Limitations:
* Does not include yet `impl`, `abstract` virtual override keywords, or the complete logic for virtual function declaration
Depends on #2460
Relates to #1881
Relates to #2493
Protobufs code hits a warning with the latest system headers on macOS.
I figured this may have been fixed so I updated protobufs and Bazel to
the latest releases. This generally cleaned things up.
However, it actually added *more* warnings. This clearly isn't a really
well tested path. In fact, we already have a disabled warning that we'd
like for Carbon code because LLVM isn't clean for that warning.
So I've switched our warning strategy to a more durable approach of
suppressing all warnings for external repository headers and source
files. This lets us re-enable the missing warning and should fix the
protobuf warning that started me down this twisty path.
Sadly, we *have* to update to Bazel 6 in order to have the necessary
flag to use this approach to suppressing warnings, so I couldn't do this
as two PRs cleanly. =/ That's why I've bundled both the Bazel (and
protobuf) updates with the warning strategy change.
Last but not least, I've fixed several unused parameters in Carbon's
code that our warnings now catch.
Followup for #2490
The switch of DiagnosticMessage to have DiagnosticMessage means we don't need to use unique_ptr. This means that copy constructors are implicit again and don't need to be avoided, but per discussion still keeping with moves. Comments on HandleDiagnostic try to capture the use of moves there.
I'm keeping DiagnosticLevel at the top-level, and adding some checking that notes are actually Notes.
Also, adding MakeMessage to unify some of the logic (this has particularly been bugging me around format_fn, and I ran into it here because of the Diagnostic -> DiagnosticMessage change). The addition of NoTypeDeduction is intended to avoid some duplicative comments that'd been piling up.
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Richard Smith
Jon Ross-Perkins
Calvin
Adrien Leravat
Carson Radtke
Priyananda Shenoy