Decouple Report Generation from BuildResult Field Dependencies

[zewei-wang]

Currently, the to_dict() method in BuildResult from results.py sets the 'compiles' field to self.success instead of self.compiles. This is due to legacy reasons — report generation expects a 'compiles' field that implies not just the compiles, but also binary_exists and is_function_referenced.

This tight coupling between BuildResult internals and report generation logic is confusing and error-prone.

We propose to decouple the report generation logic from specific fields in BuildResult, potentially by introducing an abstraction layer or adapter. This would allow future refactoring of result classes without needing to update report logic each time.

Motivation:

• Clarify field semantics (success, compiles, etc.)
• Improve maintainability
• Avoid confusion for future developers
• Align with best practices (e.g., similar to OpenAPI generator decoupling patterns)

[Ekam219]

Hi @zewei-wang
Are there other modules (e.g., analysis tools) expecting the old compiles semantics from BuildResult.to_dict()?

Do report templates (HTML/JSON) need updates if they reference compiles?

[zewei-wang]

Hi @Ekam219
There are several components rely on this field:

1. Experiment Evaluation: The run_one_experiment.py file uses the compiles field for calculating build success rates.
2. Report Generation: In report/common.py, the AccumulatedResult class has a compiles field that's incremented based on build success rate:
3. Result Processing: Various parts of the codebase check the compiles field from the dictionary returned by to_dict().

I found the report/templates/benchmark.html and report/templates/index.html do reference the compiles field directly and would need updates if the field semantics change.

[zewei-wang]

@Ekam219
For decoupling approaches, what I recommended is applying Adapter Pattern:

1. Create an Adapter Layer: Introduce a ResultAdapter class that transforms internal result objects into standardized dictionaries for reporting.
2. Clarify Field Semantics:
   a. Rename the field in the dictionary to better reflect what it represents, e.g., build_success instead of compiles.
   b. Keep compiles for backward compatibility but mark it as deprecated.
3. Update Report Generation: Modify report generation code to use the adapter layer instead of directly calling to_dict().

What's your opinion?

[abohoss]

Hi @zewei-wang ,
I think it is a good idea to keep compiles for backward compatibility, but how do you suggest we handle the deprecation? Should we log warnings when compiles is accessed, or perhaps set a timeline for its complete removal?