haxe.PosInfos rework

[kLabz]

Implicit ?pos:haxe.PosInfos argument rework

Based on #12936 — please review/merge that first.

haxe.PosInfos used to be special-cased in a dozen isolated spots, each re-deriving "tolerate a trailing optional PosInfos" with its own ad-hoc check, and with gaps between them. This PR centralizes that into a single notion of an implicit trailing argument (is_implicit_arg / split_implicit_trailing_args / strip_implicit_trailing_args), then wires every signature-comparison site (accessors, casts, operators, rest, macros) and every call site through it.

On top of the cleanup it closes several long-standing issues and generalizes the mechanism so user types — not just haxe.PosInfos — can auto-fill an omitted argument.

Fixes

• Property accessors may declare a trailing ?pos:haxe.PosInfos. get_x(?pos:haxe.PosInfos) / set_x(v, ?pos:haxe.PosInfos) now type-check — the accessor's implicit trailing args are stripped before it is unified against the property's type. Closes PosInfos in accessors? #6095.
• PosInfos after a rest argument. function f(...rest:Int, ?pos:haxe.PosInfos) is now accepted; the rest stays physically last (native varargs codegen is unchanged) and pos is auto-filled. Closes haxe.Rest and haxe.PosInfos as last arguments #10808.
• PosInfos on operator overloads. A trailing ?pos:haxe.PosInfos is allowed on @:op unary/binary operator functions (@:op(A!) function unwrap(?pos)), and on @:from / @:to casts. Closes Operator overloading together with PosInfos #7362.
• PosInfos on macro functions. A macro function may declare a trailing ?pos:haxe.PosInfos, auto-filled with the call-site position as a structured haxe.PosInfos — see Macros and haxe.PosInfos section below. Closes haxe.PosInfos and macro #11712.

New: @:posInfos — explicit override of the implicit position

By default the implicit haxe.PosInfos argument is auto-filled with the call-site position. @:posInfos lets a call explicitly designate an argument as the value for that slot, overriding the auto-fill, and pulls it out of the positional flow.

This matters when an earlier parameter's type is compatible with the position value, so a positional would otherwise capture it before it reaches pos. The classic case is a Dynamic rest, which accepts anything:

function log(...rest:Dynamic, ?pos:haxe.PosInfos):Void { /* ... */ }

var caller:haxe.PosInfos = getSomePos();

log(1, 2, caller);            // rest = [1, 2, caller], pos = auto-filled — caller is NOT the position!
log(1, 2, @:posInfos caller); // rest = [1, 2],         pos = caller

Same story for a preceding optional whose type also accepts the value:

function note(?value:Dynamic, ?pos:haxe.PosInfos):Void { /* ... */ }

note(caller);            // value = caller, pos = auto-filled
note(@:posInfos caller); // value = null,   pos = caller

Passing multiple @:posInfos arguments, or one with no matching haxe.PosInfos parameter, is a clear error.

New: implicit argument providers — @:implicitArgResolver

This generalizes the PosInfos auto-fill to user-defined types. Marking an abstract @:implicitArgResolver(name) means: when an optional argument of that abstract type is omitted at a call site, it is auto-filled by calling the named static function. haxe.PosInfos becomes just the built-in instance of this mechanism. Closes #4583.

The resolver may be a plain function (becomes a runtime call) or a macro function (runs at the call site, with the Context API available):

// plain resolver: filled with a runtime value when omitted
@:implicitArgResolver(resolve)
abstract Plain(String) from String to String {
	public inline function new(s:String) this = s;
	static function resolve():Plain return new Plain("plain");
}

// macro resolver: runs at the call site (e.g. capture the enclosing method)
@:implicitArgResolver(resolve)
abstract MacroCtx(String) to String {
	public inline function new(s:String) this = s;
	macro static function resolve() {
		return macro $v{haxe.macro.Context.getLocalMethod()};
	}
}

function log(msg:String, ?ctx:Plain):String return (ctx : String) + ": " + msg;

log("hi");          // ctx auto-filled with resolve() -> "plain: hi"
log("hi", "given"); // explicit value still wins

Rules (validated at declaration time with clear errors):

• the named field must exist and be static;
• it must take no required arguments (it is invoked with no explicit args) — it may itself take optional/implicit args, e.g. a ?pos:haxe.PosInfos that forwards the original call site;
• a plain (non-macro) resolver must return the abstract (or its underlying type);
• self- and mutually-referential resolvers are rejected (Cyclic @:implicitArgResolver) instead of looping.

Multiple implicit arguments (a resolver plus a PosInfos, say) fill independently, and a resolver-typed optional argument may sit before a rest argument.

New: macros and haxe.PosInfos

