Files
el/lang/tools/check/definitions.sh
T
bigmerge 79f6cb7985 ANSWER: if the partition is a neighbourhood, does linking survive?
The question is premature, and measuring says why. El's partition is a
FILESYSTEM PATH, not a neighbourhood, and there is no namespacing at all.

MEASURED
  import is textual inlining (resolve_imports), guarded against double
  inclusion by a __elc_imp__:<path> state key
  when a .elh header exists the header is inlined instead and the .el is marked
  seen, so symbols resolve at C link time -- so linking IS real, delegated to C
  two modules defining `helper` emit two C functions into one translation unit

So linking barely survives the PATH partition. Whether it survives a
neighbourhood partition cannot be asked yet.

A DIAGNOSTIC REGRESSION I CAUSED, found by asking this question. cc does catch
the collision, but reports:

    error: redefinition of '__el_body_helper'
    error: redefinition of '__env_helper'
    error: redefinition of '__thunk_helper'
    error: redefinition of 'helper'

The user's own function is FOURTH. The first three are generated symbols
introduced by the unconditional-wrapper pass earlier today -- before it, there
was one clear message. Repaired by catching the collision at El level instead:

    duplicate definition: 'helper' is defined 2 times — El has no namespacing,
    so imported modules share one global scope

LIMIT, stated rather than hidden: textual inlining destroys file provenance. By
the time codegen runs there is one source string, so the message can say WHICH
name collides but not which files. Naming a.el and b.el needs provenance
threaded through resolve_imports.

104/104 native, 4/4 definitions_query.sh, the compiler itself reports clean,
fixpoint ok.
2026-08-17 09:54:23 -05:00

25 lines
1.2 KiB
Bash
Executable File

#!/usr/bin/env bash
# definitions.sh — catch duplicate top-level definitions at El level.
#
# El has no namespacing. `import` is textual inlining, so two modules defining
# the same name emit two C functions into one translation unit. cc does catch
# it, but reports the generated helpers (__el_body_f, __env_f, __thunk_f) before
# the user's own function, so the first three errors name symbols the user never
# wrote.
#
# LIMIT, stated rather than hidden: textual inlining destroys file provenance.
# By the time codegen runs there is one source string and no record of which
# file a definition came from, so this can say WHICH name collides but not which
# files. Naming the files needs provenance threaded through resolve_imports.
set -uo pipefail
REL="${1:?usage: definitions.sh <relations-file>}"
[ -f "$REL" ] || exit 0
V=0
while read -r name count; do
[ "$count" -gt 1 ] || continue
printf "duplicate definition: '%s' is defined %s times — El has no namespacing, so imported modules share one global scope\n" "$name" "$count"
V=$((V+1))
done < <(grep ' calls defines$' "$REL" | awk '{print $1}' | sort | uniq -c | awk '{print $2, $1}')
[ "$V" -eq 0 ] && echo "definitions: clean"
exit "$V"