`typeid` used to be a fancy index with extra metadata stored on it. Now it is direct hash of the type.
This is safe to do in practice since any possible collisions are checked at compile time AND the chances of having a 1% collision are around 1 in 600K (see the Birthday Paradox).
Therefore accessing a `^Type_Info` is now a hash table lookup with linear probing. The table is twice the size than necessary so prevent too much probing due to an overly dense hash table.
Fixes#4798
The DLL was using the type info of the host/exe, causing crashes.
This PR tries fixing by applying hidden visibility to these corrected
symbols which makes sure that the DLL can't see the type table of the host/exe.
This fixes (on my end) #3340, #3117, #2945, #2922, and #2762
A general refactor of debug info generation in order to fix issues and
increase stability.
What I believe is the root cause of a bunch of issues is that we use the
temporary metadata/forward declarations too much (/ hold onto them for
too long). It seems to cause problems with the reference counting inside
LLVM.
This PR reduces the use of these forward declarations to a minimum, it
creates it, fills in the fields, and resolves it, instead of waiting
until the end of generating code.
Some smaller issues I came across have also been solved.
`llvm_features` being empty is the default state, and implies the
presence of certain features.
Previously if any target features were explicitly enabled by the
`enable_target_feature` attribute, they were added comma separated
to `llvm_features`.
For example: `lzcnt,popcnt,...,sse4.2,sse`
This was causing LLVM to try to target a CPU that *ONLY* has the
explicitly enabled features. This now will prefix explicitly enabled
features with a `+`, and preserve the existing `llvm_features` string
by appending to it if it is set.
gingerBill
Laytan Laats
gingerBill
Jeroen van Rijn
avanspector
avanspector
codename-irvin
Yawning Angel