linter-clang icon indicating copy to clipboard operation
linter-clang copied to clipboard

Linting inline sources

Open jplatte opened this issue 8 years ago • 1 comments

I have a bunch of .inl files that the linter has issues with. The issue is quite simple and understandable, but I'm not sure how to get around it. To get a better idea of what I'm talking about, here is an example:

SomeThing.hpp:

#ifndef _SOME_THING_HPP_
#define _SOME_THING_HPP_

template <typename T>
class SomeThing
{
  SomeThing();

  // ...
};

#include "SomeThing.inl"

#endif // _SOME_THING_HPP_

SomeThing.inl:

SomeThing::SomeThing()
{
}

// ...

Now when I'm editing the .inl file, the linter complains because it can't find the declaration of SomeThing. The only workaround that I can think of is including the header file from the .inl, which might just work and not create a circular dependency because of the include guard, but I'd really rather not do that. One possibe fix would be to have some kind of comment for the linter that tells it which file to start linting on, but I assume that would be a relatively complex task because then you'd also have to filter out lints for the header file. So unless someone comes up with a good fix for this, I guess I'll switch to having the inline implementations somewhere in the header file, as that seems to be the most common way of doing things anyway. Just wanted this issue to be documented.

jplatte avatar May 14 '16 12:05 jplatte

That is a rather tricky subject, I'm not sure if it's even possible to do this in any proper manner as the file could be inlined into multiple other files and potentially have issues in one but not another.

I'm leaning towards just ignoring this type of file as I can't think of a good way to lint them. Does anyone have a better idea?

Arcanemagus avatar Jan 18 '17 23:01 Arcanemagus