Mwazzat
Lclangsharp 16
Pmf how the hell am I meant to get people to work on 3.0 now
MYOU FIXED IT?
Ksmh not even
unsigned long long int, just unsigned long longLpartially?
Lin a hacked way
Aid love to see a language with a
no int
just
half longno int
just
half longAwhy? because screw you
Pare integer types just no longer integer types for some reason
Por perhaps we’re not stepping all the way through typedefs for some reason?
Lnot sure about the integers yet, im trying to clean up and fix the REALLY cursed code i currently have for the struct typedef issues
Ldont ask how i managed to enter this branch at all
Li dont know either
Lthe sum up what i THINK went on
Lmumble mumble breaking change making us need to move from NamedType -> CanonicalType mumble mumble
ElaboratedType in GetType doesnt handle the canonical type being a pointer mumble mumbleLsomething like that
Lthis is a weird thing to change... but sure i guess thats technically correct?
Lokay 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?
now i just gotta figure out the integers?
Lalso ew
Lthis should be fixable though too
Lwip patch
Lthe 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
Lthen i realized that was stupid and just started looking into the actual problem
Li 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
Lfun 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
TCanonical type is the most underlying type after all typedefs, attributes, elaborations, and other C/C++ modifiers have been stripped away
TThis 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
Loh yeah thats what we used to do as well however thats Not Working
Lso im doing a mix of proper recursion and also just straight up canonicaltype
TAs 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
Or you also miss stuff like function pointer calling conventions
TWhy 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
Luhhhh 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
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
Tthis was when moving to Clang 16 from 15?
Leg given
typedef struct shaderc_compiler* shaderc_compiler_t; BuildTools thinks any usages of shaderc_compiler_t are shaderc_compiler_t instead of shaderc_compiler* nowLwhen moving from 15 to 16 yes
Tright, this was also when they changed from
(anonymous enum at to (unnamed enum at, or vice versaTI'd recommend looking at all athe stuff I had to do in https://github.com/dotnet/ClangSharp/pull/456/files#diff-bac9b18ad93dc3cb267b2bd241193960d517fac455eb8b12e8e8e7aa8020108c
TThere was also: https://github.com/dotnet/ClangSharp/pull/438/files, where I improved type checking in general
TTall were iterative towards making v16 happy, which wasn't fun 
Thttps://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
but might be something else worth looking at in that list too
C@SilkX Team Aside from the math, what do we have left to do for SilkX to be ready for review?
Kgenerator
Mthe rest of the fucking owl
Ptbh, not a lot, we can go with just what we have now but I’d worry that it’d essentially be the same as the last coffee and code where we discussed it
Pthe proposal needs updating based on what we’ve decided
PI feel like the most ideal scenario would be getting a GL triangle working
CSo minimum:
- update proposal docs to match implementation
preferably:
- get OpenGL generated w/ example (hello triangle)
- Math library
I know there are a few cleanup tasks as well:
- add native versions of the functions
- fix the response file handling (searching and better logging when not found)
- update proposal docs to match implementation
preferably:
- get OpenGL generated w/ example (hello triangle)
- Math library
I know there are a few cleanup tasks as well:
- add native versions of the functions
- fix the response file handling (searching and better logging when not found)
Mi start work on monday so i hope you guys can do the other half of the maths library