Any `export` called `@""` is not exported

Zig Version

0.10.0-dev.2836+2360f8c49

Steps to Reproduce

Exporting anything identified by @"" exports nothing. on wasm32, x86_64, aarch64, probably all platforms.

export const @"": u16 = 12345;

Expected Behavior

@"" is rejected as an identifier for exports. It's simply not representable. What is the compiler supposed to call it?

Additionally, any opinions on disallowing @"" as an identifier in general? Are there any use cases? It is inexpressive. What is @"" even supposed to mean? Disallowing it altogether might be more consistent. (nvm, I don't think this is good actually, could be missing some edge cases etc.)

See also: #8262

Actual Behavior

stage1

Exporting anything identified by @"" exports nothing. on wasm32, x86_64, aarch64, probably all platforms.

export const @"": u16 = 12345;

$ zig build-lib -dynamic -target wasm32-freestanding -OReleaseSmall --strip x.zig; wasm2wat x.wasm
(module
  (memory (;0;) 1)
  (global (;0;) (mut i32) (i32.const 65536))
  (export "memory" (memory 0)))

12345 is nowhere to be found. Change @"" to @"x" and it's included.

$ zig build-lib -dynamic -target x86_64-freestanding -OReleaseSmall --strip x.zig -femit-asm; cat x.s
	.text
	.intel_syntax noprefix
	.file	"x"
	.section	".note.GNU-stack","",@progbits

12345 is nowhere to be found. Change @"" to @"x" and it's included.

stage2

$ zig build-lib -dynamic -target wasm32-freestanding -OReleaseSmall --strip -fno-stage1 x.zig; wasm2wat x.wasm
(module
  (memory (;0;) 2)
  (global (;0;) (mut i32) (i32.const 65536))
  (global (;1;) i32 (i32.const 65536))
  (export "memory" (memory 0))
  (export "test." (global 1))
  (data (;0;) (i32.const 65536) "90"))

In stage2 it is somehow exported as "test.", which is very weird.
Additionally if you add -femit-asm to this one, it doesn't work. It works without -fno-stage1.

All this is unexpected.

Would this fix it?

diff --git a/src/AstGen.zig b/src/AstGen.zig
index 522193d9a..819c227fe 100644
--- a/src/AstGen.zig
+++ b/src/AstGen.zig
@@ -7291,6 +7291,8 @@ fn builtinCall(
             switch (node_tags[params[0]]) {
                 .identifier => {
                     const ident_token = main_tokens[params[0]];
+                    if ((try astgen.identifierTokenString(ident_token)).len == 0)
+                        return astgen.failNode(params[0], "unable to export empty identifier", .{});
                     decl_name = try astgen.identAsString(ident_token);

                     var s = scope;
diff --git a/test/cases/compile_errors/stage2/empty_export_identifier.zig b/test/cases/compile_errors/stage2/empty_export_identifier.zig
new file mode 100644
index 000000000..20431de4d
--- /dev/null
+++ b/test/cases/compile_errors/stage2/empty_export_identifier.zig
@@ -0,0 +1,7 @@
+export const @"": u8 = 5;
+
+// error
+// backend=stage2
+// target=native
+//
+// :1:8: error: unable to export empty identifier

There's probably a better solution but I really struggle to test any changes with either zig build test-compare-output or using a temporary file... I think before I try to fix this myself I'll wait for the compiler development experience to improve.

[Vexu]

I think empty identifiers should be disallowed in general just like #8262 plans to forbid null bytes in them.

Ah, okay, yeah maybe that is for the better. When I said "I don't think this is good actually" I thought of some edge cases similarly to how we have u0 and if maybe the identifier is generated or something but really I just can't think of an actual use case so it's probably for the best to just disallow it, along with null bytes in them.

@Vexu I feel like both of these changes could maybe just go into tokenizer.zig right? Maybe I could try that because it's part of the std so it's much easier to test.

[Vexu]

I'd prefer to have them in AstGen since they don't prevent tokenizing and parsing.