Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generate closures for default values in type inclusions #42428

Merged

Conversation

chiranSachintha
Copy link
Member

Purpose

$title.

Fixes #42356

Approach

Describe how you are implementing the solutions along with the design details.

Samples

Provide high-level details about the samples related to this feature.

Remarks

List any other known issues, related PRs, TODO items, or any other notes related to the PR.

Check List

  • Read the Contributing Guide
  • Updated Change Log
  • Checked Tooling Support (#)
  • Added necessary tests
    • Unit Tests
    • Spec Conformance Tests
    • Integration Tests
    • Ballerina By Example Tests
  • Increased Test Coverage
  • Added necessary documentation
    • API documentation
    • Module documentation in Module.md files
    • Ballerina By Examples

@CLAassistant
Copy link

CLAassistant commented Mar 28, 2024

CLA assistant check
All committers have signed the CLA.

Copy link

codecov bot commented Mar 28, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 76.82%. Comparing base (06d9bb6) to head (dfde2e3).
Report is 415 commits behind head on master.

Additional details and impacted files
@@             Coverage Diff              @@
##             master   #42428      +/-   ##
============================================
+ Coverage     76.64%   76.82%   +0.17%     
- Complexity    53437    53971     +534     
============================================
  Files          2902     2924      +22     
  Lines        201848   203904    +2056     
  Branches      26271    26592     +321     
============================================
+ Hits         154706   156646    +1940     
- Misses        38651    38718      +67     
- Partials       8491     8540      +49     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@chiranSachintha chiranSachintha added the Team/CompilerFE All issues related to Language implementation and Compiler, this exclude run times. label Mar 29, 2024
@@ -39,3 +39,8 @@ public type ClosedVehicleWithNever record {|
int j;
never p?;
|};

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add more tests

  1. with multiple levels of inclusion: e.g.,
    i. baz:C includes bar:B which includes foo:A, where the default value is specified in foo
    ii. baz:C includes bar:B which includes foo:A, where the default value is specified in bar
  2. to make sure the default value is used only when a value is not specified
  3. a record includes two records with the same field (where one or both have a default), but the including record has to specify the field explicitly then. In such cases, add tests for both when the including record's field has a default value and doesn't have a default value. In either case default values from the included records shouldn't be used.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

added with 4d48e7a

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We aren't testing 2 (in conjunction with 3 also) are we? I guess that's OK since we have tests for the normal case.

Please add a test like 1, where foo:A has a default for a field which is overridden by bar:B, also with a default.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added with 6094bb8

@MaryamZi MaryamZi added this to the 2201.9.0 milestone Mar 29, 2024
poorna2152
poorna2152 previously approved these changes Apr 2, 2024
Copy link
Contributor

@poorna2152 poorna2152 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

BTypeSymbol typeSymbol) {
Map<String, BInvokableSymbol> defaultValues = ((BRecordTypeSymbol) typeSymbol).defaultValues;
String typeName = recordTypeNode.symbol.name.value;
for (BLangType type : recordTypeNode.typeRefs) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We seem to be creating quite a few closures unnecessarily.

  1. Isn't the problem only with inclusions from a different module? Why are we creating closures for defaults from all inclusions?

For the following points, inclusions can be from different modules once 1. is addressed.

  1. For
type Foo record {|
    int a = 1;
    int b = 2;
    int c = 3;
|};

type Bar record {|
    *Foo;
    int b = 22;
    int c;
|};

We are creating a closure wrapping c's default value closure unnecessarily. That default value closure (Foo's c field's) is not required here.

  1. For
type Foo record {|
    int a = 1;
|};

type Bar record {|
    *Foo;
|};

type Baz record {|
    *Foo;
|};

closures wrapping a's closure are created twice. Can't we avoid (or at least minimize) this using some combination of the included record's fully-qualified identifier and field name?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, Issue when type inclusion in a different module. Earlier, I created closures for when it's in the same module to keep the logic simple. I've updated that.

Do we need to skip the second and third scenarios? We need to do extra checks for those. But these scenarios are very rare, so do we need to skip them?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would fix at least 2. Easy fix, right? Just need to check by explicitly-specified fields rather than those with defaults.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. Will update that.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Udapted 52836fd

result = recordTypeNode;
}

private void generateClosuresForDefaultValuesInTypeRefs(BLangRecordTypeNode recordTypeNode,
Copy link
Member

@MaryamZi MaryamZi Apr 2, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add a comment explaining why we are doing this, mention that it's temporary, and point to relevant issues.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

added
Fixed with #41949

Comment on lines 423 to 425
//In the BIR, we generate instruction for closures when visiting the lambda function.
//Due to that, if the inclusions are in different modules, closures are not created for default values.
//Fixed with #41949 issue.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't the issue more about not being able to find that closure? Can we rephrase. Mention the workaround we are adopting here too.

Add a space after //.

I would also say "Will be fixed with ..." or "Tracked with ..." instead of "Fixed with ...". since if it is fixed, we don't need the workaround.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated. please check

@@ -39,3 +39,8 @@ public type ClosedVehicleWithNever record {|
int j;
never p?;
|};

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We aren't testing 2 (in conjunction with 3 also) are we? I guess that's OK since we have tests for the normal case.

Please add a test like 1, where foo:A has a default for a field which is overridden by bar:B, also with a default.

@@ -1050,7 +1097,8 @@ public void visit(BLangCompoundAssignment compoundAssignment) {
public void visit(BLangInvocation invocation) {
rewriteInvocationExpr(invocation);
BLangInvokableNode encInvokable = env.enclInvokable;
if (encInvokable == null || !invocation.functionPointerInvocation) {
if (encInvokable == null || !invocation.functionPointerInvocation ||
!env.enclPkg.packageID.equals(invocation.symbol.pkgID)) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could have had cases like this previously too, right? When the default value is a function call of a function from a different module? Can we add such a test also?

Copy link
Member Author

@chiranSachintha chiranSachintha Apr 3, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

added test with c681a7f

MaryamZi
MaryamZi previously approved these changes Apr 4, 2024
@@ -35,6 +35,7 @@ public class MapConstantEqualityInDifferentBalaTest {

@BeforeClass
public void setup() {
BCompileUtil.compileAndCacheBala("test-src/bala/test_projects/test_project_utils");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given that what we are introducing is a simple test, I would extract that test and packages out separately, and avoid these unnecessary compilations for other tests.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@chiranSachintha, please send a separate PR fixing this, will merge this for now since it is required for U9.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated the test case

@LakshanWeerasinghe LakshanWeerasinghe merged commit 7782a44 into ballerina-platform:master Apr 5, 2024
18 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Team/CompilerFE All issues related to Language implementation and Compiler, this exclude run times.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Bug]: records fields are set to null when there should be a default value assigned
5 participants