In the context of caching clang invocations it is important to emit diagnostics in deterministic order;
the same clang invocation should result in the same diagnostic output.
rdar://100336989
 Differential  D135118  
[clang/Sema] Fix non-deterministic order for certain kind of diagnostics Authored by akyrtzi on Oct 3 2022, 5:11 PM. 
Details In the context of caching clang invocations it is important to emit diagnostics in deterministic order; rdar://100336989 
Diff Detail 
 
Unit Tests Event TimelineComment Actions LGTM. RemoveDecl does become more expensive but I don't have better solution. I am also wondering if as follow up we should add an option to VerifyDiagnosticConsumer to be location aware (so the diagnostics from a file is emitted in order) to prevent more problem like this. 
 Comment Actions Luckily AFAICT this is not a "hot" function. 
 Interesting idea! Something to keep in mind. 
 Comment Actions Remove PropertyDeclOrder parameter from the collectPropertiesToImplement functions. This is not necessary with PropertyMap becoming a MapVector. 
 Comment Actions FYI this caused a noticeable compile-time regression (about 0.4% geomean at -O0): http://llvm-compile-time-tracker.com/compare.php?from=92233159035d1b50face95d886901cf99035bd99&to=371883f46dc23f8464cbf578e2d12a4f92e61917&stat=instructions Comment Actions @nikic, it seems to have recovered (http://llvm-compile-time-tracker.com/compare.php?from=c49cde6467f9bf200640db763152a9dc7f009520&to=0456acbfb942f127359a8defd1b4f1f44420df3e&stat=instructions) let me know if you have concerns.  | ||||||||||||||||||
Can we use the existing PropertyDeclOrder instead of changing the map type? Or else get rid of the PO parameter to functions using PropertyMap if we keep the MapVector?