hnrklssn wrote: This test is asserting that the trace graph is: ``` ExecuteCompiler | Frontend (test.c) | | ParseDeclarationOrFunctionDefinition (test.c:2:1) | | | isIntegerConstantExpr (<test.c:3:18>) | | | EvaluateKnownConstIntCheckOverflow (<test.c:3:18>) | PerformPendingInstantiations ```
We would have to relax it to also accept: ``` ExecuteCompiler | Frontend (test.c) | | ParseDeclarationOrFunctionDefinition (test.c:2:1) | | | EvaluateKnownConstIntCheckOverflow (<test.c:3:18>) | | | | isIntegerConstantExpr (<test.c:3:18>) | PerformPendingInstantiations ``` That's basically half the test case; what is the test case actually testing at that point that isn't already covered by the other tests? FWIW, when running the test 213 times on my machine I got 14 failures. That's a 6.5% failure rate: with only 2 retries you're down to 0.028%. It may still be flaky, but it's a test that takes ~1ms to run so the retries don't really cost all that much and can easily reduce the total flakiness rate by orders of magnitude. If we don't want to add retries, here are some other strawman options: - move from "X" events to pairs of begin/end events. This would basically double the output size however. - add a custom field with the entry stack depth. This wouldn't necessarily help third party visualisers, but would disambiguate the nesting structure for the purposes of these tests. - remove this test case entirely https://github.com/llvm/llvm-project/pull/138613 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
