Zig c++ does not respect -x flag #10915

WardBrian · 2022-02-17T15:46:35Z

Zig Version

0.10.0-dev.760+1a84c23d6

Steps to Reproduce

Save the following to a file with an extension which is not generally used for C++, such as test.foo or test.hpp:

// test

int main(void){
  return 1;
}

Compile with

$ zig c++ -x c++ test.foo

Expected Behavior

If the file is named test.cpp, it compiles just fine. I would expect that -x c++ to emulate this behavior.

Actual Behavior

The zig c++ command fails:

ld.lld: error: test.foo:1: unknown directive: //
>>> // test
>>> ^

The text was updated successfully, but these errors were encountered:

kassane · 2022-02-17T19:17:59Z

The zig did not recognize these extensions. hpp or foo

https://github.com/ziglang/zig/blob/master/src/Compilation.zig#L4170-L4201

WardBrian · 2022-02-17T20:19:35Z

Correct. Maybe I should have noted that gcc/clang do not exhibit this issue, there if -x c++ is specified the file can have any extension (or none at all) and be treated as a .cpp would

uhthomas · 2022-07-13T19:03:19Z

Ran into this today, really confusing.

capnproto uses the 'c++' file extension, which is looks like zig doesn't support.

zig/src/Compilation.zig

Line 3938 in 1fee9ea

