[Bug]: incompatible types of default arguments inconsistently cause errors

[DanilaFe]

In some cases, instead of rejecting candidates whose instantiations make their formal/default value pairs invalid, the compiler reports a fatal error and exits.

There is precedent to allow resolution to continue even if one of the formals' default value ends up incorrect. We have existing tests that lock in that behavior: during candidate resolution, even if a type formal's default value ends up incorrect after instantiation (or lack thereof), if its where clause is false, other candidates can still be selected.

The below program seems like it should be valid, but is not. Here, a special overload of foo is defined that initializes its default value with a real number if the argType supports real numbers. Otherwise, a fallback overload is defined that initializes the default with an integer. The same effect ought to be achievable without a config type with an additional argument to foo that precedes pi; however, due to #27973, the type of pi is not constrained by the types of the preceding formals.

proc canSupportReal(type x) param do return x == real(32) || x == real(64);
config type fooArgType = integral;
proc foo(param pi: fooArgType = 3.14) where canSupportReal(fooArgType) { writeln("pi = ", pi); }
proc foo(param pi: fooArgType = 3) { writeln("pi = ", pi); }
foo();

This is likely because the logic for instantiations throws fatal errors eagerly:

chapel/compiler/resolution/ResolutionCandidate.cpp

Lines 506 to 508 in d03955d

	USR_FATAL(formal,
	"type mismatch between declared formal type "
	"and default value type");

chapel/compiler/resolution/generics.cpp

Lines 719 to 721 in d03955d

	USR_FATAL(formal,
	"type mismatch between declared formal type "
	"and default value type");

Associated future tests

test/functions/default-arguments/incompatible-default-arg-types.chpl (#27979)