ability to include arbitrary C source text in @cImport blocks

[andrewrk]

Inspired by #1085 (comment)

Here's a use case:

const c = @cImport({
    @cInclude("curses.h");
    @cSource(
        \\static const int MY_A_STANDOUT = A_STANDOUT;
    );
});

// now we have access to A_STANDOUT even though it was
// unable to be automatically translated

This would be incredibly easy to implement. It's just a question of whether it's a good idea.

And then there's the follow-up question of, do we really need @cInclude, @cDefine, and @cUndef if we have the all-powerful @cSource?

[Akuli]

+1. This might be a particularly good solution to #1085 because it could be used to solve a bunch of other problems that nobody can think of yet. For example, if there's something that you can do in C but not in Zig, you could define a C function to do the thing and then call that from Zig (I think).

[andrewrk]

Note that you can already do something very similar with status quo:

const c = @cImport({
    @cInclude("curses.h");
    @cInclude("mycode.h");
});

mycode.h:

static const int MY_A_STANDOUT = A_STANDOUT;

[Akuli]

To @cInclude with a build.zig project, this can be added to build.zig:

    exe.addIncludeDir(".");

Now @cInclude("src/mycode.h") should work.

[daurnimator]

I think this feature would be really useful.

And then there's the follow-up question of, do we really need @cInclude, @cDefine, and @cUndef if we have the all-powerful @cSource?

We wouldn't need them as builtins, but could have them as functions in the std library instead.

[tauoverpi]

There are a hand full of languages that have taken this approach such as mercury, ats2 and would remove the need of creating separate C source files though I'd be concerned about debugger and editor support for the code contained. I guess a reason for would be the ability to replace C code function by function inline if you could embed all of it but that is also rather messy closer to the 40-60% replaced mark and would promote more C use in zig code as I see it.

[andrewrk]

Solved instead by #20630