Re-enable checks for final access.#415
Conversation
4a16687 to
ba2cdee
Compare
|
Oh yeah if you're wondering why it's a draft right now it's because it doesn't fucking work |
It works now! I mainly wrote this to help clean up FunkinCrew/Funkin#7238, so we can rewrite the variables to recycle them without the scripts being able to edit them from the outside. Definitely should get some review from contributors but this should prevent people from accidentally messing with constants when they aren't supposed to. An aside, this should be good to merge as-is, but in a future PR it might be nice to add functional metadata that, when applied to a class/method/block, skips this check (in a similar manner to |
|
On the topic of contributors reviewing, I've noticed the GCC C++ compiler would baloon in memory usage then die with this PR due to the generated meta code being too massive (and this, infact, would not be the first time this happens with this sort of macro), which prevented me from testing the code on Linux. We likely need to rework the macro to use a Resource, akin to what #366 and some other PRs before it did. |
I had the same issue, which is why it already uses a Resource (that probably changed between when you reviewed it and when I marked the PR as not draft). Please review it again if you can. |
|
Oh, I can't believe I've missed that lol. I can confirm it compiles with no issues on my end now (besides me having to locally fix all the null-safety errors that came with the nullable The only thing I found odd was that the changes from #416 were kind of reverted, was that intentional? |
…nly lets you access them locally!)
23fe9e2 to
1a99d77
Compare


finalvariables in scripts.nullorneversetters (Haxe never allows assignment tonever, and only allows local assignment tonull).finalconstants from Haxe code. This prevents issues like being able to re-assign values despite them being defined as immutable constants.