I did this a while ago so I'm not 100% sure where it comes from but I am pretty sure this logic was copied from editorconfig-core-js.

I'd also like to check here that the keys are valid, although this could get messy.

Ugly conditional to avoid writing a TempFile unnecessarily.

This is messy, but I think ultimately we need something like this in order to handle the .editorconfig format properly. EditorConfig uses globs (see fnmatch.js) whereas PHP seems to work better with regular expressions.

It might be possible to use fnmatch instead, which is probably cleaner.

One vague concern with this is that issuing find against a large working copy can be slow. Particularly, Facebook has very large working copies (many GB) with huge numbers of files, and has spent a great deal of engineering effort attempting to mitigate the costs of this.

One cheap way to avoid paying this cost (at the cost of accuracy) would be to check for $root/.editorconfig before searching, under the theory that any project which uses these files will have a default at the root. I'm not sure if this is a reasonable assumption or not.

We could also fill the cache lazily (maybe falling back to a full fill at, say, 2048 entries, under the assumption that if we're doing anything with more than 2048 paths we're probably doing something with the whole repository) but this is significantly complex.

We could also let installs enumerate the locations of their .editorconfig files elsewhere in configuration, I guess.

(I don't think any of this is worth pursuing for now.)

Once this works, though, it would be nice to capture tab width information when sending source to Phabricator, which implies we might start running it all the time.

Yeah, definitely feels messy.

This is O(N^2) if you run, e.g., arc lint --everything, I think, since we have to iterate over each path in the repository for each path we're examining.

It's probably worth the complexity cost to build a tree instead, by splitting the paths apart into components:

src
  applications
    differential => array(...)
    diffusion => array(...)

Then split the path being looked up apart, and walk down the tree.

(Would be nice to have the path.)

This should probably use \z (end of input) not $ (end of input, or before-newline-at-end-of-input).

That is, /^abc$/ matches both "abc" and "abc\n".

>>> orbital ~/devtools/arcanist $ php -r 'var_dump(preg_match("/^abc$/", "abc\n"));'
int(1)
>>> orbital ~/devtools/arcanist $ php -r 'var_dump(preg_match("/^abc\z/", "abc\n"));'
int(0)

Yeah, I don't like the idea of only looking for $root/.editorconfig.

I think that (possibly) a better approach would be to extract values that we understand from the .editorconfig and discard anything else. This means that we can safely support a subset of EditorConfig.

Yeah, this seems better.

Agreed.... I guess this function is probably overkill. I can't think of a case in which we would be parsing an INI string over an INI file (and parse_ini_file is available in all PHP versions that we support whereas parse_ini_string is only available from PHP 5.3).

Maybe I'll just change this to phutil_parse_ini_file which can behave similarly to parse_ini_file but with better exceptions?

You're probably right... I guess the assumption was that a glob wouldn't contain newlines.

Oh, right. I think making it file oriented, or adding a $what_are_we_parsing parameter, or throwing some parser-specific exception are all reasonable. Or leave it as-is for now. Although I don't have any specific designs for it, it is nice to have a string-oriented API.