default initialization of an object of const type 'const struct (anonymous struct at ./hb-algs.hh:35:14)' without a user-provided default constructor

[ryandesign]

Hello,

harfbuzz 2.4.0 fails to build on OS X 10.11 El Capitan with Xcode 7.3.1 and its clang 703.0.31; the first errors look like this:

In file included from main.cc:27:
In file included from ./hb-static.cc:27:
In file included from ./hb.hh:571:
./hb-algs.hh:49:3: error: default initialization of an object of const type 'const struct (anonymous struct at ./hb-algs.hh:35:14)' without a user-provided default constructor
} hb_hash HB_UNUSED;
  ^
         {}
./hb-algs.hh:55:3: error: default initialization of an object of const type 'const struct (anonymous struct at ./hb-algs.hh:51:14)' without a user-provided default constructor
} hb_identity HB_UNUSED;
  ^
             {}
./hb-algs.hh:61:3: error: default initialization of an object of const type 'const struct (anonymous struct at ./hb-algs.hh:57:14)' without a user-provided default constructor
} hb_bool HB_UNUSED;
  ^
         {}
./hb-algs.hh:85:3: error: default initialization of an object of const type 'const struct (anonymous struct at ./hb-algs.hh:81:14)' without a user-provided default constructor
} hb_first HB_UNUSED;
  ^
          {}
./hb-algs.hh:91:3: error: default initialization of an object of const type 'const struct (anonymous struct at ./hb-algs.hh:87:14)' without a user-provided default constructor
} hb_second HB_UNUSED;
  ^
           {}

Is this something that can/should be changed in harfbuzz, or does Harfbuzz now require a newer compiler?

It builds fine on macOS 10.12 Sierra with Xcode 8.3.3 and its clang 802.0.42.

I didn't see anything about compiler requirements in README.md or BUILD.md; maybe something could be added; I know you mentioned you're using C++11 now.

[behdad]

Sounds like a compiler bug. I don't think that's a requirement of the language. We have dozens o bots which build this happily. If you can suggest a simple workaround, we'd be happy to take in. Not adding constructors though, which would be unnecessary and add up to the library static initialization (which we prohibit).

[ra1nb0w]

Seems like https://github.com/Microsoft/AirSim/pull/61/files

[behdad]

Seems like https://github.com/Microsoft/AirSim/pull/61/files

Yeah but that's adding constructor, which is option I prefer not to do. I'm sure there's some other way...

I mean, technically we are not even using the 'const' part.

[behdad]

Okay looks like this was a fault in the standard indeed:

https://stackoverflow.com/questions/7411515/why-does-c-require-a-user-provided-default-constructor-to-default-construct-a

I'm fine dropping the const. Or maybe I add a macro:
#define HB_FUNCOBJ(x) static const x HB_UNUSED

which would drop the const on affected compilers.

[behdad]

@ebraminio reason to add that macro we were talking about the other day. ^^

[ryandesign]

Sorry, I meant to respond earlier after I found that Stack Overflow thread you mentioned above. I also did some further testing, and just to give you an idea of the compiler versions affected, I observed the error on the following compilers included with Xcode:

• OS X 10.9.5, Xcode 6.2, Apple LLVM/clang-600.0.57
• OS X 10.10.5, Xcode 7.2.1, Apple LLVM/clang-700.1.81
• OS X 10.11.6, Xcode 8.2.1, Apple LLVM/clang-800.0.42.1

I also tested a couple compiler versions in MacPorts, which did not exhibit the error:

• OS X 10.11.6, MacPorts LLVM/clang 4.0.1
• OS X 10.11.6, MacPorts LLVM/clang 5.0.2

[ra1nb0w]

what do you think about tagging a patch version, like 2.4.1?
ps. Thank you for the fix!

[behdad]

Does it work for you?

Last time we had some hiccups making a release. I'll make one soonish.

[ra1nb0w]

Now, I receive the following error

./hb-array.hh:303:3: error: invalid operands to binary expression ('decltype((rhs(lhs)))' (aka 'hb_map_iter_t<hb_array_t<const char>, <anonymous struct at ./hb-algs.hh:49:1> &>') and 'hb_reduce_t<<lambda at ./hb-array.hh:303:16>, int>')
  | hb_reduce ([] (uint32_t a, uint32_t b) -> uint32_t { return a * 31 + b; }, 0)
  ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

with Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)� and macOS 10.9.
But it is better to way @ryandesign that can repeat the tests he did.

[ryandesign]

Yes, I agree with @ra1nb0w, an error like that does occur with Apple LLVM version 6.0 (clang-600.0.57) on OS X 10.9. Here is a build failure log for harfbuzz 2.5.1 on that system.

It builds fine with Apple LLVM version 7.0.2 (clang-700.1.81) on OS X 10.10 and on later systems.

[behdad]

If there's something that you think should be fixed, please file a new issue.