Open Redoubts opened 4 years ago
Sorry I must've missed this issue. I agree definitions should be tagged different than calls, and that meta isn't good for theming.
The C grammar needs a re-write, which is being worked on. That will fix the meta
tag issue.
However, in C++ situation is more complicated due to the parsing engine itself (TextMate). AFAIK GitHub gets around this issue because they're using the much more powerful TreeSitter parser.
The following code is currently parsed correctly for me:
static void * worker_thread(void *arg) {
s_set_id(worker);
}
entity.name.function.definition
for worker_thread
entity.name.function.call
for s_set_id
The issue arises when the return value is on the previous line. The current parser (TextMate parser) can only ever "look" at one line at a time. It can switch contexts based on that line (e.g. switch into or out-of a I'm-in-a-function-body
context or an I'm-in-a-struct-definition
context) however it can't actually look ahead to see what is on the next line.
Right now the grammar basically looks for [return type] [func name] (
using a 4,000-character-long regular expression in order to activate the function-definition context. However, [func name] (
basically activates the function-call pattern.
This isn't to say nothing can be done, however it does mean that assumptions need to be made. For example, [return type]
could activate the function definition context, and then we could match the function name after that. The problem is that [return type]
can also overlap with other things, like variable declarations.
int
a;
// vs
int
main() {
}
Or for a more realistic example
std::unordered_map<
std::string, std::pair<std::string, std::map<std::string, std::map<std::string, std::map<std::string, std::pair<std::string, std::map<std::string, std::map<std::string, std::map<std::string, std::vector<std::string>>>>>>>>>
>
d;
std::unordered_map<
std::string, std::pair<std::string, std::map<std::string, std::map<std::string, std::map<std::string, std::pair<std::string, std::map<std::string, std::map<std::string, std::map<std::string, std::vector<std::string>>>>>>>>>
>
aFunction() {
// code
}
Even beyond that, std::unordered_map<
cannot even be confirmed to be a less than operator.
thing1<
int
> a;
thing2 <
100 + 0x5368 && std::cout << "thing 2 is small I guess";
However, we can at least tell if it is in the root context or not. However (unlike C AFAIK), function calls can occur in the root context.
So there probably are complex assumptions that could be made to improve this. Sadly the grammar isn't quite there yet, so it might be awhile before this is improved.
thing2 < 100 + 0x5368 && std::cout << "thing 2 is small I guess";
That actually isn't valid c++
Routed here from https://github.com/microsoft/vscode-cpptools/issues/5331
Checklist
[x] This problem exists even with the setting
"C_Cpp.enhancedColorization": "Disabled"
[x] This bug exists for C
[x] This bug exists for C++
[ ] This bug exists for Objective-C
[ ] This bug exists for Objective-C++
OS and Version: MacOS 10.15.4
VS Code Version: 1.44.2
MS C/C++ Extension Version: 0.27.0
In C and C++, function names at definition and invocation are marked with the same scope labels. I would expect these scope labels to be different because
1) In outside documentation, this is suggested:
2) I see other languages and editors make this distinction. Indeed, GitHub formatting gives different colors, as seen in snippets below.
For example, using some zmq code, the C version has
The defined function name "worker_task" is marked with the scopes
and "s_set_id" is marked with scopes
entity.name.function
at the top level, which likely means any meta tags a theme uses will be ignored always.Similarly, the C++ version has
with the defined function "worker_thread" marked with the scopes
and "s_set_id" with the scopes
entity.name.function.call
(???), creating a similarly vexing situation.