microsoft
Compiler Output Not Showing All Errors
1. Describe the bug I have an app that I am compiling against the next major release. The compiler output (not the problems window, but the actual compiler output) does not show all errors in the app. I have confirmed this is not specific to certain Cops being turned on or custom rulesets as the behavior happens when nothing is turned on.
2. To Reproduce I'm happy to privately share the repository where this is happening. I am simply compiling, either is VS Code or directly with the compiler via BcContainerHelper.
3. Expected behavior All errors should be shown in the compiler output.
4. Actual behavior
Here is the problems tab, which contains all errors and matches the Microsoft email (36 errors)
Here is the compiler output (5 errors):
And the matching pipeline output (5 errors):
When all 5 errors are corrected, I get the remaining 31 in the compiler output. The same ones included in the Microsoft email. Here are a few:
5. Versions:
- AL Language: 15.0.1129943
- Visual Studio Code: 1.93.0 (but it's happening outside of VS Code)
- Business Central: 25.0.23364.24387 (it's been all versions of 25.0, but I don't think it's BC version specific)
Hello Matt, thanks for bringing this to our attention. I see you are using version 15.0.1129943, which is a pre-release version of the AL extension, and that this happens in BC 25.0 which as of right now is also in public preview.
May I ask if you are seeing a similar issue when using the latest non-prerelease version of the extension too? I'll reach out privately too, if you would like to share the repository in which this happens.
I've reached back out via email to share the repo.
This is specifically to address issues with the next major release, so I have use BC25 symbols. I can only download those from the environment using the AL Language v15 extension. The earlier versions of the AL Language don't seem to be compatible. I can't even try to compile the app with an earlier version.
Apologies for the very late response, Matt. We've chosen to accept the issue. I can't provide a timeline for the fix as of right now, however.
I will note that this behaviour is caused by the setting al.compilationOptions.continueBuildOnError (link to docs).
The default value is false, so when building with alc.exe and the command AL: Package (Ctrl+Shift+B) in VSCode, the default behaviour will be to stop early to save resources. The Problems-pane in VSCode behaves differently right now. So you can work around this by setting al.compilationOptions.continueBuildOnError = true.
Having discussed this a bit more internally, we have decided to not change the current behaviour. The decision was made based on a few observations:
- There already exists a way to get "the full overview of errors" when using either the alc.exe or VSCode by using the aforementioned
al.compilationOptions.continueBuildOnErrorsetting - The VSCode extension uses a few triggers to fully recompile the active project based on some actions, like saving new changes in a file. This re-build ignores user's settings like
al.compilationOptions, which explains the originally reported behaviour of the output and Problems-pane showing different information - Changing the Problems-pane to take into account the user's
al.compilationOptions.continueBuildOnErrorsetting flies into a problem when the default value isfalsea. If we change that behaviour and start showing fewer diagnostics, we have broken expectations for everyone relying on the Problems-pane in VSCode b. If we change the default value totrue, we potentially make people's continuous integration builds fail much later if the setting is not explicitly set, and that's potentially a throughput problem, and raises costs of running CI/CD.
I hope the above explanation make sense. Thanks again for contributing to the AL repository @MattTraxinger