Just to clarify, it was like that when I got here™.
The problem is that the Verilog ctags parser doesn't seem to distinguish between "function inputs/outputs" (arguments) and "module inputs/outputs" (ports), and just tags both as "ports", and isn't too good at limiting their scope it seems.
Now, it makes sense to have ports listed in the tree because they are in scope in all of the module (which usually spans the whole file; it's rare to have more than one module definition per file), even from within functions/tasks declared inside the module, kind of like file-scope variables in C. They're a rather important thing. Same goes for variables (nets/registers) declared inside the module (maybe to a lesser degree of importance).
On the other hand, function argument names aren't used outside the function, and internal function variables aren't accessible from outside, but unfortunately ctags puts both in the same bag as module ports and variables respectively.
So this is something that should be fixed in ctags. Or for the time being I could remove both (ports and arguments), but I don't think I should do that since it'd probably be a big loss, and functions aren't that common anyway (modules are often declared entirely without using a single function, but ports are almost always there).

There are other things to fix in the ctags parser. The fact that a module instantiation (e.g. a_module uut (.*);) creates tags for both the module and the instance is wrong. It's like struct foo x; creating tags for both foo and x - it should only create the latter, since foo isn't being defined here, just used, and Ctrl-click shouldn't suggest that line as a "definition".
I'll file a few issues in ctags.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.