Any plans to update to latest swift/ swift 6 ?

[anutosh491]

I see the last commit was made around 7 years back.

Are there plans to update this repo ?

cc @bulbazord @save-buffer @gmittert

[anutosh491]

I can see that this is not a standard REPL but my usecase for starters is to hook the ExecuteSwift function to a Jupyter kernel.

swift-repl/REPL.cpp

Line 160 in 7e0d852

bool REPL::ExecuteSwift(std::string line)

I work on and maintain some Jupyter based projects and I am trying to have a swift Jupyter kernel for which I would like to put an orc jit based repl to use. We do the same for the C/C++ Jupyter Kernel where we put clang-repl from LLVM to use.

Tagging @compnerd too who I see has approved PRs here and has worked on swift in Jupyter if I remember correctly.

[compnerd]

I don't think that it would be easy to port this to Swift 6 at this point, it hasn't been updated in a long time. I think that the best thing to do is to investigate the more recent work that I did for a VSCode based Jupyter notebook solution.

[anutosh491]

I'll probably look into updating this then. I'm looking for a JIT based repl as I said and your solution isn't based on that iirc

[anutosh491]

Hey @compnerd,

I have some doubts as to why some things were done here. Would you help me address them ?

So what I see being done here is

• Each input line is parsed into a fresh SourceFile created as swift::SourceFileKind::Main in REPL::ExecuteSwift, so Swift allows top-level statements/expressions to exist as TopLevelCodeDecl.
• ExecuteSwift then call REPL::ModifyAST (see REPL::ModifyAST + WrapInFunction in TransformAST.cpp) to wrap the top-level code into a uniquely named function __repl_N (their module/buffer name), so execution is driven by calling that wrapper.
• But this would still end up with a synthesized main from Swift’s “main file” lowering, but I see exporting it is avoided: ConfigureFunctionLinkage sets sil_module->lookUpFunction("main")->setLinkage(swift::SILLinkage::Private).
• So main is never run : after JITing, lookup the mangled symbol for the wrapper (ASTMangler::mangleEntity(res_fn, false) where res_fn is the wrapper) and invoke it directly.
• Redeclarations are handled on the JIT side by scanning externally-linked LLVM functions and calling m_jit->RemoveSymbol(name) in REPL::RemoveRedeclarationsFromJIT (note main is typically skipped because it’s not externally linked after the SIL linkage tweak).

Not sure why y'all went for the above design, cause this is what I ideated on

What I’m trying to do (library mode + wrapper + JIT)

• Keep module-per-input (e.g. -module-name __repl_1, __repl_2, …) but compile each input as library (-parse-as-library / SourceFileKind::Library equivalent intent) so the compiler never synthesizes main.
• Because library mode rejects top-level expressions (print("hello")), we still introduce a wrapper public func __repl_N() and move top-level statements into that function body (AST transform or equivalent frontend handling).
• Top-level declarations like public let x = 5 remain as declarations; only top-level statements/expressions need wrapping to become valid in library mode.
• Then we JIT each compiled module into the same ORC session/JITDylib and lookup/call the wrapper symbol (mangled) per cell, clang-repl style.

Conclusion: this avoids needing to generate/hide/remove main entirely, and feels less hacky than “emit main then make it private”, while preserving “call a per-cell entrypoint” semantics.

What do you think ? Do you spot any obvious flaws in the approach i proposed ?
Does starting with a library file kind do better justice/ is a better approach for replicating a REPL like design ?