Similar to the concern raised at https://github.com/llvm/llvm-project/commit/50fcf7285eeb001d751eadac5d001a0e216fd701 we have received user reports about this patch: with -Ino-access-permissions -Iall-good, clang will throw an error (EACCES) even though header search goes on and will find the header in all-good. That seems a misleading an unnecessary error, especially as the header *is* found later, yet compilation "fails" because of this diagnostic.

Does this qualify? https://github.com/root-project/root/blob/master/.clang-format#L84

# You want this : enable it if you have https://reviews.llvm.org/D32525
# SpaceBeforeColon: false

in ROOT's .clang-format.

...and remove FIXME.

Only write out an ampersand if needed to make parameter and argument match types.
Increase test coverage (including a text suggested by @rjmccall using an array param) and adjust existing tests' expected diagnostics to follow this change.

In D34985#801498, @bruno wrote:

@v.g.vassilev will this also benefit from ContentCache::getBuffer improvements from D33275? I guess if getBuffer transparently handles pointing to right buffer we won't need this change?

To be clear: emitting annotations will trigger the determination of PresumedLocs. As part of that (but not the first part, IIRC) SourceManager::getBufferName(() will be called which will trigger the fopen of the file, just to get its name. Another task of PresumedLoc is to determine the line number which triggers an fopen; @v.g.vassilev is looking into a possible solution for that one.

Two comments:

• I think the part Val.getBitWidth() == 64 likely needs rewording, although I don't know how
• I can show the motivation, not sure whether that qualifies as a test case:

I cannot handle Phabricator. Ignore this, Vassil will help on D34444!

For the record, here's what GCC does (from https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html#C_002b_002b-Dialect-Options which probably has a typo, the second -Wnoexcept is likely meant to be -Wnoexcept-type): "Enabled by -Wabi and -Wc++1z-compat." -Wc++1z-compat is probably meant to enable a group out of which -Wnoexcept-type is just one (currently the only one as far as I can see). FWIW, we notice the missing -Wno-noexcept-type but not -Wc++1z-compat.

In D33468#786976, @MatzeB wrote:

D34464 fixes this in a less hacky way.

Apologies for the slow response.

Indeed, this is superseded by Keno's change from DenseMap to std::unordered_map. Sorry for the noise...

Regarding the concerns raised by @akyrtzi : maybe it's a question of making the completer interface useful at low cost (with filtering for generic use cases and less ASTReading) versus not breaking existing use cases (fuzzy match). Would you still object to this change if the filtering could be disabled in the CodeCompleteConsumer?

Because of previous review subscriptions...

Committed as r259637