We've added a linter with this fix to our library of arcanist "extras" (https://github.com/metno/arcanist-support). Also updated the install information for cpplint, as discussed in T9957.

Custom linters for stuff like that are way to go, that's true: for example some projects may have very complicated naming scheme, where "files in views must be all lowercase with .template extension, placed into dirs corresponding to name of controller, every view should either correspond to action in said controller or be named "all" or stard with underscore [...]" 😉

I just think this isn't very good:

In T9876#147243, @joshuaspence wrote:

For what it's worth, I think that this is a reasonable request. I think that the only way to implement this would be to use a custom message which would be specified in the .arclint file. For example:

.arclint

{
  "linters": {
    "file": {
      "type": "file",
      "file.regex": "(^[^\w]+$)",
      "file.message": "FIlename must consist only of punctuation characters, alphanumeric characters are forbidden."
    }
  }
}

For what it's worth, I think that this is a reasonable request. I think that the only way to implement this would be to use a custom message which would be specified in the .arclint file. For example:

I don't think telling users that their filenames must match a complicated regexp and expecting them to figure it out is a reasonable behavior for a linter to have. I think I'm fairly comfortable with regular expressions and not confident I could figure out what the message meant quickly, and I know at least some engineers just don't have regexp literacy as part of their toolset.

I wouldn't expect users to attach filetype specific filtering via the regex. The include portion of the linter config seems like a much better place to do such things.

I'm concerned that it's difficult to give users a descriptive error message if the pattern is an arbitrary regular expression. What does your patch do when a filename fails a custom regular expression? Specifically, how does it help the user fix their filename?

To configure the regexp in an .arclint option for the linter seems valuable, with a clear use case.

In T9870#146277, @vhbit wrote:

BTW, what are requirements for linter to be upstreamed so I can keep them in mind?

Your Github repository is a nice reference. I will do the same for T9797

clang-format-linter author here. I somehow missed the Community Resources page and yep ATM it's definitely a better place for this linter (alongside with one for Swift code).

In T9848#146061, @joshuaspence wrote:

In T9848#145894, @OCram wrote:

Hmm strange, I do not use any md5 function. I simply copied the ArcanistTextLinter and changed it to work with files containing \r\n line ends. Thats the reason why I do not know where the md5 function all or the variables come from ^^

Based on my understanding of what your linter does, it sounds like T5105 is what you want.

I think adding it in the Community Resources is a good move:

• It will let users use it right away
• You can collect feedback and fix stuff while it's there
• The wait time for upstreaming linters is very long (It's essentially a special integration, with all the costs of one). So getting it somewhere in the meanwhile makes sense.

I think it would be nice to have out-of-the-box support for the clang linter.

In T9848#145894, @OCram wrote:

Hmm strange, I do not use any md5 function. I simply copied the ArcanistTextLinter and changed it to work with files containing \r\n line ends. Thats the reason why I do not know where the md5 function all or the variables come from ^^

Closing as this is outside what the upstream provides support for (custom development). Generally Maniphest is for feature requests and bug reporting. Ponder, IRC, Conpherence are open areas for general use discussion.

Hmm strange, I do not use any md5 function. I simply copied the ArcanistTextLinter and changed it to work with files containing \r\n line ends. Thats the reason why I do not know where the md5 function all or the variables come from ^^

You have the path to the library directory twice, print out the variables
that you use in the md5 function.

In T9848#145709, @Mnkras wrote:

If you look at the error message and the path you can see what the issue is:

md5_file(/home/admwkiv924/phab/arcanist/src//home/admwkiv924/phab/arcanist/src/extensions/ArcanistPowerShellLinter.php): failed to open stream: No such file or directory at [/home/admwkiv924/phab/arcanist/src/lint/engine/ArcanistLintEngine.php:204]

If you look at the error message and the path you can see what the issue is:

lastest cpplint + arcanist HEAD (9e78d15) still have this issue, using @tyhoff's regex fix the issue.

+1. I agree that conflicting rules are un-resolvable (and thus a configuration issue), but in this case, even consistent rules cause an issue.

In the general case, this is impossible to resolve. Suppose that you had conflicting linter rules, such as one whiche enforced that files end with a newline character and another which enforces that files do not end with a newline character.

I conceptually like the approach you outline for --only-new.

I was thinking of changing arc lint --only-new to do the following:

Determining the directories implied by the paths we find and injecting them into the list seems reasonable to me.

Just collecting some more related stuff here: D14298 adds a .arclint-configurable version requirement check, which currently executes as a side effect of getCacheVersion().

Yes it has. Thanks!

@deuresti can you confirm this has been resolved?

I had the same problem and tracked it down to the following facts:

Pretty sure this was only possible after the introduction of .arclint.

Yes, this did the trick:

I can't remember off the top of my head, but I thought we had a way to pass flags to external linters. Something like this:

Since php.ini settings are shared across all PHP scripts on computer there is no way to increase per-script memory limit other than changing script invocation command line to something like php -d memory_limit=-1 actual_script.

I think this isn't our responsibility.

Prior to, e.g., T8921, we were very lax about lint messages which led to a lot of linters passing nonsense (e.g., non-numeric line numbers, negative character offsets, human-readable durations with units like "3 seconds"). Formalization of lint in connection with T8089 implicitly increased strictness.

Actually, all I needed to do to fix this was to use @tyhoff's regex. The issue has nothing to do with the non-zero return code. It has to do with not being able to parse any messages from the output.