fix #8405: -d:useNimRtl now works even when {.rtl.} procs are used at compile time; CTFFI now works with {dynlib} #11635
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
-d:nimHasLibFFI
, extending the scope of Foreign function interface at Compile Time #10150 to cover{.dynlib:mylib.}
, not just{.importc.}
which was only for symbols dlsym'd from the main running executablethis is especially useful as we can now call arbitrary compiled user code at CT imported as a shared library (eg regex, or access global variables via wrappers, or to speedup CT operations by avoiding the VM interpretation, or writing to stderr at compile time)
/cc @awr1 @ccll
/cc @zah because you asked about that bug here Foreign function interface at Compile Time #10150 (comment)
#8405 has been a major blocker for writing shared libraries / plugins: it prevented using any proc marked as
{.rtl.}
at compile time (more generally, any proc with{.importc.}
); for example simply importing pkg/regex would fail with-d:useNimRtl
because somewhere in the code,strutils.repeat
is used at CT. (note that #10150 mitigates but doesn't fix this as explained here: #8405 (comment))After this PR,
importc
procs with a body are executed in the VM as ifimportc
wasn't specified: the body is compiled when used at compile time, and symbol is dynamically loaded when used at runtime.nim can now be compiled with
-d:useNimRtl
, eg:(whether the produced binary is a fully working nim compiler is a separate issue that can be addressed later)
whereas this would give errors before this PR.
example usage: CT FFI, dynlib, importc; with and without VM override
output with nim c -r main.nim
output with nim c -r --experimental:compiletimeFFI -d: case_nim_has_ffi main.nim
(and nim built with -d:nimHasLibFFI)
note
-d:leanCompiler
the above command gives: I get: docutils/highlite.nim(401, 15) Error: type mismatch: got <openarray[string], string, proc (a: string, b: string): int{.cdecl, noSideEffect, gcsafe, locks: 0.}>lib/pure/parseopt.nim
, after recompiling./bin/nim c lib/nimrtl.nim
, and recompilingbin/nim_temp1
as above, runningbin/nim_temp1
would error with:could not import: npocmdLineRest
lib/system/repr.nim
was also needed to prevent:lib/system/repr.nim(306, 3) Error: undeclared identifier: 'initReprClosure'