In a future commit we will adopt golangci-lint v1.64.5, which now triggers
lint warnings for some code that was previously not detected. This commit
is the smallest change to address those differences.
Unfortunately the "cloud" package and the "remote" backend both rely on
non-idiomatic error message formatting because they emit the returned error
message text directly into the UI, so to avoid changing the UI output but
also avoid significant refactoring this just adds nolint comments to those
for now. A future commit might address this by reworking things so that
the UI takes care of its own presentation concerns instead of relying on
the main implementation to directly generate UI-appropriate error strings.
This also completely disables the exportloopref linter, because that was
for a loop scoping hazard that was already addressed by a language change
in Go 1.22. This linter is therefore completely removed in newer versions
of golangci-lint and would thus generate an error if left enabled after
upgrading.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
Go 1.24 introduces stricter checks for format string validation.
This commit fixes instances where non-constant format strings were
used in calls to functions like `fmt.Errorf`, `fmt.Printf`, and similar.
Changes include:
- Replacing dynamically constructed strings passed as format strings
with constant format strings.
- Refactoring `fmt.Sprintf` calls to ensure the format string matches
the number of arguments provided.
- Simplifying redundant formatting and ensuring compliance with Go
1.24's stricter `vet` tool checks.
This update ensures compatibility with Go 1.24 and prevents potential
runtime errors caused by misinterpreted dynamic format strings.
Resolves#2389
Signed-off-by: Mikel Olasagasti Uranga <mikel@olasagasti.info>
Co-authored-by: Martin Atkins <mart@degeneration.co.uk>
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
A lot of our testing utilities were written before the introduction of the
testing.TB interface that represents what *testing.T and *testing.B have
in common, and those that weren't have followed precedent from those that
were in directly expecting *testing.T.
Using testing.TB instead makes these helpers usable from both normal tests
and testing benchmark functions, since they only use methods that are
available in both contexts.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
We're intending to gradually improve all of the existing functions that
fail these checks as a separate project from other work, because fixing
for these particular lint rules tends to be too invasive to be safe or
sensible to combine with other work.
Therefore we'll temporarily disable these lints from the main lint run
and add a separate .golangci-complexity.yml that we can use to track our
progress towards eliminating those lint failures without continuing to
litter the code with nolint comments in the meantime.
This also removes all of the existing nolint comments for these linters so
that we can start fresh and review each one as part of our improvement
project.
We'll re-enable these linters (and remove .golangci-complexity.yml) once
each example has either been rewritten to pass the checks or we've
concluded that further decomposition would hurt readability and so added
"nolint" comments back in so we can review whether our lint rules are too
strict once we've got a bunch of examples to consider together.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
By building a map from module path to snapshotModule we can avoid repeatedly scanning the set of modules for each call to Open.
Signed-off-by: Jon Johnson <jon.johnson@chainguard.dev>
Previously we made a very generic suggestion to use -target to split a
change into two parts as a workaround for the fact that count and for_each
must be known during planning. That works, but we didn't have enough
information available to tell the operator exactly what to target and so
anyone who is not an expert on the configuration they're working with tends
to get stuck unable to figure out exactly what they need to do.
The new -exclude option gives us an opportunity to do better here: we tend
to know for which object we're currently evaluating count or for_each, and
so we can mention that object directly in the error message when if we
recommend to use -exclude instead of -target.
Not all objects that support count/for_each will necessarily be directly
targetable, so we can still potentially recommend -target when we're
dealing with one of those objects. For example, as of this commit that
is true for for_each in a provider block, because there is not currently
any syntax for specifying a provider configuration as an addrs.Targetable.
Perhaps we'll introduce such a thing in the future, but that's outside the
scope of this change that's primarily focused on improving the messaging
for resource and module count/for_each.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
Kind of odd code smell, but the only alternative I could think of was a
panic. Would rather ensure this requirement at compile time instead.
Signed-off-by: Christian Mesh <christianmesh1@gmail.com>
In the main language runtime input variables have both a "raw" value as
provided by the caller and a "finalized" value that has been
type-converted, default-attributes-inserted, and validated.
Unfortunately the "early eval" codepath is essentially a reimplementation
of the language runtime in terms of data available in the static
configuration, and it previously wasn't properly emulating the finalization
of input variable values and was thus incorrectly exposing the "raw"
values into a module instead of the "finalized" values.
Since we are already in the v1.9 prerelease period significant refactoring
is too risky, and so this just copies the most important transformations
from the language runtime into the early eval runtime. We hope to find a
more sustainable way to implement this in the future, but that will likely
require refactoring of both the early eval codepath _and_ the traditional
language runtime, and so that work needs to begin early in a minor release
period.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
