ldc2.conf: Implement ~= concatenating operator [2] #4856
Conversation
Similarly to the D counterpart, ~= is used for concatenating arrays.
The new behavior of the config file can be summarized by:
- go through each section (in the order that they appear in the file)
- if the section matches the target triple go through each setting (in
the order that they appear in the section) and carry out the
assignments. `=` or `:` override the previous value, `~=` appends to
it (in the case of arrays).
This change can break some setups, mainly setups in which a section
contained the same key multiple times. For example:
```
default: {
switches = [ "A" ]
switches = [ "B" ]
}
```
Previously, the above config would pick the flag `A` but this has been
changed to picking the flag `B`. Given that the above is unintuitive
and users should have easily realized that some of their settings were
being ignored, this can be a justified change.
Signed-off-by: Andrei Horodniceanu <[email protected]>
Signed-off-by: Andrei Horodniceanu <[email protected]>
kinke
force-pushed
the
ldc2-conf-dir
branch
4 times, most recently
from
d5200d0 to
56a938a
Compare
|
After countless CI attempts, it looks like the combination of an older host LDC (v1.35.0 with LLVM 16, or v1.37.0 with LLVM 17 - the macos-13 Xcode is LLVM-16 based), incl. skipping the bootstrap compiler build (as for macOS arm64 already), and disabling mimalloc (apparently causing the dreaded |
kinke
force-pushed
the
ldc2-conf-dir
branch
2 times, most recently
from
f6fa46a to
e0c7313
Compare
|
Okay, with LDC v1.35.0 as host/bootstrap compiler, LTO can be restored without breaking |
|
From my little testing it was way easier to make the bug disappear. Either:
I did stop testing once I saw that |
|
Yeah macOS CI is a bit of a black box, very fragile, and last time we had a similar problem (on arm64 back then), nobody could reproduce all the issues ( Edit: E.g., the current setup in master requires LTO for the macOS x86_64 build (!). Disabling it makes the built compiler useless ( |
|
I've tried -flto=thin and it seems fine. If the environment is so poor I would rather drop optimizations and go with a minimalist flag set that doesn't produce broken executables but not like I have any setup to run this on and, from your comment, it seems that not even if you have a device can you actually debug these issues. |
Oh wow, that's interesting.
So far noone has complained, so I guess they are working and sufficiently (CI-)tested. But yeah, it's definitely not a comfortable feeling. As dropping LTO breaks the build (with mimalloc at least), dropping optimizations wasn't really an option so far. But the C++/D interop LTO is IMO quite important, to inline little one-liners etc., so I'd like to keep that. I don't think PGO was ever a problem. I'm going to test mimalloc once more; disabling that for both macOS builds (no problems on arm64 so far) is IMO an option on the table, to be on the safer side. I'm also wondering if there were some breaking macOS-only changes in recent LLVM versions, making mixing bitcode objects of different clang/LDC host compiler LLVM versions problematic. |
This is way out of my league in terms of theory but I did test clang-19 once and I got the same issue. |
|
Alright, with LDC v1.35.0 and restored LTO, mimalloc can be restored too without breaking |
kinke
force-pushed
the
ldc2-conf-dir
branch
2 times, most recently
from
5f8c48a to
ae83835
Compare
|
@the-horo: What do you think about the 3rd commit here ('somewhat simplify driver/configfile.d')? I've worked on that before getting an idea of where you wanna go with that config directory. In the case of multiple .conf files and multiple consecutive |
|
It seems alright. On its own the changes look good and I like what you did. Sure, it would require me to do some more changes when (if) the directory option is merged but I don't think they would be so many that your few changes here really affect it. I think discussing about it would take more time then implementing it. Passing the array as a When I first wrote my changes I actually wanted to combine the two array merging code paths (the one in |
No description provided.