Revert "Split core.thread.fiber to package.d and base.d"

[ibuclaw]

Reverts #16695

Splitting cannot be done unless the Fiber detection code is either:

• Duplicated between both base and fiber modules
• Isolated to a common module (can't use version anymore)

https://github.com/dlang/dmd/blob/master/druntime/src/core/thread/fiber/package.d#L22-L165

Without, the static if (__traits(compiles, ucontext_t)) condition in both modules resolves to different values, causing build failures on ucontext_t targets.

[dlang-bot]

Thanks for your pull request, @ibuclaw!

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + dmd#16850"

[thewilsonator]

Isolated to a common module

This would be the preferred choice here.

[denizzzka]

@ibuclaw why reverting instead of fixing?

~2 months no one noticed this problem

[ibuclaw]

Isolated to a common module

This would be the preferred choice here.

I didn't look too deeply, but it's a chance that won't work either - what is allowed inside static if vs. version.

[ibuclaw]

@ibuclaw why reverting instead of fixing?

~2 months no one noticed this problem

No one thought to test, it shouldn't be down on me to check all permutations on a regular basis.

[denizzzka]

Without, the static if (__traits(compiles, ucontext_t)) condition in both modules resolves to different values

What is reason why this happens?

For example, maybe Phobos library binary are built on system where there is ucontext_t available and then application program is compiled on system where is no ucontext_t?

[ibuclaw]

Without, the static if (__traits(compiles, ucontext_t)) condition in both modules resolves to different values

What is reason why this happens?

For example, maybe Phobos library binary are built on system where there is ucontext_t available and then application program is compiled on system where is no ucontext_t?

No, the Fiber Platform Detection code needs to exist in all modules that any fiber package gets split into.

[denizzzka]

But this is not a "code" - it is only executed during compilation on platforms which provides ucontext_t facility

I.e., I don't understand nature of the error that is occurring here

[ibuclaw]

But this is not a "code" - it is only executed during compilation on platforms which provides ucontext_t facility

That's not how fiber detection works. Ucontext is used if all else fails (or there is a shadow stack such as Intel CET). There's a split brain as one module detects it should use ucontext, but the other does no detection.

I.e., I don't understand nature of the error that is occurring here

Then this should be merged to unbreak master.

[denizzzka]

This is what I don't understand:

There's a split brain as one module detects it should use ucontext, but the other does no detection.

How does this literally happens? How the same compile-time expression in the same environment can be compiled with different result?

[ibuclaw]

This is what I don't understand:

There's a split brain as one module detects it should use ucontext, but the other does no detection.

How does this literally happens? How the same compile-time expression in the same environment can be compiled with different result?

Because of the fiber detection code influences it.

[denizzzka]

"fiber detection code" is

static if (__traits(compiles, ucontext_t))

?

If "yes" we returning to this question: #16850 (comment)