Add external import path switch

[rikkimax]

Before I attempt to add the switch itself, let's make sure I didn't break anything with my refactoring of the DllImport detection logic.

Based upon this logic, I can see that the -dllimport=externalOnly option wouldn't be required.

I cannot foresee a reason why you would want to set the explicitly external flag on a module, without also wanting it to be DllImport.

[dlang-bot]

Thanks for your pull request and interest in making D better, @rikkimax! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

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#20899"

[rikkimax]

The switch itself needs a test, (although I have yet to figure out how to do it).

What is here, is already covered by the testsuite.

[rikkimax]

Why does this need a spec PR?

This is for CLI switch, and that gets updated automatically based upon the table in the compiler.

[thewilsonator]

Why does this need a spec PR?

Documentation

[rikkimax]

Which is automatically generated from the CLI switch table in the compiler.

So what are you expecting in the spec to change?

[rikkimax]

Upon reflection, the existing DLL tests cannot be made to work.

They require both druntime and phobos to exist as DLL's which are not current produced.

I either have to implement a -betterC test for this from scratch, or put it in without a test.

[rikkimax]

Upon review, the dllimport override switch would be required, as none would quit the process of determining DllImport status too early.

I have also determined that cxx_dll test should work for the test case. As long as its just importing a single global variable.

[rikkimax]

I'm expecting on Windows the dll_cxx test to fail, I didn't add the -dllimport=externalOnly to its args.

[rikkimax]

There we go! Error: undefined reference to `_testExternalImportVar`

We have confirmation that without -dllimport=externalOnly it fails, now to confirm that it and -extI is working.

[rikkimax]

I don't understand why Azure pipelines (Windows_DMD_bootstrap x64) is failing. It's not dll_cxx test.

I'll need to review what I changed in the checks to make sure I didn't mess that up.

[dkorpel]

Azure randomly fails sometimes

[rikkimax]

Azure randomly fails sometimes

Indeed, after review, I think that is the case here. It was a DLL test, which is why I got suspicious.

[rikkimax]

Okay it's now green.

The tags can be removed, there is a test dll_cxx and a changelog.

@ibuclaw for GDC I am assuming you'll need to name it something like --d-extI, do whatever you need to.

@kinke I'd appreciate a look, from what I see for ldc the dllimport detection logic is in two functions so its going to need a bit of work. If we need to discuss who does what for ldc we can later, there is no point doing it here until after a downstream.

@rainers you wrote the code, so if you want to check it over, here is a ping.