FR: Allow overwriting file classification heuristic

[phst]

Gazelle uses a heuristic to classify source files (

gazelle_cc/language/cc/fileinfo.go

Line 74 in f49ebb7

func getFileInfo(

). This works fine most of the time, but sometimes fails. For example, Windows binaries will often define wmain or _tmain instead of main. Therefore it would be nice to allow source authors to override the classification. For example, the source code parser could look for directives in comments of the form

// gazelle:source_kind binary

to force generation of a cc_binary rule.

[jayconrod]

cc @mateusz-olczyk

If it's possible to solve this without adding new configuration, that would be preferable. So perhaps:

1. Recognize wmain and _tmain functions as indicators of a binary source file.
2. If a source file is already assigned to a rule, keep assigning it to that rule or at least that type of rule. So the user could manually move a source file to cc_binary, and Gazelle would respect that. This should apply to hdrs / srcs too for .h files.

[phst]

Recognize wmain and _tmain functions as indicators of a binary source file.

Yeah (plus WinMain, wWinMain, _tWinMain). However, at least in my case I use a platform-dependent macro (https://github.com/phst/rules_elisp/blob/2852da23664d6bc9c68a838a30256b76ae3a5341/elisp/private/tools/platform.h#L37-L43), not sure whether the detection code should do macro expansion.

If a source file is already assigned to a rule, keep assigning it to that rule or at least that type of rule

Also sounds reasonable, but maybe this should get fixed in Gazelle itself. Right now the logic appears to be (https://pkg.go.dev/github.com/bazelbuild/bazel-gazelle@v0.46.0/merger#MergeFile)

A rule matches if it has the same kind and name or if some other attribute in rule.KindInfo.MatchAttrs matches (e.g., "importpath" in go_library).

So maybe the matching logic in Gazelle should be extended to allow for this type of cross-kind matching.

[mateusz-olczyk]

not sure whether the detection code should do macro expansion.

Macro expansion may be a difficult thing to do:

1. Macros are not always simple constants like #define MAIN wmain, they may contain expressions #define MAIN MACRO1##MACRO2. Evaluating such expressions would require rewriting a significant portion of logic already included in built-in C/C++ preprocessors. In my opinion, the most we can do is to handle simple constants.
2. Macros usually exist in a separate header file. Our current implementation parses every source file independently, so a cpp file, where a macro is used, wouldn't know about a h file, where the macro is defined.

[jayconrod]

We probably don't need to fix anything in core Gazelle's merger package. When run in # gazelle:cc_group unit mode, gazelle_cc actually checks the existing rules and tries to assign source files appropriately.

I agree with @mateusz-olczyk, I don't think full macro expansion is really feasible: that's more complexity than I'd like to take on. gazelle_cc should be helpful in repos that follow common conventions, but for more complex cases, it will be necessary to manually write build files.