You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
All public constructors (Module, Builder) will take Context as their first argument(Java api needs a name for module as well so I'll modify our constructor to take an optional name parameter)
Other constructors such as those for functions will get the context from the parent (module in the case of function)
I am assuming when it comes for types we can ignore the context even though we use it in other places (ex for i64 use LLVMInt64Type instead of LLVMInt64TypeInContext in the C api. If not constant constructors (ex:intConst) will also need Context as an argument. (In otherplaces we should be able to get the context from parent (In most cases builder)).
The text was updated successfully, but these errors were encountered:
@jclark for this I am thinking of adding fallowing to the public API
Context
to represent LLVMContextRef. Initially this can be an empty place holder since we only need this to have API similar to what we get with Implement API of nback.llvm using LLVM C API via JNI #19.createContext() returns Context
similar to https://llvm.org/doxygen/group__LLVMCCoreContext.html#gaac4f39a2d0b9735e64ac7681ab543b4c.Module
,Builder
) will takeContext
as their first argument(Java api needs a name for module as well so I'll modify our constructor to take an optional name parameter)I am assuming when it comes for types we can ignore the context even though we use it in other places (ex for
i64
useLLVMInt64Type
instead ofLLVMInt64TypeInContext
in the C api. If not constant constructors (ex:intConst
) will also needContext
as an argument. (In otherplaces we should be able to get the context from parent (In most cases builder)).The text was updated successfully, but these errors were encountered: