1298566 - Need to fix #error "STL code can only be used with infallible ::operator > new()"

Status: NEW

(Firefox Build System :: General, defect)

Description

[James Cheng[:JamesCheng]]

From bug 1298337 comment5 the first question answered by Nathan,

We should find an appropriate way to fix this compile error.

Hi glandium,
Do you have any thought on this?

Thank you.

Comment 1

[Nathan Froyd [:froydnj]]

I think the appropriate way to fix this is to remove type_traits from the list of STL wrapped headers.  There's only meta-programming stuff in said header, nothing that should be allocating, so we don't have to handle wrapping <new>.  WDYT?

Comment 2

[Mike Hommey [:glandium]]

Removing type_traits from the list of STL wrapped headers would only delay the error to some other time. It seems to me we should try and remove as many DISABLE_STL_WRAPPING from moz.builds as we can (bug 1138321)

Comment 3

[James Cheng[:JamesCheng]]

Hi glandium,
When removing from the list,

I got errors like

https://treeherder.mozilla.org/#/jobs?repo=try&revision=1062fa6e7722&selectedJob=26555228

Is that the error related to DISABLE_STL_WRAPPING you mentioned?

Comment 4

[Mike Hommey [:glandium]]

That's an error due to the fact that type_traits includes CRT header that defines _RAISE, and that breaks our needs. I was afraid that was a possibility, but I was hoping that types_traits didn't cause this. So when I said it would only delay the error to some other time, I was expecting that other time to be some random time in the future, but it turned out to mean "in another file" in the build.

So no, the work around of removing types_traits from the list is not going to pan out, and whatever reason you got the "STL code can only be used with infallible ::operator->new" needs to be found and fixed or worked around. Fortunately, in many cases, the reason why this can happen is because of DISABLE_STL_WRAPPING, and as per bug 1138321, in many cases, we should now be able to just remove it.

Comment 5

[Dzmitry Malyshau [:kvark]]

Just a heads up - I'm currently looking at this failure on Windows CI trying to vendor SPIRV-Cross: https://github.com/grovesNL/spirv_cross/issues/121 as a part of https://phabricator.services.mozilla.com/D49458. Any ideas on how to address this would be helpful.

Comment 6

[Dzmitry Malyshau [:kvark]]

Ok, it looks like I was just doing some unusual things that caused confusion, such as - having the dynamic lib targets in the Rust crates, which somehow forces cargo to build them separately. Removing the blocker mark.