if (ext == .cpp) {

Could support be added for common c++ extensions?

uhthomas · 2022-07-13T19:05:42Z

Looks like there has been some groundwork for this here:

zig/src/Compilation.zig

Line 4349 in 1fee9ea

pub fn hasCppExt(filename: []const u8) bool {

, but other code like the previously linked would need to use this. (and add '.c++').

uhthomas · 2022-07-13T19:07:11Z

Bazel has a nice list of extensions: https://docs.bazel.build/versions/main/be/c-cpp.html#cc_library

Permitted srcs file types:

C and C++ source files: .c, .cc, .cpp, .cxx, .c++, .C
C and C++ header files: .h, .hh, .hpp, .hxx, .inc, .inl, .H
Assembler with C preprocessor: .S
Archive: .a, .pic.a
"Always link" library: .lo, .pic.lo
Shared library, versioned or unversioned: .so, .so.version
Object file: .o, .pic.o

WardBrian · 2022-11-03T19:49:44Z

Bazel has a nice list of extensions

To clarify, while a partial solution to this is to expand the list of automatically recognized extensions, that is sort of orthogonal to the immediate issue of the -x flag. This is supposed to treat the file as the specified language even if it has a contradictory extension, or an extension nobody has ever seen before

This commit adds support for "-x language" for a couple of hand-picked supported languages. There is no reason the list of supported languages to not grow (e.g. add "c-header"), but I'd like to keep it small at the start. Alternative 1 ------------- I first tried to add a new type "Language", and then add that to the `CSourceFile`. But oh boy what a change it turns out to be. So I am keeping myself tied to FileExt and see what you folks think. Alternative 2 ------------- I tried adding `Language: ?[]const u8` to `CSourceFile`. However, the language/ext, whatever we want to call it, still needs to be interpreted in the main loop: one kind of handling for source files, other kind of handling for everything else. Test case --------- *standalone.c* #include <iostream> int main() { std::cout << "elho\n"; } Compile and run: $ ./zig run -x c++ -lc++ standalone.c elho $ ./zig c++ -x c++ standalone.c -o standalone && ./standalone elho Fixes ziglang#10915

sandhose · 2022-12-16T10:51:56Z

I think I'm hitting this issue (at least a similar one) when trying to build the psm Rust crate with cargo-zigbuild. The former has assembly for each arch, and the latter is just a wrapper around zig cc to use with rustc.

It fails to build src/arch/aarch_aapcs64.s with the following flags:

zig cc
  -target aarch64-linux-gnu
  -g
  -O0
  -ffunction-sections
  -fdata-sections 
  -fPIC 
  -gdwarf-4 
  -fno-omit-frame-pointer 
  -Wall
  -Wextra
  -xassembler-with-cpp
  -DCFG_TARGET_OS_linux
  -DCFG_TARGET_ARCH_aarch64
  -DCFG_TARGET_ENV_gnu
  -o /tmp/aarch_aapcs64.o
  -c src/arch/aarch_aapcs64.s

It fails with the following logs: (click to expand)

zig: warning: '-x assembler-with-cpp' after last input file has no effect [-Wunused-command-line-argument]
zig: warning: argument unused during compilation: '-ffunction-sections' [-Wunused-command-line-argument]
zig: warning: argument unused during compilation: '-D __GLIBC_MINOR__=19' [-Wunused-command-line-argument]
zig: warning: argument unused during compilation: '-fdata-sections' [-Wunused-command-line-argument]
zig: warning: argument unused during compilation: '-D CFG_TARGET_OS_linux' [-Wunused-command-line-argument]
zig: warning: argument unused during compilation: '-D CFG_TARGET_ARCH_aarch64' [-Wunused-command-line-argument]
zig: warning: argument unused during compilation: '-D CFG_TARGET_ENV_gnu' [-Wunused-command-line-argument]
src/arch/aarch_aapcs64.s:29:1: error: unrecognized instruction mnemonic
GLOBL(rust_psm_stack_direction)
^
src/arch/aarch_aapcs64.s:31:1: error: unrecognized instruction mnemonic
TYPE(rust_psm_stack_direction)
^
src/arch/aarch_aapcs64.s:32:35: error: unexpected token in argument list
FUNCTION(rust_psm_stack_direction):
                                  ^
src/arch/aarch_aapcs64.s:33:1: error: unexpected token at start of statement
/* extern "C" fn() -> u8 */
^
src/arch/aarch_aapcs64.s:35:18: error: expected compatible register or logical immediate
    orr w0, wzr, #STACK_DIRECTION_DESCENDING
                 ^
src/arch/aarch_aapcs64.s:38:30: error: expected ')'
SIZE(rust_psm_stack_direction,.rust_psm_stack_direction_end)
                             ^
src/arch/aarch_aapcs64.s:38:5: error: invalid operand
SIZE(rust_psm_stack_direction,.rust_psm_stack_direction_end)
    ^
src/arch/aarch_aapcs64.s:42:1: error: unrecognized instruction mnemonic
GLOBL(rust_psm_stack_pointer)
^
src/arch/aarch_aapcs64.s:44:1: error: unrecognized instruction mnemonic
TYPE(rust_psm_stack_pointer)
^
src/arch/aarch_aapcs64.s:45:33: error: unexpected token in argument list
FUNCTION(rust_psm_stack_pointer):
                                ^
src/arch/aarch_aapcs64.s:46:1: error: unexpected token at start of statement
/* extern "C" fn() -> *mut u8 */
^
src/arch/aarch_aapcs64.s:51:28: error: expected ')'
SIZE(rust_psm_stack_pointer,.rust_psm_stack_pointer_end)
                           ^
src/arch/aarch_aapcs64.s:51:5: error: invalid operand
SIZE(rust_psm_stack_pointer,.rust_psm_stack_pointer_end)
    ^
src/arch/aarch_aapcs64.s:55:1: error: unrecognized instruction mnemonic
GLOBL(rust_psm_replace_stack)
^
src/arch/aarch_aapcs64.s:57:1: error: unrecognized instruction mnemonic
TYPE(rust_psm_replace_stack)
^
src/arch/aarch_aapcs64.s:58:33: error: unexpected token in argument list
FUNCTION(rust_psm_replace_stack):
                                ^
src/arch/aarch_aapcs64.s:59:1: error: unexpected token at start of statement
/* extern "C" fn(r0: usize, r1: extern "C" fn(usize), r2: *mut u8) */
^
src/arch/aarch_aapcs64.s:65:28: error: expected ')'
SIZE(rust_psm_replace_stack,.rust_psm_replace_stack_end)
                           ^
src/arch/aarch_aapcs64.s:65:5: error: invalid operand
SIZE(rust_psm_replace_stack,.rust_psm_replace_stack_end)
    ^
src/arch/aarch_aapcs64.s:69:1: error: unrecognized instruction mnemonic
GLOBL(rust_psm_on_stack)
^
src/arch/aarch_aapcs64.s:71:1: error: unrecognized instruction mnemonic
TYPE(rust_psm_on_stack)
^
src/arch/aarch_aapcs64.s:72:28: error: unexpected token in argument list
FUNCTION(rust_psm_on_stack):
                           ^
src/arch/aarch_aapcs64.s:73:1: error: unexpected token at start of statement
/* extern "C" fn(r0: usize, r1: usize, r2: extern "C" fn(usize, usize), r3: *mut u8) */
^
src/arch/aarch_aapcs64.s:91:23: error: expected ')'
SIZE(rust_psm_on_stack,.rust_psm_on_stack_end)
                      ^
src/arch/aarch_aapcs64.s:91:5: error: invalid operand
SIZE(rust_psm_on_stack,.rust_psm_on_stack_end)
    ^

It worked well with zig 0.9.1, but broke with 0.10.0. Interestingly, renaming the file (mv src/arch/aarch_aapcs64.s src/arch/aarch_aapcs64.S) makes it work, but with the same warning about the "-x after last input".

This commit adds support for "-x language" for a couple of hand-picked supported languages. There is no reason the list of supported languages to not grow (e.g. add "c-header"), but I'd like to keep it small at the start. Alternative 1 ------------- I first tried to add a new type "Language", and then add that to the `CSourceFile`. But oh boy what a change it turns out to be. So I am keeping myself tied to FileExt and see what you folks think. Alternative 2 ------------- I tried adding `Language: ?[]const u8` to `CSourceFile`. However, the language/ext, whatever we want to call it, still needs to be interpreted in the main loop: one kind of handling for source files, other kind of handling for everything else. Test case --------- *standalone.c* #include <iostream> int main() { std::cout << "elho\n"; } Compile and run: $ ./zig run -x c++ -lc++ standalone.c elho $ ./zig c++ -x c++ standalone.c -o standalone && ./standalone elho Fixes ziglang#10915

motiejus · 2022-12-16T12:11:55Z

It worked well with zig 0.9.1, but broke with 0.10.0. Interestingly, renaming the file (mv src/arch/aarch_aapcs64.s src/arch/aarch_aapcs64.S) makes it work, but with the same warning about the "-x after last input".

Can you try with #13544? I just added it to understand assembler-with-cpp.

sandhose · 2022-12-16T16:18:47Z

It worked well with zig 0.9.1, but broke with 0.10.0. Interestingly, renaming the file (mv src/arch/aarch_aapcs64.s src/arch/aarch_aapcs64.S) makes it work, but with the same warning about the "-x after last input".

Can you try with #13544? I just added it to understand assembler-with-cpp.

@motiejus I built your PR and tried ; it fails with the following error:

$ /tmp/zig/build/stage3/bin/zig cc -target aarch64-linux-gnu -g -O0 -ffunction-sections -fdata-sections -fPIC -gdwarf-4 -fno-omit-frame
-pointer -Wall -Wextra -xassembler-with-cpp -DCFG_TARGET_OS_linux -DCFG_TARGET_ARCH_aarch64 -DCFG_TARGET_ENV_gnu -o /tmp/aarch_aapcs64.o -c src/arch/aar
ch_aapcs64.s
error: language 'assembly' is unsupported in this context

To reproduce:

git clone https://github.com/rust-lang/stacker
cd stacker/psm
zig cc -target aarch64-linux-gnu -g -O0 -ffunction-sections -fdata-sections -fPIC -gdwarf-4 -fno-omit-frame-pointer -Wall -Wextra -xassembler-with-cpp -DCFG_TARGET_OS_linux -DCFG_TARGET_ARCH_aarch64 -DCFG_TARGET_ENV_gnu -o /tmp/aarch_aapcs64.o -c src/arch/aarch_aapcs64.s

This commit adds support for "-x language" for a couple of hand-picked supported languages. There is no reason the list of supported languages to not grow (e.g. add "c-header"), but I'd like to keep it small at the start. Alternative 1 ------------- I first tried to add a new type "Language", and then add that to the `CSourceFile`. But oh boy what a change it turns out to be. So I am keeping myself tied to FileExt and see what you folks think. Alternative 2 ------------- I tried adding `Language: ?[]const u8` to `CSourceFile`. However, the language/ext, whatever we want to call it, still needs to be interpreted in the main loop: one kind of handling for source files, other kind of handling for everything else. Test case --------- *standalone.c* #include <iostream> int main() { std::cout << "elho\n"; } Compile and run: $ ./zig run -x c++ -lc++ standalone.c elho $ ./zig c++ -x c++ standalone.c -o standalone && ./standalone elho Fixes ziglang#10915

This commit adds support for "-x language" for a couple of hand-picked supported languages. There is no reason the list of supported languages to not grow (e.g. add "c-header"), but I'd like to keep it small at the start. Alternative 1 ------------- I first tried to add a new type "Language", and then add that to the `CSourceFile`. But oh boy what a change it turns out to be. So I am keeping myself tied to FileExt and see what you folks think. Alternative 2 ------------- I tried adding `Language: ?[]const u8` to `CSourceFile`. However, the language/ext, whatever we want to call it, still needs to be interpreted in the main loop: one kind of handling for source files, other kind of handling for everything else. Test case --------- *standalone.c* #include <iostream> int main() { std::cout << "elho\n"; } Compile and run: $ ./zig run -x c++ -lc++ standalone.c elho $ ./zig c++ -x c++ standalone.c -o standalone && ./standalone elho Fixes #10915

WardBrian added the bug Observed behavior contradicts documented or intended behavior label Feb 17, 2022

Vexu added frontend Tokenization, parsing, AstGen, Sema, and Liveness. zig cc Zig as a drop-in C compiler feature labels Feb 17, 2022

Vexu added this to the 0.10.0 milestone Feb 17, 2022

andrewrk added the enhancement Solving this issue will likely involve adding new logic or components to the codebase. label Aug 26, 2022

andrewrk modified the milestones: 0.10.0, 0.11.0 Aug 26, 2022

motiejus mentioned this issue Sep 8, 2022

zig cc does not respect - to read from stdin #12777

Closed

motiejus mentioned this issue Nov 14, 2022

zig run/cc: recognize "-x language" #13544

Merged

andrewrk closed this as completed in #13544 Jan 14, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

Zig c++ does not respect -x flag #10915

Zig c++ does not respect -x flag #10915

WardBrian commented Feb 17, 2022

kassane commented Feb 17, 2022 •

edited

Loading

Uh oh!

WardBrian commented Feb 17, 2022

Uh oh!

uhthomas commented Jul 13, 2022

Uh oh!

uhthomas commented Jul 13, 2022

Uh oh!

uhthomas commented Jul 13, 2022

Uh oh!

WardBrian commented Nov 3, 2022

Uh oh!

sandhose commented Dec 16, 2022 •

edited

Loading

Uh oh!

motiejus commented Dec 16, 2022

Uh oh!

sandhose commented Dec 16, 2022

Uh oh!

Uh oh!

Zig c++ does not respect -x flag #10915

Zig c++ does not respect -x flag #10915

Comments

WardBrian commented Feb 17, 2022

Zig Version

Steps to Reproduce

Expected Behavior

Actual Behavior

kassane commented Feb 17, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

WardBrian commented Feb 17, 2022

Uh oh!

uhthomas commented Jul 13, 2022

Uh oh!

uhthomas commented Jul 13, 2022

Uh oh!

uhthomas commented Jul 13, 2022

Uh oh!

WardBrian commented Nov 3, 2022

Uh oh!

sandhose commented Dec 16, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

motiejus commented Dec 16, 2022

Uh oh!

sandhose commented Dec 16, 2022

Uh oh!

kassane commented Feb 17, 2022 •

edited

Loading

sandhose commented Dec 16, 2022 •

edited

Loading