Details
Diff Detail
- Build Status
Buildable 10976 Build 10976: arc lint + arc unit
Event Timeline
I hope the whole design doesn't seem overly complicated. Very much open to suggestions on how to simplify it :-)
I'm missing some context for this one:
- what's the goal? Make the code read more naturally, change the async model, or something else?
- what's the end state for codeComplete specifically? will we switch to the new overload and delete the other, or is makeFutureAPIFromCallback here to stay?
We had a discussion with @sammccall offline, probably
- what's the goal? Make the code read more naturally, change the async model, or something else?
Callback API is more flexible (if std::future that we use had then, they'd be equivalent).
We have internal clients that want to be notified about results of code completion without
- what's the end state for codeComplete specifically? will we switch to the new overload and delete the other, or is makeFutureAPIFromCallback here to stay?
I think the way to go would be exactly that, switch to the new API and remove the older one. There are usages in tests, ClangdLSPServer and in our internal client, but I'll remove them with a separate commit later.
Added a deprecation notice for the API.
clangd/ClangdServer.cpp | ||
---|---|---|
51 | I'm not sure we need a template here rather than just writing the code directly. | |
257 | Isn't this exactly where you'd want to use ForwardBinder? | |
clangd/ClangdServer.h | ||
261 | Hmm, generally having a callback as the last parameter is nicer, but this doesn't play nicely with optional params... |
clangd/ClangdServer.cpp | ||
---|---|---|
51 | Removed the template, inlined its usage. | |
257 | Yes, ClangdServer uses ForwardBinder internally. We could refactor it to accept UniqueFunction instead, but I suggest we do that in a separate commit since there are more call sites that we'll have to change. | |
clangd/ClangdServer.h | ||
261 | Right, so I opted for making it a first parameter. |
Hmm, generally having a callback as the last parameter is nicer, but this doesn't play nicely with optional params...