cpplint does not lint C++ files with the `.C` suffix about megalinter HOT 16 CLOSED

With files foo.A, bar.b, testCpplint.cxx and

CPP_CPPLINT_FILE_EXTENSIONS: [".A", ".b", ".c", ".C", ".h", ".cxx", ".cpp"]

I get the following:

  +----MATCHING LINTERS-----+--------------------------+----------------+------------+
  | Descriptor | Linter     | Criteria                 | Matching files | Format/Fix |
  +------------+------------+--------------------------+----------------+------------+
  | CPP        | cpplint    | .A|.b|.c|.C|.h|.cxx|.cpp | 3              | no         |
  +------------+------------+--------------------------+----------------+------------+
...
  [cpplint] bar.b
  [cpplint] foo.A
  [cpplint] testCpplint.cxx
...
  --Error detail:
  Ignoring bar.b; not a valid file name (hpp, c++, hh, cuh, c, cc, cu, h, hxx, cxx, cpp, h++)
  Ignoring foo.A; not a valid file name (hpp, c++, hh, cuh, c, cc, cu, h, hxx, cxx, cpp, h++)
  testCpplint.cxx:0:  No copyright message found.  You should have a line: "Copyright [year] <Copyright Owner>"  [legal/copyright] [5]
  Done processing bar.b
  Done processing foo.A
  Done processing testCpplint.cxx

Again, locally cpplint works as expected, when provided with the --extensions argument.

That makes me suspect that the following is happening:

1. MegaLinter considers CPP_CPPLINT_FILE_EXTENSIONS only for collecting files to be checked with cpplint but it does not pass those extensions in the --extensions=... argument of the cpplint command and therefore cpplint always only checks files with prefixes from the default list of extensions, i.e. hpp, c++, hh, cuh, c, cc, cu, h, hxx, cxx, cpp, h++. Since it already includes "c", it always works for linting .c files.

2. MegaLinter prints a linter's output only when it exits with a non-zero code. The "not a valid file name" error does not trigger a non-zero exit code of the cpplint command, therefore it is not reported when it is the only kind of error.

from megalinter.

@vkucera probably but in case there are other constraints (FILTER_REGEX_EXCLUDE, etc....) , that way we'll be sure to send only the file extensions related to the list of files, not more extensions that are not matching files in the repo :)

PR on the way

from megalinter.

Interesting report! I clearly see that something isn't going quite right.

from megalinter.

Could you tell us what version of Megalinter it is running, and is it locally, or on CI (if so, is it GitHub Actions?). Is it using a flavor, if yes, which one? If you are locally, on what platform are you on? Is your file system case-sensitive? I know for example that on windows, NTFS is not case-sensitive, but case-preserving. This case of having a file with the same name, except the case of the extension would probably not work on windows.

There was some changes recently where we are starting to have a c and a cpp flavor in order to have more linters in that category, and having clang-format. But these aren't out yet. It might also help us to know if the same thing happens with the beta versions too (that are the main branch)

from megalinter.

Hi @echoix , thanks for your quick feedback.
v7.5.0, GitHub action, no flavour, runs-on: ubuntu-latest.
Hope it helps.

from megalinter.

To try to discriminate between a problem with file handling or extension handling, a useful case to check would be

1. file1.c and file2.C : varies the extension, without having the same name.
2. Files3.C, files3.c, files3.C, files3.c
3. folder1/file4.c and folder2/file4.C

from megalinter.

Hi @echoix , thanks for your quick feedback.

v7.5.0, GitHub action, no flavour, runs-on: ubuntu-latest.

Hope it helps.

Maybe try the beta flavor to make sure it isn't something fixed in another version :s

from megalinter.

To try to discriminate between a problem with file handling or extension handling, a useful case to check would be

1. `file1.c` and `file2.C` : varies the extension, without having the same name.

2. `Files3.C`, `files3.c`, `files3.C`, `files3.c`

3. `folder1/file4.c` and `folder2/file4.C`

The name does not seem to matter. I created the testCpplint files only to provide a MWE. I see the same issue with many other files. The only factor that makes a difference is the extension upper case. I haven't tried other extensions though.

from megalinter.

Hi @echoix , thanks for your quick feedback.
v7.5.0, GitHub action, no flavour, runs-on: ubuntu-latest.
Hope it helps.

Maybe try the beta flavor to make sure it isn't something fixed in another version :s

Will try.

from megalinter.

Hi @echoix , thanks for your quick feedback.
v7.5.0, GitHub action, no flavour, runs-on: ubuntu-latest.
Hope it helps.

Maybe try the beta flavor to make sure it isn't something fixed in another version :s

Will try.

The beta version (55f2d6f) behaves the same.

from megalinter.

Ok thanks a lot! I won't investigate tonight, but it's pretty descriptive!

from megalinter.

@vkucera your analysis seems right ! :)

• cpplint seems to ask for file extensions whereas we already send it a list of files
• it does notreturn a status code > 0 when it receives options it can not handle... that's strange

We can adapt MegaLinter to such behavior, probably by defining a python class to override some methods, but it is quite uncommon compared to many other linters ;)

from megalinter.

@nvuillam , if you can confirm that MegaLinter indeed does not call the cpplint command with the --extensions=... option, then simply adding it would fix the issue.
I guess it should not be complicated to parse CPP_CPPLINT_FILE_EXTENSIONS and provide the formatted list of extensions to the cpplint command.

from megalinter.

If you can do this when .mega-linter.yml is parsed, it will work just fine.

CPP_CPPLINT_ARGUMENTS = "--extensions=" + ",".join(e[1:] for e in CPP_CPPLINT_FILE_EXTENSIONS)

Of course provided that the potential CPP_CPPLINT_ARGUMENTS in .mega-linter.yml is included properly as well.

from megalinter.

@vkucera why not just listing the extensions from the list of files sent as arguments and dynamically create --extensions= argument ? ^^

from megalinter.

@vkucera why not just listing the extensions from the list of files sent as arguments and dynamically create --extensions= argument ? ^^

Which is equivalent to creating the --extensions argument directly from CPP_CPPLINT_FILE_EXTENSIONS, isn't it?

from megalinter.