NChybrid was the only one that didn't instantly trigger a "not
implemented" assertion on any code using nested function for a long
time, and removing the cruft greatly improves code readability
(maintainability is a moot point anyway given its current state).
Previously, we just had a hack to make ref foreach statements work.
This commit enables them to work in other cases as well, like the
implicit __result variable for functions with out-contracts (which
is such a magic ref variable for ref-returning functions).
Fixes DMD testcase 'testcontracts'.
- New functions codeGenOptLevel() and verifyModule() to remove code duplication
- Hidden option no-verify renamed to disable-verify and moved to optimizer (like opt tool)
- Removed global.params.noVerify
This is based on Item 2 of "More Effective C++". In general, the C++ cast operators are more expressive and easy to find,
e.g. by grep. Using const_cast also shuts up some compiler warnings.
This is based on Item 2 of "More Effective C++". In general, the C++ cast operators are more expressive and easy to find,
e.g. by grep. Using const_cast also shuts up some compiler warnings.
This leads to missing symbols during linking on Windows x64. If
this changes breaks other Windows platforms then we have to analyze
the triple instead of global.params.os.
Not sure why the code was special-cased for D2 in the first place –
are there any cases where we expect a »full« context struct in the
contracts for D1. At least, they don't occur in DStress/Tango/….
As a general note, this is one of many bugs which would have not gone
unnoticed if we didn't use so many bitcasts.
This should eventually be done on x86 and x86_64 as well, but as
discussed in GitHub issue #110/pull request #120, the ABI there needs a
closer look: at least on x86_64, we need to treat static arrays exactly
like if they were a struct containing T.length members of the same type
to be compatible with DMD (as soon as the ABI is correctly implemented
there, that is).
While for this reason I want to avoid a ABI change which could silently
break some code only to change the x86 ABI again shortly after, this
commit only touches the "default" ABI for unknown targets and thus
should be safe (as we give absoultely no ABI guarantees there anyway).
Just declaring the type of the parent is obviously not enoguh, we need to have run this very code for determining level and context type (if the parent is also nested, that is).
