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

Reset unknownTypeRefs after silent type checking #43758

Open
wants to merge 8 commits into
base: master
Choose a base branch
from

Conversation

rdulmina
Copy link
Contributor

@rdulmina rdulmina commented Jan 21, 2025

Purpose

$title

Fixes #43286

Approach

Compiler error at L#1749 was not reached because the field unknownTypeRefs was populated at the silent typechecking and does not reset after.


Introduced GlobalStateData inner class to make the solution scalable for such fields may occur in future

Samples

The following sample should give unknown type error of unknown types I and J

class H {};

H res = check new I();

int[] a = [1, 2, 3, 4, 5];

int[] b = from var i in a select <I> i;

float result = <J>1 + 2.0;

int result2 = true? <J>1 : 2;

var result3 = <H> new J();

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

@rdulmina rdulmina added Team/CompilerFE All issues related to Language implementation and Compiler, this exclude run times. Area/TypeChecker Type Checker related issues #Compiler labels Jan 21, 2025
@@ -9918,6 +9914,24 @@ String recordsToString(Set<BRecordType> recordTypeSet) {
}
}

public GlobalStateData getGlobalStateSnapshotAndResetGlobalState() {
Copy link
Member

Choose a reason for hiding this comment

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

Can't we do this via analyzer data instead of introducing a new data holder?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

AnalyzerData act like set of global fields where we pass through the functions. GlobalStateData is used as a snapshot of several fields where we will be creating multiple of objects of it. However, we can still use the AnalyzerData for the same purpose. The issue is it will introduce unwanted object creations of the AnalyzerData which is not clean

Copy link
Member

Choose a reason for hiding this comment

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

The addition is basically resetting unknown type refs, right? Can we just do it inline instead of introducing GlobalStateData? The name is ambiguous and can be confusing with analyzer data IMO.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Writing this inline is not a good idea in terms of scalability. We already have two fields that needs to be reset. There is a high chance of more fields require this in future. I have renamed the class name to GlobalStateSnapshot

Copy link
Member

Choose a reason for hiding this comment

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

The only additional thing we've done is changing unknown type refs, right? Error count logic was already there? It makes sense to extract out repeated logic to a function, but IMO, here we are just doing it for part of it. I would rather refactor the whole thing properly or just reset type refs in line (similar to the others). With just what we have now, I also don't think GlobalStateSnapshot is an ideal name here, since it doesn't include all "global state" and can be confusing with analyzer data.

I would introduce the change in a way that makes it readable and clear at the moment, rather than anticipating future changes (when we can refactor everything properly).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't think this approach is less readable than the inline one. If we write this inline the code becomes messy, not scalable, and the same code will duplicate at every place where we do silent type checking.

It makes sense to extract out repeated logic to a function

Yes, to extract out repeated logic we need some kind of a object or a record to get the previous data available at the caller function

@@ -9918,6 +9914,24 @@ String recordsToString(Set<BRecordType> recordTypeSet) {
}
}

public GlobalStateData getGlobalStateSnapshotAndResetGlobalState() {
Copy link
Member

Choose a reason for hiding this comment

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

The addition is basically resetting unknown type refs, right? Can we just do it inline instead of introducing GlobalStateData? The name is ambiguous and can be confusing with analyzer data IMO.

Copy link

codecov bot commented Feb 7, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 77.39%. Comparing base (cbab642) to head (9333af5).
Report is 36 commits behind head on master.

Additional details and impacted files
@@             Coverage Diff              @@
##             master   #43758      +/-   ##
============================================
- Coverage     77.41%   77.39%   -0.02%     
- Complexity    58626    58682      +56     
============================================
  Files          3446     3451       +5     
  Lines        219214   219441     +227     
  Branches      28973    29008      +35     
============================================
+ Hits         169703   169835     +132     
- Misses        40073    40153      +80     
- Partials       9438     9453      +15     

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

@rdulmina rdulmina requested a review from MaryamZi February 7, 2025 11:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area/TypeChecker Type Checker related issues #Compiler 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]: Compiler crashed when running bal build
3 participants