Upgrade front-end & libs to v2.085.0

[kinke]

No description provided.

[kinke]

Union regression: dlang/dmd#9288

[kinke]

Still to do:

• dcompute lit tests fail, due to RTInfo template from object.d (with unsupported global variable) somehow being instantiated.
• Objective-C related changes for Mac with according dmd-testsuite failures.
• druntime-test-init_fini failure for Mac, probably trivial to fix.

Should be green otherwise.

[kinke]

Besides dcompute and ObjC failures, there's a new druntime standalone test (GC) which fails on both Linux and Mac with shared druntime.

[rainers]

Besides dcompute

Can the definition of RTInfo be versioned out for dcompute? I suspect it doesn't help to have precise GC info with that target.

there's a new druntime standalone test (GC) which fails on both Linux and Mac with shared druntime.

The GC tests rebuild a couple of modules and expect to replace the original ones from the static library. I doubt that works with the runtime in a shared library.

[kinke]

Thx for the hints, Rainer.

Can the definition of RTInfo be versioned out for dcompute?

AFAIK, the dcompute specifics are per-module (i.e., you can compile normal modules alongside dcompute modules in one run), so there's no predefined version for dcompute. I guess the automatic RTInfo instantiation (by the front-end) would need to be skipped for aggregates defined in dcompute modules.

The module replacement not working with shared libs seems to make perfect sense.

[thewilsonator]

AFAIK, the dcompute specifics are per-module (i.e., you can compile normal modules alongside
dcompute modules in one run), so there's no predefined version for dcompute. I guess the automatic
RTInfo instantiation (by the front-end) would need to be skipped for aggregates defined in
dcompute modules.

That is correct, but not quite the whole story, can designate a module for both the host and device. There are a number of ways this could be fixed:
Add a constraint to the RTInfo template and ignore in the compiler if RTInfo!T fails to instantiate
Put all the RTInfo!T in their own LLVM IR module.
Simply don't generate `RTInfo symbols in the dcompute code generator.

[kinke]

[Just for the record, I won't tackle the RTInfo thing myself, in case I'm expected to do every little thing myself.]

[rainers]

Add a constraint to the RTInfo template and ignore in the compiler if RTInfo!T fails to instantiate

It's already not generated by the frontend if the template is not defined, so disabling it with version(dcompute_or_whatever) {} else template RTInfo(T)... should suffice.