Add assert_dims_compatible

[fbleibel-g]

A few more things:

• I create a dim instance explicitly from the DimSrc argument in nda::dim<>(std::get(src))). src could be an initializer list, or a single integer, or whatever dim can be created from.
• I realized (through tests failing) that the shape may not be resolved yet by the time the constructor is called. I now ignore unresolved shape values with is_dynamic: is_static(DimDst::Min) && !is_dynamic(src.min()) && src.min() != DimDst::Min. Failures can happen during resolution too, right? Should we add similar logic around the resolve() call (which one)?
• More annoyingly, the cuda build is failing, https://app.travis-ci.com/github/dsharlet/array/builds/248641873. I need to look into it. Among other things it seems to complain about printf: error: reference to __host__ function 'printf' in __host__ __device__ function. Is there something I need to do to enable printf?

[fbleibel-g]

We're currently failing because CUDA's printf can't be found, and there's no host device implementation for std::tuple's operator =. I think this is because our build test runs with:

-nocudalib -nocudainc

(so basically no cuda standard library support, and that means our stdio.h printf is not CUDA's?).

You can ignore the latest commits - I thought this might be because travis used an older version of clang (by default, clang 7.0.0 from xenial - old!), but that didn't fix it.

I'm not sure what is the best way to address this - could we install the cuda SDK on travis? Otherwise, we can disable the new functionality if CUDA is detected?

[dsharlet]

We could just run the CUDA build test with asserts turned off... that's pretty lame but it seems like it would (or at least could) work around this issue, and the only thing that differs in behavior is printf, so it seems safe enough not to test it.

@jiawen any opinions? I'm not sure if it is possible to install the CUDA SDK on travis. -nocudalib is probably not necessary, because our test doesn't try to link anything, but I doubt that will fix anything anyways.

[fbleibel-g]

I found examples on how to install the cuda toolkit in Travis, but it's a large amount of code and the references look somewhat brittle: https://github.com/tmcdonell/travis-scripts/blob/cad952b7d62aaf006b5f83a0d7a3127e758dc9cd/install-cuda-trusty.sh

Anyway, I got it to build; I realized that Jiawen already redefined a bunch of __device__ functions in build_test.cu, so I added a variadic printf there (can't use ... in cuda, so I used parameter packs instead).

There was another error related to operator= on tuples:

In file included from test/build_test.cu:20:
./array.h:1052:11: error: reference to __host__ function 'operator=' in __host__
      __device__ function
    dims_ = other;
          ^

Jiawen also noticed this, see the note that nda::shape::operator= is also broken in build_test.cu. clang only defines constexpr functions as __host__ + __device__: https://reviews.llvm.org/D18380, and operator= is only constexpr on tuples from C++20 onwards. To bypass this, I made assert_dims_compatible return the source dims, so I can use tuple's constructor instead, and that does the trick.

This change is again ready for review.

[dsharlet]

This looks good now, thanks for your persistence on the CUDA issues!

[fbleibel-g]

Thanks for carefully reviewing my bad template code! Imported back into third_party.