Most of the logic is actually in `GetIdentifierName`. I'm moving the
`CHECK` there for better sharing, also with `IdentifierNameExprId`.
Note this PR is mainly motivated by #5045, which would make this the
only place that needs `AnyNonExprIdentifierNameId` in specific (other
places need to deal with both identifiers and keywords).
Inconsistent execution environments make using a path-as-define
difficult, so switch to an embedded file.
Also fixes the lldb launch so that passing tests run cleanly, and adds
TEST_TARGET to gdb (but without testing there). I'm dropping `sourceMap`
because it's not handled quite correctly (also not great to be trying to
pass source mappings in two different ways), and `env` didn't seem to be
working as intended either; maybe specifying `initCommands` causes other
things to not be evaluated. But the straight `initCommands` looks like
it's working. I used lldb to validate execution of these changes.
```
Running initCommands:
(lldb) command script import external/+llvm_project+llvm-project/llvm/utils/lldbDataFormatters.py
(lldb) settings set target.source-map "." "/usr/local/google/home/jperkins/dev/carbon-lang"
(lldb) settings set target.source-map "/proc/self/cwd" "/usr/local/google/home/jperkins/dev/carbon-lang"
(lldb) env TEST_TARGET=//toolchain/testing:file_test
(lldb) env TEST_TMPDIR=/tmp
Running tests with 128 thread(s)
.
Done!
Note: Google Test filter = ToolchainFileTest.toolchain/check/testdata/const/collapse.carbon
[==========] Running 1 test from 1 test suite.
[----------] Global test environment set-up.
[----------] 1 test from ToolchainFileTest
[ RUN ] ToolchainFileTest.toolchain/check/testdata/const/collapse.carbon
[ OK ] ToolchainFileTest.toolchain/check/testdata/const/collapse.carbon (0 ms)
[----------] 1 test from ToolchainFileTest (0 ms total)
[----------] Global test environment tear-down
[==========] 1 test from 1 test suite ran. (1 ms total)
[ PASSED ] 1 test.
Process 3869310 exited with status = 0 (0x00000000)
```
The resulting facet type has its complete facet type canonicalized by
sorting and deduplicating the `required_interfaces`.
Impl lookup now uses the complete facet type. It continues to diagnose
with a TODO if it sees a complete facet type with 0 or more than 1
interface in it. Impl lookup to convert from a type to a facet value
hits this diagnosis.
Member lookup by name works on a facet type with more than one interface
because the name knows which interface to look for from the name, and
AppendLookupScopesForConstant() looks through all interfaces on the
complete facet type already to get the correct scope for the name.
---------
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
Doing so results in TODOs in the resulting semir, since we don't handle
combining the facet types together properly or doing lookup into them.
There's a test added demonstrating this, which will be made to work in
followups.
---------
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
When finding the binding entity name, always go through the binding
instruction's constant value to get a canonical instruction which will
always have an entity name attached to it.
Currently the only instructions in this position without an entity name
are ImportRefLoaded. But other indirect instructions may exist in the
future, which evaluate to an AnyBindName but are not themselves one. So
this makes the code more robust to change in the future.
This tripped over a lowering crash when a member function with self was
declared-but-not-defined, so that's why some test cases were updated to
have (empty) function definitions.
I'll follow-up with/look into a fix for the
self-declared-but-not-defined cases separately.
---------
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
Co-authored-by: Carbon Infra Bot <carbon-external-infra@google.com>
We had a long discussion of this, so trying to document what seems to be
the conclusion... and also clean up the exceptions that I could find.
---------
Co-authored-by: Dana Jansens <danakj@orodu.net>
Replace the large and growing `TryEvalInstInContext` function with one
function per kind. While we still have special-case handling for a small
number of instruction kinds, most instructions are now handled either
fully automatically or use a common codepath that evaluates the
instruction operands and then performs an eval-context-independent
evaluation of the instruction.
To support this, `InstConstantKind` is expanded to describe more
fine-grained details about how each kind of instruction interacts with
constant evaluation. Also, the operand kinds of instructions become
slightly more fine-grained: we now distinguish between operands that
describe the destination of an initializing expression (`DestInstId`)
from other `InstId` operands, because `DestInstId` operands need
different treatment during constant evaluation. In particular, an
initializing expression can have a constant value even if its
destination is non-constant or has not yet been set, because evaluation
of an initializing expression doesn't include the store to the
destination.
Some minor test changes:
- We now more consistently propagate errors into the results of constant
evaluation, so more instructions that depend on errors have a constant
value of `<error>`.
- Diagnostic location for invalid array types now point at the whole
array type rather than the array index expression, because
`EvalConstantinst` doesn't have access to the original expression.
- Diagnostic for failed `RequireCompleteType` doesn't print the original
type any more because `EvalConstantInst` doesn't have access to the
original expression.
As a follow-up, some of this -- in particular, the `EvalConstantInst`
overloads -- will be moved to a separate file, in an effort to split the
overall constant evaluation machinery apart from the logic to evaluate
each individual kind of instruction.
An imported generic has bindings which are of type ImportRefLoaded, and
if they come from another package, they have no entity name attached to
them.
Since a binding name is always a constant-time value, we can get the
constant value instruction for the imported instruction to get a
canonical non-imported instruction. And that one will have a local
`NameId`.
---------
Co-authored-by: josh11b <15258583+josh11b@users.noreply.github.com>
We were discussing this, `long term` only applies to issues and not PRs
(per past discussion, we don't really expect PRs should be inactive for
months). Renaming to `long term issue` to be more specific and hopefully
reduce confusion.
There aren't remaining uses on `Context` other than `DiagnosticEmitter`
itself. I'm adding `SemIRLoc` because I feel odd about having both
`Carbon::Check::DiagnosticBuilder` and
`Carbon::DiagnosticEmitter<T>::DiagnosticBuilder`, but it seems
relatively little additional typing outside the handful of
`DiagnosticEmitter` uses on `Context` itself:
```
Context::DiagnosticEmitter
DiagnosticEmitter<SemIRLoc>
Context::DiagnosticBuilder
SemIRLocDiagnosticBuilder
Context::BuildDiagnosticFn
BuildSemIRLocDiagnosticFn
```
Also clean up #include's while I'm finishing here.
Doing an in-file X-macro, though maybe we'll want to move it out to a
#include if we keep piling on more. I know there's `destroy` to add, and
possibly `copy` and `move`, but I don't know what threshold we'll want
for a separate file.
Note this does set up for an advantage where we can `switch` instead of
repeated `if` for special names, shifting to compile errors for new
values.
I also considered a simpler enum approach (with an implicit conversion
to `NameId`) but that runs into issues with things like
`Id::Kind::For<...>` as a consequence of calls like `name_id ==
special_name_id` (just requires another `operator==`) and
`context.node_stack().Push(node_id, SemIR::NameId::SelfType);` (a little
more complex how we'd want to handle it).
Right now, some post-run logic is does in `Run()`
(`CheckRequiredDefinitions();` and
`context_.sem_ir().set_has_errors(unit_and_imports_->err_tracker.seen_error());`)
whereas other parts are done by `Finalize`. Noting the goal to move
things off `Context`, this consolidates into a new `FinishRun`. Note
#4962 is adding another bit of post-run that can be consolidated in;
this seems likely to keep growing slowly.
Note this also creates more parity with mutation source, like the
`context_.scope_stack().Pop();` matches the push done by
`CheckUnit::ImportCurrentPackage` and
`context_.inst_block_stack().Pop()` was pushed in `CheckUnit::Run()`.
Also makes `exports()` more consistent with other Context APIs. Makes
`VerifyOnFinish` `const` so that it can't accidentally mutate state, and
is instead only validating that the Context is in its expected
configuration at completion.
This takes the mechanism currently used for autoupdate and expands it to
the regular tests (deliberately trying to unify logic for
test/autoupdate/dump to deliver consistent behavior). I'm seeing about a
85% reduction in test time, though results will vary based on test
system.
This does some small edits to test output to make it fit better with the
new flow. Note I'm stopping printing of the "here's how to run" on every
test by default, since it's autoupdated into file content by default.
However, it's still there for test failures.
---------
Co-authored-by: Geoff Romer <gromer@google.com>
Noted CopyNameFromImportIR while glancing around (this one's interesting
because it's NameId, not void nor auto), did a scan just for a few other
cases. Not an exhaustive fix, and TBH assuming we'd prefer `auto ... ->
auto` since equivalent Carbon syntax would probably be `fn ... -> auto`
If the `impl as` clause is on a generic interface, the parameters to the
generic may be constrained by _other_ interfaces. This then requires
another impl lookup, but it should be looking for a different impl since
it's for a different interface.
To avoid considering the same impl again, we discard it from
consideration if the interface itself does not match the interface being
queried.
Note that the query FacetType can have more than one interface in it
eventually, and a `context.TODO()` call is left to notify when we run
into this.
Make facet types complete like other types. This means that in the body
of an interface, the type of `Self` is incomplete. This involved fixing
an issue where eval of a specific_id that was already canonical was not
resolving the specific declaration, which could occur as part of
substituting into a facet type.
---------
Co-authored-by: Josh L <josh11b@users.noreply.github.com>
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Co-authored-by: Dana Jansens <danakj@orodu.net>
Emit diagnostics for a function declared in a non-owning library, that
is not redeclared (or defined) in the owning library.
---------
Co-authored-by: jonmeow <jperkins@google.com>
I believe this reflects the intent, but the phrasing of "even if
`MyBaseClass` is not" implies that `MyBaseClass` _can_ be final in
`partial MyBaseClass`. Also, make clear it's allowed on `abstract`
classes, not only `base` (this seems explicitly intended from the
`MyAbstractClass` example around line 1482).
This removes the separately built and installed LLD binary. The symlinks
used by Clang when directly invoking LLD now point back to the main
`carbon-busybox` binary and dispatch through the newly added subcommand.
With this change we're down to shipping a single busybox binary in the
toolchain, removing duplicate installed copies of LLD and all its LLVM
dependencies. =]
The LLD subcommand works a bit differently from the `clang` subcommand
because the CLI for LLD is specific to which platform flavor of linker
is being invoked.
As part of this, I've extracted some of the common functionality in the
Clang runner into a base class that can be re-used. I expect to use this
again in a follow-up change to add subcommands to run other LLVM tools.
---------
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
The CompleteFacetType value store is now a RelationalValueStore. This
type of store uses some _other_ id as the key for insertion. It allows
checking if values of the _other_ id are present in the store, since
those ids are handed out by another store and will (necessarily) exist
before there is a matching value in the RelationalValueStore.
The lookup for precense of the _other_ id returns the id of a value in
the RelationalValueStore. That id can be used to get the value out of
the store.
For our use case, the RelationalValueStore maps from FacetTypeId to
CompleteFacetTypeId. So you add a CompleteFacetType to the store with a
FacetTypeId. Then you can query with a FacetTypeId to see if there
exists a CompleteFacetTypeId. And if there is, you can use that
CompleteFacetTypeId thereafter to get the CompleteFacetType value from
the store.
This removes the need for ValueStore::GetMutable() and removes the
method. FacetTypeInfo no longer has a field that needs to be carefully
excluded from hash and comparison.
In line with the proposal in #4682, this changes the array syntax to be
array(T, N). `array` is a builtin keyword which must be followed by
parens containing two expressions and a separating comma.
The array type expression is still fully builtin, it does not forward to
a Core.Array library type yet. It merely adds the `ArrayType`
instruction, as was done with the previous syntax.
Followup work will change the instruction to reference to Core.Array,
once the library type exists and can be used directly.
---------
Co-authored-by: zygoloid <richard@metafoo.co.uk>
Expands the CompleteTypeInfo to include information about abstract
classes and computes that information as part of completing the type.
---------
Co-authored-by: Josh L <josh11b@users.noreply.github.com>
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Co-authored-by: Dana Jansens <danakj@orodu.net>
On my machine, the LLVM debug information seems to use source file paths
relative to `/proc/self/cwd`, which is the current working directory of
whatever process refers to it. Consequently, VSCode can't find those
files, because it has a different current working directory. This change
enables VSCode to rewrite those paths to a usable form.
Currently the toolchain does not recognize that tuples and structs with
abstract elements should be considered abstract.
Also make the existing `fail_abstract` test into a `no_prelude` test.
Co-authored-by: Josh L <josh11b@users.noreply.github.com>
These tests expose cycles during deduction, when the generic parameters
in an impl statement require deduction and the impl clause that
satisfies them comes after the one containing the generic parameters.
This causes the same impl to be looked at repeatedly, and produces a
cycle diagnostic.
---------
Co-authored-by: Geoff Romer <gromer@google.com>
We propose to add `Core.Array(T, N)` as a library type in the `Core`
package. Since arrays are a very frequent type, we propose to privilege
use of this type by including it in the `prelude` library of the
package.
We would like to see a shorthand where `Core.Array` is automatically
imported into the file scope, and this proposal includes future work to
this effect.
Boaz Brickner
Jon Ross-Perkins
Richard Smith
Alina Sbirlea
Dana JansensandJon Ross-Perkins
Chandler CarruthandJon Ross-Perkins