Remove submodules. Paperwork

Loader.cpp

@@ -9,8 +9,12 @@
 #endif
 using namespace std;
 Pass* (*old_get_LS)();
-extern "C" void _ZN4llvm10ModulePassD2Ev(){
-
+extern "C" void _ZN4llvm10ModulePassD2Ev(void* curr){
+  //Definitely not the current implementation
+  //Meh
+  if(curr!=null){
+    delete curr;
+  }
 }
 void llvm::Value::assertModuleIsMaterializedImpl()const{
 

README.md

@@ -19,7 +19,7 @@ Due to its hackish nature (Which is why I don't want to do this in the first pla
 - ``${LLVM_BUILD_PATH}`` The path you prepare to build in. Note that you need a seperate folder and must not reuse existing build for upstream Hikari
 
 ## Obtaining Source
-- ``git clone --recursive https://github.com/HikariObfuscator/Hanabi.git $(LLVM_SOURCE_PATH)/projects/``
+- ``git clone https://github.com/HikariObfuscator/Hanabi.git $(LLVM_SOURCE_PATH)/projects/``
 
 ## Build
 - ``cmake $(LLVM_SOURCE_PATH) -DCMAKE_BUILD_TYPE=Release -DLLVM_ABI_BREAKING_CHECKS=FORCE_OFF -G Ninja``
@@ -60,10 +60,6 @@ Or alternatively, manually edit [LoadEnv() in Obfuscation.cpp](https://github.co
 # Known Issues
 - LLVM 6.0.1 (which Apple's Clang and this project is currently based on) has bugs related to ``indirectbr`` CodeGeneration, you might get a crash if you enable ``INDIBRAN``. Another more robust solution would be hook those parts and pipe the CodeGeneration pipeline back to LLVM7.0 but I couldn't be less bothered for that
 
-
-# Future enhancements
-- Hijacking PMB is IMHO a little bit too late into the compilation pipeline. A better approach would be hijacking Clang's raw AST, reuse our own shipped Clang CG, run through the rest of our own optimization pipeline then transfer the processed LLVM IR back to Apple LLVM? Maybe? We need more research into Apple's LLVM for this
-
 # Credits
 
 - Thanks to [@AloneMonkey](https://github.com/AloneMonkey) for compiling substitute and ship it with his amazing project [MonkeyDev](https://github.com/AloneMonkey/MonkeyDev/blob/master/MFrameworks/libsubstitute.dylib)