[codegen/go] Remove ResourcePtr input/output types #8449
Conversation
|
cc @mikhailshilkov : this will definitely have some effect on SDK sizes, though I haven't yet measured it. |
|
These changes also fix the element types for |
|
Diff for pulumi-azuread with merge commit 6582e74 |
|
Diff for pulumi-random with merge commit 6582e74 |
|
Diff for pulumi-kubernetes with merge commit 6582e74 |
|
Diff for pulumi-gcp with merge commit 6582e74 |
|
Diff for pulumi-azure with merge commit 6582e74 |
|
Diff for pulumi-aws with merge commit 6582e74 |
|
Diff for pulumi-azure-native with merge commit 6582e74 |
|
Diff for pulumi-random with merge commit 925b05a |
|
Diff for pulumi-azuread with merge commit 925b05a |
|
Diff for pulumi-kubernetes with merge commit 925b05a |
|
Diff for pulumi-gcp with merge commit 925b05a |
|
Diff for pulumi-azure with merge commit 925b05a |
|
Diff for pulumi-aws with merge commit 925b05a |
|
@pgavlin I don't see much changes in https://github.com/pulumi-bot/pulumi-azure-native/compare/c62ea8d3cd6..828691f7e76 |
|
Diff for pulumi-azure-native with merge commit 925b05a |
pgavlin
force-pushed
the
pgavlin/resourcePtr
branch
from
c7c182f
to
eeb39e3
Compare
Ah, I think there's not much of a change there b/c azure-native already disables these types by leaving the |
|
...which makes me even more confident that we should take this change, as it further limits the potential set of breaks. |
|
Diff for pulumi-azuread with merge commit 8bc655f |
|
Diff for pulumi-random with merge commit 8bc655f |
|
Diff for pulumi-kubernetes with merge commit 8bc655f |
|
Diff for pulumi-gcp with merge commit 8bc655f |
|
Diff for pulumi-azure with merge commit 8bc655f |
|
Diff for pulumi-aws with merge commit 8bc655f |
|
@pgavlin, Will this change leave |
|
cc @stack72 as well |
|
Diff for pulumi-kubernetes with merge commit 6dcd3ed |
|
Diff for pulumi-gcp with merge commit 6dcd3ed |
|
Diff for pulumi-azure with merge commit 6dcd3ed |
|
Diff for pulumi-aws with merge commit 6dcd3ed |
|
I've filed follow up as #8477 New information: the scope of the remaining problem is thankfully a lot smaller than I thought. It affects URN property only, and is not related to Map/Array helpers. The problem is present on master and remains unchanged with this PR. |
|
Diff for pulumi-random with merge commit bd13f6e |
|
Diff for pulumi-azuread with merge commit bd13f6e |
|
Diff for pulumi-kubernetes with merge commit bd13f6e |
|
Diff for pulumi-gcp with merge commit bd13f6e |
|
Diff for pulumi-azure with merge commit bd13f6e |
|
Diff for pulumi-azure-native with merge commit 6dcd3ed |
|
Diff for pulumi-aws with merge commit bd13f6e |
|
Diff for pulumi-azure-native with merge commit bd13f6e |
These changes remove the `Ptr` variants of input/ouptut types for
resources. A `TPtr` input or output is normally generated for `T` if `T`
is present in an `optional(input(T))` or `optional(output(T))` and if
the Go representation for `T` is not nilable. The generation of `Ptr`
variants for resource types breaks the latter rule: the canonical
representation of a resource type named `Foo` is a pointer to a struct
type named `Foo` (i.e. `*Foo`). `Foo` itself is not a resource, as it
does not implement the Go `Resource` interface. Because this
representation already accommodates `nil` to indicate the lack of a
value, we need not generate `FooPtr{Input,Output}` types.
Besides being unnecessary, the implementation of `Ptr` types for
resources was incorrect. Rather than using `**Foo` as their element
type, these types use `*Foo`--identical to the element type used for
the normal input/output types. Furthermore, the generated code for
at least `FooOutput.ToFooPtrOutputWithContext` and `FooPtrOutput.Elem`
was incorrect, making these types virtually unusable in practice.
Finally, these `Ptr` types should never appear on input/output
properties in practice, as the logic we use to generate input and output
type references never generates them for `optional({input,output}(T)).
Instead, it generates references to the standard input/output types.
Though this is _technically_ a breaking change--it changes the set of
exported types for any package that defines resources--I believe that in
practice it will be invisible to users for the reasons stated above.
These types are not usable, and were never referenced.
This is preparatory work for #7943.
pgavlin
force-pushed
the
pgavlin/resourcePtr
branch
from
6056723
to
d8aa4fc
Compare
|
Diff for pulumi-azuread with merge commit 43a8d0a |
|
Diff for pulumi-random with merge commit 43a8d0a |
|
Diff for pulumi-kubernetes with merge commit 43a8d0a |
|
Diff for pulumi-gcp with merge commit 43a8d0a |
|
Diff for pulumi-azure with merge commit 43a8d0a |
|
Diff for pulumi-aws with merge commit 43a8d0a |
|
Diff for pulumi-azure-native with merge commit 43a8d0a |
emiliza
added
capacity/quality
size/M
These changes remove the
Ptrvariants of input/ouptut types forresources. A
TPtrinput or output is normally generated forTifTis present in an
optional(input(T))oroptional(output(T))and ifthe Go representation for
Tis not nilable. The generation ofPtrvariants for resource types breaks the latter rule: the canonical
representation of a resource type named
Foois a pointer to a structtype named
Foo(i.e.*Foo).Fooitself is not a resource, as itdoes not implement the Go
Resourceinterface. Because thisrepresentation already accommodates
nilto indicate the lack of avalue, we need not generate
FooPtr{Input,Output}types.Besides being unnecessary, the implementation of
Ptrtypes forresources was incorrect. Rather than using
**Fooas their elementtype, these types use
*Foo--identical to the element type used forthe normal input/output types. Furthermore, the generated code for
at least
FooOutput.ToFooPtrOutputWithContextandFooPtrOutput.Elemwas incorrect, making these types virtually unusable in practice.
Finally, these
Ptrtypes should never appear on input/outputproperties in practice, as the logic we use to generate input and output
type references never generates them for `optional({input,output}(T)).
Instead, it generates references to the standard input/output types.
Though this is technically a breaking change--it changes the set of
exported types for any package that defines resources--I believe that in
practice it will be invisible to users for the reasons stated above.
These types are not usable, and were never referenced.
This is preparatory work for #7943.