A macro function may now declare a trailing ?pos:haxe.PosInfos, auto-filled with the call site — as a structured haxe.PosInfos record (fileName, lineNumber, className, methodName), the same shape a regular function receives.

This complements Context.currentPos() rather than duplicating it. Both refer to the call site, but they differ in format: currentPos() returns an opaque Position (a file + byte range; Context.getPosInfos turns it into {file, min, max}), whereas ?pos hands you the resolved PosInfos directly — including the enclosing className / methodName, which a raw Position does not carry.

macro static function log(e:haxe.macro.Expr, ?pos:haxe.PosInfos) {
	trace(pos.className + "." + pos.methodName); // the caller's class/method
	return macro null;
}

It composes with the rest of the macro signature — extra Expr arguments and a trailing haxe.Rest both work — and the value can be forwarded: handing pos to a plain helper invoked inside the macro carries the original call site through.

The build-macro flavors resolve to the natural site:

• @:genericBuild → the use site (where the generic type is referenced);
• @:build / @:autoBuild → the class-build site (methodName is null);
• an init macro (--macro) → a synthetic command-line position.

Because the value is compiler-filled at compile time, passing it explicitly (an extra positional, or an @:posInfos override) is rejected with a clear error.

Workaround unlocked: Reflect.makeVarArgs + PosInfos (#6696)

A trace-like "any number of arguments + call-site position" function no longer needs Reflect.makeVarArgs (whose Dynamic result can't carry a per-call position). Thanks to rest + trailing PosInfos (above), just write:

function log(...rest:Dynamic, ?pos:haxe.PosInfos):Void {
	trace(pos.lineNumber, rest);
}

Each call gets its own position, fully typed and native. This doesn't change makeVarArgs itself, so #6696 stays open, but the use case it was about now has a first-class solution.

Notes

• #10955 (optional-before-rest skipping) is handled by the parent [typer] fix might_skip vs rest arguments #12936, not here.
• Backwards compatible: existing PosInfos behavior is unchanged; the new behavior only adds previously-rejected forms.

[kLabz]

@back2dos do you think the Implicit argument providers section covers your needs for #4583? (see also the added tests)

[Simn]

This function already exists in tOther.ml as is_rest.

[Simn]

I agree with the sentiment but this looks like it's trying to do too much at once and seems unnecessarily messy. It's also hard to review because of that and I'm not sure where to start.

I think the biggest hack is @:posInfos which is introduced to deal with the arcane issue #10808. I still argue that no further arguments should be allowed after ...rest, which would make the ...rest:Dynamic, ?pos:haxe.PosInfos example invalid. What should be supported here instead is implicit PosInfos arguments in non-trailing positions, which avoids this whole "compiler understands it as rest but it's actually pos" nonsense.

The ?value:Dynamic, ?pos:haxe.PosInfos variant would also be covered by that. Putting a more generic optional argument type before a more specific one and then expecting it to be skipped via some hacky metadata is a user code problem.

I'll stop there for now so we can iterate on it in a sane fashion, but I'll have more complaints down the line.

[back2dos]

@back2dos do you think the Implicit argument providers section covers your needs for #4583? (see also the added tests)

Yes, perfect ;)

---

Putting a more generic optional argument type before a more specific one and then expecting it to be skipped via some hacky metadata is a user code problem.

The thing is that there are two different intentions intermingling here:

1. support for different signatures (and I'm inclined to say that arg skipping is a hack that has outlived its usefulness with the advent of overloading)
2. support for implicit arguments (which is hardcoded into the compiler for exactly one type)

I concede that it's awkward trying to bring more predictability and control to a rather questionable design from two decades ago, but it's really not a user problem that these two concerns are so entangled. The more radical approach to fixing this would to be separate arguments into two different classes: an argument is either explicit (and only then can be optional) and or implicit (and then cannot be passed by the user).

Then there's no ambiguity in any of these:

• function log(value:Dynamic, @:implicit pos:haxe.PosInfos):Void;
• function log(...values:Dynamic, @:implicit pos:haxe.PosInfos):Void;
• function log(@:implicit pos:haxe.PosInfos, ...values:Dynamic):Void;

For inspiration, this is how Scala implements this: https://docs.scala-lang.org/tour/implicit-parameters.html

On one side there's how Scala derives those implicits at the call site, which is kinda besides the point here: we move that problem into the argument type and then allow the user to take full control via a macro (arguably more flexible - definitely sufficient for implementing a solution equivalent to Scala's). But what I want to draw attention to is that there's a clear separation there - even stricter than the one I proposed above (implicits are actually passed as a separate argument list). This separation allows the compiler to clearly know whether an argument is to be found at the call site or resolved via a separate mechanism (the context in Scala, the type in Haxe).