Fix implicit-any error for bare tuple and Callable (#1970)

[jackulau]

Summary

Fixes #1970

When the implicit-any error is enabled, bare tuple and Callable annotations now generate errors, matching the existing behavior for list.

Before

def f(
    x: list,      # ERROR: implicit-any
    y: tuple,     # no error
    z: Callable,  # no error 
):
    pass

After

def f(
    x: list,      # ERROR: implicit-any
    y: tuple,     # ERROR: implicit-any
    z: Callable,  # ERROR: implicit-any
):
    pass

Changes

• Add ImplicitAny error for SpecialForm::Tuple, SpecialForm::Callable, and SpecialForm::Type in canonicalize_all_class_types
• Add ImplicitAny error for ClassDef(tuple) to handle the builtin tuple
• Add test case covering the fix

Notes

• Bare builtin type still doesn't error because it's not defined as generic in typeshed (the type class has no type parameters). However, typing.Type does error correctly.

[rchen152]

Thanks! The logic looks good, but it would be nice if we could reduce code duplication a bit.

[rchen152]

Would it be possible to pull out the error message creation from

pyrefly/pyrefly/lib/alt/class/targs.rs

Lines 176 to 183 in 713e5b7

	vec1![
	format!(
	"Cannot determine the type parameter `{}` for generic class `{}`",
	tparam.name(),
	cls.name(),
	),
	"Either specify the type argument explicitly, or specify a default for the type variable.".to_owned(),
	],

into a reusable helper method rather than copy-pasting?

[github-actions]

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

[meta-codesync]

@grievejia has imported this pull request. If you are a Meta employee, you can view this in D90608813.

[rchen152]

Review automatically exported from Phabricator review in Meta.