fix macros @which, @edit, @functionloc, @less for literal_pow case.

[KlausC]

The macros @which, @edit, @functionloc, @less from InteractiveUtils, if
applied to the case of literal powers, like a^12 or 2^-1 used to direct the
user to function ^, while the compiler generates code for Base.literal_pow.

Now the user is shown the code, the compiler generates.

Fixes #53691
Fixes #43337
Fixes #21014

Observation: the literal_pow code is generated only if x is a signed integer constant with -2^61 <= x < 2^61.

[KlausC]

Can somebody have a look at this tiny but valuable improvement of InteractiveUtils?

[mbauman]

I think this is great and much needed, but I'm quite puzzled why typemax(Int)÷4 is the cutoff in the first place. The "real" transformation happens here — or so I think:

julia/src/julia-syntax.scm

Lines 2683 to 2685 in 09400e4

	((and (eq? (identifier-name f) '^) (length= e 4) (integer? (cadddr e)))
	(expand-forms
	`(call (top literal_pow) ,f ,(caddr e) (call (call (core apply_type) (top Val) ,(cadddr e))))))

So why is 1^2305843009213693951 literal_pow but 1^2305843009213693952 not? Both are integers, and lisp's (integer? 2305843009213693952) agrees.

But flisp does use a different type for values between 2^61-2^63. And depending on the path we take to lowering, Julia boxes these large values into opaque pointers instead of flisp's c primitives when going from a Julia Expr to flisp and back. And then the opaque pointer is no longer integer?.

▶ julia --lisp
> 2305843009213693951
2305843009213693951

> 2305843009213693952
#int64(2305843009213693952)

> (julia-expand (julia-parse "1^2305843009213693952"))
(call (top literal_pow) (outerref ^) 1
      (call (call (core apply_type) (top Val) #int64(2305843009213693952))))

But this is all a non-sequitur to this PR — and this PR does accurately reflect the status quo as far as I can see.

[KlausC]

@mbauman: Yes, this PR is to reflect the current behavior of the compiler(s). Of course that has to be adapted, in case that should change.

[KlausC]

bump