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

[Master] Reduce creating unwanted type definitions for const annotations #40964

Merged
merged 11 commits into from
Jul 17, 2023

Conversation

prakanth97
Copy link
Contributor

@prakanth97 prakanth97 commented Jul 10, 2023

Purpose

Fixes #40914

Approach

  • According to the spec, information related to source annotation shouldn't be propagated to runtime. So, we removed all the type definitions created for constant values of source annotation.
  • Remove unnecessary type definitions created for constant annotations. It reduced by approximately half.

Samples

For the following code, the jar size is reduced from 9.773571 Mb to 7.729598 Mb (20.913 %). Tried the native image size for same code in mac is reduced from 41.151857 Mb to 31.244385 Mb (24.075 %).

public function main() {
    int numbers = addNumbers(1, 2);
}

function addNumbers(int i, int j) returns int {
    return i + j;
}

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

@prakanth97 prakanth97 marked this pull request as ready for review July 11, 2023 07:27
@prakanth97 prakanth97 changed the title Reduce creating type definitions for const annotations Reduce creating unwanted type definitions for const annotations Jul 11, 2023
@prakanth97 prakanth97 added the Team/CompilerFE All issues related to Language implementation and Compiler, this exclude run times. label Jul 11, 2023
@prakanth97 prakanth97 marked this pull request as draft July 11, 2023 07:53
@prakanth97 prakanth97 marked this pull request as ready for review July 12, 2023 06:31
@codecov
Copy link

codecov bot commented Jul 12, 2023

Codecov Report

Patch coverage: 97.67% and no project coverage change.

Comparison is base (b2f1436) 76.63% compared to head (24d343b) 76.63%.

Additional details and impacted files
@@            Coverage Diff            @@
##             master   #40964   +/-   ##
=========================================
  Coverage     76.63%   76.63%           
- Complexity    55494    55509   +15     
=========================================
  Files          3393     3393           
  Lines        208749   208779   +30     
  Branches      27035    27043    +8     
=========================================
+ Hits         159965   159999   +34     
+ Misses        39954    39949    -5     
- Partials       8830     8831    +1     
Impacted Files Coverage Δ
...c/main/java/org/wso2/ballerinalang/util/Flags.java 95.20% <ø> (ø)
...iler/semantics/analyzer/ConstantValueResolver.java 45.24% <93.75%> (+1.10%) ⬆️
...lerinalang/compiler/bir/codegen/JvmPackageGen.java 89.66% <100.00%> (+0.07%) ⬆️
...lerinalang/compiler/bir/writer/BIRWriterUtils.java 96.63% <100.00%> (+0.14%) ⬆️
...ng/compiler/semantics/analyzer/SymbolResolver.java 80.83% <100.00%> (+0.09%) ⬆️
...lerinalang/diagramutil/SyntaxTreeMapGenerator.java 89.00% <100.00%> (+0.11%) ⬆️

... and 7 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

@prakanth97 prakanth97 changed the title Reduce creating unwanted type definitions for const annotations [Master] Reduce creating unwanted type definitions for const annotations Jul 13, 2023
@hasithaa
Copy link
Contributor

Can you add a test case, where you have a record type definition which used for both annotation purposes and used for normal value creations?

@prakanth97
Copy link
Contributor Author

Can you add a test case, where you have a record type definition which used for both annotation purposes and used for normal value creations?

Added c6e9721

@prakanth97 prakanth97 requested a review from hasithaa July 13, 2023 07:54
@prakanth97 prakanth97 added this to the 2201.8.0 milestone Jul 14, 2023
@hasithaa hasithaa merged commit d7ad710 into ballerina-platform:master Jul 17, 2023
17 checks passed
string value;
|};

const annotation Data dataAnon on type;
Copy link
Member

@MaryamZi MaryamZi Jul 17, 2023

Choose a reason for hiding this comment

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

Anon or Annot?

Person2 foo = {name: "James"};
typedesc<any> t = typeof foo;
Data? annon = t.@dataAnon;
assertEquality("{\"value\":\"T1\"}", annon.toString());
Copy link
Member

Choose a reason for hiding this comment

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

Generally better to assert the value rather than the string representation IMO (since it'll take types also into account).

Comment on lines +360 to +361
Data data = {value: "T2"};
assertEquality("{\"value\":\"T2\"}" , data.toString());
Copy link
Member

Choose a reason for hiding this comment

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

Is this to test the availability of Data at runtime? If so, aren't tests that actually validate against Data better? E.g., positive and negative is checks. Can also use a record with a default, use cloneWithType with it with a value that doesn't have a field for the field with the default, and test that the default is used.

@@ -2588,6 +2589,15 @@ public void populateAnnotationAttachmentSymbol(BLangAnnotationAttachment annotat
constantSymbol);
}

private boolean isSourceAnonOnly(Set<AttachPoint> attachPoints) {
Copy link
Member

Choose a reason for hiding this comment

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

Annot?

Copy link
Member

Choose a reason for hiding this comment

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

Need to change where called also.

@@ -667,8 +672,8 @@ private void updateConstantType(BConstantSymbol symbol, BLangExpression expr, Sy
return;
}

if (resolvedType.getKind() == TypeKind.INTERSECTION && isListOrMapping(type.tag)) {
expr.setBType(((BIntersectionType) resolvedType).effectiveType);
if (resolvedType.getKind() == TypeKind.RECORD && isListOrMapping(type.tag)) {
Copy link
Member

Choose a reason for hiding this comment

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

Was this intersection only for records? Not for lists (tuples)?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Since this fix is only for the constant annotation. Then record would be the only possible case not tuple. Right?

Copy link
Member

Choose a reason for hiding this comment

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

I was thinking about when there's a list as a member (field) of the annotation? I don't think we get here for that though.

const annotation map<map<string>[]> annot on source var;

@annot {
    x: [{a: "hello", b: "world"}]
}
var val = 1;

private void updateRecordFields(BRecordType recordType, Location pos, SymbolEnv env) {
BTypeSymbol structureSymbol = recordType.tsymbol;
for (BField field : recordType.fields.values()) {
field.type = ImmutableTypeCloner.getImmutableType(pos, types, field.type, env,
Copy link
Member

Choose a reason for hiding this comment

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

Within this we still create type defs, right? E.g., mapping within mapping. Shall we create an issue to avoid this also as a future improvement?

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.

[Improvement]: Remove unnecessary type definition creation for interop function definitions
5 participants