Open Radar

 
Summary:
I think, it would be useful if you could extend Xcode using custom clang plugins. See http://clang.llvm.org/docs/ClangPlugins.html for more information on these.


Use cases
---------

I can currently think of two different ways, how these clang plugins could be integrated into Xcode:

1. Run plugin on each clang invocation by Xcode

If the plugin is run with each invocation of clang by Xcode, it would allow developers to create e.g. custom warnings that include custom fix-its. You would be able to access the full AST as its generated by clang and all the power that the compiler offers. 
As an example, I can currently think of a warning that is triggered if a string is not localised, but am pretty sure that there are plenty more and better possibilities awaiting.

2. Run on demand

An Xcode Source Editor Plugin can trigger to run clang with this plugin enabled and pass custom flags to it.
Using this technique you would, for example, be able to develop refactoring tools for C++ with the following workflow:
- The user selects the name of a class to rename
- He clicks the extension's menu item
- The extensions prompts the user for a new name
- The extension invokes clang with the clang plugin enabled and passes the old class’s declaration to it (note that it is not necessary to build the whole product but that parsing and type checking probably suffices)
- The clang plugin searches for all occurrences of this class and returns them either as command line output or using other techniques like XPC (I believe this should be the plugin’s developer’s job to implement)
- The extension tells Xcode to rename all the classes names. For this it would need to have a list of all the files in the project. These files can be manipulated in the same way that it is done in the current Xcode 8 beta 1 API.


clang compatibility
-------------------

Since clang does not provide a stable API for plugins, all plugins must specify a list of clang versions that are supported, similar to how it was done for Xcode plugins in Xcode 7.


Swift support
-------------

Once Swift gains support for compiler plugins, these should be supported as well. To the best of my knowledge, there are plans for such plugins but they won’t be implemented in the near future. See http://article.gmane.org/gmane.comp.lang.swift.devel/2032/match=plugins for an email on this topic. Until then, support for Swift is not included in this proposal.


Alternatives considered
-----------------------

1. Xcode could offer a well defined, stable API to access the AST of a program. However, I believe this would be a major task to implement and difficult to keep up to date with new language features in a resilient way.

2. Each extension could include the latest version of clang it supports. However, this would increase the size of the extension unnecessarily, disallow use case 1 and compilation caches created by Xcode could probably not be used as effectively if the plugin uses a different version of clang.


Disclaimer
--------------

The API I am proposing here is not aimed to be simple, but to give you maximum power in an officially supported way. I believe, you can see by the number of Xcode plugins that were available in Xcode 7 that there is a community of developers that are willing to use a complicated API to achieve such features.

This proposal isn’t carefully thought through and there may be major issues with this idea, but I hope it provides a discussion point for a powerful way to extend Xcode.

Steps to Reproduce:


Expected Results:


Actual Results:


Version:


Notes:


Configuration:


Attachments: