[PATCH] D52273: [clangd] Initial implementation of expected types

Ilya Biryukov via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Mon Sep 24 09:56:10 PDT 2018


ilya-biryukov added a comment.

> This seems very clever, but extremely complicated - you've implemented much of C++'s conversion logic, it's not clear to me which parts are actually necessary to completion quality.

Clearly the model that supports C++ conversions is something that **will** improve code completion quality.
I do agree it's not trivial, but would argue we at least want:

- qualification conversions (i.e. adding const)
- user-defined conversions (e.g. operator bool is commonly useful think)
- derived-to-base conversions (Derived* should convert to Base*)

Without those, we don't support a bunch of useful cases.

> As chatted offline, I think the return type can be split into multiple orthogonal signals. For example, const T & can be split into 3 independent signals {const, type T, reference}. I think this can make the reasoning of boosting/scoring easier for both index and code completion. Agree with Sam that we should start with something simple (e.g. type matching without conversing) and land basic components to make further evaluation possible.

Yeah, I do keep it in mind and I think it's a great idea. E.g., we can put all numeric types into one equivalence class and get rid of all numeric conversions.
That adds some complexity to the interface, though, I wanted to measure how the trivial solution (enumerate all types) works. To make sure we actually can't get away without it.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D52273





More information about the cfe-commits mailing list