This is just a routine upgrade. Upstream has added various new features but
all of them require opt-in either by explicit configuration or by using
new field types that were not previously supported at all, so they should
not immediately affect OpenTofu's behavior.
OpenTofu uses this library only in some legacy code that sticks around from
much older versions of its predecessor. Most uses of it were replaced by
HCL-based and cty-based equivalents a long time ago, but it sticks around
in the inline copy of the legacy plugin SDK used by the config decoding
logic from some state storage backends, and in some of the provisioner
configuration handling. These features only use very old, legacy parts of
the mapstructure library that have been preserved for
backward-compatibility.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is just a routine upgrade. The only upstream change that could affect
runtime behavior is a new option to disable matching hidden files, but
that's an opt-in so will not affect OpenTofu's behavior.
This library is used only as part of the implementation of the built-in
function "fileset", which returns a set of paths matching a given glob
pattern.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
Because this is work based on an RFC, as usual this links to the RFC
tracking issue instead of to an individual PR since that's a better
overview of all the work behind this change.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This repurposes the page that was previously about "terraform" blocks to
now be about "language" blocks instead.
This is the modern way to describe version compatibility constraints for
OpenTofu, though we retain some support for required_versions in
"terraform" blocks as a transitional aid for those who want to write
modules that can work with older versions of OpenTofu.
There were previously additional sections on this page discussing other
settings that can appear in "terraform" blocks, but they were essentially
just links to more detailed documentation elsewhere and so this reduces
all of that to just a single section that acknowledges that this block
type accepts other options and links to the relevant documentation for
each one. This structure matches the reality that "terraform" blocks are
just a dumping ground for a variety of tangentially-related settings, and
that we're intending to gradually replace all of the settings in there
with brand-agnostic alternatives in future releases.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
Previously we interpreted a "required_version" argument in a "terraform"
block as if it were specifying an OpenTofu version constraint, when in
reality most modules use this to represent a version constraint for
OpenTofu's predecessor instead.
The primary effect of this commit is to introduce a new top-level block
type called "language" which describes language and implementation
compatibility metadata in a way that intentionally differs from what's used
by OpenTofu's predecessor.
This also causes OpenTofu to ignore the required_version argument unless
it appears in an OpenTofu-specific file with a ".tofu" suffix, and makes
OpenTofu completely ignore the language edition and experimental feature
opt-in options from OpenTofu's predecessor on the assumption that those
could continue to evolve independently of changes in OpenTofu.
We retain support for using required_versions in .tofu files as a bridge
solution for modules that need to remain compatible with OpenTofu versions
prior to v1.12. Module authors should keep following the strategy of
having both a versions.tf and a versions.tofu file for now, and wait until
the OpenTofu v1.11 series is end-of-life before adopting the new "language"
block type.
I also took this opportunity to simplify how we handle these parts of the
configuration, since the OpenTofu project has no immediate plans to use
either multiple language editions or language experiments and so for now
we can reduce our handling of those language features to just enough that
we'd return reasonable error messages if today's OpenTofu is exposed to
a module that was written for a newer version of OpenTofu that extends
these language features. The cross-cutting plumbing for representing the
active experiments for a module is still present so that we can reactivate
it later if we need to, but for now that set will always be empty.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is just a routine upgrade. The Go project's ratcheting policy means
that we must also upgrade x/crypto, but that one doesn't have any changes
that are significant to OpenTofu.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
Because the Go team always ratchets these all to depend on newer versions
of each other, it's not possible to upgrade these in isolation.
The main goal of this commit is to update all of the modules whose only
significant change is the dependency ratchet, in preparation for performing
more significant upgrades.
Unfortunately because many of these modules depend on x/tools, and x/tools
depends on x/net, there is no way to avoid performing a partial upgrade
of x/net. This is the smallest possible upgrade to that module to satisfy
the dependencies of the others I intend to make a followup commit focused
on x/net to bring it all the way to the latest available version.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This rewrites and reorders various entries added to the changelog during
the v1.12 development period to use consistent terminology and phrasing
between similar items and to present the changes in a very subjective
ordering by "relevance".
As usual, "relevance" is pretty loosely defined but the general guideline
is: configuration-related changes, then CLI-related changes, then changes
that affect integrations with other software like providers and backends.
Within each of those categories I went mainly by "vibes" based on my
impression of how much interest there had been in each of the features
or fixes in earlier discussion.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
We don't typically just broadly run automatic rewriting tools like "go fix"
across our codebase because that tends to cause annoying and unnecessary
merge conflicts when we're backporting to earlier release branches.
But all of the files in this commit were changed in some non-trivial way
already during the OpenTofu v1.11 development period anyway, and so the
likelyhood we'd be able to successfully backport from them is reduced and
therefore this seems like a good opportunity to do some focused
modernization using "go fix".
My rules for what to include or not are admittedly quite "vibes-based", but
the general idea was:
- Focusing on files under the "command" directory only, because that's
already been an area of intentional refactoring during this development
period.
- If the existing diff in a file is already significantly larger than
the changes the fixer proposed to make, or if the fixer is proposing
to change a line that was already changed in this development period.
- More willing to include "_test.go" files than non-test files, even if
they hadn't changed as much already, just because backports from test
files for bug fixes tend to be entirely new test cases more than they
are modifications to existing test cases, and so the risk of conflicts
is lower there.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
The "go fix" modernizer for using wg.Go instead of explicit wg.Add/wg.Done
only works when the goroutine function has no arguments, so it didn't match
here where this code was still using an old trick to ensure that each
goroutine would capture a different value of "i".
But that old trick isn't needed anymore because modern Go already ensures
that each iteration of the loop has an independent "i", so I made a small
change to remove the argument and just let the closure capture "i" from
the outer loop, and then "go fix" was able to complete the rewrite to
use wg.Go here.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is just the result of running the "go fix" modernizers against this
package.
It seems that there were some lines with trailing whitespace previously,
which also got removed here because "go fix" includes an implicit "go fmt".
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is the result of running the "go fix" modernizers on the subset of
files under this prefix that were already changed during the v1.12
development period.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is just a routine upgrade.
The latest version of go.opentelemetry.io/otel/sdk has adopted a newer
version of semconv and so this also updates our traceattrs package to
use the same version, as usual.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
As with the previous tests added for for_each, this is some basic coverage
under the assumption that the rules for count are not likely to change
so much that it would be arduous to update these tests.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
As with the previous tests added for for_each, this is some basic coverage
under the assumption that the rules for count are not likely to change
so much that it would be arduous to update these tests.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
The previous implementation was rejecting most out-of-range errors, but
it was not rejecting negative numbers, and it was also generating
misleading error messages in other cases because cty's own error messages
for numeric range are pretty generic.
Now we'll do our own numeric range checks before we attempt to extract
the number into an int variable, so we can return more tailored error
messages and can reject negative numbers properly.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This case is not particularly interesting -- it just always produces a
hard-coded result -- but is tested anyway for completeness.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
So far we've been pretty light on testing in these new codepaths because
they've been churning quite a lot during our "walking skeleton" phase of
the new runtime development.
But this instance-selector-related code seems relatively self-contained and
settled, so this introduces an initial set of unit tests for the handling
of for_each expressions, primarily just to document what the intended
behavior of the current implementation was and to illustrate that it is
indeed unit-testable in (relative) isolation.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
The comment here was correct that we can accept unknown values of object
types because the attributes are known as part of the type, but we do still
need to handle that in a special way because we need to produce the result
based only on the type information in this case, without trying to access
the value.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
In earlier work we added some more detailed typechecking rules further
down that can reject incorrectly-typed values even when the value is
unknown, but forgot to remove this early return that made that other code
unreachable whenever the value is unknown.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
For unit tests of components that don't depend on any particular symbol
table structure, where we just want to test if they are using the provided
scope _at all_, it's helpful to be able to just quickly create a static
symbol table.
This is a reusable helper function for that.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
The earlier drafts of this RFC included a special rule for ignoring
required_version declarations across all files in any module that includes
a "language" block. That special case was an adaptation of some complexity
from earlier proposals in this area that was intended for gradual adoption
of the new syntax.
However, with the current form of this proposal that exception doesn't
really serve any useful purpose: any module with a "language" block in it
will be immediately incompatible with OpenTofu v1.11, but we already
included a gradual adoption strategy by having authors continue to use
the old-style required_version pattern until they are ready to require
OpenTofu v1.12 or later.
Therefore we'll now amend the RFC to say that the old and new strategies
are allowed to coexist in the same module and that OpenTofu will check and
enforce them separately, which is an easier rule to explain and also much
easier to implement because it allows checking each declaration
independently rather than having to wait until the full module has loaded
to decide which declarations are relevant.
This also proposes a small heuristic warning to hopefully help authors
notice that they must continue using required_version for any module that
is explicitly intended to support the OpenTofu v1.11 series. This will
complement our documentation to reinforce the recommendation to continue
using the old-style approach until the v1.11 series is no longer supported.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
Our new language runtime uses a set of new methods on SyncState to work
with its preferred "full" representation of resource instance objects, but
those are implemented in terms of methods that already existed for the old
runtime's benefit and so we need to deal with some quirks of those existing
methods.
One such quirk is that the operations to write or remove objects also want
to update some resource-level and instance-level metadata as a side-effect,
and we need to carry through that metadata even when we're intending to
completely remove a resource instance object.
To preserve our goal of leaving the existing codepaths untouched for now,
this pushes a little complexity back up into the main caller in the apply
engine, forcing it to call a different method when it knows it has deleted
an object. That new method then only takes the metadata we need and not
an actual resource instance object, so it gels better with the underlying
ModuleState methods it's implemented in terms of.
Hopefully in the long run we'll rethink the state models to not rely on
these hidden side-effects, but that's beyond the scope of our current phase
of work on the new language runtime.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is just a routine upgrade. It contains a single fix for a panic bug
on invalid arguments to scrypt.Key.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is just a routine upgrade. There are absolutely no useful changes in
this release, but the Go team routinely just ratchets up the
interdependencies between the golang.org/x/* modules, and this one was
recently unblocked by us upgrading to golang.org/x/sys v0.42.0.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is just a routine upgrade.
Changes to this module are often tricky to review because OpenTofu's
relationship to most code in this module is very indirect, but from
studying the code diff carefully it doesn't seem like any changes here will
negatively impact OpenTofu's behavior.
This changeset includes some improvements to how supported CPU features are
detected on darwin_arm64 which may cause architecture-specific code in
some of our dependencies to perform better by using newer architecture
features, but I've not gone searching for any specific examples of that.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is just a routine upgrade to the latest available commit, just for
the sake of getting this off our list of available upgrades.
The only change here is from opentofu/registry-address#7, which is purely
a documentation update that doesn't affect the behavior.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
Go team policy is to ratchet all of these together and so this is just the
usual periodic churn of updating all of the "easy" ones (the ones that
don't affect code that OpenTofu is directly using) to unblock later
upgrades of the ones that might require more intricate review.
All of the direct dependencies upgraded here feature only irrelevant
upgrades such as code modernization or new functionality that OpenTofu does
not currently import.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This also includes an upgrade to github.com/cloudflare/circl@v1.6.3, which
is newer than strictly required by go-crypto but includes the fix for a
security advisory that does not affect OpenTofu but would otherwise cause
false-positive reports because the Go vulnerability database entry for it
is too broad. The goal here is only to reduce false-positive scanner noise
for folks using the forthcoming v1.12.x series.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
