ballerina-lang icon indicating copy to clipboard operation
ballerina-lang copied to clipboard

Bal build is showing compilation warnings for external modules

Open Mirage20 opened this issue 4 years ago • 7 comments

Description: $title. For example, if we use an external module that does not have documented fields, we get undocumented field warnings when we compile the original project. Since the developer doesn't have any control over these warnings, it is better to remove these warnings from getting printed in the current project.

Steps to reproduce:

Build a project with an external module that has compilation warnings.

Example code:

import ballerinax/covid19;
import ballerina/http;

service / on new http:Listener(8090) {
    resource function get .(http:Request req) returns json|error? {

        covid19:Client covid19Endpoint = check new ();
    }
}

This will produce the following warnings

Compiling source
        mirajabeysekara/sandbox12:0.1.0
ballerinax/covid19:1.0.0 [central.ballerina.io -> home repo]  100% [=======================================================================] 12/12 KB (0:00:00 / 0:00:00) 
        ballerinax/covid19:1.0.0 pulled from central successfully
WARNING [ballerinax/covid19/1.0.0::types.bal:(163:5,163:27)] undocumented field 'cases'
WARNING [ballerinax/covid19/1.0.0::types.bal:(164:5,164:28)] undocumented field 'deaths'
WARNING [ballerinax/covid19/1.0.0::types.bal:(165:5,165:31)] undocumented field 'recovered'
WARNING [ballerinax/covid19/1.0.0::types.bal:(367:5,367:18)] undocumented field 'cases'
WARNING [ballerinax/covid19/1.0.0::types.bal:(368:5,368:28)] undocumented field 'deaths'
WARNING [ballerinax/covid19/1.0.0::types.bal:(369:5,369:31)] undocumented field 'recovered'

Running Tests

        sandbox12

                No tests found


Generating executable
Language telemetry service is disabled.
        target/bin/sandbox12.jar

Affected Versions: SL Beta3 RC4

Mirage20 avatar Sep 30 '21 06:09 Mirage20

@hasithaa Thoughts on this? I don't think it is correct to remove these warnings even though they are coming from a dependent module.

anupama-pathirage avatar Sep 30 '21 18:09 anupama-pathirage

IMO this is not a bug since it was a conscious decision to show any errors or warnings coming from the compiler for dependent modules.

Possible improvement can be introduce a mode to the compiler for compiling dependencies where the compiler can skip checks which are not relevant to a module user. ie ( lint errors, documentation issues etc)

hevayo avatar Oct 01 '21 07:10 hevayo

IMO this is not a bug since it was a conscious decision to show any errors or warnings coming from the compiler for dependent modules.

Here, the developer can't take any action to fix the warning right? Also, these warnings will disappear on the next builds because of the caching.

Possible improvement can be introduce a mode to the compiler for compiling dependencies where the compiler can skip checks which are not relevant to a module user. ie ( lint errors, documentation issues etc)

+1

Another approach is to give flags to disable warnings like -Wundocumented-field similar to C++, but I am not sure whether it is the correct approach for Ballerina.

Mirage20 avatar Oct 01 '21 08:10 Mirage20

Yes, this is not a bug. I am closing this issue. Please create a new issue with a proposal.

sameerajayasoma avatar Oct 04 '21 17:10 sameerajayasoma

Reopening this issue since this came up once again in a language design call when discussing https://github.com/ballerina-platform/ballerina-lang/issues/37463 and it was suggested that we shouldn't be showing these warnings/errors to the user.

MaryamZi avatar Sep 21 '22 03:09 MaryamZi

Considering recent issues/warnings, I now believe that we should suppress compile-time warnings generated by package dependencies. We decided to allow all such warnings a few years ago, but the situation has changed now.

My proposal is to suppress such warnings by default and provide a compiler option to see them.

sameerajayasoma avatar Apr 22 '24 01:04 sameerajayasoma

Reopening this issue again, we need to suppress the errors from the dependent modules and show a common error instead.

Thevakumar-Luheerathan avatar May 03 '24 10:05 Thevakumar-Luheerathan