Re-vendor hex_core in at 0.7.0

[starbelly]

Updates hex_core to 0.7.0 which includes OTP 24 compatibility changes.

[paulo-ferraz-oliveira]

Do you think it possible to wait on hexpm/hex_core#105 (comment) for a few days, at most? We'd not have to do this twice, but it's OK of the PR is closed in the meantime.

[tsloughter]

I think so. It won't be until this weekend that I can get a new relx cut and waiting on that for a new rebar3 release.

[paulo-ferraz-oliveira]

@starbelly, if #2412 gets accepted, you should then re-run the vendoring script (and find no differences in the generated output - unless you've also waited until hexpm/hex_core#105 gets accepted, in which case there'll be small differences in generated code... and also a warningless dialyzer analysis^[1]).

---

^[1] just waiting on the results, here.

[starbelly]

Yup 👍

[paulo-ferraz-oliveira]

If @tsloughter beats me to it, by all means to that rebar3 release... I'm waiting on stuff from master, in any case. 😄

[ferd]

filelib:ensure_dir(Target) will do that.

[paulo-ferraz-oliveira]

Does this still leave erlang:get_stacktrace references in code?

Edit: I don't know if we'll be able to compile under OTP 24, in that case. Compiling works, which is the most important part. It'll probably fail on using some Hex-related elements, though.

[starbelly]

@paulo-ferraz-oliveira Yes, at 0.7.0 erlang:get_stacktrace is still in play. A PR needs to be sent to hex_core to handle this with a platform define or similar to the way rebar3 is doing this with a macro at the moment :

rebar3/src/rebar.hrl

Line 62 in a42f515

-ifdef(fun_stacktrace).

Edit: Opened this PR hexpm/hex_core#106

[paulo-ferraz-oliveira]

Cool. That PR (and subsequent import to rebar3) will work if the goal is to test rebar3 if compiled with OTP 21, for example. I guess the jump to support 24 will be accompanied with the jump to let go of 19 and 20, though.

[paulo-ferraz-oliveira]

@starbelly 0.7.1 has been cut. You may want to use that one :)