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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
