--useCquery probably incorrectly handles SOURCE_FILE's

[Asdprom]

Hi!

I noticed a difference in behavior between the cquery and query implementations - on the same repository (bazel-diff-sample.zip), we get different results.

The example is quite simple: target B depends on the source file A.cc through the sample_repo local repository and target A.

//:B -> @sample_repo//:A -> @sample_repo//:A.cc

Query returns significantly more targets than cquery (with the --fineGrainedHashExternalRepos=sample_repo flag specified in both cases), when A.cc is modified.

cquery:

//sample_repo:A

query:

//sample_repo:A
@sample_repo//:A.cc
@sample_repo//:A
//sample_repo:A.cc
//:B

It is possible that the tool with the --useCquery flag is not working correctly. My suspicion falls on these two (1, 2) code fragments, where almost all sources are implicitly filtered out from the target list because SOURCE_FILE has empty rule.name. Which leads to warnings like:

[Warning] Unable to calculate digest for input @sample_repo//:A.cc for rule @sample_repo//:A

And there is no similar filtration performed when the tool is run in query mode. Sorry in advance if I somehow misunderstood this code or idea behind it, but results seem a little bit strange.

[honnix]

Maybe due to

bazel-diff/cli/src/main/kotlin/com/bazel_diff/bazel/BazelQueryService.kt

Lines 93 to 96 in eedaeba

	if providers(target) == None:
	# skip printing non-target results. That is, source files and generated files won't be
	# printed
	return ""

, which looks like by design.

[honnix]

@tinder-maxwellelliott I think this might be indeed an issue. Not only source files, but also generated files are filter out because of empty rule.name.

[honnix]

I think we might just convert Build.Target into BazelTarget already in BazelQueryService so we can call .name. But would that break the initial design (BazelQueryService should strictly dealing with Bazel proto objects)?

[tinder-maxwellelliott]

@honnix Id be open to a PR for this to see what the impact is

[honnix]

I put up something quickly in #251