Bugzilla

This sounds super useful!

I believe :sg has been using https://github.com/aras-p/ClangBuildAnalyzer for analysis as the source of information for his bugs improving header inclusions, etc.

I've definitely thinking it would be useful to be able to have explicit analysis metadata about files/compilation units.  I'd mainly been thinking that the crossref process would aggregate/derive this metadata for files as part of the process of cross-referencing[1], with us introducing some new [symbol scheme](https://github.com/mozsearch/mozsearch/blob/master/docs/analysis.md#symbols) that corresponds to files.  This could make sense for this scenario given that to implement bug 1418001 we'd likely want an analysis record that lines up directly with the include tokens rather as part of a separate metadata store.  This should also ideally work with merge-analyses in a reasonably straightforward way.

That said, we totally do now have an infrastructure for per-file info that is totally distinct from the analysis data as part of the test info and coverage info enhancements.  If we want the info to live separately or it's just most pragmatic to land what you already have, it's just a question of modifying https://github.com/mozsearch/mozsearch/blob/master/tools/src/bin/derive-per-file-info.rs and https://github.com/mozsearch/mozsearch/blob/master/tools/src/bin/output-file.rs to propagate and emit the data, respectively, if it makes sense to integrate with that pipeline.  output-file could also just pull the data directly from the __INCLUDEINFO__ structure, but the upside to the centralized per-file JSON (and single aggregating per-file super JSON) is it's already JSON formatted stuff that we could start serving up from router.py/its successor without any special logic.

1: In the fancy branch I do have it propagating/deriving information and it seems like it would be reasonably straightforward to similarly make sure that the includer and includee can know about each other.

This sounds super useful!

I believe :sg has been using https://github.com/aras-p/ClangBuildAnalyzer for analysis as the source of information for his bugs improving header inclusions, etc.

I've definitely thinking it would be useful to be able to have explicit analysis metadata about files/compilation units.  I'd mainly been thinking that the crossref process would aggregate/derive this metadata for files as part of the process of cross-referencing[1], with us introducing some new [symbol scheme](https://github.com/mozsearch/mozsearch/blob/master/docs/analysis.md#symbols) that corresponds to files.  This could make sense for this scenario given that to implement bug 1418001 we'd likely want an analysis record that lines up directly with the include tokens rather as part of a separate metadata store.  This should also ideally work with merge-analyses in a reasonably straightforward way.

That said, we totally do now have an infrastructure for per-file info that is totally distinct from the analysis data as part of the test info and coverage info enhancements.  If we want the info to live separately or it's just most pragmatic to land what you already have, it's just a question of modifying https://github.com/mozsearch/mozsearch/blob/master/tools/src/bin/derive-per-file-info.rs and https://github.com/mozsearch/mozsearch/blob/master/tools/src/bin/output-file.rs to propagate and emit the data, respectively, if it makes sense to integrate with that pipeline.  output-file could also just pull the data directly from the `__INCLUDEINFO__` structure, but the upside to the centralized per-file JSON (and single aggregating per-file super JSON) is it's already JSON formatted stuff that we could start serving up from router.py/its successor without any special logic.

1: In the fancy branch I do have it propagating/deriving information and it seems like it would be reasonably straightforward to similarly make sure that the includer and includee can know about each other.

This sounds super useful!

I believe :sg has been using https://github.com/aras-p/ClangBuildAnalyzer for analysis as the source of information for his bugs improving header inclusions, etc.

I've definitely thinking it would be useful to be able to have explicit analysis metadata about files/compilation units.  I'd mainly been thinking that the crossref process would aggregate/derive this metadata for files as part of the process of cross-referencing[1], with us introducing some new [symbol scheme](https://github.com/mozsearch/mozsearch/blob/master/docs/analysis.md#symbols) that corresponds to files.  This could make sense for this scenario given that to implement bug 1418001 we'd likely want an analysis record that lines up directly with the include tokens rather than as part of a separate metadata store.  This should also ideally work with merge-analyses in a reasonably straightforward way.

That said, we totally do now have an infrastructure for per-file info that is totally distinct from the analysis data as part of the test info and coverage info enhancements.  If we want the info to live separately or it's just most pragmatic to land what you already have, it's just a question of modifying https://github.com/mozsearch/mozsearch/blob/master/tools/src/bin/derive-per-file-info.rs and https://github.com/mozsearch/mozsearch/blob/master/tools/src/bin/output-file.rs to propagate and emit the data, respectively, if it makes sense to integrate with that pipeline.  output-file could also just pull the data directly from the `__INCLUDEINFO__` structure, but the upside to the centralized per-file JSON (and single aggregating per-file super JSON) is it's already JSON formatted stuff that we could start serving up from router.py/its successor without any special logic.

1: In the fancy branch I do have it propagating/deriving information and it seems like it would be reasonably straightforward to similarly make sure that the includer and includee can know about each other.