use a builtin enum for calling conventions instead of keywords

[andrewrk]

right now we have these keywords for function calling conventions:

• extern - must have C ABI. Also used to indicate C ABI on structs, enums, and unions.
• stdcallcc
• coldcc - cold calling convention is a thing, but this might be better off as an optimizer hint that the function is cold rather than specifying a calling convention. Currently the line is blurred.
• nakedcc - used for entry points like _start and when inline assembly defines the whole function.

If no calling convention is specified, then the calling convention is selected automatically (and currently defaults to the "fast calling convention" that LLVM has available.) Related issue: #105 when mixing automatic calling convention with specified calling conventions.
Any function can be exported, and if the calling convention of an exported function is not specified, then extern is chosen.

This proposal is to make a builtin enum:

pub const CC = enum {
    Auto,
    C,
    StdCall,
    Cold,
    Naked,
};

And instead of keywords, the fn keyword has optional calling convention specifier that matches align, like this:

export fn _start() callconv(builtin.CC.Naked) {
    // ...
}

If a calling convention is not specified, builtin.CC.Auto is the default. This is similar to the endianness in pointers proposal (see #649). When displaying a fn type, the calling convention only has to be specified if it is not builtin.CC.Auto.

Then it becomes easier to add reflection with @typeInfo(@typeOf(_start)). builtin.TypeInfo.CallingConvention should be pulled out into builtin.CallingConvention

Now that enum literals have arrived, this proposal is nicer:

export fn _start() callconv(.Naked) {
    // ...
}

[kyle-github]

I like this. Extra keywords can come back and bite you later.

Java has annotations. Nim has odd looking pragmas etc. It seems like a good idea to have some way to apply metadata/modifiers to things without cluttering up the keyword set.

I like where you are going with this.

[phase]

I like where this is going, but I don't see what other uses an enum annotation has for functions other than the calling convention. If you're going to introduce the notion of "you can annotate functions with enums", it better have more than one use case.

I think this can be applicable to other function attributes, such as noreturn and always_inline. Having something that encapsulates all of these would be cleaner than having separate systems for each subcategory of attribute.

[tiehuis]

This was something I was wondering about a little while back so I generally like the proposal.

I think it'd be wise as @phase mentioned on looking at the __attribute__ system in GCC/LLVM and what specific things are exposed. This system is pretty flexible and custom compilers (for example embedded gcc forks) add extra attributes necessary for their custom architectures if needed. I don't expect us to copy verbatim or anything, but just to keep in mind the extensibility as an example.

https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes

We already expose some of these at the language level (such as align) and others aren't applicable to zig, (i.e. non-null). I can see more attribute like functionality wanted in the future, in which case we would need a system to handle many attributes.

[andrewrk]

Extra keywords can come back and bite you later.

How so?

[kyle-github]

How so?

The more keywords you have the more you have to watch your variable names etc. If you have multiple namespaces (i.e. struct field names do not collide with other names), then it is not so bad. Translating C to C++ can be "fun" sometimes because of the reserved words.

[andrewrk]

In zig you can use @"keyword" to name any identifier that collides with a keyword. For example if you import an .h file that has a struct with a field called align (a zig keyword) then you can access it like this: foo.@"align"