Skip to content
This repository has been archived by the owner on Aug 7, 2023. It is now read-only.

Linting inline sources #156

Open
jplatte opened this issue May 14, 2016 · 1 comment
Open

Linting inline sources #156

jplatte opened this issue May 14, 2016 · 1 comment

Comments

@jplatte
Copy link

jplatte commented May 14, 2016

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.

@Arcanemagus
Copy link
Member

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?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants