Opened 11 years ago

Closed 10 years ago

#38422 closed defect (worksforme)

textmate2: error: no matching function for call to 'begin'

Reported by: ryandesign (Ryan Carsten Schmidt) Owned by: neverpanic (Clemens Lang)
Priority: Normal Milestone:
Component: ports Version: 2.1.3
Keywords: Cc: cooljeanius (Eric Gallager)
Port: textmate2

Description

PlugIns/dialog/Commands/menu.mm:66:29: error: no matching function for call to 'begin'
        for(NSDictionary* menuItem : menuItems)
                                   ^

OS X 10.8.2, Xcode 4.5.2, Apple clang version 4.1 (tags/Apple/clang-421.11.66) (based on LLVM 3.1svn)

Attachments (1)

main.log.bz2 (20.5 KB) - added by ryandesign (Ryan Carsten Schmidt) 11 years ago.

Download all attachments as: .zip

Change History (9)

Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)

Attachment: main.log.bz2 added

comment:1 Changed 11 years ago by neverpanic (Clemens Lang)

Status: newassigned

I've seen this before and also talked to upstream about this, but neither of us could find out why this happens. The required template definitions should be available at this point and the statement here should work. This might actually be a bug in clang.

Unfortunately this issue is not easily reproducible. If you re-try the build it might just go away.

comment:2 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)

The issue is quite easy for me to reproduce; it happens every time, using the above version of clang. If this is a bug in this version of clang, please blacklist it. I think you'll also need to fix the port so that it is UsingTheRightCompiler (currently it seems to always use clang).

comment:3 Changed 11 years ago by neverpanic (Clemens Lang)

The port is actually using the right compiler, unless you give it a compiler that can not be used to compile the project. Only a few very recent versions of clang will work – if you choose an incompatible version (e.g. llvm-gcc-4.2), it will fall back to Xcode's compiler or /opt/local/bin/clang, if that exists.

So the port should instead blacklist all gcc and llvm-gcc compilers; however, since those aren't the default on any supported platform, this seemed unnecessary to me.

comment:4 Changed 11 years ago by neverpanic (Clemens Lang)

Is there any reason why you're not using a newer Xcode and newer command line tools? I could blacklist this version of clang and fall back to a clang compiler from macports that might, or might not, work fine, but I don't see the point in forcing users to compile a full blown clang rather than erroring out and telling them to upgrade Xcode.

comment:5 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)

It does not appear to be using using the right compiler; I ran sudo port install textmate2 compiler.blacklist=clang and MacPorts then claimed that it was building with llvm-gcc-4.2, but it still built with clang. clang appears to be hardcoded in ${worksrcpath}/build/build.ninja.

This is a secondary machine, with various older OSes and Xcodes, specifically to find problems like this (on which I needed a text editor and wanted to use textmate2; I ended up downloading a binary from their web site instead). If a particular compiler will not work, you should blacklist it. It's one line to include the portgroup and one line to list the compilers you want to blacklist. This is much easier than trying to figure out other criteria for erroring out. Specifically, checking the Xcode version is not a solution, since Xcode can be updated independently of the command line tools, and it's the version of the compiler in the command line tools that matters here. Also, since we have binaries, the burden for installing a compiler via MacPorts is less than it used to be.

comment:6 Changed 11 years ago by neverpanic (Clemens Lang)

It only attempts to use llvm-gcc-4.2, because you manually blacklist clang, which causes MacPorts to use llvm-gcc-4.2. LLVM GCC, however, can not be used to build textmate2, and its build system tries to be smart by looking for a different compiler that might work. I don't see a reason to stop it from doing so, though, because the Portfile currently does not blacklist clang and all supported platforms use clang as their default compiler.

We're not in a habit of blacklisting compilers that aren't being used anyway – we're not blacklisting gcc-3 on most ports, although it is in the fallback list on some systems and it will probably not compile most software in macports. This brings me back to topic: I can't test with the compiler you're trying to use, so feel free to commit a patch that will blacklist it (and then ensure a proper fallback is chosen, probably by also blacklisting llvm-gcc-4.2 and every other compiler that comes in the fallback list before a suitable clang, or just modify the fallback list to contain the host clang and a recent enough macports clang).

The build.ninja file is only created after running configure – it's not actually hardcoded, but it uses the value of $CC that it found suitable for buildig.

Last edited 11 years ago by neverpanic (Clemens Lang) (previous) (diff)

comment:7 Changed 11 years ago by cooljeanius (Eric Gallager)

Cc: egall@… added

Cc Me!

comment:8 Changed 10 years ago by neverpanic (Clemens Lang)

Resolution: worksforme
Status: assignedclosed

I haven't been able to reproduce this with the most recent versions in a while; I'm assume it has somehow been fixed. Please re-open if that's not the case.

Note: See TracTickets for help on using tickets.