carbon-language/carbon-lang
1
0
Fork 0
mirror of https://github.com/carbon-language/carbon-lang.git synced 2026-10-05 22:02:55 +01:00
Code Issues Packages Projects Releases 10 Wiki Activity

Add builtin functions for destroy, with special requirements in facet types (#6035)

Browse Source 
This is in support of a goal of changing the blanket `destroy` impl to
use (roughly):

```
private fn CanAggregateDestroy() -> type = "type.can_aggregate_destroy";

// Handles aggregate type destruction.
impl forall [AggregateDestroyT:! CanAggregateDestroy()] AggregateDestroyT as Destroy {
  fn Op[addr self: Self*]() = "type.aggregate_destroy";
}
```

That isn't done here because there's still other issues that migrating
raises. What this *does* do is add the builtin functions, and in
particular, support to `FacetTypeInfo` to make `CanAggregateDestroy`
work.

The "special requirement" approach in `FacetTypeInfo` allows us to
support restricting a blanket impl under the current approach of impls.
Maybe we'll find a cleaner approach that can work in the future, but
this fits into the current model by propagating similar to other
requirements. I'm using an enum mask because we have a number of similar
things to add (e.g. copy, move) but I'm not sure we need a full vector.

A few alternatives considered were:

- Supporting syntax more like `where .Self impls
TypeCanAggregateDestroy(.Self, SupportedInterface,
UnsupportedInterface)`. I think it'd be a little cleaner, but requires
better compile-time evaluation in order to assess the type of the call.
Right now it's expected to be a `FacetType` too early to make this work,
and I was concerned about pouring too much more time down this route.
- Providing an actual interface, in particular doing name lookup back
into `Core.` for an interface. This would've added name lookup overhead,
and the question of whether an `impl` exists.
- Generating an interface. This avoids the name lookup, but would still
raise the question of whether an `impl` should also be generated. Work
I've previously done generating interfaces for class destruction also
feels complex to both write and understand (an unfortunate issue).
- Still modeling as an `ImplsConstraint`, for example by defining a
special `InterfaceId::CanAggregateDestroy = -2` similar to what we do on
other ids. I was hesitant because of how this expands the number of
modes of `InterfaceId`, and things for consuming code to watch out for,
for what feels like a relatively niche set of use-cases that are only
interface-like.

---------

Co-authored-by: Dana Jansens <danakj@orodu.net>
This commit is contained in:
Jon Ross-Perkins
2025-09-15 17:03:43 +00:00
committed by GitHub
co-authored by Dana Jansens
parent 3ec0bcb4fd
commit 5e3bb523f8
401 changed files with 20575 additions and 20097 deletions
Download Patch File Download Diff File Expand all files Collapse all files
toolchain/lower/testdata/function/generic/call_basic_depth.carbon
Vendored
+6 -6
View File
@@ -48,7 +48,7 @@ fn M() {
// CHECK:STDOUT: %.loc34 = load i32, ptr %n.var, align 4, !dbg !9
// CHECK:STDOUT: call void @_CF.Main.b88d1103f417c6d4(i32 %.loc34), !dbg !10
// CHECK:STDOUT: %.loc35_9 = load i32, ptr %n.var, align 4, !dbg !11
// CHECK:STDOUT: %G.call = call i32 @_CG.Main.b7c8e4dff2adcdaa(i32 %.loc35_9), !dbg !12
// CHECK:STDOUT: %G.call = call i32 @_CG.Main.de631560529e9861(i32 %.loc35_9), !dbg !12
// CHECK:STDOUT: store i32 %G.call, ptr %m.var, align 4, !dbg !13
// CHECK:STDOUT: ret void, !dbg !14
// CHECK:STDOUT: }
@@ -61,14 +61,14 @@ fn M() {
// CHECK:STDOUT: ret void, !dbg !16
// CHECK:STDOUT: }
// CHECK:STDOUT:
// CHECK:STDOUT: define linkonce_odr i32 @_CG.Main.b7c8e4dff2adcdaa(i32 %x) !dbg !17 {
// CHECK:STDOUT: define linkonce_odr i32 @_CG.Main.de631560529e9861(i32 %x) !dbg !17 {
// CHECK:STDOUT: entry:
// CHECK:STDOUT: %H.call = call i32 @_CH.Main.b7c8e4dff2adcdaa(i32 %x), !dbg !18
// CHECK:STDOUT: %H.call = call i32 @_CH.Main.de631560529e9861(i32 %x), !dbg !18
// CHECK:STDOUT: call void @_CF.Main.b88d1103f417c6d4(i32 %x), !dbg !19
// CHECK:STDOUT: ret i32 %x, !dbg !20
// CHECK:STDOUT: }
// CHECK:STDOUT:
// CHECK:STDOUT: define linkonce_odr i32 @_CH.Main.b7c8e4dff2adcdaa(i32 %x) !dbg !21 {
// CHECK:STDOUT: define linkonce_odr i32 @_CH.Main.de631560529e9861(i32 %x) !dbg !21 {
// CHECK:STDOUT: entry:
// CHECK:STDOUT: call void @_CF.Main.b88d1103f417c6d4(i32 %x), !dbg !22
// CHECK:STDOUT: ret i32 %x, !dbg !23
@@ -99,10 +99,10 @@ fn M() {
// CHECK:STDOUT: !14 = !DILocation(line: 30, column: 1, scope: !4)
// CHECK:STDOUT: !15 = distinct !DISubprogram(name: "F", linkageName: "_CF.Main.b88d1103f417c6d4", scope: null, file: !3, line: 16, type: !5, spFlags: DISPFlagDefinition, unit: !2)
// CHECK:STDOUT: !16 = !DILocation(line: 16, column: 1, scope: !15)
// CHECK:STDOUT: !17 = distinct !DISubprogram(name: "G", linkageName: "_CG.Main.b7c8e4dff2adcdaa", scope: null, file: !3, line: 24, type: !5, spFlags: DISPFlagDefinition, unit: !2)
// CHECK:STDOUT: !17 = distinct !DISubprogram(name: "G", linkageName: "_CG.Main.de631560529e9861", scope: null, file: !3, line: 24, type: !5, spFlags: DISPFlagDefinition, unit: !2)
// CHECK:STDOUT: !18 = !DILocation(line: 25, column: 3, scope: !17)
// CHECK:STDOUT: !19 = !DILocation(line: 26, column: 3, scope: !17)
// CHECK:STDOUT: !20 = !DILocation(line: 27, column: 3, scope: !17)
// CHECK:STDOUT: !21 = distinct !DISubprogram(name: "H", linkageName: "_CH.Main.b7c8e4dff2adcdaa", scope: null, file: !3, line: 19, type: !5, spFlags: DISPFlagDefinition, unit: !2)
// CHECK:STDOUT: !21 = distinct !DISubprogram(name: "H", linkageName: "_CH.Main.de631560529e9861", scope: null, file: !3, line: 19, type: !5, spFlags: DISPFlagDefinition, unit: !2)
// CHECK:STDOUT: !22 = !DILocation(line: 20, column: 3, scope: !21)
// CHECK:STDOUT: !23 = !DILocation(line: 21, column: 3, scope: !21)