Major cleanup. Remove compile, compile_wasm, and MixTape (#146)

* Remove `compile`, do some cleanup

* update README

* note about `compile_shlib`

* note about compile_shlib

* remove compile_wasm and MixTape; allow specifying a method_table

* Forgot v1.8 doesn't have package extensions

* oops

* don't export `compile_wasm`

.github/workflows/ci-integration.yml

@@ -20,6 +20,7 @@ jobs:
         version:
           - '1.8'
           - '1.9'
+          - '1.10.0-rc1'
         os:
           - ubuntu-latest
           - macOS-latest

.github/workflows/ci.yml

@@ -20,6 +20,7 @@ jobs:
         version:
           - '1.8'
           - '1.9'
+          - '1.10.0-rc1'
         os:
           - ubuntu-latest
           - macOS-latest

Project.toml

@@ -1,7 +1,7 @@
 name = "StaticCompiler"
 uuid = "81625895-6c0f-48fc-b932-11a18313743c"
 authors = ["Tom Short and contributors"]
-version = "0.5.3"
+version = "0.6"
 
 [deps]
 Clang_jll = "0ee61d77-7f21-5576-8119-9fcc46b10100"
@@ -17,7 +17,7 @@ StaticTools = "86c06d3c-3f03-46de-9781-57580aa96d0a"
 
 [compat]
 CodeInfoTools = "0.3"
-GPUCompiler = "0.21"
+GPUCompiler = "0.21, 0.22, 0.23, 0.24"
 LLVM = "6"
 MacroTools = "0.5"
 StaticTools = "0.8"

README.md

@@ -15,39 +15,8 @@ using Pkg
 Pkg.add("StaticCompiler")
 ```
 
-There are two main ways to use this package:
-
-### Linked compilation
-The first option is via the `compile` function, which can be used when you want to compile a Julia function for later use from within Julia:
-```julia
-julia> using StaticCompiler
-
-julia> fib(n) = n <= 1 ? n : fib(n - 1) + fib(n - 2)
-fib (generic function with 1 method)
-
-julia> fib_compiled, path = compile(fib, Tuple{Int}, "fib")
-(f = fib(::Int64) :: Int64, path = "fib")
-
-julia> fib_compiled(10)
-55
-```
-Now we can quit this session and load a new one where `fib` is not defined:
-```julia
-julia> using StaticCompiler
-
-julia> fib
-ERROR: UndefVarError: fib not defined
-
-julia> fib_compiled = load_function("fib")
-fib(::Int64) :: Int64
-
-julia> fib_compiled(10)
-55
-```
-See the file `tests/runtests.jl` for some examples of functions that work with `compile` (and some that don't, marked with `@test_skip`).
-
 ### Standalone compilation
-The second way to use this package is via the `compile_executable` and `compile_shlib` functions, for when you want to compile a Julia function to a native executable or shared library for use from outside of Julia:
+StaticCompiler.jl provides the functions `compile_executable` and `compile_shlib` for compiling a Julia function to a native executable or shared library for use from outside of Julia:
 ```julia
 julia> using StaticCompiler, StaticTools
 
@@ -63,25 +32,49 @@ shell> ls -alh hello
 shell> ./hello
 Hello, world!
 ```
-This latter approach comes with substantially more limitations, as you cannot rely on `libjulia` (see, e.g., [StaticTools.jl](https://github.com/brenhinkeller/StaticTools.jl) for some ways to work around these limitations).
+This approach comes with substantial limitations compared to regular julia code, as you cannot rely on julia's runtime, `libjulia` (see, e.g., [StaticTools.jl](https://github.com/brenhinkeller/StaticTools.jl) for some ways to work around these limitations).
+
+The low-level function `StaticCompiler.generate_obj` (not exported) generates object files. This can be used for more control of compilation. This can be used for example, to cross-compile to other targets.
+
+### Method overlays
 
-The low-level function `StaticCompiler.generate_obj` (not exported) generates object files. This can be used for more control of compilation. This can be used to cross-compile to other targets.
+Sometimes, a julia function you want to statically compile will do things (such as throwing errors) that aren't supported natively by StaticCompiler. One tool provided for working around this is the `@device_override` macro which lets you swap out a method, but only inside of a StaticCompiler.jl compilation context. For example:
 
-### Mixtape
+```julia
+julia> using Libdl, StaticCompiler
+
+julia> f(x) = g(x) + 1;
+
+julia> g(x) = 2x
+
+julia> @device_override g(x::Int) = x - 10
 
-This feature allows one to change functionality when statically compiling. This uses code and API from [Mixtape](https://github.com/JuliaCompilerPlugins/Mixtape.jl) to transform lowered code much like [Cassette](https://github.com/JuliaLabs/Cassette.jl).
+julia> f(1) # Gives the expected answer in regular julia
+3
+
+julia> dlopen(compile_shlib(f, (Int,), "./")) do lib
+           fptr = dlsym(lib, "f")
+           # Now use the compiled version where + is replaced with -
+           @ccall $fptr(1::Int)::Int 
+       end
+-8
+```
+Typically, errors should be overrided and replaced with `@print_and_throw`, which is StaticCompiler friendly, i.e.
+we define overrides such as
+``` julia
+@device_override @noinline Base.Math.throw_complex_domainerror(f::Symbol, x) =
+    @print_and_throw c"This operation requires a complex input to return a complex result"
+```
 
-To use the Mixtape feature, define a `CompilationContext` struct and pass this to any of the compilation functions with the `mixtape` keyword. Define `transform` and `allow` functions for this `CompilationContext` to define the transformation to be done.
+If for some reason, you wish to use a different method table (defined with `Base.Experimental.@MethodTable` and `Base.Experimental.@overlay`) than the default one provided by StaticCompiler.jl, you can provide it to `compile_executable` and `compile_shlib` via a keyword argument `method_table`.
 
-See [here](https://github.com/tshort/StaticCompiler.jl/blob/master/test/testintegration.jl#L329) for an example.
 
 ## Approach
 
 This package uses the [GPUCompiler package](https://github.com/JuliaGPU/GPUCompiler.jl) to generate code.
 
 ## Limitations
 
-* GC-tracked allocations and global variables do work with `compile`, but the way they are implemented is brittle and can be dangerous. Allocate with care.
 * GC-tracked allocations and global variables do *not* work with `compile_executable` or `compile_shlib`. This has some interesting consequences, including that all functions _within_ the function you want to compile must either be inlined or return only native types (otherwise Julia would have to allocate a place to put the results, which will fail).
 * Since error handling relies on libjulia, you can only throw errors from standalone-compiled (`compile_executable` / `compile_shlib`) code if an explicit overload has been defined for that particular error with `@device_override` (see [quirks.jl](src/quirks.jl)).
 * Type instability. Type unstable code cannot currently be statically compiled via this package.
@@ -97,29 +90,24 @@ To enable code to be statically compiled, consider the following:
 
 * Avoid Julia's internal allocations. That means don't bake in use of Arrays or Strings or Dicts. Types from StaticTools can help, like StaticStrings and MallocArrays.
 
-* If need be, manage memory manually, using `malloc` and `free`. This works with StaticTools.MallocString and StaticTools.MallocArray.
+* If need be, manage memory manually, using `malloc` and `free` from StaticTools.jl. This works with `StaticTools.MallocString` and `StaticTools.MallocArray`, or use [Bumper.jl](https://github.com/MasonProtter/Bumper.jl). 
 
 * Don't use global variables that need to be allocated and initialized. Instead of global variables, use context structures that have an initialization function. It is okay to use global Tuples or NamedTuples as the use of these should be baked into compiled code.
 
 * Use context variables to store program state, inputs, and outputs. Parameterize these typese as needed, so your code can handle normal types (Arrays) and static-friendly types (StaticArrays, MallocArrays, or StrideArrays). The SciML ecosystem does this well ([example](https://github.com/SciML/OrdinaryDiffEq.jl/blob/e7f045950615352ddfcb126d13d92afd2bad05e4/src/integrators/type.jl#L82)). Use of these context variables also enables allocations and initialization to be centralized, so these could be managed by the calling routines in Julia, Python, JavaScript, or other language.
 
-* If your code needs an array as a workspace, instead of directly creating it, create it as a function argument (where it could default to a standard array creation). That code could be statically compiled if that function argument is changed to a MallocArray or another static-friendly alternative. 
+* Arguments and returned values from `compile_shlib` must be native objects such as `Int`, `Float64`, or `Ptr`. They cannot be things like `Tuple{Int, Int}` because that is not natively sized. Such objects need to be passed by reference instead of by value.
 
-* Use [Bumper.jl](https://github.com/MasonProtter/Bumper.jl) to avoid allocations in some loops.
+* If your code needs an array as a workspace, instead of directly creating it, create it as a function argument (where it could default to a standard array creation). That code could be statically compiled if that function argument is changed to a MallocArray or another static-friendly alternative. 
 
 ## Guide for Statically Compiling Code
 
-If you're trying to statically compile generic code, you may run into issues if that code uses features not supported by StaticCompiler. One option is to change the code you're calling using the tips above. If that is not easy, you may by able to compile it anyway. One option is to use method overrides to change what methods are called. Another option is to use the Mixtape feature to change problematic code as part of compilation. For example, you could convert all Strings to StaticStrings.
+If you're trying to statically compile generic code, you may run into issues if that code uses features not supported by StaticCompiler. One option is to change the code you're calling using the tips above. If that is not easy, you may by able to compile it anyway. One option is to use method overlays to change what methods are called.
 
 [Cthulhu](https://github.com/JuliaDebug/Cthulhu.jl) is a great help in digging into code, finding type instabilities, and finding other sources of code that may break static compilation.
 
 ## Foreign Function Interfacing
 
 Because Julia objects follow C memory layouts, compiled libraries should be usable from most languages that can interface with C. For example, results should be usable with Python's [CFFI](https://cffi.readthedocs.io/en/latest/) package.
 
-For WebAssembly, interface helpers are available at [WebAssemblyInterfaces](https://github.com/tshort/WebAssemblyInterfaces.jl).
-
-
-
-
-
+For WebAssembly, interface helpers are available at [WebAssemblyInterfaces](https://github.com/tshort/WebAssemblyInterfaces.jl), and users should also see [WebAssemblyCompiler](https://github.com/tshort/WebAssemblyCompiler.jl) for a package more focused on compilation of WebAssebly in general.