Toh, @Perksey, since you're using TerraFX's rsp
I should probably warn you that I'm taking a breaking change for .NET 8
I should probably warn you that I'm taking a breaking change for .NET 8
Lyeah, rider also gives full completions for things like generated files, iirc vscode c# doesnt yet
Pno worries, what is it out of curiosity?
Tnamely switching to use
(save a bit of metadata bloat)
finally switching to use
and switching
[InlineArray] and explicitly dropping the AsSpan() and indexer methods, since those are no longer necessary(save a bit of metadata bloat)
finally switching to use
CallConvMemberFunction, so I don't need to maintain manual fixups for COM methodsand switching
[DisableRuntimeMarshalling] on, which means boolchar get generated by default (rather than byte and ushort)Tnothing huge, but minor convenience things for the new LTS and since it makes some things that much nicer
P1. fine
2. fine
3. huh?
2. fine
3. huh?
Tboolchar aren't blittable, which is why TerraFX had been using byte and ushort up until now[assembly: DisableRuntimeMarshalling] makes blittable == unmanaged and actively prevents the ability to use any marshalling (including varargs)Tso by switching that on,
boolchar become blittable and can be safely usedPwow that is not what i would expect that to do haha
Pbut that's cool i guess, i think we're ready for those changes as is
Tthe options were to either block
and making it 1-to-1 ends up being better long term
boolchar entirely, or simply make it 1-to-1and making it 1-to-1 ends up being better long term
Tthat also means
SetLastError doesn't work, but TerraFX was already setup for thatLgod i wish we had full tracy integration or SOMETHING for BuildTools so i could actually trace code flow without throwing exceptions when something im interested in happens to see the stack trace
Por alternatively we could just rewrite it so that we have an actually sane generator codebase
Lthats another option: however then i dont get to spend an hour re-learning the codebase every time i need to touch it
Li have now managed to attach a debugger to buildtools
Lwow this is 100% easier to reason about than throw new Exception() and Console.WriteLine everywhere
Kcongrats!
LSO CLOSE
but the typemapper is still borked for some reason
but the typemapper is still borked for some reason
K
Lokay so im STARTING to boil this down
Lfor some reason clang.cs doesnt think
shaderc_compiler * is a pointerLand im not sure why yet
Loh hey look
Lit works
Lsometimes
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