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

[C++] Go to function append the return type of the function to the function name if separated on a different line if the return type is a custom type #3938

Open
Haiderahandali opened this issue Mar 3, 2024 · 4 comments
Labels
C: Syntax T: bug A bug in an existing language feature

Comments

@Haiderahandali
Copy link

Expected behavior

The same behavior that exists for built in types (int, void)

Actual behavior

The return type is being appended to the function name in goto function as shown in the video below:

possible.bug.for.function.name.mp4

Note the issue does not happen with void and int types for example (I have not tested but probably all built in types works fine)

Steps to reproduce

define Internal as static #define Internal static
define your own struct
separate the return type prefixed by Internal in its own line, while the function name in the line after it.

@Haiderahandali
Copy link
Author

As discussed in the discord, this seems to be related to the macros
here is a video showcasing that it does work with static and not with Internal despite it being just
#define Internal static

Sublime.Bug.Update.mp4

@deathaxe
Copy link
Collaborator

deathaxe commented Mar 3, 2024

Syntax definition effectively doesn't currently (fully) support function declarations spanning multiple lines for historical reasons - caused by regexp patterns applying on individual lines, only.

It is possible to achive that - e.g. Java does already, but it requires major overhaul of the whole syntax definition.

@deathaxe deathaxe added T: bug A bug in an existing language feature C: Syntax labels Mar 3, 2024
@Haiderahandali
Copy link
Author

Haiderahandali commented Mar 3, 2024

@deathaxe so should I assume this is not going to be fixed within a week or two? because if I so I will just stop using it (despite it being useful for me honestly)

@deathaxe
Copy link
Collaborator

deathaxe commented Mar 3, 2024

I don't think so.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: Syntax T: bug A bug in an existing language feature
Projects
None yet
Development

No branches or pull requests

2 participants