pulumi/CHANGELOG_PENDING.md

### Improvements

- [codegen/go] - Remove `ResourcePtr` types from generated SDKs. Besides being
  unnecessary--`Resource` types already accommodate `nil` to indicate the lack of
  a value--the implementation of `Ptr` types for resources was incorrect, making
  these types virtually unusable in practice.
  [#8449](https://github.com/pulumi/pulumi/pull/8449)

### Bug Fixes
Cleanup post v3.2.1 release 2021-05-06 20:27:21 +02:00			`### Improvements`
Programgen support for fnOutput forms in node (#7949) (#8434) * Teach PCL about fnOutput forms * Teach PCL about fnOutput forms * Teach Node program gen to emit fnOutput forms * TypeCheck fix * AWS package bump * Add tests * CHANGELOG * Temporarily skip non-Node affected tests * Address PR feedback: restrict new form to Output args only 2021-11-17 21:27:50 +01:00
[codegen/go] Remove ResourcePtr input/output types (#8449) 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. 2021-11-23 19:24:56 +01:00			- [codegen/go] - Remove `ResourcePtr` types from generated SDKs. Besides being
			unnecessary--`Resource` types already accommodate `nil` to indicate the lack of
			a value--the implementation of `Ptr` types for resources was incorrect, making
			`these types virtually unusable in practice.`
			`[#8449](https://github.com/pulumi/pulumi/pull/8449)`

[sdk/go] Respect default parent in go aliases. (#8288) * Respect default parent in go aliases. * Update changelog * Handle empty parrents correctly * Allow specifying no parent * clarify variable name * Improve `Unparent` ergonomics * Take t0yv0's suggestion * Adopt @t0yv0's tests and doc comments. * Make NoParent,Parent,ParentURN mutually exclusive 2021-10-29 02:25:31 +02:00			`### Bug Fixes`
Fix issue with --target deletion dependent calculation (#8360) * Fix issue with --target deletion dependant calculation The code that computed --target deletion dependants was not correct. It used parent/child component relationships, but did not respect actual DAG dependencies. As a result, it could erroneously leave hanging references to resources that no longer exist after performing a `pulumi destroy --target X` operation. This manifested in bugs like https://github.com/pulumi/pulumi/issues/6283, which is fixed by this change. The solution is to compute the (transitive!) dependency graph correctly, factoring in both parent/child, as well as explicit and implicit, dependencies. The existing logic does the correct thing once we do this. I've also added tests for this area, including regression tests that cover transitive dependency relationships, as well as ones that would cause an infinite loop given a naive implementation. * Add a changelog entry * Fix failing test to include all destroyed targets Unless I'm missing something, the entire tree should be deleted in this test case because A is the ancestor for the entire tree. * Use DependencyGraph to compute dependents Per code review feedback from @pgavlin. Co-authored-by: Anton Tayanovskyy <anton@pulumi.com> 2021-11-12 16:02:51 +01:00