fix #12150 C++ free functions are now supported using new importcpp:"!$1" syntax

[timotheecour]

fix #12150

example

proc freeFn(a: cint) {.importcpp: "!$1".}
# maps to `void freeFn(int)`

[Clyybber]

This should be handled in ccgcalls.genPatternCall instead.

[timotheecour]

This should be handled in ccgcalls.genPatternCall instead.

this wouldn't help with #12150, try it; one problem was that sfInfixCall inhibited emitting a declaration in client code that calls importcpp on a free function

[Varriount]

Why doesn't importc work for this?

[timotheecour]

Why doesn't importc work for this?

because it would use c mangling. If you have a C++ free function, (eg: void fun(int a);), this would mangle differently.

[Araq]

this wouldn't help with #12150, try it; one problem was that sfInfixCall inhibited emitting a declaration in client code that calls importcpp on a free function

Please explain this in more detail.

[timotheecour]

@Araq this line should explain everything:

if sfInfixCall notin prc.flags: genProcPrototype(m, prc)

in the example of #12150, fun1 is an importcpp proc therefore before PR has sfInfixCall in prc.flags, so genProcPrototype isn't called, and fun1 isn't declared in t0725.nim, hence giving error: use of undeclared identifier 'fun1'

after PR, I distinguish C++ free functions (which need a declaration) vs methods (sfInfixCall), which don't.

[Araq]

Ok, but I meant to ask:

This should be handled in ccgcalls.genPatternCall instead.

Why can't it be done in genPatternCall? Seems the most obvious place to put it.

[timotheecour]

I don't see how that would work, at very least I don't see how it would be simpler than the way I wrote it, if you have a concrete idea in mind please provide more details / edit this PR.

I need to tell whether an importcpp symbol is sfInfixCall or not early on (inside processImportCpp) since it affects semantics/codegen in a few places, so moving the following lines to genPatternCall adds complexity

let isFreeFunction = extname.startsWith "!"
  if isFreeFunction:
    extname = extname[1..^1]
  else:
    incl(s.flags, sfInfixCall)

and interface of genPatternCall doesn't fit well here

[timotheecour]

Hi @Araq anything else needed here? I rebased to fix conflicts

[timotheecour]

rebased again to fix bitrot conflicts... I'd really like to have this merged

[timotheecour]

ping @xflywind

[ringabout]

looks good

[timotheecour]

PTAL

[timotheecour]

@Araq any other comments or can we merge this?

[Araq]

Sorry for being late but if we really need this, we should have a dedicated importCppProc pragma instead of more magic going on in the import pattern.

[timotheecour]

maybe we need {.pattern: .} instead of this PR, which would be more general (work in c,cpp,js backends), refs nim-lang/RFCs#315 (comment)

eg:

proc freeFn(a: cint) {.pattern: "$call".} # whole call; honors backend mangling (c/c++/js)
proc freeFn2(a, b: cint) {.pattern: "std::bar(@)".} # calls std::bar(a, b)
proc `+`*(a, b: int128): int128 {.pattern: "$1 + $2".} # calls a + b
proc `+!`*(a, b: int128): int128 {.pattern: "$2 + $1".}  # calls b + a
proc freeFn3(a, b: cint) {.pattern: "$0(1, @)".} # calls freeFn3(1, a, b)

[Araq]

Either importCppProc or pattern would be better. Closing for now.