-
-
Notifications
You must be signed in to change notification settings - Fork 658
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[display] diagnostics miss errors from Haxe's post-processing #7931
Comments
Any error from our post-processing is missed because we don't run it for diagnostics. We can explicitly run the var init check and null-safety in diagnostics mode. They are early filters, so it should be fine. |
By the way, do we have diagnostics tests now? |
Yep, although just a single one that checks that there are no diagnostics. So no |
Not easy to fix because we don't have access to a good error function in post-processing. This is going to require some refactoring. |
I assume "Type name should start with an uppercase letter" is one of these too? |
No, that's a parser error. But it might be a hard error still. |
I kinda want to solve this for 4.1, but it's not so easy. I think we can do something like However, the more general problem here is there is various post-processing that could cause errors and we don't want to run all of that for diagnostics. Unfortunately, this then means that diagnostics will never 100% match compilation errors. |
We don't? What's an example of something that would be too expensive to run? |
The analyzer for sure, but this is more about the sum of the parts. Our post-processing is not designed to just detect errors, it's a huge AST transformation framework which just happens to spit out some errors in the process. We should go through the individual steps and check which ones might report user-facing errors (not the |
This has been addressed by #11220. I'll go through the filters and see that I add some tests. |
Adding sane tests for this is kind of blocked by #9134. |
Filters like null safety not yet here, this or #7933 should be reopened? |
* [display] diagnostics as json rpc (Backport #11412) * [tests] use json rpc diagnostics * [tests] Add test for 11695 * [tests] Update diagnostics tests * Run some filters in diagnostics (#11220) * let's see how much breaks * [tests] enable diagnostics tests for 11177 and 11184 * [tests] Update test for 5306 * Don't cache/run filters for find reference/implementation requests (#11226) * Only run filters and save cache on diagnostics, not usage requests * [tests] Update test for 11184 * disable test * add VUsedByTyper to avoid bad unused local errors * revert @:compilerGenerated change --------- Co-authored-by: Rudy Ges <[email protected]> * [display] get rid of TypeloadParse.current_stdin * [display] fix -D display-stdin handling * [display] generalize fileContents behavior to other json rpc display calls * [display] fix range of pattern variables Note: not including texprConverter changes see 160a490 see #7282 * [tests] add test for #7282 * [tests] add test for #7931 * Remove populateCacheFromDisplay config Legacy diagnostics = false, json rpc diagnostics = true * [std] Diagnostics request doc * [tests] Test Json RPC diagnostics with several open files * [diagnostics] fix multi display files (#11722) * [diagnostics] fix json rpc diagnostics display config * [tests] Server tests: do not fail silently when runHaxeJsonCb errors * [tests] add more diagnostics tests * [display] rework multiple display files handling * clean up a bit... * [diagnostics] handle a.b.c.hx case, even if pointless * [diagnostics] do not skip errors during DisplayProcessing.process_display_file * Enable display tests again... * [tests] fix display tests --------- Co-authored-by: Simon Krajewski <[email protected]>
* [display] diagnostics as json rpc (Backport #11412) * [tests] use json rpc diagnostics * [tests] Add test for 11695 * [tests] Update diagnostics tests * Run some filters in diagnostics (#11220) * let's see how much breaks * [tests] enable diagnostics tests for 11177 and 11184 * [tests] Update test for 5306 * Don't cache/run filters for find reference/implementation requests (#11226) * Only run filters and save cache on diagnostics, not usage requests * [tests] Update test for 11184 * disable test * add VUsedByTyper to avoid bad unused local errors * revert @:compilerGenerated change --------- Co-authored-by: Rudy Ges <[email protected]> * [display] get rid of TypeloadParse.current_stdin * [display] fix -D display-stdin handling * [display] generalize fileContents behavior to other json rpc display calls * [display] fix range of pattern variables Note: not including texprConverter changes see 160a490 see #7282 * [tests] add test for #7282 * [tests] add test for #7931 * Remove populateCacheFromDisplay config Legacy diagnostics = false, json rpc diagnostics = true * [std] Diagnostics request doc * [tests] Test Json RPC diagnostics with several open files * [diagnostics] fix multi display files (#11722) * [diagnostics] fix json rpc diagnostics display config * [tests] Server tests: do not fail silently when runHaxeJsonCb errors * [tests] add more diagnostics tests * [display] rework multiple display files handling * clean up a bit... * [diagnostics] handle a.b.c.hx case, even if pointless * [diagnostics] do not skip errors during DisplayProcessing.process_display_file * Enable display tests again... * [tests] fix display tests --------- Co-authored-by: Simon Krajewski <[email protected]>
Is that still a thing ? Do you have a way to repro ? |
I think it is, see this example, but for diagnostics check |
Indeed, thanks! |
Interestingly, it reaches the error but the reporting isn't working properly. |
This fails to compile with
Local variable s used without being initialized
, but there's no diagnostics error for it.Seems like this is not a regression / has always been this way.
The text was updated successfully, but these errors were encountered: