Open Bug 1298566 Opened 4 years ago Updated 1 year ago

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

Categories

(Firefox Build System :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

People

(Reporter: JamesCheng, Unassigned)

References

Details

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.
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?
Flags: needinfo?(mh+mozilla)
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)
Flags: needinfo?(mh+mozilla)
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?
Flags: needinfo?(mh+mozilla)
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.
Flags: needinfo?(mh+mozilla)
Product: Core → Firefox Build System

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.

Blocks: 1575008

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.

No longer blocks: 1575008
You need to log in before you can comment on or make changes to this bug.