Shorthand names are intended to be used in the textual format of
references to instructions in another IR (which can't happen now, but
will be possible in a forthcoming PR). The shorthand name uses the file
name (minus the `.carbon` suffix) as a base, and if that base name is
ambiguous within the compilation, it is given a numerical suffix `.N`,
just like other textual IR names. Shorthand names are prefixed with `$`
in the textual format, to distinguish them from inst and scope names.
For example, a file `foo/bar.carbon` has the shorthand name `$bar`, and
an instruction `@baz.%qux` in that file can be referenced from another
file as `$bar.@baz.%qux`.
This PR adds `toolchain/check/testdata/basics/file_name.carbon` to test
this behavior. All other test changes are just applying this change to
the existing textual SemIR dumps.
---------
Co-authored-by: Dana Jansens <danakj@orodu.net>
Determining that a type has trivial destruction requires checking
whether all of its subobjects have trivial destruction and whether its
type has a custom witness for `Destroy.Op`. This isn't possible when
`Destroy` is the custodian for `Destroy.Op` and `SubobjectDestroy.Op`,
so we need to make `SubobjectDestroy` its own interface.
`Destroy.SelfDestruct` becomes a standalone function because it depends
on `SubobjectDestroy` and `Destroy` being implemented, and is also
responsible for generating any custom witnesses for both interfaces.
Making `SelfDestruct` an interface was experimented with, but this
required a blanket impl that caused issues for facet types.
`Destroy` depends on `SubobjectDestroy` to be implemented. We'd ideally
use `require impls SubobjectDestroy`, but it isn't complete yet, and it
also causes problems when `Destroy` is implemented inside the class
definition. We work around this by temporarily renaming the `Destroy`
interface to `DestroyImpl`, and introducing a constraint called
`Destroy` so that user code doesn't need to write `Core.SubobjectDestroy
& Core.Destroy`.
A first step in expanding support for default values for parameters in
generic functions.
Adds code to parameter type deduction to include default values for
absent call arguments. In support of that, this PR also generalizes a
function from `export.cpp` that is useful to extract a default
`ConstantId` value from an arbitrary function paramater pattern.
Geoff RomerandDana Jansens
Christopher Di Bella
Lucile Rose Nihlen