configs: Refined error messages for mismatched provider passing

This set of diagnostic messages is under a number of unusual constraints
that make them tough to get right:
 - They are discussing a couple finicky concepts which authors are
   likely to be encountering for the first time in these error messages:
   the idea of "local names" for providers, the relationship between those
   and provider source addresses, and additional ("aliased") provider
   configurations.
 - They are reporting concerns that span across a module call boundary,
   and so need to take care to be clear about whether they are talking
   about a problem in the caller or a problem in the callee.
 - Some of them are effectively deprecation warnings for features that
   might be in use by a third-party module that the user doesn't control,
   in which case they have no recourse to address them aside from opening
   a feature request with the upstream module maintainer.
 - Terraform has, for backward-compatibility reasons, a lot of implied
   default behaviors regarding providers and provider configurations,
   and these errors can arise in situations where Terraform's assumptions
   don't match the author's intent, and so we need to be careful to
   explain what Terraform assumed in order to make the messages
   understandable.

After seeing some confusion with these messages in the community, and
being somewhat confused by some of them myself, I decided to try to edit
them a bit for consistency of terminology (both between the messages and
with terminology in our docs), being explicit about caller vs. callee
by naming them in the messages, and making explicit what would otherwise
be implicit with regard to the correspondences between provider source
addresses and local names.

My assumed audience for all of these messages is the author of the caller
module, because it's the caller who is responsible for creating the
relationship between caller and callee. As much as possible I tried to
make the messages include specific actions for that author to take to
quiet the warning or fix the error, but some of the warnings are only
fixable by the callee's maintainer and so those messages are, in effect,
a suggestion to send a request to the author to stop using a deprecated
feature.

I think these new messages are also not ideal by any means, because it's
just tough to pack so much information into concise messages while being
clear and consistent, but I hope at least this will give users seeing
these messages enough context to infer what's going on, possibly with the
help of our documentation.

I intentionally didn't change which cases Terraform will return warnings
or errors -- only the message texts -- although I did highlight in a
comment in one of the tests that what it is a asserting seems a bit
suspicious to me. I don't intend to address that here; instead, I intend
that note to be something to refer to if we later see a bug report that
calls that behavior into question.

This does actually silence some _unrelated_ warnings and errors in cases
where a provider block has an invalid provider local name as its label,
because our other functions for dealing with provider addresses are
written to panic if given invalid addresses under the assumption that
earlier code will have guarded against that. Doing this allowed for the
provider configuration validation logic to safely include more information
about the configuration as helpful context, without risking tripping over
known-invalid configuration and panicking in the process.

internal/configs/config_build.go

@@ -31,7 +31,7 @@ func BuildConfig(root *Module, walker ModuleWalker) (*Config, hcl.Diagnostics) {
 		cfg.resolveProviderTypes()
 	}
 
-	diags = append(diags, validateProviderConfigs(nil, cfg, false)...)
+	diags = append(diags, validateProviderConfigs(nil, cfg, nil)...)
 
 	return cfg, diags
 }

internal/configs/config_build_test.go

@@ -224,7 +224,7 @@ func TestBuildConfigInvalidModules(t *testing.T) {
 				}
 
 				if !found {
-					t.Errorf("Expected error diagnostic containing %q", msg)
+					t.Errorf("Expected error diagnostic containing:\n    %s", msg)
 				}
 			}
 
@@ -241,7 +241,7 @@ func TestBuildConfigInvalidModules(t *testing.T) {
 				}
 
 				if !found {
-					t.Errorf("Unexpected error: %q", diag)
+					t.Errorf("Unexpected error:\n    %s", diag)
 				}
 			}
 
@@ -255,7 +255,7 @@ func TestBuildConfigInvalidModules(t *testing.T) {
 				}
 
 				if !found {
-					t.Errorf("Expected warning diagnostic containing %q", msg)
+					t.Errorf("Expected warning diagnostic containing:\n    %s", msg)
 				}
 			}
 
@@ -272,7 +272,7 @@ func TestBuildConfigInvalidModules(t *testing.T) {
 				}
 
 				if !found {
-					t.Errorf("Unexpected warning: %q", diag)
+					t.Errorf("Unexpected warning:\n    %s", diag)
 				}
 			}
 

internal/configs/provider.go

