Big update to prettier-extension-monkeyc

1. Where do you get an error, if all the relevant places are either Number or Array<Number>?

2. One obvious, but resource wasting solution is to return arrays with 1 element in release

3. I know how to create a stripped down version, the problem is that because of the many inline functions inside inline functions it is very unstable. The slightest change (even of seemingly unrelated code) changes it enough that the bug doesn't happen. That's why I'd prefer to send some log, and even if I have to send big chunks of my code I wouldn't want to post it here (not that the forum would let me...)

1. I got my error in all places, where Number/Array<Number> function is called. While it is strictly "Number" or "Array<Number>" in release and debug modes, PMC clashes these distinct function declarations during analysis into one with "Number or Array<Number>" return type.

2. Yes, this is the reason, why I don't want to unify the return type.

1. strange, this kind of looks like the exact opposite of the problem I have:
I have:

(:debug) const X = 1;
(:release) const X = null;

and my code checks whether X == null, and it tells me it's unnecessary to check, as it's not null, it's a Number (in other words it only sees the debug code)

while your case suggest the opposite: it would make sense that it knows that in the specific build either everywhere it's Number or everywhere it's Array<Number> but not "Number or Array<Number>" however the error suggests that it looks at both the debug and the release code, thus it merges the 2 possible types.

flocsy🤠 said:

I understand the explanation and the examples in github, but I don't understand why they apply here. My only guess is that your code sees value.toString() and thinks it can change value?

It just doesn't do enough analysis to prove that toConfigStr doesn't change its argument. So yes, a better version of the extension could determine that it's not a problem. But what I'm trying to do is ensure that all the unsafe places are reported; and that means reporting things that haven't been proven to be safe.

I do have code to analyze functions to determine if they modify arguments, but it's currently partly disabled because it's a surprisingly hard thing to get right...

9811827 said:

PMC clashes these distinct function declarations during analysis

Yes. See my reply to flocsy🤠

flocsy🤠 said:

I don't understand why there are 2 errors that are almost (but not exactly) identical

Usually this is because the error is reported at different times during the build, and the source changes enough that the optimizer doesn't recognize it as the same error.

I've tried just reporting everything at the start - but that misses errors that only become obvious after inlining, or other optimizations. And I've tried just reporting things at the end; but that misses things that get optimized out. Sometimes you might want such warnings to be removed; but sometimes the code was removed because of the thing being warned about.

I don't understand. He has a set of functions with Number for release, and another set of the same functions for debug. Either this or that half of them are excluded, how does it get to merge the Number and the Array<Number> ?

When it optimizes, it produces a separate set of code for each set of exclude options. So (I believe) it correctly figures out all the types and doesn't issue any warnings.

When it analyzes the code, it looks at all the code at once, and reports on that, so it sees the two definitions for the function, and reports a warning.

And your case is the reverse. When it analyzes the code, it sees both versions, realizes that the const might be null, and doesn't issue a warning. But when it optimizes, it sees one version at a time, and does warn.

I don't think I want to get multiple warnings about the same thing. Here it's very clear that it's the same line, same column, same parameter of the same function.

Not only I don't want to get multiple errors of the same thing, I think it's at least confusing if not misleading that according to the 2 error messages something (either the passed value or the called method's parameter's type changed on the way? I'm ok getting errors about my code, but getting error about code that the optimizer transformed?

If my original code was incorrect, then report it at the beginning. Regardless whether you reported an error of my code or you haven't (and now let's assume that you haven't because my original code was correct) then don't report anything about some code that haven't been written by me but by the optimizer. Do you understand what I mean? I'm ok having a different type of error message, similar to what we sometimes see in the Garmin compiler telling me that there's some bug in the compiler and I should report it. Because any error that wasn't there in my original code is not a bug if my code IMHO, but the optimizer's.

I can however see some cases where the optimizer could give me tips how I could improve my code in such a way that it would become even more optimizabe (similar to the message we get when a method with inline annotation cannot be inlined). But having original code that is correct when Garmin checks it, correct when the optimizer checks it, but becomes .... I don't know what... sub-optimal for optimization? Or incorrect because of transformations that were made by the optimizer? That's shouldn't be an error to me IMHO.