Merge remote-tracking branch 'upstream/stable' into merge_stable

[MartinNowak]

No description provided.

[dlang-bot]

Thanks for your pull request, @MartinNowak!

Bugzilla references

Auto-close	Bugzilla	Description
✓	18315	wrong code for i > 0
✓	18352	[REG 2.078] dmd can't generate 64-bit binaries on Windows 10 with VS 2015
✓	18354	[Reg 2.078] Building fails with VC 2015 Build Tools

⚠️⚠️⚠️ Warnings ⚠️⚠️⚠️

• Regression or critical bug fixes should always target the stable branch. Learn more about rebasing to stable or the D release process.

[MartinNowak]

The semaphore issue looks unrelated (and occurs several times). Furthermore they don't seem to have a retest button :/.

[wilzbach]

They do, did you login?

You should have access?

The semaphore issue looks unrelated (and occurs several times).

I have seen something similar yesterday after a passing PR was merged to Phobos.
Eventually I had to revert that PR: dlang/phobos#6130 :/

[wilzbach]

For reference, the failure is:

Test failed.  The logged output:
../generated/linux/release/64/dmd -conf= -m64 -Irunnable  -fPIC  -odtest_results/runnable -oftest_results/runnable/structlit_0  runnable/structlit.d 
runnable/structlit.d(1298): Deprecation: constructor `structlit.test11256.F11256!((gv) => true).F11256.this` all parameters have default arguments, but structs cannot have default constructors.
runnable/structlit.d(1298): Deprecation: constructor `structlit.test11256.F11256!((gv) => true).F11256.this` all parameters have default arguments, but structs cannot have default constructors.
runnable/structlit.d(1298): Deprecation: constructor `structlit.test11256.F11256!((gv) => true).F11256.this` all parameters have default arguments, but structs cannot have default constructors.
test_results/runnable/structlit_0
test_results/runnable/structlit_0: symbol lookup error: test_results/runnable/structlit_0: undefined symbol: _D4core4stdc4math5isnanFNaNbNiNedZi


==============================
Test failed: expected rc == 0, exited with rc == 127

make[1]: *** [test_results/runnable/structlit.d.out] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [start_runnable_tests] Error 2

Though @marler8997 saw it too: https://semaphoreci.com/wilzbach/dmd-2/branches/pull-request-7777/builds/6

I bet this is due to dlang/druntime#2045
However, that would imply that our testsuite is somehow linking in the wrong version of Phobos :O

[MartinNowak]

However, that would imply that our testsuite is somehow linking in the wrong version of Phobos :O

Yes, looks like there is a mismatch between the druntime import and the linked version.
Looks like the makefile isn't using -conf=

dmd/test/Makefile

Line 177 in 7e8bea0

DFLAGS=-I$(DRUNTIME_PATH)/import -I$(PHOBOS_PATH) -L-L$(PHOBOS_PATH)/generated/$(OS)/$(BUILD)/$(MODEL)

, so we could pick up one of the dmd.conf/sc.ini locations.

[wilzbach]

Looks like the makefile isn't using -conf=

#7846

Though lots of things failed.

[MartinNowak]

I can reproduce the failure locally, will check and fix it tomorrow.

[MartinNowak]

Seems related to having the install.sh environment activated while running dmd's test makefile. Quite annoying that d_do_test passes lots of config intransparently through environment variables.

[marler8997]

Seems related to having the install.sh environment activated while running dmd's test makefile. Quite annoying that d_do_test passes lots of config intransparently through environment variables.

I think the reason for this is because many of those variables are shared by both the Makefile and the shell scripts. By setting them in the initial Makefile, both d_do_test and the test files all reference the same set of variables.

This isn't ideal but it allows variables to be shared between these 3 languages, Make, D and BASH. If everything was in the same langauge, say D, all these variables could be declared in a common library and passed around without poisoning the environment.

[MartinNowak]

I think the reason for this is because many of those variables are shared by both the Makefile and the shell scripts. By setting them in the initial Makefile, both d_do_test and the test files all reference the same set of variables.

It's definitely easier for recursive invokations, but hard when you try to reproduce sth.
Anyhow, here is a fix, don't run tests with activated host compiler, as it hijacks the linker path (by setting LIBRARY_PATH). This seems to take precendence over the -L-L$(PHOBOS_PATH)/generated/$(OS)/$(BUILD)/$(MODEL).

[marler8997]

It's definitely easier for recursive invokations, but hard when you try to reproduce sth.

Yes, completely agree with this.

[MartinNowak]

@wilzbach FYI I fixed the semaphore issue in 1e81c60.