exportc now mangles same as importc, fixes #10578

[timotheecour]

• fix exportc mangles as C++ and doesn't work with importc(C) with nim cpp  #10578
• see added tests

[EDIT] note

• multiple {.emit: "NIM_EXTERNC".} is harmless so it's ok to have:

{.emit: "NIM_EXTERNC".}  # this can be omitted after this PR but does not cause harm after this PR
proc fun() {.exportc.} = discard

[Araq]

This is a breaking change. It needs a changelog entry and it requires us to introduce externCpp to compensate for the loss of functionality.

[timotheecour]

This is a breaking change. It needs a changelog entry and it requires us to introduce externCpp to compensate for the loss of functionality.

done.

• I'm assuming you meant exportcpp, not externCpp (since we have wExportNims, wExportc already), I've added {.exportcpp.}

• I refactored a bit the pragma sets in pragmas.nim to reuse a common declPragmas which makes it easier to spot the common part vs different parts; To avoid changing semantics (except for the added wExportcpp), I had to exclude some elements from lambdaPragmas and fieldPragmas, not clear to me whether these missing pragmas were omissions or intended, please double check

• Instead of adding sfExportCpp and patching in many places, it was much simpler to add a sfMangleCpp that can combine with sfExportC; sfMangleCpp is then used in a single place

• importcpp never worked for nim cpp (at least for free functions) and this PR doesn't try to fix it; making it work is left for future PR's; so I used instead this in the test:
  proc funx1() {.importc: "_Z5funx1v".}

• [EDIT] exportcpp produces an error with nim c;

note

see timotheecour@fd86320 for an alternative to producing an error:
I had tried something different but it didn't work and would've required a bigger change, which can be done in future PR since it's a new (and more niche) use case anyway : instead of localError, trigger optMixedMode as follows:

  if c.config.cmd == cmdCompileToC:
    let m = s.getModule()
    incl(m.flags, sfCompileToCpp)
  incl c.config.globalOptions, optMixedMode

and adjust requiresExternC; however this didn't work, and (to my surprise) depends on ordering of declarations, eg:

proc fun1() {.exportc.} = discard # in cgen, will be processed as if sfCompileToCpp notin m
proc funx1() {.exportcpp.} = discard # triggers sfCompileToCpp in m
proc fun1() {.exportc.} = discard # in cgen, will be processed with sfCompileToCpp in m

not sure why cgen doesn't come after semantic is completed, but that can be investigated later to enable that niche use case

[Araq]

Thank you!

[kaushalmodi]

This is awesome! Does it mean that I do not need to scatter my Nim wrappers with this?

const
  externCDecl* = when defined(cpp):
                   """extern "C" $1 $2 $3"""
                 else:
                   """$1 $2 $3"""

# ..

proc foo() {.exportc, codegenDecl: externCDecl.} =
  # ..

i.e. Below will now result in unmangled proc symbols whether I do nim c or nim cpp?

proc foo() {.exportc.} =
  # ..

[timotheecour]

indeed (let me know if that's not the case somehow), except if you need to support nim versions prior to this PR