[MINOR][DOC] Fix comments of ConvertToLocalRelation rule

[seancxmao]

What changes were proposed in this pull request?

There are some comments issues left when ConvertToLocalRelation rule was added (see #22205/SPARK-25212). This PR fixes those comments issues.

How was this patch tested?

N/A

[SparkQA]

Test build #99909 has finished for PR 23273 at commit dfd0f71.

• This patch fails Spark unit tests.
• This patch merges cleanly.
• This patch adds no public classes.

[seancxmao]

retest this please.

[SparkQA]

Test build #99944 has finished for PR 23273 at commit dfd0f71.

• This patch passes all tests.
• This patch merges cleanly.
• This patch adds no public classes.

[srowen]

Maybe we should just not specify this in the docs. Are you sure the [[...]] links work when you generate scaladoc? the test builder doesn't check. I've seen many errors/warnings generated by some types of links.
If so again maybe easier to restrict this to merely removing this line.

[seancxmao]

@srowen Sorry, I found that the links just do not work for scaladoc, though they works in IDE like Intellij IDEA. I should have generated the docs to see if there's any problem.

I have changed [[...]] to backticks in a new commit.

Also, I have some findings:

• Because org/apache/spark/sql/catalyst is excluded for doc generation, I include catalyst in SparkBuild.scala and run build/sbt unidoc, there are many errors/warnings, should we fix these problems? Seems simple but many places.
• As for [[...]], fully qualified class name should be used if a link points to a class in another package. If the link points to a class in the same package, package prefix could be omitted.

[srowen]

catalyst isn't meant to be a public API (for our convenience, it's not all marked private in the source). That's why it's not in the docs and yeah that's why writing references to it won't work, as I recall.

For this comment I think it's simplest to remove it, or leave it but don't add references, or move it to an inline comment.

[seancxmao]

Thanks a lot @srowen for your explanation. Since it's not a public API and the code is clear, it makes sense to remove this line, this can also eliminate the needs to modify this line when new cases are added. I have removed this line in the new commit.

[srowen]

I also wouldn't tag this as SPARK-25212 as that was merged into 2.4.0. This is just a "MINOR" change

[SparkQA]

Test build #100006 has finished for PR 23273 at commit 1cca847.

• This patch fails due to an unknown error code, -9.
• This patch merges cleanly.
• This patch adds no public classes.

[seancxmao]

retest this please.

[SparkQA]

Test build #100032 has finished for PR 23273 at commit 1cca847.

• This patch fails SparkR unit tests.
• This patch merges cleanly.
• This patch adds no public classes.

[seancxmao]

retest this please.

[SparkQA]

Test build #100054 has finished for PR 23273 at commit 1cca847.

• This patch fails SparkR unit tests.
• This patch merges cleanly.
• This patch adds no public classes.

[seancxmao]

@srowen The build failed twice because of the same reason. It seems we ran into SparkR CRAN feasibility check server problem, which blocks PR build.

Error messages from log:

* this is package 'SparkR' version '3.0.0'
* checking CRAN incoming feasibility ...Error in .check_package_CRAN_incoming(pkgdir) : 
  dims [product 24] do not match the length of object [0]
Execution halted

[seancxmao]

retest this please.

[SparkQA]

Test build #100075 has finished for PR 23273 at commit 1cca847.

• This patch fails due to an unknown error code, -9.
• This patch merges cleanly.
• This patch adds no public classes.

[seancxmao]

retest this please.

[SparkQA]

Test build #100082 has finished for PR 23273 at commit 1cca847.

• This patch passes all tests.
• This patch merges cleanly.
• This patch adds no public classes.

[srowen]

Merged to master

[seancxmao]

Thank you! @srowen