always_construct_holder feature to support intrusively reference-counted types

[wjakob]

This PR addresses a regression in one of my projects following #533. When using smart pointers with intrusive reference counting, we always want to construct the holder type because it's always possible to do so (the instance is really its own holder type, that's the point of intrusive refcounts).

[wjakob]

Hmm.. there is something really weird going on with Travis. Builds with "GCC 6.2.1" (which isn't even an existing version) fail mysteriously on super-basic stuff. I suspect a codegen issue. The same thing is also happening on the PyPy branch. I have not been able to reproduce the issue with GCC 6.2.0 on Linux, which is the latest 6.x release.

Can we change travis to use 6.2.0?

[wjakob]

^ @dean0x7d

I suspected that ubuntu-toolchain-r-test is to blame, but this is a package from debian-testing.

[jagerman]

6.2.1 is essentially upstream gcc's 6.2 stable branch. I'll investigate and see what's going on.

[jagerman]

Aha, it's not a gcc issue: python 2.7.13 RC1 just hit debian testing, and it's what causes the failure.

[jagerman]

(And just to confirm: building under clang 3.9/python 2.7.13 RC1 gives the same failures).

[jagerman]

PR #562 will "fix" it, temporarily, by allowing that test to fail until a fixed python 2.7 propagates to debian testing. (We could fix it by using something like pytest.mark.xfail(sys.version_info = (2, 7, 13, 'candidate', 1), "broken 2.7.13 RC1"), but the one-line fix to allow failures seems simpler.)

These Python RC's are not playing nicely with pybind11.

[dean0x7d]

Interesting day for Python RC builds.

Regarding the PR itself, it would be good to add a test (the intrusive pointer's refcount) to avoid regressions.

[wjakob]

Thank you @jagerman. I've become so distrustful of compilers after playing with the AVX512 vectorization backend of Clang and GCC that I didn't realize that Python could be at fault. ;)

I'll merge this then (with an added testcase)