A local named after a libm builtin (floor) breaks unrelated modules, with errors attributed to the wrong file

[nicolas-maman]

Seen with aetherc from Aether 0.651.0 (Windows, ae3d).

A program with a local variable named floor:

on_start(state: ptr, e: *Engine) {
    floor = loader.plane(2, 10.0)
    core.model_set_position(floor, 0.0, 0.0, 0.0)
}

fails type checking with three errors that point at a different file altogether:

error[E0200]: cannot cast ptr to int with `as`: a value cast converts between a distinct type and its base, or between numeric types
  --> examples/gltf_viewer.ae:127:18
  --> examples/gltf_viewer.ae:128:18
  --> examples/gltf_viewer.ae:129:18

examples/gltf_viewer.ae has nothing at those lines; the errors are in an imported module (ae3d.noise, which does floor(x) as int), where the builtin floor now resolves to the program's *Model variable. Editing the program does not move the line numbers, which is what makes it hard to find: I bisected the whole file before guessing the name.

Two asks:

1. A local should not shadow a builtin across module boundaries -- the module's floor(x) should stay libm's whatever a program names its variables -- or the compiler should refuse the shadowing with a message naming it.
2. An error inside an imported module should name the module's file and line, not the main program with the module's line numbers.

Renaming the variable (ground) fixes it.

[nicolas-maman]

Same family, worse outcome, seen while writing a test for #2094: a user function named read:

struct Thing { value: int }
read(thing: *Thing) -> int { return thing.value }
main() {
    thing = Thing { value: 5 }
    println("${read(&thing)}")
}

compiles (a gcc warning about the incompatible declaration of read from <io.h> on MinGW, nothing at all from Aether) and prints -1: the generated C calls libc's read(int, void*, unsigned) with a Thing*, and the program silently gets the CRT's return value. On Linux glibc it is the same collision with <unistd.h>'s read. Any user function whose name is a libc/POSIX symbol the generated C pulls in (read, write, open, close, send, time, index, floor, …) is in the same position; the compiler already renames the index case for closure parameters (#2087 shows it doing so half-way), so the mechanism exists — it wants applying to every user-defined symbol that would collide, or a diagnostic at the definition.