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

Private identifiers in part file treated as local symbols #39

Open
matthewnitschke-wk opened this issue May 20, 2023 · 1 comment
Open

Comments

@matthewnitschke-wk
Copy link
Contributor

matthewnitschke-wk commented May 20, 2023

If a private identifier is within a part file, any reference to that identifier will be a local x symbol, even if its defined within a separate file. For example:

// main.dart
part 'part_file.dart';
void main() => _test();
//             ^^^^^ reference local 0
// part_file.dart
part of 'main.dart';
void _test() {}
//   ^^^^^ definition local 0

scip requires that any symbol in a different file cannot be local, this edge case must be handled

@matthewnitschke-wk
Copy link
Contributor Author

This is somewhat more difficult than the other fixes

We need to generate the symbol from both sides: the definition and the reference. This would technically be possible in the current system from the reference: check the targetElement, if that element is in a different file, then the symbol is not local. But from the definition side, we dont exactly know if there are any references from within part files

While not ideal, the most practical solution to this problem is to generate all fields, methods, and other things that can be referenced within part files as regular symbols, regardless of their part status. This means that local references will be specific to parameters, and a few other unique edge cases. I'm not sure if there is a large con to this, other than potential performance differences on the post analysis side of things, but from the scip generation side, things are made much easier

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant