Alternate title: MacOS uses case-insensitive file name matching for language detection
I recently moved to MacOS and Exuberant Ctags version 5.8_1 (via homebrew) and found a number of missing symbols. Searching the C++ source file narrowed the problem down to a definition of an operator=() member function. Changing the function name to operator==, or operator++, but not operator+=, resolved the problem. The symptom was that no symbols were reported past that point in the source file. Moving the definition of operator=() to the end of the file allowed production of all the other symbols, except operator=().
Isolating a test case revealed the likely cause: the MacOS build uses case-insensitive matching on file name extensions to detect the language. I was unable to adjust the --langmap settings to create distinct mappings for ".C" and ".c" on MacOS. The C-language parser behaves badly when encountering a C++ definition with a name like operator=().
The diagnosis was complicated by the fact that the C-language parser does very well on almost all C++ code. Further, the observed behavior was affected following definitions. Adding int number;
following the operator=() definition allowed it to properly generate that symbol and the following ones, except for "number" itself. Putting that line before the operator=() definition didn't help. Apparently, just a following semi-colon is all that is required to avoid the C-language parsing problem.
The two attachments test-operator-eq.C and test-operator-eq.cpp illustrate this behavior.
Possibly useful background. I have another machine running RHEL5.5 that has Exuberant Ctags v5.6 (Compiled: Jul 17 2006, 11:40:44), which works fine. It shows the operator=() definition and all those after it without trouble. Of course, RedHat Linux is a strictly case-sensitive environment. Its default langmap has distinct mappings for .c and .C. Previously, I used Debian Wheezy and its version of Ctags (5.9-svn20110310, compiled 3-Oct-2014 13:16:33) also works fine. I heard about Universal Ctags and used homebrew to install that version on MacOS and it behaves better. It still (usually) omits the operator=() symbol in .C files, but does not abort processing the rest of the file, so the following symbols are still produced. In practice, this is a big improvement.
Second attachment, for reference.