Noticed these issues when trying to query raw semir with
[yq](https://github.com/mikefarah/yq)
- Removed additional "}" within PrintClassFields
- Removed additional "}" after is_frozen_period_self
- Surround `int(value: 123)` in quotes to avoid issues parsing the
additional ':'
- Updated DeclaredFacetType::Print to have valid YAML structure
- Constraints are added to inline list (i.e. wrapping in `[ ... ]`)
- Switched Outer seperator to Comma.
The last two may be up for debate, maybe there's no intention for raw
semir to be true valid yaml but I think its quite useful, for example I
can now do the following:
```sh
carbon compile examples/sieve.carbon --phase=check --dump-raw-sem-ir | yq '
.sem_ir |
select(.names as $n | .classes[] | .name as $k | $n[$k] == "Sieve") |
. as $ir |
$ir.classes[] |
select(.name as $k | $ir.names[$k] == "Sieve" and .body_block_id != "inst_block_empty") |
. as $c |
($ir.inst_blocks[$c.body_block_id][] as $i | $ir.insts[$i])
'
```
outputs:
```yaml
{kind: ImplDecl, arg0: impl41000000, arg1: inst_block41000008}
{kind: ImplSelfWitness, arg0: inst41000014, arg1: specific_interface41000000, type: type(inst(WitnessType))}
{kind: FunctionDecl, arg0: function41000000, arg1: inst_block41000013, type: type(inst41000030)}
{kind: FunctionDecl, arg0: function41000001, arg1: inst_block41000023, type: type(inst4100005B)}
{kind: FieldDecl, arg0: field41000000, arg1: region41000002, type: type(inst41000065)}
{kind: CompleteTypeWitness, arg0: inst41000067, type: type(inst(WitnessType))}
```
On Zen 5, a hashtable benchmark's result depends on where its timed loop
lands in memory. With a fixed hash seed, `BM_MapContainsMiss<Map<int,
int>>/64` takes 5.5-6.3 cycles per lookup at 8 of the 16 possible loop
positions within 256 bytes, and 6.7-7.1 at the other 8, through effects
in the op cache, the BTB, and the branch predictor. Which position a
build gets is an accident of the surrounding code, so comparing two
builds conflates a change's effect with where its code landed.
Each timed loop now runs from one of 16 out-of-line copies, aligned to
256 bytes and padded in 16-byte steps, which place the loop at each of
those 16 positions. A process picks a copy at random, or the one named
in `CARBON_BENCH_LAYOUT`, and reports it in the `Layout` counter.
Running `bench_runner.py` with enough runs to sample every position, 48
for example, makes its medians and confidence intervals account for
layout.
In a sweep over 1024 bytes, performance depended only on the loop's
address modulo 256, and loop heads are 16-byte aligned, so finer or
wider padding found nothing more on this CPU.
`CARBON_BENCH_LAYOUT_PAD_STEP` and `CARBON_BENCH_LAYOUT_PAD_RANGE`
adjust it. The copies grow `map_benchmark` from 4.8 MB to 7.6 MB.
On AArch64, LLVM doesn't align loop heads for generic or Apple CPUs, so
they land on any 4-byte boundary and 16-byte steps only reach a quarter
of the positions. AArch64 builds pad in 4-byte steps instead, giving 64
layouts and growing `map_benchmark` there to 16.6 MB. Every copy,
including the unpadded one, also emits the padding `asm` statement,
because its presence changes how the surrounding code is compiled.
Assisted-by: Claude Code
---------
Co-authored-by: Nicholas Bishop <nbishop@nbishop.net>
Extend the design's keyword list with the keywords from all the approved
proposals to date. Update our four syntax highlighters to have matching
keyword lists.
There are a few other stale things in some of the syntax highlighters;
those are not fixed here.
Assisted-by: Claude via Antigravity
`InstNamer` takes O(N^2) time to resolve N colliding inst names, so it
should be limited to textual dumps (where we can presumably prioritize
readability over performance). Without this change, compiling 200,000
destructor calls took hours. With this change, compiling 1,000,000
destructor calls takes about 30 seconds.
- Add TODOs indicating places where design doc updates are needed for
accepted proposals.
- Remove TODOs about unicode which were already accurately reflected in
the text and references. Issue is that proposal #142 left some work to
do, but any such work would have to be in another proposal.
- Update design docs where only a little more was needed, like the
"lambdas" section in the main README.
- Add references sections to clarify where proposals have already been
incorporated.
- Add to TODO that was missing which proposals made the decision.
- Small fixes found when creating this PR.
Fixes#5398
Assisted-by: Gemini via Antigravity
Co-authored-by: Josh L <josh11b@users.noreply.github.com>
This allows us to collect rewrites from named constraints and use them
to initialize the witness table for an `impl as` statement.
Only rewrites from extend constraints are tracked, as other constraints
should turn into equality constraints, as they don't modify the witness
table.
This change introduces a new inst kind `CppFunctionPointerType`, which
represents an imported C++ function pointer that can be invoked from
Carbon (support for forming such a pointer from a Carbon function is in
a follow-up PR). This is implemented by treating the operation of
invoking a function pointer in C++ as if it were a call to an `__invoke`
method on the function pointer type, and extending the existing
function-import logic to support importing this fictitious method.
---------
Co-authored-by: Nicholas Bishop <nbishop@nbishop.net>
This is a step toward supporting C++ function pointer types, which need
to be
imported and thunked in much the same way as C++ functions, but have a
different
underlying representation. `CalleeFunctionInfo` gives us a way to
abstract
away the representation differences, so expressing import and thunking
in terms
of `CalleeFunctionInfo` lets us reuse that code for function pointers.
Actual support for function pointers will come in a follow-up PR, but
the
API design choices I've made here are driven by that use case.
Destruction doesn't care about constness, so we remove the
`const`-qualifier and destroy the object using its non-const type.
This is a partial implementation of #7362.
Implements `typeof(expr)`, as described in #7697. `expr` is treated as
an unevaluated operand, and is kept in an `ExprRegion` separate from the
enclosing scope.
Assisted-by: Claude via Antigravity
The AST doesn't really matter here, since it's NRVO, there's no actual
code to generate to return the value. But having a correct AST does
address at least one clang false-positive diagnostic:
```
error: stack memory associated with local variable 'return_storage' is returned
3 | fn F() -> bool {
| ^
```
Check that every use of a non-constant instruction is dominated by a
definition of that instruction. Remove the fake (instruction creation
order based) dominance checks in convert; these start spuriously failing
during template instantiation of initializers.
Assisted-by: Claude Opus 5 via Antigravity
The `self` parameter block is presumably a relic from when `self` was in
the implicit parameter list; now it's just SemIR bloat.
This also factors out some common code between `self` and the other
parameters.
Includes changes from accepted proposals:
- #3762
- #3763
- #3980
- #5366
Examples from the proposals has been updated to reflect changes made in
later proposals, such as using `ref` instead of `addr`. Links from #3762
have been changed to point to the version of the code from when the PR
was merged.
Assisted-by: Gemini via Antigravity
---------
Co-authored-by: Josh L <josh11b@users.noreply.github.com>
Co-authored-by: Geoff Romer <gromer@google.com>
`render_fixed_width_float` formatted the whole part with `int(whole)`,
which is `0` with no sign for any value in (-1, 0). A -0.669% delta
rendered as `0.669%`, identical to a +0.669% one, and only the
improvement or regression marker told them apart. Render the sign
separately. Every value outside (-1, 0) renders exactly as before.
Assisted-by: Claude Code
The `Support/LLVMDriver.h` header was renamed to `Driver.h`, and the API
of `llvm::ToolContext` changed such that a constructor call is needed
instead of aggregate initialization.
A couple new bazel deps were added (libxml2 and xz), and rules_cc
required an updated version. The addition of libxml2 and xz required
some additions to check_non_test_cc_deps.py. libxml2 also required
allow-listing an additional URL in CI jobs.
Dropped `0011_Temporarily_remove_reference_to_hermetic_toolchain.patch`,
no longer needed.
Added `0012_Drop_dependencies_on_linux_uapi_and_pyyaml.patch` to remove
a couple dependencies from llvm that Carbon doesn't currently require.
These were causing bazel queries in check_deps and
forbid_llvm_googletest.py to fail.
We use `LocId`s to refer to physical locations in source code. Those
don't exist for toolchain-generated entities, so we instead choose a
related location that can stand in for a physical location. This inlines
the generated entities' constants into their points of use, and reduces
the total amount of generated SemIR.
This is especially important for calls to `Destroy.SelfDestruct` because
these are automatically generated when any destroyable object reaches
the end its lifetime.
We've made quite a few changes to how associated constants are
implemented since this was written; update the doc to match.
Assisted-by: Claude via Antigravity
Reconstruct the call syntax from the callee's explicit parameter
patterns, the callee specific, and the call arguments.
Assisted-by: Claude via Antigravity.
* Adds function begin/end logic for non-trivial `SubobjectDestroy.Op`
* Reorganises cases in `MakeSubobjectDestroyOpBody` to use `CARBON_KIND`
so each case can be made as an independent change.
As I was starting to try to play around with carbon, I wanted nvim
integration. Unfortunately, a lot of the code in the integration had
bitrotted, but not unbearably so, so I updated it 😄
It works now! Syntax highlighting and the LSP work out of the box with
nvim 0.12 (and should also work on nvim 0.11)
Hopefully all good that I did All The Commits, I come from the school of
"every commit should do one thing"
Closes#7821
---------
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Removes support for unspecified default values. Fixes canonicalization
of the `DefaultValuePattern` instruction by making them immutable after
they are issued, and by removing the `DefaultValueId` operand which
wasn't being canonicalized.
If a line or column is unknown, we internally represent it as line or
column -1. When mapped from our 1-based numbering to LSP's 0-based
numbering, it comes out as -2, which is out of range since LSP requires
lines and columns to be >= 0.
Detect this case and produce a fallback.
Assisted-by: Claude via Antigravity
The '...Exec...' version of this benchmark runs subprocesses in a tight
benchmarking loop which seems like the likely culprit for timeouts we're
seeing on GitHub. Reduce testing to only a single one of those
benchmarks to hopefully reduce the frequency.
Add support for deferring initialization as a template action, and
performing the deferred initialization during template instantiation.
This is substantially more complex than other conversion actions, for
two primary reasons:
* The initializer in the generic may have storage arguments as inputs.
We model an initializing expression as having a "slot" where
initialization writes the location that should be initialized by that
initializing expression, and that needs to be an output of the
initialization action.
* Initialization from a tuple or struct literal needs to recurse into
that literal, and the literal will have been spelled in the generic,
meaning we don't have an `InstId` that can be used to name the specific
version of the initializer as input for nested conversions.
These issues are addressed by introducing two new features to the action
machinery:
In addition to `InstAction`, we now have `MultiInstAction`, which is an
action that produces a tuple of instruction values instead of a single
instruction value. Initialization actions produce one instruction for
the final result, which is spliced at the point of initialization, plus
one instruction for each storage argument, which are spliced into the
storage argument slots in the original generic. During initialization,
if we find one of those splices in the storage argument of an
initializing expression, we return the new storage argument back to the
initialization action to be included in the specific, instead of
overwriting the storage argument in the generic.
Actions whose `PerforrmAction` takes a `SpecificId` as input no longer
perform automatic refinement of their operands to specific instructions.
Instead, the action is given control over when and where it performs
that refinement. In `InitializeAction`, we use this freedom to form a
`SpecificInst` for the initializer in the primary output block, and form
a `SpecificInst` for the target in the target block. When detecting
whether we are initializing from a tuple or struct literal, we step over
the `SpecificInst` and track its `SpecificId`, and if necessary create a
new `SpecificInst` wrapping the sub-initializer when we recurse into the
nested element conversion.
Assisted-by: Claude and Gemini via Antigravity
This change partially implements [PR #7362], which revises how objects
are destroyed. It is a partial implementation for two reasons:
1. This change moves `Destroy.Op`'s current behaviour into
`Destroy.SubobjectDestroy`, but it doesn't add support for objects with
non-trivial destruction.
2. `Destroy.SubobjectDestroy` is a workaround for `require impls
SubobjectDestroy`. We aren't able to use the latter until the dependents
add their requirements' implementations to their own witness tables.
[PR #7362]: https://github.com/carbon-language/carbon-lang/pulls/7362
Add hover cards and jump to declaration / definition / reference for the
formatted SemIR that appears in check tests. This is done by adding a
heuristic "parser" for SemIR to the language server. The
cross-references are strictly best-effort, since this is just a tool for
Carbon developers, not a user-facing facility.
A couple of other changes made along the way:
* file_test tests with an AUTOUPDATE-SPLIT no longer look for CHECK:
lines outside that split. This was motivated by the tests for this new
facility including CHECK: lines as part of the test input.
* An agent skill for working on the language server, tracking some
things that cost Claude time when working on this.
Assisted-by: Claude via Antigravity
It had a few subtle GNU extensions in it that didn't work on macOS.
There are simple portable alternatives so it was easy to adapt.
Assisted-by: Antigravity with Gemini
When an LLM tool is used to prototype a change, one of the major tasks
it must undertake is validating filetest output changes. This skill
helps to ground that validation in some best practices and explain what
sorts of changes should or should not be expected, and how to judge
STDOUT vs STDERR changes.
Assisted-by: Opus 5
When a generic impl uses a default or final fn, it picks the specific
function value out of the interface to put in the witness table.
However, because this is done by modifying an existing instruction
block, the generics machinery has no hook to convert the function
constant into an attached constant, and because it was found in a
specific for a different generic, the constant inst will be unattached.
Fix this by manually mapping to an attached constant inst in the current
generic when building the witness table.
When there's a wildcard in a path, git treats the path as matching
exactly, unless the path also ends in a wildcard. So
`toolchain/*/testdata` only matches the testdata directory names,
whereas `toolchain/*/testdata/*` matches all the files under them.
The type `type` is now a `FacetType` inst with no constraints. This
brings the model implemented in the toolchain into better alignment with
the language design. The `SemIR::TypeType` struct remains as a scope for
holding the `TypeInstId`, `ConstantId`, and `TypeId` constants, but is
not an `InstKind` anymore.
The `TypeType` inst looks a lot like singletons, but there are many
`FacetType` insts so it doesn't quite fit that model. So we put it
alongside singletons with a fixed inst id but refer to it as a more
general "builtin" inst that is not a singleton.
`Namespace::PackageInstId` is similar, and we group it with `TypeType`
conceptually as another builtin instruction with a fixed id.
No conversion is needed anymore to use a `type` as a facet, since types
also have a `FacetType` type. This simplifies and removes a number of
helpers and branches throughout the code.
The `TypeType` inst is now part of the constant store, so we end up
printing it in the constants block in every test. But it's also named
`type` rather than `%type` to preserve the majority of existing
formatting behaviour, though this does look different from other
constants.
Assisted-by: Opus 5 was used to generate a first draft and validate the
refactoring. Though nearly everything non-trivial the tool wrote has
been modified or rewritten.
josh11bandJosh L
DavidLoftus
Chandler CarruthandNicholas Bishop
Richard Smith
Geoff Romer
Dana Jansens
Christopher Di Bella
David Blaikie
dependabot[bot]
Nicholas Bishop
nicole mazzucaandChandler Carruth
Lucile Rose Nihlen