Closed
Bug 1438446
Opened 7 years ago
Closed 6 years ago
ipdlTuple.h tries to use non-memmovable wstring in nsTArray
Categories
(Firefox Build System :: General, defect, P1)
Tracking
(firefox64 fixed)
RESOLVED
FIXED
mozilla64
Tracking | Status | |
---|---|---|
firefox64 | --- | fixed |
People
(Reporter: kats, Assigned: kats)
References
Details
Attachments
(2 files)
16.67 KB,
text/x-log
|
Details | |
4.52 KB,
patch
|
jld
:
review+
|
Details | Diff | Splinter Review |
Hot off the heels of getting a clang build working on Windows, I tried to --enable-clang-plugin and build with that. It proceeded but eventually failed with what looks like a legitimate error.
Build log is attached, but basically the nsTArray at [1] contains a bunch of IpdlTupleElement [2] instances, which are variants that might contain a OpenFileNameIPC [3] struct, which contains a std::wstring [4] (actually it contains a few wstring fields). The clang plugin complains because nsTArray has MOZ_NEEDS_MEMMOVABLE_TYPE [5] but wstring is not guaranteed to be memmove-able.
This seems like a legitimate complaint, which makes me wonder why our static analysis builds in automation didn't pick this up.
[1] https://searchfox.org/mozilla-central/rev/9011be0a172711bc243e50dfca16d42e877bf4ec/dom/plugins/ipc/IpdlTuple.h#82
[2] https://searchfox.org/mozilla-central/rev/9011be0a172711bc243e50dfca16d42e877bf4ec/dom/plugins/ipc/IpdlTuple.h#68
[3] https://searchfox.org/mozilla-central/rev/9011be0a172711bc243e50dfca16d42e877bf4ec/dom/plugins/ipc/FunctionBrokerIPCUtils.h#138
[4] https://searchfox.org/mozilla-central/rev/9011be0a172711bc243e50dfca16d42e877bf4ec/dom/plugins/ipc/FunctionBrokerIPCUtils.h#121
[5] https://searchfox.org/mozilla-central/rev/9011be0a172711bc243e50dfca16d42e877bf4ec/xpcom/ds/nsTArray.h#690
Thanks for filing, I encountered this last week also, but got distracted and forgot about it.
Updated•7 years ago
|
Product: Core → Firefox Build System
> This seems like a legitimate complaint, which makes me wonder why our static
> analysis builds in automation didn't pick this up.
Clang versions prior to 7 somehow didn't catch this, probably for the same reason as bug 1492743.
This will prevent us from moving Windows static analysis into our primary build tasks. :handyman, would you be able to look into this?
Blocks: 1486554
Flags: needinfo?(davidp99)
Comment 3•6 years ago
|
||
will do
Assignee: nobody → davidp99
Flags: needinfo?(davidp99)
Priority: -- → P1
Oh, on closer look this may be easier than I thought...
> The clang plugin complains because nsTArray has MOZ_NEEDS_MEMMOVABLE_TYPE
That's just the default implementation of nsTArray_CopyChooser. If you're not memmove-able, you can override it. This might be as simple as `DECLARE_USE_COPY_CONSTRUCTORS(IpdlTupleElement)`.
Assignee | ||
Comment 5•6 years ago
|
||
It turned out to be a little more complicated since IpdlTupleElement is private inside IpdlTuple (i.e. can't forward-declare it), and the DECLARE_USE_COPY_CONSTRUCTORS needs to be outside the mozilla namespace, and yet the DECLARE_USE_COPY_CONSTRUCTORS needs to happen before the array is defined. I had to move the IpdlTupleElement and related things outside IpdlTuple to get it working. I'll put up a try push shortly once I confirm my local build doesn't have any other errors.
Assignee | ||
Comment 6•6 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=e8a410c6df917e0e23f48614796d2aafe909e119
This error seems fixed, but there's some other error now. My local build is still going...
Assignee | ||
Comment 7•6 years ago
|
||
At any rate, this patch should be ok to go in. Suggestions on how to make it less ugly are welcome.
Attachment #9014112 -
Flags: review?(dmajor)
Attachment #9014112 -
Flags: review?(dmajor) → review?(jld)
Comment 8•6 years ago
|
||
Thanks. FWIW, I prefer this namespace setup anyway.
Comment 9•6 years ago
|
||
Comment on attachment 9014112 [details] [diff] [review]
Patch
Review of attachment 9014112 [details] [diff] [review]:
-----------------------------------------------------------------
Seems reasonable.
The only other thing I could think of is to use nsString instead of std::wstring in OpenFileNameIPC (see also bug 1447674), but that might be more trouble than it's worth, especially with wchar_t vs. char16_t.
Attachment #9014112 -
Flags: review?(jld) → review+
Comment 10•6 years ago
|
||
Pushed by kgupta@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/52ad4fb54981
Use the nsTArray copy constructor for the non-memmovable IpdlTupleElement on Windows. r=jld
Comment 11•6 years ago
|
||
bugherder |
Status: NEW → RESOLVED
Closed: 6 years ago
status-firefox64:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla64
Assignee | ||
Updated•6 years ago
|
Assignee: davidp99 → kats
You need to log in
before you can comment on or make changes to this bug.
Description
•