Fixset around SHIFT-TAB documentation

[Jan Lahoda]

Hi Shinya,

Thanks, I've pushed the patch (adjusting it slightly to avoid 
unnecessary use of JCtree).

Thanks,
     Jan

On 23.4.2015 04:04, ShinyaYoshida wrote:
> Hi Jan,
> I've just updated my patch:
> http://cr.openjdk.java.net/~shinyafox/kulla/201504171/webrev.01/
>
> Please review my patch.
>
> Thanks,
> shinyafox(Shinya Yoshida)
>
>
> 2015-04-22 23:35 GMT+09:00 Jan Lahoda <jan.lahoda at oracle.com
> <mailto:jan.lahoda at oracle.com>>:
>
>     On 21.4.2015 04:33, ShinyaYoshida wrote:
>
>         Hi Jan,
>         Thank your for your review.
>
>             I am not sure about this one. Considering:
>             "".getBytes(""
>             there is still viable continuation of this that would lead
>             to the use of the first method:
>             "".getBytes("".length(), ...)
>
>
>           > So it may be more appropriate to print also the other method
>         overloads that we cannot rule out reliably.
>
>         Ok, I agree with you.
>         The documentation will be only methods which have more than 1
>         argument,
>         such as following, right?:
>         (In the other word, REPL shouldn't print the documentation for
>         String#getBytes())
>         java.lang.String.getBytes(int arg0, int arg1, byte[] arg2, int arg3)
>         java.lang.String.getBytes(java.lang.String arg0)
>         java.lang.String.getBytes(java.nio.charset.Charset arg0)
>
>
>     Yes, I guess that would be appropriate.
>
>     Thanks,
>         Jan
>
>
>         Regards,
>         shinyafox(Shinya Yoshida)
>
>         2015-04-21 4:40 GMT+09:00 Jan Lahoda <jan.lahoda at oracle.com
>         <mailto:jan.lahoda at oracle.com>
>         <mailto:jan.lahoda at oracle.com <mailto:jan.lahoda at oracle.com>>>:
>
>
>              Hi Shinya,
>
>              Thanks for the report and patches. Comments inline.
>
>              On 17.4.2015 11:00, ShinyaYoshida wrote:
>
>                  Hi,
>                  I found some bugs(?) around SHIFT-TAB documentation.
>                  Please review my fixset for the bugs.
>
>                  Here is the fixset and tests:
>         http://cr.openjdk.java.net/~shinyafox/kulla/201504171/webrev.00/repl/src/impl/SourceCodeAnalysisImpl.java.udiff.html
>
>                  Description of issues
>                  1. REPL doesn't print method/constructor document which
>         don't
>                  have any
>                  parameter:
>
>                  -> "".length([SHIFT-TAB]
>                  [no output]
>
>                  We can't get String#length documentation.
>
>                  -> "".geｔBytes([SHIFT-TAB]
>                  java.lang.String.getBytes(int arg0, int arg1, byte[]
>         arg2, int arg3)
>                  java.lang.String.getBytes(java.lang.String arg0)
>                  java.lang.String.getBytes(java.nio.charset.Charset arg0)
>
>                  There is String#getBytes() but it is not printed
>         https://docs.oracle.com/javase/8/docs/api/java/lang/String.html#getBytes
>
>
>              I agree, the methods with no parameters should also be
>         included.
>
>
>                  2. REPL doesn't treat the last argument as argument:
>                  -> "".getBytes(""[SHIFT-TAB]
>                  java.lang.String.getBytes(int arg0, int arg1, byte[]
>         arg2, int arg3)
>                  java.lang.String.getBytes(java.lang.String arg0)
>                  java.lang.String.getBytes(java.nio.charset.Charset arg0)
>
>                  REPL prints all getBytes methods.
>                  But I think it should print only the method which the first
>                  argument is
>                  String in this case.
>
>
>              I am not sure about this one. Considering:
>              "".getBytes(""
>              there is still viable continuation of this that would lead
>         to the
>              use of the first method:
>              "".getBytes("".length(), ...)
>
>              So it may be more appropriate to print also the other method
>              overloads that we cannot rule out reliably.
>
>              Thanks,
>                  Jan
>
>
>                  Regards,
>                  shinyafox(Shinya Yoshida)
>
>
>