[Project API] Concerns regarding not supporting isToolingCompilation

[rasika]

By design, when there's errors in CODE_ANALYZE phase Compiler won't be continued to other phases such as DOC_ANALYZER...etc.

Since this behavior is problematic(and breaks UX) for the tooling experience we had set the isToolingComilation flag when we were using Compiler.compile(). Just after migration to project-api we cannot set this flag since project-api doesn't support this.

https://github.com/ballerina-platform/ballerina-lang/blob/master/compiler/ballerina-lang/src/main/java/io/ballerina/projects/internal/CompilerPhaseRunner.java#L268

Due to above issue, current behavior is that you won't get any diagnostics in latter phases such as documentation issues when there's code-analyzer errors. IMO end of the day IDE users are the real end users of this language. It is bit hard to explain current behavior to the end users. For example something like following, "If you have code-analyzer errors, you won't get any documentation errors".

We are receiving issues such as #27936 due to above

[rasika]

looping @sameerajayasoma @hevayo @hasithaa @Kishanthan

[Kishanthan]

We have a way to pass BuildOptions using the ProjectAPI. So we can pass in this option as a BuildOptions and check in CompilePhaseRunner to skip, which will be the same logic as before.

@hevayo, @sameerajayasoma, @azinneera shall we provide this support with BuildOptions?

[rasika]

Exactly, what I am asking is to allow this flag through the BuildOptions of the project-api as good old days

[hasithaa]

I know this is a limitation right now. But this is a safety check added to the type checker, to prevent cascading failures and unintended diagnostics. 

For example, with the previous implementation, we have seen a type called 'other' in some diagnostics when using VSCode. which is misleading. Even it may create incorrect diagnostics.  So bypassing this safety check using a build option, is a bad idea.

In order to fix it properly, we need to make the type checker resilient. So I would suggest keeping the current behavior as it is for SwanLake.

[rasika]

My view on this might be quite subjective. But for me having 'other' as a type for some diagnostics is far better than the current behavior. Even that is understandable when you are having semantic errors. Users coming from other languages are already aware of such behavior. On the otherhand, it is very common to have at least one semantic error when you are writing code (in such cases issues such as #27936 might break the flow of the coding).

I believe most of the case, we were good with what we had before. Otherwise we could have gone through quite high number of issues reporting diagnostics are wrong. And I believe even not having this support in project-api is not a result of avoiding such issues.

Since we are not yet decided any release dates for resilient type checker, having this weird behavior indefinitely is quite annoying 😛.

[hasithaa]

Giving a misconception in diagnostics completely wrong. For example, what is the meaning of Incompatible type: expected other found int. That is why we have this safety check. Even in the Java compiler, I have seen this behavior earlier.

Users tend to fix semantic errors first, before going to add some more stuff. Once we fix the original issue, We can fix this properly, So I would suggest not to add temporary workaround.