Fix `readonly` intersection with type reference for readonly

[LakshanWeerasinghe]

Purpose

$subject With this PR we will support having intersection for type reference type with readonly.

Fixes #41916

Approach

In the type resolver when resolving effective intersection type we are not taking the referred type for type reference types.

Samples

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

Check List

• [x] Read the Contributing Guide
• [ ] Updated Change Log
• [ ] Checked Tooling Support (#<Issue Number>)
• [x] Added necessary tests
  • [x] 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

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 76.73%. Comparing base (187079a) to head (7b1c0d8). Report is 748 commits behind head on master.

Additional details and impacted files

@@             Coverage Diff              @@
##             master   #42025      +/-   ##
============================================
+ Coverage     76.68%   76.73%   +0.05%     
- Complexity    53066    53740     +674     
============================================
  Files          2882     2907      +25     
  Lines        200002   203149    +3147     
  Branches      26040    26481     +441     
============================================
+ Hits         153362   155890    +2528     
- Misses        38206    38741     +535     
- Partials       8434     8518      +84     

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[chiranSachintha]

@LakshanWeerasinghe Can you verify the reason to define two iterators, namely bLangTypeItr and iterator? It seems that one is used to iterate over typeNode, and the other to iterate over types. Since type information can be obtained directly from the typeNode, I don't think we need both iterators

[LakshanWeerasinghe]

@LakshanWeerasinghe Can you verify the reason to define two iterators, namely bLangTypeItr and iterator? It seems that one is used to iterate over typeNode, and the other to iterate over types. Since type information can be obtained directly from the typeNode, I don't think we need both iterators

Let's consider type as below,

type T1 int & int;

In here when we get constituent type nodes we get two nodes. And when we get the constituent btypes of the intersection type we get an array of single type with int. If we use bLangTypeItr to get the bType we get int in both cases. As per the current implementation of the calculateEffectiveType function, this will get an error.

[github-actions[bot]]

This PR has been open for more than 15 days with no activity. This will be closed in 3 days unless the stale label is removed or commented.

[github-actions[bot]]

This PR has been open for more than 15 days with no activity. This will be closed in 3 days unless the stale label is removed or commented.

[CLAassistant]

All committers have signed the CLA.