JuliaLang / julia / 1301

77%

Build Type

push

buildkite

Committed by web-flow

Commit Message

ccall: make distinction of pointer vs name a syntactic distinction (#59165)

We have long expected users to be explicit about the library name for
`ccall`, and the `@ccall` macro has even always enforced that. That
means users should have already been using explicit syntax, even though
it wasn't strictly enforced. And indeed, the other syntax forms weren't
handled reliably anyways (since doing so would require linearizing IR if
and only if the runtime values required it, which is not something that
is computable, and thus was often done wrong). This now intends to align
the runtime and compiler to expect only those syntax forms that we could
reliably handle in the past without errors, and adds explicit errors for
other cases, most of which we previously knew would be unreliable due to
reliance upon inference in making particular decisions for the
semantics. The `ccall` function is already very special since it is more
like a actual macro (it does not exist as a binding or value), so we can
make unusual syntax decisions like this, mirroring `@ccall` also.

This fixes #57931, mostly by restricting the set of things that are
allowed to the set of things that have an obvious and pre-existing
behavior to be guaranteed to do that behavior. The hope is to PkgEval
this to check if any packages are doing something unusual and see if we
even need to allow anything else.

This drops support for https://github.com/JuliaLang/julia/pull/37123,
since we were going to use that for LazyLibraries, be we decided that
approach was quite buggy and that PR would make static compilation quite
impossible to support, so we instead actually implemented LazyLibraries
with a different approach. It could be re-enabled, but we never had
correct lowering or inference support for it, so it is presumably still
unused.

The goal is to cause breakage only where the package authors really
failed to express intent with syntax, and otherwise to explicitly
maintain support by adding cases ... (continued)

Run Details

20 of 35 new or added lines in 8 files covered. (57.14%)

721 existing lines in 81 files now uncovered.

60487 of 79754 relevant lines covered (75.84%)

7672511.81 hits per line