Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

haxe --display "No completion point was found" for leading // comment #10322

Closed
jcward opened this issue Jul 23, 2021 · 3 comments
Closed

haxe --display "No completion point was found" for leading // comment #10322

jcward opened this issue Jul 23, 2021 · 3 comments
Assignees
Labels
bug feature-ide IDE / Editor support

Comments

@jcward
Copy link
Contributor

jcward commented Jul 23, 2021

I'm trying to use module-symbols to detect the type definitions in a file., but --display fails if the byte specified falls within a single-line comment

I would typically inspect a file like so:

./haxe --display Test.hx@0@module-symbols

But unfortunately, a common scenario is a comment at the top of a file:

// Copyright something

class Test { public function new() {} }

Which results in:

>haxe --display Test.hx@0@module-symbols
Error: No completion point was found

Note that all of the following do work:

/* Copyright something */
class Test { public function new() {} }

(note leading whitespace):

 // Copyright something
class Test { public function new() {} }

I would think that // and /* comments would be treated the same.

Workaround:

Some less-than-ideal workarounds include:

  • Detect the leading comment length N and construct my command as: haxe --display Test.hx@${ N }@module-symbols
  • Change all my source files with leading // comments -- either to /* */ comments, or simply add a \n or at the beginning.
@RealyUniqueName RealyUniqueName added bug feature-ide IDE / Editor support labels Jul 23, 2021
@RealyUniqueName RealyUniqueName added this to the Bugs milestone Jul 23, 2021
@Simn Simn self-assigned this Jul 26, 2021
@Simn
Copy link
Member

Simn commented Jul 26, 2021

I would think that // and /* comments would be treated the same.

Well, that's not quite true because unlike /* we never interpret // as possible documentation comments.

However, in this situation // should obviously not cause any issues.

@Simn
Copy link
Member

Simn commented Jul 26, 2021

This is related to #7050. The special case is that the display position is 0 and thus is considered to be "in" the comment, which is pretty silly...

@Simn Simn closed this as completed in 1d5f076 Jul 26, 2021
@jcward
Copy link
Contributor Author

jcward commented Jul 26, 2021

Thank you, @Simn.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug feature-ide IDE / Editor support
Projects
None yet
Development

No branches or pull requests

3 participants