The recent changes to static checking causes the following code Eigen::Vector4f pl_t; Eigen::Vector3f fp_c; ... pl_f (3) = -fp_c.dot (pl_f.block (0, 0, 3, 1)); to fail with ./third_party/eigen3/Eigen/src/Core/Dot.h:75:3: error: static_assert failed due to requirement 'Block<Eigen::Matrix<float, 4, 1, 0, 4, 1>, -1, -1, false>::IsVectorAtCompileTime' "YOU_TRIED_CALLING_A_VECTOR_METHOD_ON_A_MATRIX" EIGEN_STATIC_ASSERT_VECTOR_ONLY(OtherDerived) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./third_party/eigen3/Eigen/src/Core/util/StaticAssert.h:142:3: note: expanded from macro 'EIGEN_STATIC_ASSERT_VECTOR_ONLY' EIGEN_STATIC_ASSERT(TYPE::IsVectorAtCompileTime, \ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./third_party/eigen3/Eigen/src/Core/util/StaticAssert.h:33:40: note: expanded from macro 'EIGEN_STATIC_ASSERT' #define EIGEN_STATIC_ASSERT(X,MSG) static_assert(X,#MSG); ^ ~ third_party/pcl/filters/include/pcl/filters/impl/frustum_culling.hpp:113:20: note: in instantiation of function template specialization 'Eigen::MatrixBase<Eigen::Matrix<float, 3, 1, 0, 3, 1> >::dot<Eigen::Block<Eigen::Matrix<float, 4, 1, 0, 4, 1>, -1, -1, false> >' requested here pl_f (3) = -fp_c.dot (pl_f.block (0, 0, 3, 1)); // perpendicular edges of the far plane
It would probably be better to write this as pl_f (3) = -fp_c.dot (pl_f.head(3)); but it still seems like the check it tailing to see that this block is indeed a vector.
For the record, this is the breaking commit: https://bitbucket.org/eigen/eigen/commits/3aaba77a3cc919b61 Honestly, I would prefer forcing users to use the correct block operation here (i.e., head, tail or segment in this case). To avoid breaking code, we could extent the current `dot_nocheck` struct to have it test (in another template parameter) whether the inputs are both vectors at compile time and deprecate the variant where that is not the case. There are however other possibilities that the EIGEN_STATIC_ASSERT_VECTOR_ONLY will fail at other places (just grep for that macro or for IsVectorAtCompileTime in our source). Another alternative would be to relax the assertion of the macro if a certain compile-time flag is set (similar to the Eigen2 compatibility macros we had when Eigen3 started)
To explain why this check is actually valid: It prevents for example from accidentally using `pl_f.block(0,0,3,0)`
I agree. Alternatively people could use block<3,1>(0,0). I'll fix the code in question.
-- GitLab Migration Automatic Message -- This bug has been migrated to gitlab.com's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.com/libeigen/eigen/issues/1664.