Bug 2181 - Xcode 7.0 (clang-602.0.53) errors
Xcode 7.0 (clang-602.0.53) errors
Status: RESOLVED FIXED
Product: ns-3
Classification: Unclassified
Component: core
ns-3.24
All Mac OS
: P1 normal
Assigned To: Tom Henderson
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-18 16:40 EDT by Tommaso Pecorella
Modified: 2015-11-11 21:50 EST (History)
4 users (show)

See Also:


Attachments
fixes (4.29 KB, patch)
2015-09-18 16:40 EDT, Tommaso Pecorella
Details | Diff
alternate wscript fix (1.63 KB, patch)
2015-09-23 15:53 EDT, Tom Henderson
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tommaso Pecorella 2015-09-18 16:40:22 EDT
Created attachment 2146 [details]
fixes

As reported in the forums, the recently released Xcode 7.0 treats as an error an once-working typedef in src/core/model/make-event.h

The solution is not that nice, but it's trivial: trade some code readability for a clean compilation (and no need to add a conditional flag to disable the check).

The proposed patch seems to fix everything.
As a side note, I'd strongly suggest to amend the recently released 3.24
Comment 1 Tom Henderson 2015-09-21 18:06:41 EDT
There is another warning on Xcode 7 when compiling the bindings; many warnings such as these:

src/topology-read/bindings/ns3module.cc:1482:16: error: expression with side effects will be evaluated despite being used as an operand to 'typeid' [-Werror,-Wpotentially-evaluated-expression]
    if (typeid((*const_cast<ns3::Node *> (ns3::PeekPointer (retval)))).name() == typeid(PyNs3Node__PythonHelper).name())
               ^
Passing a modified CXXFLAGS will work as a workaround to both this warning and the unused-local-typedefs warning

https://www.nsnam.org/wiki/Ns-3.24-errata
Comment 2 Tom Henderson 2015-09-23 15:53:05 EDT
Created attachment 2147 [details]
alternate wscript fix

This patch works around both issues by suppressing the warnings if the Xcode 7 version of clang (or greater) is detected.   

I am proposing to fix the ns-3.24 release with it to get that release working quickly.

I propose to leave the bug open for ns-3-dev changes.  For the typedefs issue, either Tommaso's patch or a solution based on variadic templates.
Comment 3 Tom Henderson 2015-10-07 02:06:31 EDT
I pushed the wscript fix to ns-3-dev (changeset 11682:daa3bfadabef) so we could move forward with ns-3-dev builds, but will leave open for now in case upstream changes allow us to remove wscript suppressions.

The potentially-evaluated-expression issue is logged here:
https://github.com/gjcarneiro/pybindgen/issues/2

Peter and I preferred the wscript fix to Tommaso's patch, since the problem is an upstream issue with a compiler.  It may be possible for a variadic template to fix this as well, but that may take some time to incorporate and the patch doesn't exist yet.

Moving to NEEDINFO to wait if more upstream info becomes available.
Comment 4 Vedran Miletić 2015-10-09 08:12:14 EDT
I would prefer wscript fix as well and I would avoid introducing variadic templates (and a requirement for C++11).

Should we, however, decide to introduce C++11, there are other areas that can be improved. At one occasion Mathieu mentioned usage of variadic templates to simplify the implementation of bound callbacks, and IIRC Tommaso mentioned replacing Ptr<> with shared_ptr<>.
Comment 5 Peter Barnes 2015-10-09 13:38:11 EDT
[off topic]

On C++11/C++14, there are a ton of templates in core which would be drastically simplified by variadic arguments, and I'd also love to see shared_ptr, not to mention unordered_map...
Comment 6 Tom Henderson 2015-10-09 13:53:03 EDT
(In reply to Tom Henderson from comment #3)
> I pushed the wscript fix to ns-3-dev (changeset 11682:daa3bfadabef) so we
> could move forward with ns-3-dev builds, but will leave open for now in case
> upstream changes allow us to remove wscript suppressions.
> 
> The potentially-evaluated-expression issue is logged here:
> https://github.com/gjcarneiro/pybindgen/issues/2

Gustavo decided to treat this as an upstream problem and wontfix.  Discussion in the above URL.

So I think we can just close this for now with the two suppressions in place?