You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
Conditional imports have some problems:
By default, the source file path is not checked, which can only be enabled through an optional lint. I think it should be the other way around, disabling the check should be a lint. - Discussion in Conditional imports not checked #4525
Thanks! I've split (2) into #4530 an will use this to track (3).
We can continue discussion of (1) in #4525 (comment). It's not something I have a real preference on, but changing default lints is a decision for others to make.
@bwilkerson@scheglov I think this happens because when we rename a file, we search for all references to it using _searchReferences_CompilationUnit in Search. This uses fileState.referencingFiles to find which files reference the one being moved, but that only includes the "selected" uri from the directive.
Would it be reasonable for FileState.referencingFiles to also be populated with all non-"selected" URIs from a directive? There are a few other places that use this list but it's not clear to me what are the implications of it having the others in there.
FileState.referencingFiles is currently used to say "these files semantically depend on this file", so if this file changes, we need to reanalyze these files (transitively). I think non-selected URIs probably should not transitively affect files that contain them.
It seems that we need to know how the file is referenced, so the kind is better than a separate collection. Maybe somehow else, depends on for what else we need to use it.
Activity
[-]Conditional imports support[/-][+]Renaming files doesn't update conditional imports[/+]DanTup commentedon May 9, 2023
Thanks! I've split (2) into #4530 an will use this to track (3).
We can continue discussion of (1) in #4525 (comment). It's not something I have a real preference on, but changing default lints is a decision for others to make.
DanTup commentedon May 10, 2023
@bwilkerson @scheglov I think this happens because when we rename a file, we search for all references to it using
_searchReferences_CompilationUnitinSearch. This usesfileState.referencingFilesto find which files reference the one being moved, but that only includes the "selected" uri from the directive.Would it be reasonable for
FileState.referencingFilesto also be populated with all non-"selected" URIs from a directive? There are a few other places that use this list but it's not clear to me what are the implications of it having the others in there.bwilkerson commentedon May 10, 2023
It seems reasonable to me.
scheglov commentedon May 10, 2023
FileState.referencingFilesis currently used to say "these files semantically depend on this file", so if this file changes, we need to reanalyze these files (transitively). I think non-selected URIs probably should not transitively affect files that contain them.DanTup commentedon May 10, 2023
@scheglov would it be better to add another collection? Or have some flag against each to signify if they may affect analysis?
scheglov commentedon May 10, 2023
It seems that we need to know how the file is referenced, so the kind is better than a separate collection. Maybe somehow else, depends on for what else we need to use it.
1 remaining item