Trying to workaround "unsynced" case for newly added files.

[dkashyn-sfdc]

Checklist

• I have filed an issue about this change and discussed potential changes with the maintainers.
• I have received the approval from the maintainers to make this change.
• This is not a stylistic, refactoring, or cleanup change.

Please note that the maintainers will not be reviewing this change until all checkboxes are ticked. See
the Contributions section in the README for more
details.

Discussion thread for this change

Issue number: <please reference the issue number or url here>

Description of this change

#5347

[mai93]

This can be fixed by running "Partial Sync" on the newly added file, can you explain why this fix is needed?

[dkashyn-sfdc]

Because when you refactoring/adding files, unsynced by default is confusing.

Of course Partial Sync can help but:

• it takes 1 minute for our project if you are lucky
• with existing IJ project structure this operation is excessive so we can use sync status of surrounding files
• it is so opaque and unapparent to our users that manual sync is required for every move/add operation

[blorente]

Sorry for the late review. The more I think about it, the more I am against this sort of change, because it will expose lies to users.

I agree that we should have a lightweight way of updating the SourceToTargetMap for just one target that essentially expands the globs in srcs. Does Bazel -> Sync -> Sync Directories work for this case? It should be much faster, since it doesn't build anything with Bazel.

[dkashyn-sfdc]

@blorente, sorry for being a little bit blunt here, but we are having issues even with the first "Bazel Sync" need, with our engineers. This operation is so unnatural for IJ.

"Sync" after any refactor or file changes might be okay, for Google with your huge project and associated tooling, but for mere mortals outside of Google, this is so unnatural that people are really struggling with this remedy.

Even more: a few of hundreds of our engs are fluent in all 5 types of syncs that Bazel Plugin has.

[ujohnny]

Folks, let me jump in here. It looks like this change might lead to an incorrectly analyzed code, for example, in CLion as the target-level settings won't be applied, and a file will be analyzed with project-wide settings. I agree that any sync is a too rough solution when a single file is added/moved, but there's a lot of code that should be run for every file in the project model, at least for CLion to get correct code analysis, and so far that code can be reached only from sync routines. If someone can add a listener for a new file / moved file and "implement a part of bazel" (ie, detect target to which it did belong, which it will belong) on the IntelliJ side and update the workspace state properly, then it will be really cool. Otherwise, I am afraid of new reported issues regarding "red code," etc.

[dkashyn-sfdc]

Well, this was never 100%-complete solution since if the package is empty there is nothing to triangulate against.

Also if we are talking about tests there won't be consensus in targets (packages?) for those.

[dkashyn-sfdc]

We decided not to proceed with this PR and to keep it to our internal version only :( I wish BSP were here faster!