The javadoc for BTree.insert says "don't insert if the key was already
there, in which case we return the record that matched".
However, the implementation was returning the new record even when it
was not actually inserted.
This is a fix for the problem and a test case to demonstrate the issue.
Further Changes:
----------------
I have modified the code style as described in the comments in
https://git.eclipse.org/r/#/c/10804.
However, I'm still not sure what style is expected. I've looked through
the CDT wiki a few times, especially the 'new developer' parts, but
haven't found anything relevant. When I asked the question a few weeks
ago, the only reply was to use the "eclipse built-in style", which I
can't find in my preferences. The default seems to be "K&R Style" (that
is what it is set to now, and I don't think that I would have changed
it), so that is what I've used here.
If I've missed the section in the wiki then a pointer would be greatly
appreciated. Otherwise this topic would be a great topic for someone
that knows the answers to add to the wiki.
Change-Id: If079f235871fcdfbd35f1cba3f64cc3e33edaaec
Reviewed-on: https://git.eclipse.org/r/10804
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
Tested-by: Doug Schaefer <dschaefer@qnx.com>
Addresses review comments from https://git.eclipse.org/r/#/c/10648.
Fixes the junit problems by making sure that the dummy PDOM acquires its
write lock before calling exercising the tag index.
Original commit message:
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: I6ae1afc949082f7f4484b3faa1550670be43312f
Reviewed-on: https://git.eclipse.org/r/10659
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
Tested-by: Doug Schaefer <dschaefer@qnx.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>
first parameter in constructor
createBinding is called twice for the enumeration specifier because now
ImplicitsAnalysis calls createType on the constructor parameter
declaration. The second time it is called, it wrongly thinks the
specifier is a redefinition. We can check that it's not a redefinition
by comparing the ast names.
Change-Id: If7fb168d578a7a59e78867d6d8154e0866d2a730
Reviewed-on: https://git.eclipse.org/r/10272
Reviewed-by: Sergey Prigogin <eclipse.sprigogin@gmail.com>
IP-Clean: Sergey Prigogin <eclipse.sprigogin@gmail.com>
Tested-by: Sergey Prigogin <eclipse.sprigogin@gmail.com>
