line number incorrect for methods defines in files over 2,147,483,647 lines long

[oxinabox]

Consider:

julia> fh = open("verylong.jl", "w")
IOStream(<file verylong.jl>)

julia> for ii in 1:typemax(Int32)
       println(fh)
       end

julia> println(fh, "foo()=1")

~/temp/longfile ❯ ls -lah .                                                                                                                                                            16:53:34
total 2.1G
drwxrwxr-x 2 oxinabox oxinabox 4.0K Sep 12 16:51 .
drwxrwxr-x 4 oxinabox oxinabox 4.0K Sep 12 16:51 ..
-rw-rw-r-- 1 oxinabox oxinabox 2.1G Sep 12 16:53 verylong.jl
~/temp/longfile ❯ wc -l verylong.jl                                                                                                                                                    16:53:37
2147483648 verylong.jl
~/temp/longfile ❯ julia                                                                                                                                                                16:53:53
               _
   _       _ _(_)_     |  Documentation: https://docs.julialang.org
  (_)     | (_) (_)    |
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.9.3 (2023-08-24)
 _/ |\__'_|_|_|\__'_|  |  Official https://julialang.org/ release
|__/                   |

julia> include("verylong.jl")
foo (generic function with 1 method)

julia> foo()
1

julia> @which foo()
foo()
     @ Main ~/temp/longfile/verylong.jl:-2147483648

The correct line number is 2147483648 But it comes out negated, because we have overflowed an Int32.

Realistically, I don't imagine even extremely long generated source code files would exceed this limit. And I suspect if it wasn't mostly whitespace something else would have broken first. But also, I am surprised we use an Int32 for this even on a 64 bit system,

[KristofferC]

Realistically, I don't imagine even extremely long generated source code files would exceed this limit.

I agree with this and I think it is fine to save on the space not to support this.

[abraemer]

Is there a reason to use a signed Int32 as opposed to an UInt32? That would allow for twice the number of lines before overflowing... :smile:

[vtjnash]

There are a lot of places that consume the info, so we can't be sure all of them will handle unsigned numbers well and they print normally as hex then, but that said, LLVM does expect them as uint32: https://llvm.org/doxygen/classllvm_1_1DILocation.html#a756c88c4d0458513f7a73da2e904afbf