Fixes for name mangling/demangling

The source of a lot of these changes is that our current strategy for dealing with "builtin" operations when emitting HLSL from the IR is to de-mangle the mangled name of an operation, and then emit HLSL code for a function call to an operation with that de-mangled name.

This change introduces a few fixups for that work:

- It adds support for parsing the mangled names of generics (specialized and unspecialized)

- It adds logic for detecting when the operation being invoked is a member function
  - This is currently a bit ugly, since we compare the number of actual arguments we have in the IR against the number of parameters declared for the callee, and if they don't match we assume we have an extra `this` argument.

On the mangling side, we add (hacky) support for mangling a function name when its types involve generic parameters, e.g.:

```
__generic<T, let N : int> T length(vector<T,N> v);
```

In this case the mangled name of the function needs to include a mangling for the type `vector<T,N>` which means it also needs to include a mangling for `N`.

The reason I describe this support as "hacky" is because we really shouldn't be reproducing the names `T` or `N` in the mangled symbol name. By doing so we make it so that a user changing the name of a generic parameter would break (IR) binary compatibility with existing code that was separately compiled.
I've included comments in the code about a better way to handle this, but it isn't a priorit right now since binary compatibility isn't something meaningful until we start emitting usable bytecode modules.

1 files changed, 12 insertions, 0 deletions

diff --git a/source/slang/mangle.cpp b/source/slang/mangle.cpp
index b9fba6380..dca48f671 100644
--- a/source/slang/mangle.cpp
+++ b/source/slang/mangle.cpp
@@ -152,6 +152,18 @@ namespace Slang
             // value, so we certainly don't want to include
             // it in the mangling.
         }
+        else if( auto genericParamIntVal = dynamic_cast<GenericParamIntVal*>(val) )
+        {
+            // TODO: we shouldn't be including the names of generic parameters
+            // anywhere in mangled names, since changing parameter names
+            // shouldn't break binary compatibility.
+            //
+            // The right solution in the long term is for generic parameters
+            // (both types and values) to be mangled in terms of their
+            // "depth" (how many outer generics) and "index" (which
+            // parameter are they at the specified depth).
+            emitName(context, genericParamIntVal->declRef.GetName());
+        }
         else
         {
             SLANG_UNEXPECTED("unimplemented case in mangling");