[SERVER-56748] Investigate ways to avoid IWYU violations when using pre-compiled headers Created: 07/May/21 Updated: 27/Oct/23 Resolved: 27/Oct/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Andrew Morrow (Inactive) | Assignee: | [DO NOT ASSIGN] Backlog - Server Development Platform Team (SDP) (Inactive) |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Server Development Platform
|
| Participants: |
| Description |
|
One downside to using pre-compiled headers is that it can allow developers to not explicitly include the headers that their code really depends on, because the PCH header they are building with already includes that associated header. However, if the contents of the PCH change (perhaps we discover we can get better build performance by shuffling around what is in the PCH), that risks breaking compilation for files which have failed to honor include-what-you-use and are reliant on the pre-compiled header to paper over the issue. The issue is especially pernicious if we decide to generate the pre-compiled header by doing static analysis of header usage and relationships, since the pre-compiled header contents may change without user action. Overall, use of pre-compiled headers can result in a more fragile codebase. How can we ensure that a future deployment of pre-compiled headers avoids this pitfall? |