arphaman added a comment. In https://reviews.llvm.org/D32081#727450, @benlangmuir wrote:
> 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. > > What do you think? I thought about this as well. I'm not sure which way is better though. The current way is simple in the sense that we automatically suppress all diagnostics in the placeholder, so we don't have to modify the parser at all. Clang generates placeholders in a bunch of different places so I reckon there'll have to be a lot of modifications to suppress all problematic cases. Although I suppose that if we teach the parser about the most common places where placeholders could occur (e.g. expressions), that would probably suppress the majority of diagnostics that we care about. I'll try out the parser changes right now. Repository: rL LLVM https://reviews.llvm.org/D32081 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
