Fix accidental recursion in jl_concrete_subtype

jl_concrete_subtype was recursing into the vararg element of a tuple,
which I don't think is correct (because it could be zero-length and
thus be constructible even if the element type is not). Fix that and
as a bonus get we are now able to get rid of the previous condition
that (accidentally) special cased tuples to have that behavior.

Fixes #31062

src/gf.c

@@ -2648,11 +2648,7 @@ int jl_has_concrete_subtype(jl_value_t *typ)
     if (((jl_datatype_t*)typ)->name == jl_namedtuple_typename)
         return jl_has_concrete_subtype(jl_tparam1(typ));
     jl_svec_t *fields = ((jl_datatype_t*)typ)->types;
-    size_t i, l = jl_svec_len(fields);
-    if (l != ((jl_datatype_t*)typ)->ninitialized)
-        if (((jl_datatype_t*)typ)->name != jl_tuple_typename)
-            return 1;
-    for (i = 0; i < l; i++) {
+    for (size_t i = 0; i < ((jl_datatype_t*)typ)->ninitialized; i++) {
         jl_value_t *ft = jl_svecref(fields, i);
         if (!jl_has_concrete_subtype(ft))
             return 0;

test/core.jl

@@ -6865,3 +6865,11 @@ let x = SplatNew{Tuple{Int16}}((1,))
     @test x.y === (Int16(1),)
 end
 @test_throws ArgumentError SplatNew{Int8}()
+
+# Issue #31062 - Accidental recursion in jl_has_concrete_subtype
+struct Bar
+    x::NTuple{N, Bar} where N
+end
+# Use eval to make sure that this actually gets executed and not
+# just constant folded by (future) over-eager compiler optimizations
+@test isa(Core.eval(@__MODULE__, :(Bar())), Bar)