Where `--no-dump-sem-ir` is used, change to `--dump-sem-ir-ranges=only`.
Otherwise, add `--dump-sem-ir-ranges=if-present` with a TODO to change
to `only`.
Note, SemIR is affected just because the extra comments change line
numbers in files where splits aren't in use.
Where `--no-dump-sem-ir` is used, change to `--dump-sem-ir-ranges=only`.
Otherwise, add `--dump-sem-ir-ranges=if-present` with a TODO to change
to `only`.
Note, SemIR is affected just because the extra comments change line
numbers in files where splits aren't in use.
Where `--no-dump-sem-ir` is used, change to `--dump-sem-ir-ranges=only`.
Otherwise, add `--dump-sem-ir-ranges=if-present` with a TODO to change
to `only`.
Note, SemIR is affected just because the extra comments change line
numbers in files where splits aren't in use.
Noticed this while working on class tests (crash bug). Forward declared
generics have a decl_id of the forward declaration, not the definition.
I'm giving up trying to have the caller know if it's a start node, and
instead just choosing based on the node kind.
The same specific function will (eventually) be emitted as part of
lowering multiple different source files, so don't give them unique
external linkage.
Where `--no-dump-sem-ir` is used, change to `--dump-sem-ir-ranges=only`.
Otherwise, add `--dump-sem-ir-ranges=if-present` with a TODO to change
to `only`.
Note, SemIR is affected just because the extra comments change line
numbers in files where splits aren't in use.
Previously we walked the global variables defined by the current file
and emitted an LLVM global variable definition for each of them. Now
instead, when emitting a constant reference to a global variable, we
emit an LLVM global variable declaration, and we then subsequently walk
the global variables defined by the current file and convert each of
them from a declaration to a definition.
In order to make import of names of global variables work, add support
for import of `var`, as well as support for importing `tuple_access` and
`tuple_pattern` in the case where the `var` has a tuple pattern in its
declaration. Also treat `bind_name`s that are reference bindings to
`var`s as having the same constant reference value as their `var` so
that we can properly import and lower them.
---------
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
Co-authored-by: Carbon Infra Bot <carbon-external-infra@google.com>
Entities, such as `Function`s may be created during phase 2 and need to
read the `Class`'s `scope_id` at that point, so it must be made
available earlier (in phase 2, rather than 3) when importing.
(thanks @zygoloid for explaining this all to me)
I'll look into other instances of this 3 phase lookup to see if they
have
similar bugs/if I can create test cases to tickle them as follow-ups.
---------
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Where `--no-dump-sem-ir` is used, change to `--dump-sem-ir-ranges=only`.
Otherwise, add `--dump-sem-ir-ranges=if-present` with a TODO to change
to `only`.
Where `--no-dump-sem-ir` is used, change to `--dump-sem-ir-ranges=only`.
Otherwise, add `--dump-sem-ir-ranges=if-present` with a TODO to change
to `only`.
Note, SemIR is affected just because the extra comments change line
numbers in files where splits aren't in use.
Where `--no-dump-sem-ir` is used, change to `--dump-sem-ir-ranges=only`.
Otherwise, add `--dump-sem-ir-ranges=if-present` with a TODO to change
to `only`.
Note, SemIR is affected just because the extra comments change line
numbers in files where splits aren't in use.
Where `--no-dump-sem-ir` is used, change to `--dump-sem-ir-ranges=only`.
Otherwise, add `--dump-sem-ir-ranges=if-present` with a TODO to change
to `only`.
Note, SemIR is affected just because the extra comments change line
numbers in files where splits aren't in use.
Where `--no-dump-sem-ir` is used, change to `--dump-sem-ir-ranges=only`.
Otherwise, add `--dump-sem-ir-ranges=if-present` with a TODO to change
to `only`.
Note, SemIR is affected just because the extra comments change line
numbers in files where splits aren't in use.
Where `--no-dump-sem-ir` is used, change to `--dump-sem-ir-ranges=only`.
Otherwise, add `--dump-sem-ir-ranges=if-present` with a TODO to change
to `only`.
Note, SemIR is affected just because the extra comments change line
numbers in files where splits aren't in use.
Where `--no-dump-sem-ir` is used, change to `--dump-sem-ir-ranges=only`.
Otherwise, add `--dump-sem-ir-ranges=if-present` with a TODO to change
to `only`.
Note, SemIR is affected just because the extra comments change line
numbers in files where splits aren't in use.
Where `--no-dump-sem-ir` is used, change to `--dump-sem-ir-ranges=only`.
Otherwise, add `--dump-sem-ir-ranges=if-present` with a TODO to change
to `only`.
Note, SemIR is affected just because the extra comments change line
numbers in files where splits aren't in use.
Where `--no-dump-sem-ir` is used, change to `--dump-sem-ir-ranges=only`.
Otherwise, add `--dump-sem-ir-ranges=if-present` with a TODO to change
to `only`.
Note, SemIR is affected just because the extra comments change line
numbers in files where splits aren't in use.
Where `--no-dump-sem-ir` is used, change to `--dump-sem-ir-ranges=only`.
Otherwise, add `--dump-sem-ir-ranges=if-present` with a TODO to change
to `only`.
Note, SemIR is affected just because the extra comments change line
numbers in files where splits aren't in use.
Where `--no-dump-sem-ir` is used, change to `--dump-sem-ir-ranges=only`.
Otherwise, add `--dump-sem-ir-ranges=if-present` with a TODO to change
to `only`.
Note, SemIR is affected just because the extra comments change line
numbers in files where splits aren't in use.
This test has its own directory, since #3056. We haven't added any more,
so fold it into basics. Also simplify it a little using `else`, and
`no_prelude`.
Note, I'm not even sure how much we need this test given the
`%.loc<line>_<col>`, but I feel slightly worse deleting it.
When a pattern is an error, avoid wrapping it as a subpattern in a
RefParamPattern or VarPattern. This allows further error handling to
observe the error occurred without having to unwrap it.
This avoids a crash when an invalid associated constant is written which
has a VarPattern in it. The associated constant machinery expects an
AssociatedConstantDecl but was getting a VarPattern with an ErrorInst
inside. Now it receives an ErrorInst directly, which it is already
looking for.
This choice means that `var` statements in an `interface` will always be
diagnosed as being non-constant, or as being a constant with a `var`, so
we don't need an extra diagnostic saying that `var` is not allowed in an
interface, as this just leads to two diagnostics on the same thing.
This crash was found by a fuzzer.
Tinkering with #5517, splitting out this suggestion to try to avoid
delaying merge. I figured out what I was missing on the variadiac
expansion. :)
(and also realized the struct could probably be a function)
Updating tests in the style of
https://github.com/carbon-language/carbon-lang/pull/5455.
- Moving `Run`-specific tests into their own directory, with a README to
explain why it's unusual.
- Note, I suspect we'll also get more over time (e.g., with arguments)
- This makes a little more use of `if-present` just because there are
more tests that want to print their full output.
- I'm combining the two empty-ish tests, thought I do still want the
*really* empty one to be fully empty (i.e., no tokens provided by the
file).
- Dropping multifile.carbon because it doesn't seem like an interesting
test to keep.
Move the operation of resolving the specific decl block from
`GetConstantValue()` to `TryEvalTypedInst()`, with is now happening
after replacing the fields of the instruction with new constant values,
but before running the evaluation of the instruction. Since imported
instructions are not evaluated, this avoids resolving the specific decl
block from imported instructions, resolving a TODO in
`AddImportedConstant()`. Now `AddImportedConstant()` can replace
constant values in its fields without having to worry about that
operation resolving any specific decl blocks.
We get to add a new TODO however, to explain why we still need a special
case in resolving specific decl blocks for handling `Impl` construction.
The witness table contains instructions with specifics referring to the
generic self of the impl declaration. But the table must be constructed
before the impl's generic is finished, in order to make the instructions
dependent for the generic. But then resolving the specific decl block
can't be done when the instructions are created and evaluated, as that
requires a finished generic.
---------
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
Note the amount of IR excluded is pretty small, but non-zero (mainly
prelude-related, due to the way a choice depends on `UInt`)
Renaming fail_todo_params.carbon to just params.carbon, and folding in
fail_invalid.carbon.
Updating tests in the style of
https://github.com/carbon-language/carbon-lang/pull/5455.
Notable things for builtins:
- #4748 disabled semir output in int tests, but not other tests. After
discussion with zygoloid, adding ranges just for runtime calls that seem
significant. The rest can rely on type checking to demonstrate
correctness.
- Fixes cases of things like `RuntimeCallIsValidBadReturnType` using the
wrong number of args, and being invalid as a result.
- Splits out the too few, too many, and bad return type tests -- I think
this helps highlight where the above is an issue.
- Expands use of `library "[[@TEST_NAME]]";` in tests where package
names were previously in use.
Ranges tests were already updated for splits, so not really touching
that. Also, the prelude interaction gets a little gnarly because these
also partly test prelude bits.
---------
Co-authored-by: David Blaikie <dblaikie@gmail.com>
This refactors `CollectNamesInBlock` to pull out the lambdas and try to
give the switch its own function. I'm hoping that, on the whole, this
makes the flow a little easier to see.
This also moves `AnyBranch` handling into the switch, instead of before
the switch.
Note, I think the helper class approach is still a little complex, but I
believe it should be negligible cost. And I couldn't think of a better
way to translate the lambdas to helper functions without adding required
arguments at the call site, which I suspected might be a source of
readability friction.
In LLVM, CLANG_DEFAULT_PIE_ON_LINUX is
[configurable](https://github.com/llvm/llvm-project/blob/main/clang/test/CMakeLists.txt#L8),
so change lowering to specify a value.
Also, adjust how the target is set so that function_decl.carbon isn't
trying to overload every flag, and so that the target isn't forgotten
elsewhere.
This is fixing issues introduced by #5427; note #5520 is also a related
fix.
---------
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Outside of `match_first` this adds diagnostics for invalid non-final and
final `impl` declarations in line with those being proposed in
https://github.com/carbon-language/carbon-lang/pull/5337.
- Two non-final `impl`s with the exact same type structure is invalid.
- A `final impl` that matches the self/constraint of another `impl` as a
query would always be preferred, making the second one invalid.
- Two `final impl`s that overlap (have compatible type structures) in
different files is invalid.
- Two `final impl`s that overlap (have compatible type structures) in
the same file is invalid outside of `match_first`.
- A `final impl` in a different file from its root self type and
interface is invalid.
We add tests for all these scenarios as well as correct scenarios.
The "compatible" test for two type structures was being done
symmetrically, which is incorrect. We want it to test that a query type
structure is the same _or more specific_ in a compatible way with an
impl's type structure. This is corrected in the implementation, and the
diagnostics now have to test both directions to get the desired output,
as expected.
---------
Co-authored-by: josh11b <15258583+josh11b@users.noreply.github.com>
For an `IdKind value`, `CARBON_CHECK(false, "{0}", value)` prints the
`Label` of the id type in place of the `{0}`. For different inst types,
we would like to display `TypeEnum(...)` with the actual inst type
rather than always `TypeEnum(inst)`. The latter is misleading,
suggesting the `IdKind` value is `InstId` when it may be `TypeInstId`,
or `MetaInstId`, etc.
Updating tests in the style of
https://github.com/carbon-language/carbon-lang/pull/5455.
I'm leaving adapter_conversion.carbon pretty much as-is because of the
`adapt_i32.carbon` test, which I'm not clear how critical `i32` is there
but feels specific enough that maybe it can't be `min_prelude`. Other
tests felt all pretty reasonable to adjust to `min_prelude` and a single
file (`basics.carbon`).
Updating tests in the style of #5455.
array indexing requires integers, so this is a more prelude-dependent
area than some. But as it turns out, writing something like `3` never
references `Core.IntLiteral` so seeing if I can roll with more minimal
preludes.
This requires:
* Making `FunctionDecl` mutable since generating code
(`HandleTopLevelDecl()`) requires a mutable declaration and since we
manually add `used` attribute to force code generation.
* Passing the file system to `Lower` since it's needed by Clang code
generation.
* Creating an internal Clang LLVM module and link it against the Carbon
LLVM module.
Demo:
```c++
// hello_world.h
extern int puts;
inline void hello_world() {
((int (*)(const char*))&puts)("hello world");
}
```
```carbon
// main.carbon
library "Main";
import Cpp library "hello_world.h";
fn Run() -> i32 {
Cpp.hello_world();
return 0;
}
```
```shell
$ bazel-bin/toolchain/carbon compile main.carbon
$ bazel-bin/toolchain/carbon link main.o --output=demo
$ ./demo
hello world
```
Based on https://github.com/carbon-language/carbon-lang/pull/5406.
Part of #5405.
- Track the `VarPattern` instruction on the `VarStorage` instruction so
that it's available for name mangling.
- Mangle global variables based on the first binding name within their
pattern.
- Give global variables external rather than internal linkage, except if
they have no bindings whatsoever in their pattern.
- To support lowering references to bindings nested within a global var,
such as for `var (x: i32, b: i32)`, add some basic initial support for
reference constant expressions. Treat a global `var` as a reference
constant, and treat an aggregate access into a reference constant as a
reference constant.
Taking a stab at restructuring towards allowing better reuse. Some of
that is with `AnyAggregateInit` and `AnyImportRef`. Some with
`FormatDeclRhs`.
This adds a `FormatArg` dispatch table so that `FormatInstRhs` doesn't
rely as heavily on templating. I'm mixed on the intermediate result -- a
step further might be to change `FormatArg` to dispatch to a
`FormatArgAndKind` that could use a switch. But, figured I'd check in on
the general direction.
Note this kind of direction opens up changing `FormatInst` to not be
templated, too, removing the `#define CARBON_SEM_IR_INST_KIND(InstT)`
variant of `FormatInst`.
I'm trying to make the offsetting a little easier to understand, and
also get a better `requires` structure on calls. The second is for an
attempt to refactor the `Formatter` API, but also changing the `InstId`
`derived_from` requires seems helpful for clarity on what's really
happening.
We make 5 changes:
- Allow `require Self impls I` in an `interface` or `constraint` scope
to omit the `Self`, so it can be written `require impls I`.
- Rename `extend I` to `extend require impls I` in an `interface` or
`constraint` scope.
- Define `extend impl as I` and `extend final impl as I` in an
`interface` scope to copy the members of `I` and define an `impl` of `I`
in terms of the extending interface.
- Allow a non-final `impl` to overlap a final `impl` as long as it isn't
subsumed by the final `impl`. The final `impl` will be given priority on
the overlap.
- Allow `final` on a `match_first` block, used to declare overlapping
final impls.
These features work together to allow a form of interface extension
where:
- Types only need to `impl` the extending interface to also get an
`impl` of the extended interface.
- Multiple interfaces can extend the same interface.
- An interface can extend multiple interfaces.
---------
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>
Co-authored-by: Carbon Infra Bot <carbon-external-infra@google.com>
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
This proposal re-affirms (with additional rationale) that a `var`
pattern
declares a durable complete object, and refines the terminology for
binding
patterns in a `var` pattern to be more explicit about the intended
semantics. It
also makes several other changes and clarifications to the semantics of
pattern
matching on objects:
- The storage for a variable pattern is initialized eagerly, rather than
being
deferred until the end of pattern matching.
- Any initializing expressions in the scrutinee of a `match` statement
are
materialized before matching the `case`s.
- An initializing expression can only initialize temporary storage or a
single
variable pattern, not a tuple/struct pattern or a subobject of a
variable
pattern. Removing this limitation is left as future work.
Finally, as a drive-by fix, it clarifies what parts of the `match`
design are
still placeholders.
---------
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
Jon Ross-Perkins
Richard Smith
David BlaikieandRichard Smith
Thomas Köppe
Dana Jansens
Boaz Brickner
Geoff RomerandJon Ross-Perkins