Add lib functions earlier so that they are visible in top-level macros#12848
Conversation
|
I literally could not be happier about this! |
|
@sol-vin that's great to hear! If you want you can compile a compiler from this branch and try it out. Maybe this works but we'll still be missing things to make this usable. |
|
@asterite My main dev computer is Windows right now, so I use the |
|
Oh, no worries then. Thanks! |
|
Just saying... https://learn.microsoft.com/en-us/windows/wsl/install But yeah, building the compiler on Windows is not exactly a walk in the park. That's mostly due to the lib dependencies (you need LLVM with You can easily wait for this to be merged into master and install the nightly build from scoop. |
straight-shoota
deleted the
feature/allow-listing-lib-functions-at-the-top-level
branch
…15635) `has_method?` in top-level macro expressions was broken before Crystal 1.7.0 (fixed in #12848). On older compiler versions `LibGC.has_method?(:set_stackbottom)` would always return `false` and break assumptions about available lib symbols. This patch simply moves the macro expression into the `def` body. We don't need this on the top level. More details in #15633 (comment)
3 participants
Fixes #12395
CI will fail because of #12840
It turns out this was really easy to do. The previous times I tried it I got failures and I didn't want to spend time debugging it. The failures were because the
Externalwas created withoutargsinitially, and then they were added. I missed that... but once I realized that was the problem fixing it was very easy.Note: lib types won't be solved at the top-level because that happens later on. The reason for that is to not require forward declarations. But I think that even without resolved types this is useful.