@nodejs/v8 do you guys know if there are any plans to expose the value of a bigint assuming it fits in an int64 or similar?

@devsnek : No plans currently, but we're open to suggestions if there is demand for such an API :-)

@jakobkummerow i was just looking at integrating bigint into our napi after we bump to 6.7 (https://gist.github.com/devsnek/34c3243a650ef5f4419a16961bca5cd8) and it seems like a bit of an inconsistency to not have some sort of method to see what the value of a bigint is. (https://gist.github.com/devsnek/34c3243a650ef5f4419a16961bca5cd8#file-napi_bigint-diff-L145) i'm probably not the best person to come up with a solution to that problem as i'm no c++ guru, but i personally do have a use case for passing 64bit integers between c++ and js.

@devsnek : it's an intentional omission/postponing -- we didn't want to introduce some random API that we didn't have a use case for. I absolutely agree that for working with BigInts via the C++ API, more methods are needed, and I'd be happy to collaborate on a reasonable design for V8 6.8. We should probably take that discussion elsewhere though.

CI: https://ci.nodejs.org/job/node-test-pull-request/14377/
V8 CI: https://ci.nodejs.org/job/node-test-commit-v8-linux/1330/

What's going on with 731b4adf42fb65c53c1964037fb6f227b269b9b4 ? It seems bigger than the commit it is reverting anyway.

@ofrobots 731b4ad is an exact revert of f02b74d.
0e99791 replaces it.

Updated.
New CI: https://ci.nodejs.org/job/node-test-pull-request/14610/
V8 CI: https://ci.nodejs.org/job/node-test-commit-v8-linux/1350/

Re earlier discussion: anyone who has opinions on what V8's BigInt API should look like, please chime in at crbug.com/v8/7712.

/cc @nodejs/platform-freebsd @nodejs/platform-macos

We have a compiler issue with clang. Can someone please have a look?

FreeBSD error:

64/out/Release/obj.target/v8_base/deps/v8/src/inspector/wasm-translation.o ../deps/v8/src/inspector/wasm-translation.cc
08:08:42 ../deps/v8/src/inspector/wasm-translation.cc:91:40: error: default initialization of an object of const type 'const v8_inspector::WasmSourceInformation' requires a user-provided default constructor
08:08:42     static const WasmSourceInformation singleEmptySourceInformation;
08:08:42                                        ^
08:08:42 1 error generated.
08:08:42 deps/v8/gypfiles/v8_base.target.mk:625: recipe for target '/usr/home/iojs/build/workspace/node-test-commit-freebsd/nodes/freebsd10-64/out/Release/obj.target/v8_base/deps/v8/src/inspector/wasm-translation.o' failed
08:08:42 gmake[2]: *** [/usr/home/iojs/build/workspace/node-test-commit-freebsd/nodes/freebsd10-64/out/Release/obj.target/v8_base/deps/v8/src/inspector/wasm-translation.o] Error 1

macOS error:

../deps/v8/src/inspector/wasm-translation.cc:91:40: error: default initialization of an object of const type 'const v8_inspector::WasmSourceInformation' without a user-provided default constructor
    static const WasmSourceInformation singleEmptySourceInformation;
                                       ^
../deps/v8/src/inspector/wasm-translation.cc:91:68: note: add an explicit initializer to initialize 'singleEmptySourceInformation'
    static const WasmSourceInformation singleEmptySourceInformation;
                                                                   ^
                                                                   {}
1 error generated.
make[2]: *** [/Users/iojs/build/workspace/node-test-commit-osx/nodes/osx1010/out/Release/obj.target/v8_base/deps/v8/src/inspector/wasm-translation.o] Error 1

ping

@targos those errors are likely related to an older version of clang being used in our OSX/FreeBSD servers. I was able to build without problem on my machine (Mac OS 10.13.4). Therefore we need to either:

• Update our clang to a version which won't complain about this struct not having a user-provided constructor
• Float a patch on V8 to make this struct compatible with older versions of clang
• Maybe there's a flag to disable this check on clang, but I couldn't find it :(

I'll try to reproduce this issue in a FreeBSD box and figure out which clang version fixes this issue.

/cc @nodejs/v8 @nodejs/build

FWIW I was able to reproduce this error on Ubuntu 16.04 with clang 3.8.

Also a reference to why I think this is a clang version issue: https://stackoverflow.com/a/28338265/2956796

Upstream bug: https://bugs.chromium.org/p/v8/issues/detail?id=7743

I'll try to open a CL fixing it by the end of the day

CI-run with fix applied: https://ci.nodejs.org/job/node-test-commit-osx/nodes=osx1010/18396/
Upstream CL: https://chromium-review.googlesource.com/c/v8/v8/+/1050666

Fix landed upstream. Should we try to backport it to 6.7 or should we float it?

Thanks for your help @mmarchini !
It would be nice to get it backported to 6.7. A merge request has been made in https://bugs.chromium.org/p/v8/issues/detail?id=7743

@jasnell, @cjihrig I just read your comments in #20662 about semver-ness of adding new globals.

This version of V8 adds 3 of them: BigInt, BigInt64Array, BigUint64Array. Are we going to have to disable the BigInt feature to be able to land V8 6.7 on Node 10?

I would say no due to the relative non-existence of them in code, and anyone who is using those globals is running with harmony since you can't really polyfill bigint. I would personally consider this extenuating circumstances but I understand if it would be semver-major anyway.

+1 to not considering the BigInt global addition semver-major.

v8::HeapProfiler::SetWrapperClassInfoProvider is deprecated

I think I can do that, or guide somebody else do address this. What’s the time frame? Does it have to happen before the ETA date (May 29)? It looks like for now it’s just a deprecation.

An issue with this might be the interaction with addons. I’m not aware of addons using the old API, but I wouldn’t be surprised if there are. The new API seems to assume a monolithic embedder (like Chromium), but in Node’s case we cannot provide information about objects created by userland addons. I’ll try to figure out what we can do here.

(@ChALkeR I know Gzemnid is JS-focused, but would it be possible to see if SetWrapperClassInfoProvider is something that addons use?)