2447 Commits (eecbfbf2cccedfb581469ee63599c4b4abc5c60f)

Author	SHA1	Message	Date
Martin Atkins	84df5562f2	moduleaddrs: Terraform now owns module source address normalization ... We've been gradually chipping away at how much we use go-getter for source packages, because it's generally been a bit of a nightmare and sharing it with other codebases means that any time someone wants to change something we end up needing to find some way to prevent it breaking Terraform's compatibility promises. Here we make one further step: Terraform owns the "detectors" idea that deals with source address normalization, and now always produces fully-qualified addresses for go-getter to chew on only for the getting and decompressing steps. Retaining go-getter for the actual getting part is helpful because we can then benefit from security fixes upstream, but Terraform owning the first layer of parsing means that we can fix in place the definition of what "module source address" syntax means, and thus we can avoid having everything in this codebase indirectly depend on go-getter just because it wants to parse module source addresses. Now only the module installer actually depends indirectly on go-getter, which finally disconnects go-getter's subtree from all of the remote state backend dependency graphs.	2 years ago
Martin Atkins	78ae6af906	legacy/terraform: Minimize the contents of this legacy package ... At one point we were relying on this for a few different things, but now it's here exclusively to support legacy/helper/schema, the legacy SDK snapshot that is still being used by a few of the remote state backends. The SDK only really needs a tiny portion of the functionality from this package, and by deleting as much of the unused stuff as possible we can reduce the indirect dependencies of this package and thus, in turn, the indirect dependencies of the remote state backends. This also selectively deletes a few parts of the legacy SDK that are focused on providers and provisioners, because we know that we have this here only to support the backends that haven't yet been weaned off it, but we'll save a more adventurous purge of _that_ package for another day.	2 years ago
Martin Atkins	621befc3a2	configtesting: Separate package for the SynthBody helper ... This "SynthBody" helper doesn't really have anything to do with package configs except that it's sometimes useful for creating fake instances of the types in there for testing. Moving it into its own package means that package backend no longer needs to depend on package configs, since it doesn't actually have any need for parsing module configurations. The old configs.SynthBody function is still available as a forwarding alias, because most of the existing callers of it are from packages that already need to import package configs for other reasons, and so this reduces the need to churn loads of existing tests.	2 years ago
Martin Atkins	5d87e32eb9	moduleaddrs: Split module source address parsing from package addrs ... Our package addrs ends up getting imported from just about ever other package in Terraform, because it contains the types we use to talk about various different kinds of objects. Therefore we typically try to keep its transitive dependency graph relatively small, because anything it depends on becomes an indirect dependency of nearly everything else. A while back we moved the module source address models into package addrs, which also brought with them the code for parsing strings to produce those addresses. Unfortunately, remote module source addresses are defined using the external dependency go-getter, which is pretty heavy itself and also brings with it numerous other external dependencies such as the AWS SDK, the Google Cloud Platform SDK, etc. Since only relatively few packages actually need to _parse_ source addresses -- with most either not caring about them at all or only consuming addresses that were already parsed by someone else -- we'll move the parser functions into their own package, while keeping the resulting address types in package addrs. This does still retain the package addrs dependency on external module github.com/hashicorp/terraform-registry-address, which is not ideal but that one at least has a relatively shallow dependency subgraph, so there's not so much urgency to tidy that one.	2 years ago
Martin Atkins	58b48f4bab	provider/terraform: Use new convention for function names ... When we added these functions we hadn't yet settled on a single convention for how provider-contributed functions ought to be named, and so these followed the convention previously used for Terraform's own built-in functions. We've now decided to use the new provider namespace as an opportunity to partially fix the historical design error of naming functions as all lowercase without any separation between words. This makes the provider functions inconsistent with the built-in functions, but should at least hopefully encourage the provider functions to be consistent with one another, so that the rule for which to use is relatively easy to remember. This also switches the word order because the provider functions convention prefers the verb to come first: encode_tfvars instead of tfvarsencode.	2 years ago
Martin Atkins	56006416ba	go.mod: go get golang.org/x/tools@v0.19.0 ... We use this just for development-time tools like "stringer", so this upgrade should not have any runtime impact.	2 years ago
Martin Atkins	c541757f4a	go.mod: go get golang.org/x/mod@v0.16.0 ... Aside from development tool dependencies we use this only for the directory hashing logic used to compute go module hashes, which we also use for Terraform provider hashes. There are no changes to the dirhash package in this update, so this should have no runtime impact.	2 years ago
Martin Atkins	b059985227	go.mod: go get golang.org/x/sync@v0.6.0 ... This update only changes a documentation comment, so cannot affect runtime behavior.	2 years ago
Martin Atkins	caa7a757bc	go.mod: go get golang.org/x/oauth2@v0.18.0 ... This only upgrades a Google-specific subpackage, and so the only potential impact is to the GCS backend.	2 years ago
Martin Atkins	9c7ece8ad4	go.mod: go get golang.org/x/net@v0.22.0 ... This update is largely focused on QUIC implementation changes, which do not directly affect Terraform. There is one fix for the HTTP2 implementation to terminate the stream if a sender recieves an out-of-bounds window update, which makes the implementation better match the specification. This seems unlikely to cause any practical problems for Terraform.	2 years ago
Martin Atkins	fad9c2a4cd	go.mod: go get golang.org/x/crypto@v0.21.0 ... This update is mostly internal changes that don't affect external behavior. The only update potentially significant to Terraform is the new exclusion of a particular root certificate that is used only for some specific names under the .tr CCTLD, but the certificate database doesn't specify that constraint in a way that the library can understand, so it's excluded to avoid making the trust for that certificate broader than intended.	2 years ago
Martin Atkins	a1d2169c85	go.mod: go get golang.org/x/term@v0.18.0 ... This update contains no real changes. It just updates transitive dependencies to newer versions that we've already selected anyway.	2 years ago
Martin Atkins	b3f6a6230d	go.mod: go get golang.org/x/sys@v0.18.0 ... This small update does not directly affect any Terraform functionality.	2 years ago
Martin Atkins	61a5c1f57b	go.mod: go get github.com/hashicorp/terraform-registry-address@v0.2.3 ... This is really just a bunch of changes to the upstream go.mod for updates to its own dependencies, but Terraform already has new enough versions of those dependencies for other reasons and so this changes nothing.	2 years ago
Martin Atkins	8603ee0ab5	go.mod: go get github.com/hashicorp/go-slug@v0.14.0 ... This has just some changes to the "sourcebundle" building API, which doesn't affect Terraform CLI or Terraform Core because they currently only consume source bundles, not build them.	2 years ago
Martin Atkins	914618b061	gcs: Adopt the "ReadPathOrContents" helper function ... Package backend previously had a ReadPathOrContents helper that takes a string that could represent either a filename or some literal content, and then reads the given file if it's a filename or just returns the literal content otherwise. We originally used variations of this helper to shim a number of different situations that had originally accepted filenames but later changed to accept literal content, but over time we've eliminated all of those and so the only remaining caller is the gcs backend which uses it to accept GCP credentials either as literal content or as a file containing the credentials. Therefore here we move that helper function to be just an unexported part of the gcs backend package. This is part of an ongoing effort to minimize what each remote state backend depends on (either directly or indirectly) so that we can make gradual progress towards these remote state backends being self-contained enough to move into other codebases. In the short term though, it just puts this helper function closer to its caller so it's easier to maintain them both together if needed.	2 years ago
Martin Atkins	dbde17b535	terraform console: Multi-line entry support ... The console command, when running in interactive mode, will now detect if the input seems to be an incomplete (but valid enough so far) expression, and if so will produce another prompt to accept another line of expression input. This is primarily to make it easier to paste in multi-line expressions taken from elsewhere, but it could also be used for manual input. The support for multi-line _editing_ is limited by the fact that the readline dependency we use doesn't support multiline input and so we're currently doing this in spite of that library. Hopefully we'll be able to improve on that in future either by contributing multi-line editing support upstream or by switching to a different readline dependency. The delimiter-counting heuristic employed here is similar to the one used by HCL itself to decide whether a newline should end the definition of an attribute, but this implementation is simpler because it doesn't need to produce error messages or perform any recovery. Instead, it just bails out if it encounters something strange so that the console session can return a parse error. Because some invalid input may cause a user to become "stuck" in a multi- line sequence, we consider a blank line as intent to immediately try to evaluate what was entered, and also interpret SIGINT (e.g. Ctrl+C) as cancellation of multi-line input, assuming that at least one line was already entered, extending the previous precedent that SIGINT cancels when at least one character was already entered at the prompt.	2 years ago
Martin Atkins	f058de612c	statemgr: Incorporate IntermediateStateConditionalPersister ... This interface was originally in the local backend's package because that backend is the only one that _truly_ runs Terraform operations and thus needs to negotiate how to store the intermediate state snapshots that result from them. However, putting the interface and its supporting types/functions there means that anything that wants to implement this interface needs to import the local backend package, and thus indirectly depends on the entire modules runtime, etc. We already had package stagemgr as a home for the shared stuff used by most state storage managers, and so we'll just move these symbols over there and then we can shed some internal dependencies on package local. This also severs the last dependency link between the remote state backends and the modules runtime, allowing us to shed a bunch of indirect dependencies from those remote state backends.	2 years ago
Liam Cervante	c6ff573180	Include provider functions in scope used to evaluate test assertions (#34825)	2 years ago
Daniel Schmidt	8bab2a588d	stacks: use component config address relative to stack	2 years ago
Daniel Schmidt	1fd99fe6e4	stacks: adjust tests to include component addr	2 years ago
Daniel Schmidt	0cea00e919	stacks: emit component address in find stack configuration component response	2 years ago
Martin Atkins	cf3bbb890f	State managers use schemarepo.Schemas instead of terraform.Schemas ... schemarepo.Schemas used to be terraform.Schemas, but its presence in the terraform package was the only reason for a state manager to need to import package terraform, so we've moved it out into its own package in the parent commit. This means that none of the state-related packages need to import package terraform any longer, and so once we've untangled some other dependencies this will curtail the number of packages in this codebase that the remote state backends transitively depend on, as part of an ongoing effort to eventually separate them from this codebase entirely.	2 years ago
Martin Atkins	034bf4487f	schemarepo: Schema repositories get their own package ... It's a cross-cutting concern to need the dynamic value schemas of the various plugins used with a Terraform configuration, but previously we had the type for that in "package terraform", forcing lots of packages to depend on the modules runtime even though they have no direct interest in evaluating Terraform modules. We'll now split it out into its own package "schemarepo". There are currently forwarding aliases left behind in "package terraform" so that we don't need to update all of the callers at once. We'll update the callers whose dependency changes will have the most significant benefits in future commits. The new package is further split into a separate "laodschemas" part that deals with the plugin interactions, because most packages that use a schema repository expect that it was already constructed by someone else, and so don't need or want to depend indirectly on all of the plugin execution machinery.	2 years ago
Martin Atkins	88cb4aeea3	backendrun: Separate the types/etc for backends that support operations ... We previously had all of the types and helpers for all kinds of backends together in package backend. That kept things relatively simple, but it also meant that the majority of backends that only deal with remote state storage ended up still indirectly depending on the entire Terraform modules runtime, configuration loader, etc, etc, which brings into scope a bunch of external dependencies that the remote state backends don't really need. Since backends that support operations are a rare exception, we'll move the types and helpers for those into a separate package "backendrun", and then the main package backend can have a much more modest set of types and, more importantly, a modest set of dependencies on other packages in this codebase. This is part of an ongoing effort to reduce the exposure of Terraform Core and CLI code to the remote backends and vice-versa, so that in the long run we can more often treat them as separate for dependency maintenance purposes.	2 years ago
Martin Atkins	545980d664	langrefs: Separate package for expression reference analysis ... Finding references in an expression is a static analysis operation, but we previously had it grouped in with "package lang" that primarily deals with dynamic evaluation of expressions. We need to do static analysis in far more locations than we do full expression evaluation, the static-analysis-only callers don't need anything else from package lang, and the reference-analysis functions are self-contained little wrappers around the address parsing logic in package addrs anyway. Splitting these into a separate package therefore minimizes which packages depend indirectly on package lang, and thus which packages depend indirectly on the implementations of the built-in functions. Some of the built-in functions rely on dependencies we don't use anywhere else, so cutting these out shrinks how many packages indirectly depend on those external dependencies. In particular, they are no longer in the indirect import chain for the "legacy" module.	2 years ago
Martin Atkins	5f2eab6944	providerreqs: Provider requirement/version types in their own package ... As we previously found with "package addrs", any package that contains types used as identifiers or addresses tends to get imported from all over, which means that if we mix real logic with those types in the same package then a lot more packages end up depending indirectly on our external dependencies. In this case, the getproviders package depends on various things we need only during provider installation, such as the library we use for GPG signature verification. Lots of different packages in Terraform need to talk about provider requirements, but only the CLI layer actually needs to do provider installation, and so this commit splits the types we use to talk about requirements into a new package "providerreqs", which package getproviders then depends on. To keep the size of this diff relatively small to start I've left forwarding aliases in package getproviders, which means that not all of the callers needed to be updated all at once. This commit does update all of the packages that the remote state backends depend on though, because that then allows us to reduce the set of indirect dependencies for each of those backends. The nested module go.mod files show that this has disconnected the indirect dependencies on github.com/ProtonMail/go-crypto and on github.com/cloudflare/circl , both of which Terraform CLI uses only for provider installation.	2 years ago
James Bardin	154f9ada90	disconnect remote-exec immediately ... The remote-exec provisioner was not disconnecting immediately after provisioning. The remote exec context was tired to the lifetime of the provisioner, but the provisioner node used to not live long after the remote execution had completed so it was not noticed. Some more recent refactoring extends the lifetime of the node, and causes the provisioner connections to hang around longer when they're not needed. Ensure we disconnect immediately after the remote execution is complete.	2 years ago
Martin Atkins	310331bdc6	backend/consul: go.mod updates from a merge conflict ... Two changes landed concurrently and caused these dependencies to get out of sync.	2 years ago
Martin Atkins	5811be26f8	go.mod: Separate modules at code ownership boundaries ... Historically it's been hard for us to keep on top of dependency upgrades as a matter of course because it's unclear which code owners might be affected by or responsible for an upgrade of each module. After trying a few different techniques to try to mitigate this, the most promising one seems to be to tell the Go toolchain that each of these components is a separate Go module, but then to stitch them all back together again using replace directives so that we can mostly ignore these module boundaries in everyday development. The one case where we _do_ need to pay attention to these boundaries is also the case where the separation is useful: upgrading a dependency of any one of these modules might potentially force upgrading it for another module too, and so the Go toolchain will help us notice that interaction and we can immediately which code owners might need to be involved in reviewing and testing that particular upgrade. To make that process less onerous, this adds a new makefile target "make syncdeps" which runs "go mod tidy" in all of the modules at once and thus forces the toolchain to align their dependencies to the extent required for them all to be linked together successfully, and to generate go.mod and/or go.sum diffs that will match our configured code ownership paths to trigger the appropriate code review requests. Hopefully before too long we'll be able to move all the backends out into provider plugins and delete the "legacy" module entirely and then this oddness won't be needed anymore, but as long as we're all trying to play together in this same sandbox this is a small amount of extra ceremony in return for hopefully reducing the level of anxiety involved in keeping the system's dependencies up to date more consistently.	2 years ago
Martin Atkins	6bd1c66cbc	backendbase: Basic support for default values ... Some existing backends make very heavy use of environment variable-based default values and fallback values, which are available in the legacy SDK but not in Terraform's own schema model. To ease the migration away from the legacy SDK for those backends, backendbase.Base now supports a lightweight mechanism for declaring such defaults, and applies them automatically as part of PrepareConfig. This gets us pretty close to the assumptions that the SDK allowed callers to make, but with considerably less code. It's intentionally considerably less flexible than the legacy SDK was, because in practice most backends use only a tiny subset of the SDK functionality anyway.	2 years ago
Martin Atkins	b16cb49fb6	backendbase: "SDK-like" helpers ... A lot of the remote state backends' current Configure functions unfortunately rely quite heavily on the "do the best you can" API of the legacy SDK, which makes questionable shortcuts like treating null as equivalent to the Go zero value of a type, but in return makes it convenient to assign into other data structures that happen to make similar assumptions. And of course that means that the backends' other data structures were built to make those similar assumptions! This new set of utilities therefore aims to provide a bare-minimum subset of "SDK-like" functionality to ease the initial migration away from the legacy SDK. It isn't exactly equivalent an in particular focuses only on the small subset of legacy SDK functionality that most existing backends rely on, but this should at least make the initial adaptations a little more mechanical so that we can continue to defer the full modernization of these backends for some undetermined future time without having to continue retaining the huge legacy SDK snapshot in this codebase.	2 years ago
Martin Atkins	a5d63a23ab	backend/consul: Use backendbase instead of helper/schema ... The legacy helper/schema package is really just a frozen copy of Terraform's old plugin SDK, which is a complicated heap of code that nobody at HashiCorp really understands anymore. This backend will now use the lightweight "backendbase" helper package instead, which is at a slightly lower level of abstraction and therefore requires more explicit logic during config decoding, but these extra calls to helper functions are still considerably less code than the whole helper/schema package and its various external dependencies that Terraform imports purely to keep it working.	2 years ago
Martin Atkins	eb87e86ddf	backend/http: Use backendbase instead of helper/schema ... The legacy helper/schema package is really just a frozen copy of Terraform's old plugin SDK, which is a complicated heap of code that nobody at HashiCorp really understands anymore. This backend will now use the lightweight "backendbase" helper package instead, which is at a slightly lower level of abstraction and therefore requires more explicit logic during config decoding, but these extra calls to helper functions are still considerably less code than the whole helper/schema package and its various external dependencies that Terraform imports purely to keep it working.	2 years ago
Martin Atkins	2222c23d4b	backendbase: BoolValue and MustBoolValue ... With legacy helper/schema it's common to just type-assert whatever ResourceData.Get returns and trust that it'll always be valid. We can't achieve something quite that lazy with cty, but we can at least factor out the work of turning a value we already know is a bool into a bool value. We also have a "must" variant for this one, because it's relatively easy for a caller to ensure that it controls all of the inputs enough to ensure that it should never fail.	2 years ago
Martin Atkins	1eaa18d60a	backendbase: IntValue ... With legacy helper/schema it's common to just type-assert whatever ResourceData.Get returns and trust that it'll always be valid. We can't achieve something quite that lazy with cty, but we can at least factor out the work of turning a value we already know is a number into an int64 value.	2 years ago
Martin Atkins	70537aab08	backendbase: ErrorAsDiagnostics ... The legacy helper/schema based Backend implementation expected the backend-specific code to return error and then wrapped it in diagnostics itself before returning. Backends using backendbase are supposed to return diagnostics directly themselves, but having to manually replace every error case with a higher-quality diagnostic message would get in the way of EOLing the legacy helper/schema implementation, and so this helper function is a pragmatic compromise to allow us to keep those updates purely mechanical for now and then improve diagnostics as a separate effort later.	2 years ago
Martin Atkins	46951b5b35	backendbase: Attribute lookup helpers ... Most of the remote state backends are currently written in terms of schema.ResourceData, lookup up attributes by path and possibly substituting default values when the attributes aren't explicitly set. These helpers aim to substitute for those common applications so that we can convert the existing backend logic more directly, without significantly increasing its complexity by suddenly moving the default value handling inline in their Configure functions.	2 years ago
Martin Atkins	d4c58fac4c	backend/inmem: No more legacy/helper/schema ... This now uses "backendbase", which is a lighter replacement for our local copy of Terraform's legacy plugin SDK.	2 years ago
Martin Atkins	df4cefbea9	backend: new "backendbase" helper package ... This is intended as a lighter-weight replacement for the Backend type in the legacy/helper/schema package, which indirectly pulls in our local copy of the entire legacy Terraform plugin SDK. This depends on the slightly-lower-level configschema package, which means that it's not quite as feature-rich as what it's replacing, but backends have relatively modest needs and so we can compensate with just some extra logic in their Configure functions, which will be considerably simpler than the huge bunch of legacy code we're currently depending on to get the same effects. In particular, configschema has no concept of "default values" for arguments, and so we'll need to deal with those in the Configure methods using imperative code, instead of declaratively. Nothing is using this yet, but in future commits we'll gradually convert all of the remote state backends to use this instead of the legacy system, and then remove the legacy system.	2 years ago
Martin Atkins	66bec6c3c7	command: TestWorkspace_deleteWithState uses modern state format ... This test is intending to test behavior in the presence of a state snapshot but was achieving that using the legacy state snapshot format that we preserved only for its previous (now eliminated, in an earlier commit) purpose of implementing the CLI backend state format. Instead, we'll construct a state snapshot format using the modern API for doing that, which therefore constructs a modern state snapshot file as would be created by today's Terraform. This eliminates the last use of the "legacy/terraform" package aside from the calls from other packages under "legacy".	2 years ago
Martin Atkins	06f51dbe04	command/workdir: Model the "backend state" file format ... Historically (before there were "backends") Terraform had a single state file format used both for real state snapshots and for tracking where remote state was stored. Terraform v0.12 caused these two to be split because we adopted state snapshot version 4 for real snapshots but retained a subset of version 3 for tracking the remote backend configuration in the local working directory. Unfortunately we previously kept that working by retaining a snapshot of the entire Terraform v0.11 "terraform" package as legacy/terraform, which happened to still be around because we also needed to retain a copy of the entire legacy SDK to keep the remote state backends working. This now hoists just the tiny slice of legacy terraform package functionality needed to implement the "backend state" file format into package workdir. This package is a good home for it because it's part of the working directory state. Ideally it would be accessed through methods of the workdir.Dir type, but that's too disruptive a refactor to combine into this and so that'll need to wait for another day; for now we'll keep the existing callers doing their access through our "clistate" package that is itself a forked snapshot of what statemgr.Filesystem used to be in Terraform v0.11. This removes all but one of the uses of "legacy/terraform" aside from calls in the other packages under "legacy". We'll clean up the last one in a later commit, because it's not related to the backend state file format.	2 years ago
Martin Atkins	53fd930d6a	legacy/helper/acctest: Entirely remove ... This is no longer called from anywhere in this codebase.	2 years ago
Martin Atkins	c0943fdd2a	backend/azure: Bring randString test helper into this package ... We've been keeping around the whole legacy "acctest" package just for this one function, used only by the Azure provider. Instead we'll inline the function into this package, so that we can delete the acctest package in a future commit.	2 years ago
Martin Atkins	049093a3ad	statefile: Use lighter techniques for data copying ... This package was our last non-legacy use of the third-party "copystructure" library, and that library is far more general than most of this work needs. Most of this is replacing overly-general code with more specific code, since it's not exactly hard to shallow-copy a map or a slice of strings. The 2-to-3 upgrade is a little trickier because we were previously copying the entire data structure before making light modifications to it, since the V2 and V3 formats are similar enough. However, we can be a little naughty and use our mainly-test-oriented copy.DeepCopyValue helper instead of copystructure, since these structures are simple enough for that to work and are never going to change because they are here only to support upgrading from long-obsolete file formats. This removes Terraform's last non-legacy dependency on copystructure, and with it the last non-legacy indirect dependency on the sibling module "reflectwalk".	2 years ago
Martin Atkins	af44fdbbf5	cloud: Use copy.DeepCopyValue instead of copystructure dependency ... The mock implementations of the Terraform Cloud SDK types were previously using the rather-heavy external dependency mitchellh/copystructure for creating deep copies of the mock values. This package doesn't need all of the customizability and generality of that library, and so our smaller internal helper copy.DeepCopyValue is sufficient.	2 years ago
Martin Atkins	d14c149001	copy: DeepCopyValue utility ... Over the years we've gradually removed all use of various third-party reflection-based libraries for deep-copying and projecting data structures from main code, because they proved to be a maintenance nightmare and thus better replaced by direct code that is less fun to write but far clearer to read. However, we've still got a few examples of _test_ code hanging on to these helpers because the tradeoffs for unit tests tend to be different. That's valid, but it's annoying to have to include several large and very general dependencies just to support some tests whose needs are well-known and relatively simple. Therefore this new helper function copy.DeepCopyValue aims to be a more straightforward replacement for mitchellh/copystructure (which also indirectly subsumes mitchellh/reflectwalk) that eschews all of the customizability that those libraries offered and instead focuses narrowly on what our few remaining unit tests need. In particular, this replacement doesn't offer any means for registering helper functions to translate struct types with unexported fields. Those instead just get left set to their zero value in the result. Since our focus is only on unit test code, we can know ahead of time when that limitation is relevant and code around it in the calling test rather than complicating this utility code.	2 years ago
Martin Atkins	4295cebb05	dependencies: No more golang.org/x/exp ... This module was a temporary home for what are now the standard library "slices" and "maps" packages. We're building Terraform with a sufficiently new version of Go that we can use the standard library equivalents, so we no longer need this dependency. It lives on as an indirect dependency for now because hashicorp/aws-sdk-go-base is also using it, but hopefully it'll vanish altogether in future if that library is updated to also use stdlib instead.	2 years ago
Alisdair McDiarmid	f409639934	Merge pull request #34765 from hashicorp/alisdair/stack-root-input-variable-defaults ... stackruntime: Apply defaults to root variables	2 years ago
Martin Atkins	e6ad0c282d	tfdiags: Support errors.Join and stdlib wrapped errors ... HashiCorp needed support for wrapping multiple errors into a single error and for wrapping one error inside another long before that was in the standard library, and so built its own libraries for those needs. However, the standard library now has its own answers for both and so the HashiCorp libraries are redundant. We've already eliminated all use of both elsewhere in Terraform (except for some legacy packages that predate tfdiags anyway), so we no longer need to support them in package tfdiags.	2 years ago