fix Issue 12044 - Invalid code gen causes segfault

[WalterBright]

fix https://d.puremagic.com/issues/show_bug.cgi?id=12044

[WalterBright]

This is a regression fix, so please pull, as it is blocking 2.065.

[yebblies]

Could you explain what the problem was and why this fixes it? Otherwise I'm going to have to re-discover the same thing you just did and that seems rather pointless.

[9rnsr]

I'd like to move this case into runnable/link12044.d. It would make easier to re-run testsuite for future linker-issue fixing.

[9rnsr]

@WalterBright I don't like to push everything into xtest64.d.

[9rnsr]

@yebblies It is name mangling issue on local enum E. It's declared in lambda, so the before and after the semantic3 of the lambda, it will have different mangle name.

[yebblies]

@9rnsr Thanks, it's very helpful to have an explanation like that when what's going on isn't immediately obvious and it's in an area of the compiler I don't know well.

[9rnsr]

This is a part of the not yet solid D mangling scheme. Until now, several issues were found - Voldemort Types, the symbols mixed-in by unnamed template mixin, the declared symbols inside unrolled foreach statement, mangling for template instances, etc.

And 12044 is comes from the inference of function attributes, return type, and context-ness. So I'm considering to update the mangling scheme to compliant with the extended current language features.

[WalterBright]

@9rnsr is right. Attribute inference in FuncDeclaration::semantic3() changes the type of the function, which changes its name mangling (deco). Types constructed before semantic3() is run will have different decos than after.

[WalterBright]

I'd like to move this case into runnable/link12044.d . It would make easier to re-run testsuite for future linker-issue fixing.

1. it's not a linker issue, although it was the linker that detected the problem.
2. Although it makes logical sense to have each test case in its own file, having such would make the test suite take an incredibly long time to run. The longer the test suite takes to run, the less useful it is, because one will start avoiding running it.

[9rnsr]

OK.

[yebblies]

Although it makes logical sense to have each test case in its own file, having such would make the test suite take an incredibly long time to run. The longer the test suite takes to run, the less useful it is, because one will start avoiding running it.

Having one test per file doesn't mean we only compile one at once. Each test file could contain a unittest block and the tester tool could build 100s at once.