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 ?

[save-buffer]

Are there plans to update this repo ?

No, probably not.

[anutosh491]

Hey @save-buffer,

No issues. I implemented a swift-repl based on the ORC JIT & I'm now collaborating with some swift maintainers for having a Jupyter Kernel for the same. Here's a demo

Screen.Recording.2026-03-23.at.5.23.17.PM.mp4

All of this work is now private (cause we're still building) but is expected to land upstream in the near future.

Thanks for the work on this repo cause it did help me with some inspiration.