microsoft / AL

Home of the Dynamics 365 Business Central AL Language extension for Visual Studio Code. Used to track issues regarding the latest version of the AL compiler and developer tools available in the Visual Studio Code Marketplace or as part of the AL Developer Preview builds for Dynamics 365 Business Central.
MIT License
728 stars 241 forks source link

Increasing field showing as AL0432 #7594

Closed KrunoslavPipic closed 9 months ago

KrunoslavPipic commented 9 months ago

1. Describe the bug Why is field increasing treated as AL4032 rule? When the field retains the same ID, only the field is increased.

2. To Reproduce Steps to reproduce the behavior:

Execute the code that triggers Rule AS0086. e.g. add field(35; "Home Page"; Text[80]) from table 79 "Company Information" to some report e.g. add ffield(106; "Package Tracking No."; Text[30]) from table table 36 "Sales Header" to some report

3. Expected behavior There should be another rule to inform of increasing field. For example AS0086

4. Actual behavior The rule is incorrectly showing the warning as AL0432.

5. Versions: latest insider build: https://bcinsider.azureedge.net/sandbox/24.0.14083.0/w1](https://bcinsider.azureedge.net/sandbox/24.0.14083.0/w1 AL language: v13.0 Base app version: 24.0.14088.0

image image image image

We can add in ruleset file to ignore AL4032 warning, but then we will not have information of real obsolete fields.

dannoe commented 9 months ago

It is marked this way so that the developer knows they need to increment the field BEFORE the change is released in BC24. Example:

   local procedure DoSomething();
    var
        CompanyInformation: Record "Company Information";
        MyHomepage: Text[80];
    begin
        CompanyInformation.Get();
        MyHomePage := CompanyInformation."Home Page"; // this code will create runtime errors in BC24 and a warning in BC24
        ...
    end;

If you want to get rid of the warning and not get errors in BC24: increase the field length of the variables now and add a pragma to the line. Remember to remove the pragma with BC24 so that you will be notified of future increases. If you instead assign values to this table field in Company Information, you must use CopyStr with MaxStrLen. This will "automatically" increase the assignable length with BC24 (AFAIK this doesn't work for runtime packages).

qutreson commented 9 months ago

@KrunoslavPipic - As mentioned in the comment above, obsolete properties are currently used to give a notice on future breaking changes so that you can update your code accordingly. We do not have a mechanism for giving you such notices without obsolete properties, but this could be a new feature to propose on aka.ms/BCIdeas.

KrunoslavPipic commented 9 months ago

Implemented a temporary workaround: image

to capture information about obsolete/increasing fields while allowing the compilation in pipeline to pass.

INFO can be easily ignored during coding, and with each new version, we'll review the rules: image

qutreson commented 9 months ago

Note that AL0432 is not only used to let you know about field increases, but is also used for anything that might be completely removed. By fully ignoring it through rulesets, you might now be missing a lot of important information about future removal of objects or features. The suggestion from @dannoe to use pragma suppressions (i.e. #pragma warning disable/restore AL0432) on specific instances of code where the diagnostic AL0432 is report was a better approach to this problem as it would suppress the ones about the length increase that you want to ignore, while still showing all the other ones.

KrunoslavPipic commented 9 months ago

I agree, but having a bunch of pragma lines and adding/removing them with each new version is not the happiest solution.

We are not ignoring the rule; we're just showing it as info :) and with each new version, the info needs to be reviewed. image

Also, the AL-pipeline will fail with insider artifacts (current version 24.0.) if the field removal has indeed become obsolete, and we have enough time to rewrite the logic