Tailor should skip sources for which inference cannot extract symbol information

[stuhood]

To improve the onboarding experience, we should consider having the tailor rules for inference languages actually attempt to run inference on the files for which it is generating targets, and skip generating (possibly with a warning) if those files fail to parse.

This would be particularly helpful for files which (based on their extension) should be valid code, but which are instead templates or resources to be used by codegen or tests (another heuristic for this might be to use filenames: like src/resources on the JVM), etc.

[Eric-Arellano]

one thing which would almost work would be to have tailor execute all of its changes, and then execute a fallible validation step on the target afterward,

I suspect it's much easier to 100% localize the validation. Trying to generalize sounds like a leaky abstraction & over-eager generalization.

[stuhood]

I've broken out the following issues:

1. 4 / 14 failures - tailor should not create targets for unparseable requirements.txt/pyproject.toml/etc. #15734
2. 2 / 14 failures - tailor should not create go_package targets without a valid owning go.mod #15735
3. 1 / 14 failures - Failure to analyze Java sources with unicode in their names #15736
   • (imo, slightly higher priority because it's a bit of a broken window)

I believe that we should leave this ticket open to cover sources themselves. They are a slightly more expensive problem to solve: to actually parse source files for this validation, you'd need to run the dependency extraction processes, but likely with different cache keys than they would usually have.