Hi, I'm having some issues with AngelScript 2.33.0, running on Windows 10 and being compiled in Visual Studio 2019.

I have a heavily data oriented game using a data oriented entity component system in C++.
I have implemented AngelScript in a way so you can hook certain events, get a "fake" object oriented representation of an "object" which has functions you can use which modifies my Struct of Arrays data for that object.

I register "dummy" classes to do the object oriented abstraction, they look a bit like this.
AngelScriptMap: https://pastebin.com/BVQzT6gt

I also register some global functions like this, this gets run after RegisterMapFunctions.
GlobalFunctions: https://pastebin.com/gNyA3GwK 

And finally I have my very simple script which looks like this: https://pastebin.com/dnJSFbUb

When running this script, it crashes when returning the map object on line 17 of GlobalFunctions. It crashes with this message:
Exception thrown at 0x00007FF7C29CDEA3 in worldnode.exe: 0xC0000005: Access violation writing location 0x0000000000000002.

When I inspect the id being passed into the GetMapFromId function, instead of 2 (like I hard coded) it appears to be 3435973836, or represented in hex: CCCCCCCC
I _believe_ that the issue is that the .asm file that implements CallX64 doesn't initialize something (stack?), but I know basicly no assembly and I can't figure out why this would happen.
I was hoping that someone in here could explain this issue and how I can work around it.

Here's a screenshot of my callstack in case it helps: 

From the values you see it is clear that the function GetMapFromId() is expected to receive a hidden pointer to the memory location where the AngelScriptMap should be returned. For some reason AngelScript doesn't identify this need to pass the hidden pointer to the function, and instead expects the AngelScriptMap to be returned in a CPU register as a primitive. 

I don't see any error in the way you've registered the AngelScriptMap type or the GetMapFromId function just by reviewing the code. I'll need to debug the code in order to figure out what is going on.

It will probably take a while before I can get a chance to look into this.

In the meantime I think you'll be able o work around the problem by implementing the default constructor and copy constructor for the C++ AngelScriptMap type. That should be enough to allow AngelScript to detect that the type needs to be returned in memory rather than as in the CPU register.

Just implementing the default  constructor seems to be a workaround, thank you very much!

A bit off topic, but do you have any plans for official support for AngelScript using the LLVM toolchain from Visual Studio?
https://marketplace.visualstudio.com/items?itemName=LLVMExtensions.llvm-toolchain

I'm currently using that but I had to make some (probably) hackfixes to get AngelScript to compile due to previously unexpected macro combinations.
I also had to change as_callfunc_x64_msvc.cpp to this at the top since Clang has an inline assembler: https://pastebin.com/qp2tmkz4

The assembly there is just taken from as_callfunc_x64_mingw.cpp, and this seems to Just Work(tm), at least so far.

Oh, and don't worry, one of the first things I did was try the bug reported above on unchanged AngelScript running MSVC to make sure I didn't break it.

I hadn't planned for it, since I wasn't really aware of the LLVM toolchain for VS

If you can help me point out the differences I can add the appropriate config in as_config.h to detect the LLVM toolchain with MSVC and make it compile out-of-the-box.

Sure, but probably not until tomorrow. I don't remember exactly what I did but I could easily diff the files.

Do you want the changes listed here, in a PM or maybe in a more chat-like manner for any followup questions?

You can post it here or send me an e-mail at andreas@angelcode.com. Whichever you prefer.

Actually, I just ran a diff of the whole directory and there doesn't seem to be any other changes remaining except for the inline assembly in as_callfunc_x64_msvc.cpp.

I did have more changes before, but if I remember correctly it was to try to get the MSVC-LLVM toolchain to pick as_callfunc_x64_mingw.cpp instead. This seemed to work at first, until I started using some more advanced features of AngelScript and it all broke down. This led me to try the other approach of modifying as_callfunc_x64_msvc.cpp which turned out to work way better.

So https://pastebin.com/qp2tmkz4 should be all you need!

I would also like to thank you for your work on AngelScript, I am extremely happy to have found a good scripting solution other than Lua or Python, with an arguably way better syntax! As an extra bonus you have support for disabling globals which lets me create a completely pure scripting API based on callbacks, which I'm going to use to let my callbacks run in parallel with one (or more) as_context per thread.

Thanks for the patch. I'll review it and have it included for the next release.