When I initially released this project, I released it under my own copyright. I
have since then worked on it in my 20% time at Google (and want to continue
doing this) and my life becomes much simpler if the copyright is Google's.
From the perspective of how this project is run and managed, **NOTHING**
changes. YCM is not a Google product, merely a project run by someone who just
happens to work for Google.
Please note that the license of the project is **NOT** changing.
People sending in future pull requests will have to sign the Google
[CLA](https://developers.google.com/open-source/cla/individual) (you can sign
online at the bottom of that page) before those pull requests could be merged
in. People who sent in pull requests that were merged in the past will get an
email from me asking them to sign the CLA as well.
This means we can now load just ycm_client_support (which is a much smaller
library) into Vim and ycm_core into ycmd. Since ycm_client_support never depends
on libclang.so, we never have to load that into Vim which makes things much,
much easier.
The server is multi-threaded and will spawn a new thread for each new request.
Thus, the completers need not manage their own threads or even provide async
APIs; we _want_ them to block because now were implementing the request-response
networking API.
The client gets the async API through the network (i.e., it can do something
else while the request is pending).
Previously, "Foo" would match "Foo" but not "FOO". Now it matches both. Bottom
line, an uppercase char matches only uppercase chars but lowercase chars can
match either. We used to insist that lowercase chars in the query match
lowercase chars in the candidate strings IF the query also had uppercase
letters; this was dumb and a poor user experience.
Fixes#501.
GetWordBoundaryChars would return "allcaps" for "ALL_CAPS" instead of "ac". This
would manifest as ranking (for instance) "STDIN_FILENO" ahead of "stdin" for
query "std", which is terrible.
This bug has been present in YCM for many months, but no one noticed the issue.
Fixes#272.
Previously, a string like 'foo\'bar\'zoo' would make the collection process
think that "bar" is not inside a string because it wouldn't recognize that the
quotes are escaped. Now it does.
Fixes#143.
This change should fix the random hangs and segfaults when using the clang
completer. Also, assertion errors printed to the console on vim exit should go
away too, same thing with segfaults on vim exit. These "on exit" errors were
caused by not cleanly shutting down the background threads; both the identifier
completer and the clang one now join the threads on destruction. This results in
a clean shutdown.
The new clang completer architecture now uses only one clang thread (again)
instead of a completion and parsing thread. Since the parsing task needs to wait
on the completion task if it was started first (and vice-versa) there's no point
to using two threads. The desired "simplicity" of using two threads for these
two tasks actually created needless complexity (and bugs). Sigh. Such is life.
A TranslationUnit abstraction was also created and this in turn also reduces the
complexity of the clang completer.
The clang completer now also has some (very) basic tests.
We limit the number of candidates returned to Vim to 20 and also make sure that
we are not returning any duplicate candidates. This provides a noticeable
improvement in latency.
This removes the need for a special overload for AddCandidatesToDatabase. Also,
the GetFuture function now provides a more sensible API with the list being
returned instead of accepted as an out parameter.
llvm also has a copy of gtest in its source tree. This causes cmake to bork
since it sees several different targets with the same name (gtest and
gtest_main). So we have to rename our versions of gtest and gtest_main to
something else... We're just appending _ycm now.
This will cause pain when we want to update gtest in the future from upstream,
but I don't see a better way of handling this.
The problem was that should have been using a longest common subsequence
algorithm for the "number of word boundary character matches" calculation. Our
old approach would fail for the following case:
Query: "caafoo"
Candidate1 : "acaaCaaFooGxx"
Candidate2 : "aCaafoog"
Candidate1 needs to win. This is now also a test case.
The point is that we want to prefer candidates that have the query characters
"earlier" in their text, e.g. "xxabcxxx" over "xxxxxabc" for "abc" query.
