frontend: fix stack protector option logic

Commit 97e23896a9168132b6d36ca22ae1af10dd53d80d regressed this behavior
because it made target_util.supportsStackProtector *correctly*
notice which zig backend is being used to generate code, while the
logic calling that function *incorrectly assumed* that .zig code is being
compiled, when in reality it might be only C code being compiled.

This commit adjusts the option resolution logic for stack protector so
that it takes into account the zig backend only if there is a zig
compilation unit. A separate piece of logic checks whether clang
supports stack protector for a given target.

closes #18009
closes #18114
closes #18254

1 files changed, 7 insertions, 0 deletions

diff --git a/src/target.zig b/src/target.zig
index 04c25a5f0c..68777945a9 100644
--- a/src/target.zig
+++ b/src/target.zig
@@ -360,6 +360,13 @@ pub fn supportsStackProtector(target: std.Target, backend: std.builtin.CompilerB
     };
 }
 
+pub fn clangSupportsStackProtector(target: std.Target) bool {
+    return switch (target.cpu.arch) {
+        .spirv32, .spirv64 => return false,
+        else => true,
+    };
+}
+
 pub fn libcProvidesStackProtector(target: std.Target) bool {
     return !target.isMinGW() and target.os.tag != .wasi and !target.isSpirV();
 }