@@ -46,6 +46,11 @@ func decodeProviderBlock(block *hcl.Block) (*Provider, hcl.Diagnostics) {
 	name := block.Labels[0]
 	nameDiags := checkProviderNameNormalized(name, block.DefRange)
 	diags = append(diags, nameDiags...)
+	if nameDiags.HasErrors() {
+		// If the name is invalid then we mustn't produce a result because
+		// downstreams could try to use it as a provider type and then crash.
+		return nil, diags
+	}
 
 	provider := &Provider{
 		Name:      name,

internal/configs/testdata/config-diagnostics/empty-configs/warnings

@@ -1,4 +1,4 @@
-empty-configs/mod/main.tf:10,1-15: Empty provider configuration blocks are not required; Remove the foo provider block from module.mod
-empty-configs/mod/main.tf:13,1-15: Empty provider configuration blocks are not required; Remove the foo.bar provider block from module.mod
-empty-configs/mod/main.tf:17,1-15: Empty provider configuration blocks are not required; Remove the baz provider block from module.mod.\nTo ensure the correct provider configuration is used, add baz to the required_providers configuration
-empty-configs/mod/main.tf:20,1-15: Empty provider configuration blocks are not required; Remove the baz.bing provider block from module.mod. Add baz.bing to the list of configuration_aliases for baz in required_providers to define the provider configuration name
+empty-configs/mod/main.tf:10,1-15: Redundant empty provider block; Earlier versions of Terraform used empty provider blocks ("proxy provider configurations") for child modules to declare their need to be passed a provider configuration by their callers. That approach was ambiguous and is now deprecated.
+If you control this module, you can migrate to the new declaration syntax by removing all of the empty provider "foo" blocks and then adding or updating an entry like the following to the required_providers block of module.mod:
+empty-configs/mod/main.tf:17,1-15: Redundant empty provider block; Earlier versions of Terraform used empty provider blocks ("proxy provider configurations") for child modules to declare their need to be passed a provider configuration by their callers. That approach was ambiguous and is now deprecated.
+If you control this module, you can migrate to the new declaration syntax by removing all of the empty provider "baz" blocks and then adding or updating an entry like the following to the required_providers block of module.mod:

internal/configs/testdata/config-diagnostics/incorrect-type/errors

@@ -1 +1 @@
-incorrect-type/main.tf:15,5-8: Invalid type for provider module.mod.provider["example.com/vendor/foo"]; Cannot use configuration from provider["registry.terraform.io/hashicorp/foo"] for module.mod.provider["example.com/vendor/foo"]
+incorrect-type/main.tf:15,11-14: Provider type mismatch; The local name "foo" in the root module represents provider "hashicorp/foo", but "foo" in module.mod represents "example.com/vendor/foo".

internal/configs/testdata/config-diagnostics/incorrect-type/warnings

@@ -1 +1 @@
-incorrect-type/main.tf:16,5-8: Provider baz is undefined; Module module.mod does not declare a provider named baz.\nIf you wish to specify a provider configuration for the module
+incorrect-type/main.tf:16,5-8: Reference to undefined provider; There is no explicit declaration for local provider name "baz" in module.mod, so Terraform is assuming you mean to pass a configuration for "hashicorp/baz".

internal/configs/testdata/config-diagnostics/nested-provider/errors

@@ -1,3 +1 @@
-Module module.child.module.child2 contains provider configuration; Providers cannot be configured within modules using count, for_each or depends_on
-
-
+nested-provider/root.tf:2,11-12: Module is incompatible with count, for_each, and depends_on; The module at module.child.module.child2 is a legacy module which contains its own local provider configurations, and so calls to it may not use the count, for_each, or depends_on arguments.

internal/configs/testdata/config-diagnostics/override-provider/errors

@@ -1 +1 @@
-override-provider/main.tf:17,5-8: Cannot override provider configuration; Provider bar is configured within the module module.mod and cannot be overridden.
+override-provider/main.tf:17,5-8: Cannot override provider configuration; The configuration of module.mod has its own local configuration for bar, and so it cannot accept an overridden configuration provided by the root module.

internal/configs/testdata/config-diagnostics/pass-inherited-provider/main.tf

@@ -5,3 +5,19 @@ provider "test" {
 module "mod" {
   source = "./mod"
 }
+
+# FIXME: This test is for an awkward interaction that we've preserved for
+# compatibility with what was arguably a bug in earlier versions: if a
+# child module tries to use an inherited provider configuration explicitly by
+# name then Terraform would historically use the wrong provider configuration.
+#
+# Since we weren't able to address that bug without breaking backward
+# compatibility, instead we emit a warning to prompt the author to be explicit,
+# passing in the configuration they intend to use.
+#
+# This case is particularly awkward because a change in the child module
+# (previously referring to a provider only implicitly, but now naming it
+# explicitly) can cause a required change in _this_ module (the caller),
+# even though the author of the child module would've seen no explicit warning
+# that they were making a breaking change. Hopefully we can improve on this
+# in a future language edition.

internal/configs/testdata/config-diagnostics/pass-inherited-provider/warnings

@@ -1 +1 @@
-pass-inherited-provider/mod/main.tf:15,16-20: No configuration passed in for provider test in module.mod; Provider test is referenced within module.mod, but no configuration has been supplied
+pass-inherited-provider/main.tf:5,1-13: Missing required provider configuration; The configuration for module.mod expects to inherit a configuration for provider hashicorp/test with local name "test", but the root module doesn't pass a configuration under that name.

internal/configs/testdata/config-diagnostics/required-alias/errors

@@ -1 +1 @@
-required-alias/main.tf:1,1-13: No configuration for provider foo.bar; Configuration required for module.mod.provider["registry.terraform.io/hashicorp/foo"].bar
+required-alias/main.tf:1,1-13: Missing required provider configuration; The child module requires an additional configuration for provider hashicorp/foo, with the local name "foo.bar".

internal/configs/testdata/config-diagnostics/unexpected-provider/warnings

@@ -1,2 +1 @@
-unexpected-provider/main.tf:13,5-8: Provider foo is undefined; Module module.mod does not declare a provider named foo.
-
+unexpected-provider/main.tf:13,5-8: Reference to undefined provider; There is no explicit declaration for local provider name "foo" in module.mod, so Terraform is assuming you mean to pass a configuration for "hashicorp/foo".

internal/configs/testdata/config-diagnostics/unknown-root-provider/warnings

@@ -1 +1 @@
-unknown-root-provider/main.tf:5,11-14: Provider bar is undefined; No provider named bar has been declared in the root module
+unknown-root-provider/main.tf:5,11-14: Reference to undefined provider; There is no explicit declaration for local provider name "bar" in the root module, so Terraform is assuming you mean to pass a configuration for provider "hashicorp/bar".