to cdt-file-types-list (as defined in c++ standard section 17.6.1.2)
Change-Id: Idbbba12655a72b24cd28aab71d9a613320a7e70c
Signed-off-by: Lukas Felber <l.felber@gmx.ch>
Reviewed-on: https://git.eclipse.org/r/24854
Tested-by: Hudson CI
Reviewed-by: Sergey Prigogin <eclipse.sprigogin@gmail.com>
Tested-by: Sergey Prigogin <eclipse.sprigogin@gmail.com>
Adds a -exclude option to list directories and files that are to be
excluded from the pre-built PDOM so we don't get header files that
users don't get suggest optional headers.
The problem is solved by allowing to ignore duplicated markers in case
there is already loaded a plugin that could handle QML files
The ProblemMarkerFilter extension point allows to filter out unneeded
problem markers. For example during building of Qt base project with QML
files tool Qt Linguist could report syntax errors in some qml file.
These errors are presented as "C/C++ Problems" in qml files because they
match format CDT expects for errors. If there is already installed plug-in
that handles QML files it is a wise to ignore such errors because they
are already reported as "QML Problems" with more meaningful descriptions.
Change-Id: I3a0a1b58e9690bed9c2774e4328760c695d54a54
Signed-off-by: Daniel Pesch <dpesch@blackberry.com>
Reviewed-on: https://git.eclipse.org/r/20581
Tested-by: Hudson CI
Reviewed-by: Andrew Eidsness <eclipse@jfront.com>
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
The CDT persists an index of source code relationships by processing the
AST produced by the parser. There is an existing extension-point that
allows contributors to create new linkages in this persisted file.
However there is no mechanism allowing contributors to influence the
data that is stored to the file.
This introduces a new extension-point allowing contributors to
participate in processing the AST that is being persisted to the index.
The intent is for this to be used to store data into the contributor's
new Linkage.
There is no change in functionality for existing linkages. A
contributor will soon be added in the Qt plugin.
Change-Id: I845c90cbf7c713e23319e2ed1168eb7d74db5868
Signed-off-by: Andrew Eidsness <eclipse@jfront.com>
Reviewed-on: https://git.eclipse.org/r/19089
Tested-by: Hudson CI
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
This change introduces three new ProcessRunners that can be used in the
New Project wizard's template.xml files. These will be used by two new
Qt project wizards that I will introduce in a second patch.
The three new rules are:
1) "AddMakeTarget" which creates new Make Targets (in the Make Targets
view) for the new projects.
2) "SetEnvironmentVariable" which sets an environment variable in all of
the new project's build configurations.
3) "ExtraLanguageSettingsProvider" which modifies the new project's
build configurations to include a new ILanguageSettingsProvider.
The first two are straightforward, the third is a bit different.
Instead of creating a new Toolchain or Configuration it modifies the
Configurations that were created for the new project. In this case the
only modification is to add the extra ILanguageSettingsProvider, but it
might be useful to extend this to other customizations as well.
Change-Id: I30710400e9b0dffcbe6e8965ce7ce2078c1c99ca
Signed-off-by: Andrew Eidsness <eclipse@jfront.com>
Reviewed-on: https://git.eclipse.org/r/16817
Reviewed-by: Andrew Gvozdev <angvoz.dev@gmail.com>
IP-Clean: Andrew Gvozdev <angvoz.dev@gmail.com>
Tested-by: Andrew Gvozdev <angvoz.dev@gmail.com>
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>
- Reworked IFileSystem utility so that now it is noimplement/noextend. Clients should now extend from concrete class FileSystemUtility instead to better insulate them from future API changes.
- Reworked the resulting concurrency fixes - indexing and scanner discovery now synchronize on the project root as a scheduling rule. Original HEAD behaviour was to synch on the project's .settings folder for indexing, but that deadlocked with scanner discovery.
- Fixed remote indexing. Changes on HEAD that deprecated CodeReader broke the ability for remote translation units to provide the path to load the file content from. Added API to ITranslationUnit for this purpose.
