Review Request: Further improve auto-completion in switch statements.

[Olivier Jean de Gaalon]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105561/#review15946
-----------------------------------------------------------


Sorry, one of my comments last time probably wasn't clear...


languages/cpp/codecompletion/context.cpp
<http://git.reviewboard.kde.org/r/105561/#comment12574>

    Holy conditional, batman!
    I didn't mean to combine both of return cases :)
    
    I meant something tamer... like:
    -----
    if (ConstantIntegralType::Ptr constantIntegralType = decl->type<ConstantIntegralType>() &&
        TypeUtils::isIntegerType(constantIntegralType.cast<IntegralType()))
      return true;
    
    IntegralType::Ptr integralRetType;
    if (acceptHelperItems && FunctionType::Ptr funType = decl->type<FunctionType>())
        integralRetType = funType->returnType().cast<IntegralType>())
    
    return integralRetType && TypeUtils::isIntegerType(integralRetType);
    -----
    Bonus: you can go back to the previous per-case comments and no fall-through.


- Olivier Jean de Gaalon


On July 16, 2012, 8:37 a.m., Ivan Shapovalov wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105561/
> -----------------------------------------------------------
> 
> (Updated July 16, 2012, 8:37 a.m.)
> 
> 
> Review request for KDevelop and Olivier Jean de Gaalon.
> 
> 
> Description
> -------
> 
> Only compile-time integral constants are valid in "case ..."
> statements, so filter any certainly non-constant completion items.
> 
> This has 2 usability issues (well, not issues, but questionable points):
> 1) We do not filter type-names since they can be used either as scopes
> (SomeType::someConstant) or as ctor-like initializers
> (SomeIntegralTypedef(42)).
> 2) We do not filter integer-returning functions since they
> can be constexpr (thus syntactically usable) but we cannot handle
> constexpr now.
> 
> But, since one rarely would use these items, their match quality
> is forced to zero in order to avoid pollution of "best matches".
> 
> 
> Diffs
> -----
> 
>   languages/cpp/codecompletion/context.h e17fe7c 
>   languages/cpp/codecompletion/context.cpp 34bc728 
>   languages/cpp/tests/test_cppcodecompletion.h f88eb01 
>   languages/cpp/tests/test_cppcodecompletion.cpp eb44618 
> 
> Diff: http://git.reviewboard.kde.org/r/105561/diff/
> 
> 
> Testing
> -------
> 
> Unit-tests have been made aware of the newly-introduced filtering (+ added a new unit-test verifying the filtering itself); usability has been discussed with Olivier Jean de Gaalon.
> 
> 
> Thanks,
> 
> Ivan Shapovalov
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20120716/62b904ea/attachment.html>