fix(parser): allow new Foo IDENT => ... indirect-object form

[fglock]

Summary

Commit 668a348 ("don't greedily consume new as indirect-object class") introduced a regression that broke the legitimate indirect-object form:

my $req = new HTTP::Request GET => $config;

This is exactly the syntax used in Log::Log4perl::Config line 647, so any program that loaded Log::Log4perl failed to compile — including CPAN itself, which surfaced as a confusing tail-end failure of jcpan -t <anything>:

... All tests successful ...
Undefined subroutine &Log::Log4perl::Logger::cleanup called at .../Log/Log4perl.pm line 5
exit 1

The actual symptom was a syntax error ... near "::Request GET " while requiring Log::Log4perl::Config, which then prevented Log::Log4perl::Logger::cleanup from being defined when its END block fired.

Root cause

The added rejection clause in SubroutineParser.java fired whenever the candidate "class" was unknown and the next token was an IDENTIFIER. That correctly handled myfunc new Foo (4,5) (outer myfunc is a known sub) but also wrongly rejected the bare top-level case new HTTP::Request GET => $url where GET is just the first list-arg.

Fix

Restrict the rejection clause to subExists — i.e. only when the outer call is itself a known subroutine (the original target case). The bare top-level new Class IDENT => ... then parses as Class->new(IDENT => ...) again.

Test plan

• make passes (all unit tests green)
• jperl -MLog::Log4perl -e 1 no longer errors
• jcpan -t URI::Simple exits 0
• Original disambiguation still works: f new Foo (1) parses as f(Foo->new(1)) (verified with a defined f and Foo::new printing trace output)

Generated with Devin