Silk.NET•3y ago

SO CLOSE but the typemapper is still borked for some reason

SO CLOSE
but the typemapper is still borked for some reason

khitiara•11/3/23, 11:08 PM

reminds me of my favorite function by far, Debugger.Launch

LLyris the Kitori SO CLOSE but the typemapper is still borked for some reason

Lyris the KitoriOP•11/3/23, 11:26 PM

okay so im STARTING to boil this down

Lyris the KitoriOP•11/3/23, 11:26 PM

for some reason clang.cs doesnt think shaderc_compiler *shaderc_compiler * is a pointer

Lyris the KitoriOP•11/3/23, 11:27 PM

and im not sure why yet

Lyris the KitoriOP•11/3/23, 11:38 PM

oh hey look

Lyris the KitoriOP•11/3/23, 11:38 PM

it works

Lyris the KitoriOP•11/3/23, 11:38 PM

sometimes

Maxine•11/3/23, 11:38 PM

wazzat

Lyris the KitoriOP•11/3/23, 11:38 PM

clangsharp 16

Perksey•11/3/23, 11:38 PM

mf how the hell am I meant to get people to work on 3.0 now

Maxine•11/3/23, 11:38 PM

YOU FIXED IT?

khitiara•11/3/23, 11:38 PM

smh not even unsigned long long intunsigned long long int, just unsigned long longunsigned long long

Lyris the KitoriOP•11/3/23, 11:38 PM

partially?

Lyris the KitoriOP•11/3/23, 11:38 PM

in a hacked way

Aqua•11/3/23, 11:39 PM

id love to see a language with a half longhalf long
no int
just half longhalf long

Aqua•11/3/23, 11:39 PM

why? because screw you

LLyris the Kitori sometimes

Perksey•11/3/23, 11:42 PM

are integer types just no longer integer types for some reason

Perksey•11/3/23, 11:42 PM

or perhaps we’re not stepping all the way through typedefs for some reason?

Lyris the KitoriOP•11/3/23, 11:43 PM

not sure about the integers yet, im trying to clean up and fix the REALLY cursed code i currently have for the struct typedef issues

Lyris the KitoriOP•11/3/23, 11:43 PM

dont ask how i managed to enter this branch at all

Lyris the KitoriOP•11/3/23, 11:43 PM

i dont know either

Lyris the KitoriOP•11/3/23, 11:44 PM

the sum up what i THINK went on

Lyris the KitoriOP•11/3/23, 11:45 PM

mumble mumble breaking change making us need to move from NamedType -> CanonicalType mumble mumble ElaboratedTypeElaboratedType in

GetType

GetType

doesnt handle the canonical type being a pointer mumble mumble

Lyris the KitoriOP•11/3/23, 11:45 PM

something like that

Lyris the KitoriOP•11/3/23, 11:48 PM

this is a weird thing to change... but sure i guess thats technically correct?

Lyris the KitoriOP•11/3/23, 11:49 PM

okay i think i have pointer typedef stuff working now (in shaderc, one of the simplest bindings we have)
now i just gotta figure out the integers?

Lyris the KitoriOP•11/3/23, 11:49 PM

also ew

LLyris the Kitori also ew

Lyris the KitoriOP•11/3/23, 11:49 PM

this should be fixable though too

Lyris the KitoriOP•11/3/23, 11:52 PM

wip patch

hammer-hit-nail-poorly-but-still-hit-nail.patch21.73KB

LLyris the Kitori if all i have is a hammer (old code relying on old clangsharp behaviour) then ev...

Lyris the KitoriOP•11/3/23, 11:53 PM

the reason i said this was that my original plan was to write a script to find all the differences and then generate a MASSIVE typemap file to just typemap away all the shit

Lyris the KitoriOP•11/3/23, 11:54 PM

then i realized that was stupid and just started looking into the actual problem

Lyris the KitoriOP•11/3/23, 11:54 PM

i want you to know that it WOULD have worked i tested my typemap theory and i was able to manually fixup large parts of shaderc

Lyris the KitoriOP•11/3/23, 11:56 PM

fun fact: i have no idea what canonical type vs named type means: but it gets shaderc into a better state changing what i did so therefor im on the right path

LLyris the Kitori fun fact: i have no idea what canonical type vs named type means: but it gets sh...

tannergooding•11/4/23, 12:02 AM

Canonical type is the most underlying type after all typedefs, attributes, elaborations, and other C/C++ modifiers have been stripped away

tannergooding•11/4/23, 12:04 AM

This is where modern ClangSharp often has a self recursive function that steps through each step of the typedef and manually accounts for certain kinds of abstractions(like typedefs) or makes observations based on others (attibutations, etc) and rarely goes straight for canonical

Lyris the KitoriOP•11/4/23, 12:04 AM

oh yeah thats what we used to do as well however thats Not Working

Lyris the KitoriOP•11/4/23, 12:04 AM

so im doing a mix of proper recursion and also just straight up canonicaltype

tannergooding•11/4/23, 12:05 AM

As otherwise you can miss important info, like something being intptr_t or size_t and therefore needing to be nint

Or you also miss stuff like function pointer calling conventions

LLyris the Kitori so im doing a mix of proper recursion and also just straight up canonicaltype

tannergooding•11/4/23, 12:05 AM

Why isn't that working? Are you missing a particular Type kind that needs handling as part of the recursion? Some were introduced in newer Clang due to how the language works

Lyris the KitoriOP•11/4/23, 12:07 AM

uhhhh i dont know honestly i just poked at it until i did what i wanted and when it didnt i just changed something random until it looked more correct
just something in the chain isnt finding the underlying type and so the name of the typedef instead of the underlying type is being used when generating for some reason now

tannergooding•11/4/23, 12:07 AM

this was when moving to Clang 16 from 15?

Lyris the KitoriOP•11/4/23, 12:07 AM

eg given
typedef struct shaderc_compiler* shaderc_compiler_t;typedef struct shaderc_compiler* shaderc_compiler_t; BuildTools thinks any usages of shaderc_compiler_tshaderc_compiler_t are shaderc_compiler_tshaderc_compiler_t instead of shaderc_compiler*shaderc_compiler* now

Lyris the KitoriOP•11/4/23, 12:08 AM

when moving from 15 to 16 yes

tannergooding•11/4/23, 12:09 AM

right, this was also when they changed from (anonymous enum at(anonymous enum at to (unnamed enum at(unnamed enum at, or vice versa

tannergooding•11/4/23, 12:09 AM

I'd recommend looking at all athe stuff I had to do in https://github.com/dotnet/ClangSharp/pull/456/files#diff-bac9b18ad93dc3cb267b2bd241193960d517fac455eb8b12e8e8e7aa8020108c

tannergooding•11/4/23, 12:11 AM

There was also: https://github.com/dotnet/ClangSharp/pull/438/files, where I improved type checking in general

tannergooding•11/4/23, 12:11 AM

and https://github.com/dotnet/ClangSharp/pull/437, which had some small fixes to type lookup

tannergooding•11/4/23, 12:11 AM

all were iterative towards making v16 happy, which wasn't fun

tannergooding•11/4/23, 12:12 AM

https://github.com/dotnet/ClangSharp/releases/tag/v16.0.0 has the full diff, most are irrelevant towards type lookup
but might be something else worth looking at in that list too

Curin•11/4/23, 7:36 PM

@SilkX Team Aside from the math, what do we have left to do for SilkX to be ready for review?

SO CLOSE but the typemapper is still borked for some reason

Similar Threads

Similar Threads

Similar Threads