Pre-release of the AL compiler: AL0920 reports warnings on internal interfaces
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 45/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Quiet
- Tech stack
- vscode
- Domain
- compilers
Research direction
Start with the minimal AL interface and codeunit example in the issue and reproduce diagnostic AL0920 using the listed AL Language and Business Central versions. Trace the compiler's interface implementation accessibility check; done when an internal interface implemented by an internal procedure no longer produces the warning or future-error diagnostic.
Written by the indexing model from the issue text.
Description
1. Describe the bug
We're getting reports in the pre-release of AL of the new/undocumented AL0920 warning.
The method 'Foo' cannot be used as the implementation for the interface method 'IFoo.Foo' because it is not public. This warning will become an error when targeting a runtime with version '19.0' or higher.
Interfaces can be declared as public or internal on object-level, e.g. for mocking/testing.
Interface methods themselves cannot be declared as internal.
A codeunit implementing the interface can be declared public or internal on object-level, and its procedures can be local/internal/public.
2. To Reproduce
Declare an internal interface and implement it using internal procedures for the signature and you'll get the warning (future error).
interface IFoo {
Access = Internal;
procedure Foo() // interface procedures can't be explicitly marked as internal, but the object itself is internal
}
codeunit 50000 CuFoo implements IFoo {
internal procedure Foo() // matches the signature and access of IFoo.Foo
begin
end;
}
3. Expected behavior
We expect the warning not to apply to interfaces with Access = Internal, because their procedures aren't publicly available.
CuFoo.Foo isn't public, but so is IFoo.Foo, because IFoo isn't public.
4. Actual behavior
A warning is raised, indicating it'll be a future error.
5. Versions:
- AL Language: 18.0.2498801
- Visual Studio Code: 1.125.1
- Business Central: 28.0 , runtime 17.0
- List of Visual Studio Code extensions that you have installed: Pre-release of ms-dynamics-smb.al
- Operating System:
- Windows
- Linux
- MacOS
Final Checklist
Please remember to do the following:
-
Search the issue repository to ensure you are reporting a new issue
-
Reproduce the issue after disabling all extensions except the AL Language extension
-
Simplify your code around the issue to better isolate the problem
Internal work item: AB#641381
- Dominant language
- PowerShell
- Stars
- 881
- Forks
- 285
- Avg merge
- 3d 36m
- Merged PRs (30d)
- 1
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from microsoft/AL
-
accepted al-tools bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
AL 18.0.2732683 regression: System.Drawing types cannot be resolved from assembly probing paths Open
Difficulty 4/5 3-5 days Newbie friendliness 48/100
-
Difficulty 3/5 1-2 days Newbie friendliness 55/100
-
Difficulty 3/5 1-2 days Newbie friendliness 68/100
-
accepted packaging
Difficulty 4/5 3-5 days Newbie friendliness 48/100
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
objectionary/eo#8869 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
EricSpencer00/Resilient#4824 · 1 comment ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
objectionary/jeo-maven-plugin#1758 ·
-
generics
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
mlir
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
llvm/llvm-project#224908 · 1 comment ·