error C2956: sized deallocation function 'operator delete(void*, size_t)' would be chosen as placement deallocation function.

RESOLVED FIXED in Firefox 41

Status

Firefox Build System
General
RESOLVED FIXED
3 years ago
5 months ago

People

(Reporter: zhoubcfan@163.com, Unassigned)

Tracking

Trunk
mozilla41

Firefox Tracking Flags

(firefox41 fixed)

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

3 years ago
User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0
Build ID: 20150428111228

Steps to reproduce:

vs2015rc building trunk

central\layout\style\nsCSSDataBlock.cpp(315): error C2956: sized deallocation function 'operator delete(void*, size_t)' would be chosen as placement deallocation function.
central\layout\style\nsCSSDataBlock.cpp(342): error C2956: sized deallocation function 'operator delete(void*, size_t)' would be chosen as placement deallocation function.
central\layout\style\nsCSSDataBlock.cpp(487): error C2956: sized deallocation function 'operator delete(void*, size_t)' would be chosen as placement deallocation function.
central\layout\style\nsCSSDataBlock.cpp(491): error C2956: sized deallocation function 'operator delete(void*, size_t)' would be chosen as placement deallocation function.
(Reporter)

Updated

3 years ago
Blocks: 1119082
Created attachment 8603494 [details] [diff] [review]
Example fix (there are other instances)

That error message is pretty cryptic. I could be misunderstanding this, but from looking at [0], there is a distinction between:
void T::operator delete( void* ptr, std::size_t sz );   and
void T::operator delete( void* ptr, user-defined-args... );

So if user-defined-args happens to be a size_t, then there's a collision. (And uint32_t is size_t on VS2015 at least)

I was able to make the errors go away with a dummy disambiguation parameter. It's kinda yucky. And there are more instances of these; fixing one reveals others.

dholbert, you like layout and compiler oddities! Am I interpreting the error correctly? Do you have any better ideas for a workaround?

[0] http://en.cppreference.com/w/cpp/memory/new/operator_delete
Attachment #8603494 - Flags: feedback?(dholbert)

Updated

3 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
https://code.google.com/p/chromium/issues/detail?id=440500 suggests that this could be disabled with /Zc:sizedDealloc-. There isn't (yet) an MSDN page for that switch, but the command line usage says:

  sizedDealloc[-]       enable C++14 global sized deallocation
                        functions (on by default)
https://isocpp.org/files/papers/n3778.html#basic.stc.dynamic.deallocation
"Footnote: This deallocation function precludes use of an allocation function void operator new(std::size_t, std::size_t) as a placement allocation function (C.?.? [diff.cpp11.basic]). —end footnote"
At this point I lean towards just disabling the compiler feature. For now the goal is just to unblock local VS2015 builds. We can cross the language-bridge at some future time.
I haven't used placement-new very much, and I'd never heard of "placement deallocation" before today, so I'm probably not the best person to comment intelligently on this (and I'd want to do a bit more digging/reading before I'd be comfortable doing so).

However, from a first-pass skim, I'll note the following:
 - The error is about choosing a "placement deallocation function"
 - In the cppreference page linked in comment 1, the functions labeled as "placement deallocation function" are all documented as only being called if the constructor throws an exception.

So, I don't think this is something we have to worry about, in practice, since (IIRC) we forbid exceptions (per https://developer.mozilla.org/en-US/docs/Using_CXX_in_Mozilla_code ), which means the "placement deallocation function" will never be called, so it doesn't really matter what it is.

So, if I'm understanding correctly, I think I agree with comment 4.
Yeah it definitely seems like the right way to go, for now. Comment 1 was written at a time when I didn't think there was any other way around this.
Created attachment 8603632 [details] [diff] [review]
-Zc:sizedDealloc-
Attachment #8603494 - Attachment is obsolete: true
Attachment #8603494 - Flags: feedback?(dholbert)
Attachment #8603632 - Flags: review?(mh+mozilla)
(Reporter)

Comment 8

3 years ago
I worked around this by defining operator delete or changing the type of the second arg.
Comment on attachment 8603632 [details] [diff] [review]
-Zc:sizedDealloc-

Review of attachment 8603632 [details] [diff] [review]:
-----------------------------------------------------------------

::: configure.in
@@ +538,2 @@
>              CFLAGS="$CFLAGS -Wv:18"
> +            CXXFLAGS="$CXXFLAGS -Wv:18 -Zc:sizedDealloc-"

You need the same change in js/src/configure.in
Attachment #8603632 - Flags: review?(mh+mozilla) → feedback+
Created attachment 8604755 [details] [diff] [review]
-Zc:sizedDealloc-

I always forget the JS configure; thanks for catching!

I noticed further down that the pattern is to put each flag fix on its own line, so I followed suit.
Attachment #8603632 - Attachment is obsolete: true
Attachment #8604755 - Flags: review?(mh+mozilla)
Attachment #8604755 - Flags: review?(mh+mozilla) → review+
https://hg.mozilla.org/mozilla-central/rev/d44f5512d584
Status: NEW → RESOLVED
Last Resolved: 3 years ago
status-firefox41: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla41

Updated

5 months ago
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.