Fix clang-tidy warnings

Fix the incomplete type issue with PointerUnion in DeclOccurrence. h. I'm not actually sure how that code compiles without error with other versions of clang.

Fixed clang-format issue.

Removing myself as reviewer since I no longer work in this area. Someone who is more involved with llvm Support/ADT should review this.

I haven't work on this in a long time; replacing myself with Bruno as reviewer.

LGTM, but I'd appreciate someone who has worked on this more recently taking a look.

LGTM, although I made a small suggestion for clarity. FYI InPCH was used by PTH, which was removed a couple of months ago.

@property(attr, attr2) instead of @property ( attr,attr2 ).

@arphaman @akyrtzi could you take a look at this?

@sammccall RE using USRs: we want to integrate clangd into a larger source tooling system that is already using USRs extensively to identify symbols. The most obvious case is that we have an index outside of clangd that uses USRs from clang-the-compiler, so exposing USRs in clangd lets us integrate information from both places. The most critical piece of this is being able to ask "what symbol is at this location" and correlate that with index queries. Beyond this one case, my experience is that any time a language service API is providing information about a symbol or list of symbols it may be useful to add the USR (e.g. hover, definition or workspace symbols).

LGTM

LGTM

r333202

Thanks for looking up the supported bash version! Updated diff.

In D47273#1109985, @ruiu wrote:

sed -e "$(echo -e 's/\t.*//')"

In D47273#1109934, @ruiu wrote:

I wonder if you could replace \t with \0x09. At least it works on my machine which has GNU sed.

r328337

Did you consider just using a different pragma that triggers this behaviour instead of avoiding the crash? I don't really have a strong preference but I'd be interested to hear what you think the pros/cons are.

Spotted one issue, but otherwise seems okay to me. I'd like @bruno to take a look at this, because he's thought about this code much more recently than me.

In D34512#856301, @xazax.hun wrote:

In D34512#856184, @dcoughlin wrote:

In either case, the important scenario I think we should support is choosing at a call site to a C function the most likely definition of the called function, based on number and type of parameters, from multiple possible definitions in other translation units. If the API is rich enough to support this then I think that is a good indication it will be useful for other scenarios as well.

Note that the lookup is already based on USR which is similar to mangled names in a sense that it contains information about the function parameters. So the only way to get multiple candidates from the lookup is having multiple function definitions with the same signature.

Thanks, this looks good to me. I'd appreciate if @klimek could take a quick look though.

It would be nice if the doc comment for the single file parse mode flag was updated to include this new functionality.

LGTM, thanks!

I agree with not detecting these during PP-only, but there's nothing wrong with <#>. It's either not a placeholder, or it's part of a placeholder like <#>#>, which is a placeholder containing the text ">". Similarly, <## could be the start of an empty placeholder <##>.

LGTM. One stylistic comment, but I'll leave that up to you.

A couple of minor comments, but otherwise LGTM.

What do you think about a hybrid approach: Don't suppress diagnostics in the placeholder range when we handle the placeholders in parser/sema, but do suppress the range when the placeholder isn't explicitly handled?

LGTM

Rather than stick ranges into the diagnostic engine, I think it would be cleaner to have the identifier have a method like isEditorPlaceholder() that can be used to avoid situations like this in a principled way, or to customize behaviour for placeholders in the parser, etc. That's how we are handling it in Swift. Using an API on the placeholder is also better for handling errors that could be caused by the placeholder but not have it as the primary location.

LGTM

Sorry for the delay, I though you were still iterating with @aprantl for some reason. LGTM

LGTM

Can we test the already-validated diagnostics?

I'm inclined to suggest we break that behaviour with modules and treat a user module the same no matter where it was imported. @rsmith, what do you think?

Does it mean that a system module should only import system modules? If a system module is allowed to import non-system modules, for a non-system module, we will validate diagnostic options differently depending on whether a system module or a non-system module imports it. This will cause a non-system module that was validated earlier to be invalidated by a child thread.

LGTM, sorry for the delay.

LGTM, but @rsmith should glance at this too.

This should have a test for the writer change. Otherwise LGTM.

Still missing the change for if (IsPrebuilt) {, but otherwise LGTM.