Skip to content

Conversation

@jokade
Copy link
Contributor

@jokade jokade commented Jun 22, 2019

Description:
This PR provides a new annotation InlineSource(language: String, source: String) which allows to embed source snippets into the NIR generated for a class or object, e.g.

@InlineSource("C","int foo(int i) { /* ... */ }")
@extern
object Foo {
  def foo(i: Int): Int = extern
}

These source snippets can then be processed with sbt plugins by registering an InlineSourceHook to the task key nativeInlineSourceHooks.

Use Cases:

  • embed small external helper functions
  • on-the-fly generation of wrapper code (e.g. for C++ libraries) with macros (i.e. the macro generates the InlineSource snippet that contains the C wrapper around some C++ type).

Changes:

  • add new annotation InlineSource(source,language)
  • add new NIR tag InlineSrcAttr
  • handle tag in BinarySerializer/BinaryDeserializer
  • collect all InlineSource attrs during linking
  • add Config.inlineSourceHooks; registered hooks are called with the list of InlineSource attrs after optimization is completed => only InlineSource fragments that are attached to classes/objects which are actually linked into the binary will be passed to the hooks
  • provide sbt settingKey nativeInlineSourceHooks to register hooks that should be called after optimization is completed

@ekrich
Copy link
Member

ekrich commented Jun 22, 2019

Related: #657

@coreyoconnor
Copy link
Contributor

This reminds me of "inline-c" for GHC haskell. Which has definitely been proved to be useful.

The name "ExternalSource" sounds odd to me. The @extern makes sense as short for "has an external implementation". However ExternalSource doesn't really follow the same conceptual expansion IMO

How about mirroring haskell and using "InlineSource"?

@coreyoconnor
Copy link
Contributor

@jokade
Copy link
Contributor Author

jokade commented Jul 8, 2019

@coreyoconnor good point, I didn't put too much thought into it. I'll go with your proposal.

@jokade jokade changed the title [WIP] Support embedding of external source strings in NIR [WIP] Support embedding of inline source strings in NIR Jul 8, 2019
- add new annotation InlineSource(source,language)

- add new NIR tag InlineSource

- handle tag in BinarySerializer/BinaryDeserializer

- collect all InlineSource attrs during linking

- add Config.inlineSourceHooks;
  registered hooks are called with the list of InlineSource attrs after
  optimization is completed

- provide sbt settingKey nativeInlineSourcesHooks to register
  hooks that should be called after optimization is completed
@jokade jokade force-pushed the embed-external-source branch from 6b94630 to 588c924 Compare September 17, 2020 10:50
@lolgab
Copy link
Contributor

lolgab commented Jan 2, 2025

Do we need this at this point?
It has not been touched for 5 years and Scala Native is moving away from C and C++ code more and more.

@keynmol
Copy link
Contributor

keynmol commented Jan 2, 2025

Honestly I feel like this would be a good idea if the annotations were on functions – for cases where there is naked struct passing the forwarders are very mechanical and I wish they just lived in the Scala source as well, instead of having to ship a C file: https://gist.github.com/keynmol/642af3a015d3aa05cefdadfb8635f5d3#file-clay-glue-c-L9-L12

@lolgab
Copy link
Contributor

lolgab commented Jan 2, 2025

sn-bindgen would still need to generate c source code, just in a different place, without autocomplete, source highlighting, etc.
I don't see much value in this feature but I'm happy to be proved wrong.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants