[NFC][clang][test][asan] Make instantiation-depth-default.cpp a valid test case under asan and ubsan configs

[wdunicornpro]

Clang test instantiation-depth-default.cpp fails on Windows when built with ubsan due to extra warnings printed by the compiler:

File instantiation-depth-default.cpp Line 11: stack nearly exhausted; compilation time may suffer, and crashes due to stack overflow are likely

The test case was disabled for asan in 571a647 because of the extra stack usage. Since ubsan also increases stack usage, seems like the two configs should be treated uniformly.

On the other hand, we might be able to re-enable this test case for asan. During some preliminary testing on Windows, Linux, and macOS with the host compiler being as old as clang-10, the test case exited successfully if the stack-exhausted warnings are suppressed, though I haven't done exhaustive testing across platforms and clang versions. Any insights into whether this change will introduce any risks to existing buildbots is appreciated.

Enabling this test case for asan helps to improve our test coverage, but if it causes problems on any buildbot, marking it as unsupported for ubsan is also a viable solution.

[llvmbot]

@llvm/pr-subscribers-clang

Author: Duo Wang (wdunicornpro)

Changes

Clang test instantiation-depth-default.cpp fails on Windows when built with ubsan due to extra warnings printed by the compiler:

File instantiation-depth-default.cpp Line 11: stack nearly exhausted; compilation time may suffer, and crashes due to stack overflow are likely

The test case was disabled for asan in 571a647 because of the extra stack usage. Since ubsan also increases stack usage, seems like the two configs should be treated uniformly.

On the other hand, we might be able to re-enable this test case for asan. During some preliminary testing on Windows, Linux, and macOS with the host compiler being as old as clang-10, the test case exited successfully if the stack-exhausted warnings are suppressed, though I haven't done exhaustive testing across platforms and clang versions. Any insights into whether this change will introduce any risks to existing buildbots is appreciated.

Enabling this test case for asan helps to improve our test coverage, but if it causes problems on any buildbot, marking it as unsupported for ubsan is also a viable solution.

---

Full diff: https://github.com/llvm/llvm-project/pull/75254.diff

1 Files Affected:

• (modified) clang/test/SemaTemplate/instantiation-depth-default.cpp (+5-11)

diff --git a/clang/test/SemaTemplate/instantiation-depth-default.cpp b/clang/test/SemaTemplate/instantiation-depth-default.cpp
index f5835b86b3a385..362cf2b34aef51 100644
--- a/clang/test/SemaTemplate/instantiation-depth-default.cpp
+++ b/clang/test/SemaTemplate/instantiation-depth-default.cpp
@@ -1,18 +1,12 @@
-// RUN: %clang_cc1 -fsyntax-only -verify -ftemplate-backtrace-limit=2 %s
-//
-// FIXME: Disable this test when Clang was built with ASan, because ASan
-// increases our per-frame stack usage enough that this test no longer fits
-// within our normal stack space allocation.
-// UNSUPPORTED: asan
-//
+// RUN: %clang_cc1 -fsyntax-only -verify -ftemplate-backtrace-limit=2 -Wno-stack-exhausted %s
 // The default stack size on NetBSD is too small for this test.
 // UNSUPPORTED: system-netbsd
 
 template<int N, typename T> struct X : X<N+1, T*> {};
-// expected-error-re@11 {{recursive template instantiation exceeded maximum depth of 1024{{$}}}}
-// expected-note@11 {{instantiation of template class}}
-// expected-note@11 {{skipping 1023 contexts in backtrace}}
-// expected-note@11 {{use -ftemplate-depth=N to increase recursive template instantiation depth}}
+// expected-error-re@5 {{recursive template instantiation exceeded maximum depth of 1024{{$}}}}
+// expected-note@5 {{instantiation of template class}}
+// expected-note@5 {{skipping 1023 contexts in backtrace}}
+// expected-note@5 {{use -ftemplate-depth=N to increase recursive template instantiation depth}}
 
 X<0, int> x; // expected-note {{in instantiation of}}
 

[wdunicornpro]

ping: this helps to improve our test coverage under asan and ubsan configs.

[wdunicornpro]

@goussepi Do you have any thoughts on this?

[goussepi]

Is it possible to disable the stack-exhausted warning only if asan or ubsan? I am thinking we still might want to be able to detect stack usage regressions. It also helps documenting.
Not tested but maybe something like // RUN: %clang_cc1 -fsyntax-only -verify -ftemplate-backtrace-limit=2 %if {{asan|ubsan}} %{ -Wno-stack-exhausted %} %s
If not possible then LGTM, let me know if you need someone to commit for you.

[wdunicornpro]

Great point. Just pushed an update.

[wdunicornpro]

If the update looks good to you, could you help me commit it once the CI passes? Thanks!

[goussepi]

LGTM!

[hctim]

Hey folks, unfortunately this started supriously failing again on AArch64+ASan. So I've disabled it again under sanitizers (by reverting this patch): https://lab.llvm.org/buildbot/#/builders/239/builds/6363