Skip to main content
summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorAndrew Eidsness2013-02-19 20:40:15 -0500
committerDoug Schaefer2013-02-20 11:27:03 -0500
commit2279927623d6d393db81fba7ceca12f047935bf8 (patch)
treee5a5aa01a4250376abece91abf5f2cbde0423197 /core/org.eclipse.cdt.core/plugin.properties
parent81885d232fec146ec4c1d6c1fbac552daff416ea (diff)
downloadorg.eclipse.cdt-2279927623d6d393db81fba7ceca12f047935bf8.tar.gz
org.eclipse.cdt-2279927623d6d393db81fba7ceca12f047935bf8.tar.xz
org.eclipse.cdt-2279927623d6d393db81fba7ceca12f047935bf8.zip
Bug 400020: Allow tagging of IBindings
This new extension point allows contributors to put their own information into the PDOM and to later retrieve it for their own purposes. There are many details in the bug. The idea is that contributors provide an implementation of IBindingTagger, which is given a chance to examine IBindings when they are created. The ITagWriter interface allows the contributor to create a new tag which can then have data written to it. The ITagService interface (accessible from CCorePlugin.getTagService() provides a way for the contributor to later get an instance of ITagReader to retrieve tags from bindings. ITags are copied to the PDOM when the associated binding is persisteed. Contributors use a unique id (based on their plugin id), so that multiple contributors are able to independently tag a given binding. In-memory tags are not cached. I've done some timing tests using my sample implementation and found no measurable difference. The full log lines look like: !MESSAGE Indexed 'simple-01' (2 sources, 184 headers) in <see below> sec: 21,550 declarations; 35,394 references; 0 unresolved inclusions; 1 syntax errors; 0 unresolved names (0.00%) I did 5 tests using the current master (no tagging-related code), the times were: 18.86 sec 9.17 sec 5.91 sec 4.79 sec 4.83 sec And then I ran the same sequence of tests using the code in this commit: 18.73 sec 9.39 sec 6.50 sec 4.78 sec 5.27 sec If performance does become a problem, then caching could be introduced with a new implementation of ITaggableService. The two problems are finding a key other than the identity of the IBinding (since IBindings are re-created often) and properly evicting stale entries when the binding is no longer valid. The process of copying tags from an in-memory IBinding to a PDOMBinding, is a synchronization. This means that tags that are no longer applicable, will be removed from the persistent store. While developing this I found that PDOMBindings are not deleted from the Database (only the names that reference them are deleted), so there is no provision for deleting all tags at once. New database locks are not needed. By the time the persistent tags are accessed, higher levels of code have already taken a read or write lock as appropriate. There are new unit tests covering the changes to the PDOM. Change-Id: I8da1bf5eeba7e1fc2ca7ec308ed8e212629986a4 Reviewed-on: https://git.eclipse.org/r/10407 IP-Clean: Doug Schaefer <dschaefer@qnx.com> Tested-by: Doug Schaefer <dschaefer@qnx.com> Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
Diffstat (limited to 'core/org.eclipse.cdt.core/plugin.properties')
-rw-r--r--core/org.eclipse.cdt.core/plugin.properties1
1 files changed, 1 insertions, 0 deletions
diff --git a/core/org.eclipse.cdt.core/plugin.properties b/core/org.eclipse.cdt.core/plugin.properties
index 46e1547c2f..287ee25012 100644
--- a/core/org.eclipse.cdt.core/plugin.properties
+++ b/core/org.eclipse.cdt.core/plugin.properties
@@ -121,6 +121,7 @@ CConfigurationDataProvider.name = CConfigurationData provider
projectConverter.name = project converter
CIndex.name = CIndex
externalSettingsProvider.name = External Settings provider
+tagger.name = Parser Node Tagger Extension Point
GeneratePDOMApplication.name = GeneratePDOM
defaultProvider.name = Default Provider
templatesExtensionPoint.name = Templates Extension point

Back to the top