-
Notifications
You must be signed in to change notification settings - Fork 744
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
Conversation
Codecov ReportPatch coverage:
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
☔ View full report in Codecov by Sentry. |
.../src/main/java/org/wso2/ballerinalang/compiler/semantics/analyzer/ConstantValueResolver.java
Outdated
Show resolved
Hide resolved
compiler/ballerina-lang/src/main/java/org/wso2/ballerinalang/util/Flags.java
Outdated
Show resolved
Hide resolved
.../src/main/java/org/wso2/ballerinalang/compiler/semantics/analyzer/ConstantValueResolver.java
Outdated
Show resolved
Hide resolved
.../src/main/java/org/wso2/ballerinalang/compiler/semantics/analyzer/ConstantValueResolver.java
Outdated
Show resolved
Hide resolved
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 |
string value; | ||
|}; | ||
|
||
const annotation Data dataAnon on type; |
There was a problem hiding this comment.
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()); |
There was a problem hiding this comment.
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).
Data data = {value: "T2"}; | ||
assertEquality("{\"value\":\"T2\"}" , data.toString()); |
There was a problem hiding this comment.
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) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Annot?
There was a problem hiding this comment.
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)) { |
There was a problem hiding this comment.
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)?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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, |
There was a problem hiding this comment.
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?
Purpose
Fixes #40914
Approach
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 %).
Remarks
Check List