[Issue 24867] Wrong deprecation warning of @system variable usage under CTFE

[d-bugmail at puremagic.com]

https://issues.dlang.org/show_bug.cgi?id=24867

--- Comment #7 from Luís Ferreira <contact at lsferreira.net> ---
> No example you gave here justifies the outer `align(1)`

It does. Considering our tracing system:

```
align(1) struct TracesMetadata {
align(1): 
    const char* name;
    int b = 2;
}

@section(".traces.metadata") @assumeUsed
static immutable Bar bar1 = Bar("foo1");
@section(".traces.metadata") @assumeUsed
static immutable Bar bar2 = Bar("foo2");
```

We need both alignment specifiers in order for the section to be fully packed
across two of those constants. These items inside the traces metadata section
shouldn't have any alignment, or, very specific alignment. The metadata is very
much like DWARF `.debug_info`, not supposed to be used at runtime, so
everything packed is desired to save space in the binary. Sure you can specify
the alignment when you define the constant, but this is here to prevent
forgetting and then having issues. 

These types are never ever used at the runtime of the program.

I can't give examples of filesystem, because I don't known enough about it to
claim a point. Outer alignment, sure, it makes less sense, but it serves a
purpose.

The packed outer alignment also makes sense in the context of embedded systems
firmware where specific data types that are also often used inside sections are
very space constraint (and not performance critical).

If you tell me a safety issue using these at the compile-time, sure, but
forbidding it to be used within a safe context when its actually 100% safe, for
me, it has no sense.

Btw, pedantic-wise, we shouldn't also specifically well-define this whole error
at all, because this is only unsafe because of limitations or otherwise
impractical behaviour of the druntime GC. I don't know how we phrase this in
spec, but we should tell its implementation defined. If we take a look at DMD
implementation, there's no reason to not allow it, because all the situations I
showed above are 100% safe.

--