Nvim-treesitter: Incorrect definition highlighting in for different scopes

Created on 2 Jul 2020  路  4Comments  路  Source: nvim-treesitter/nvim-treesitter

Describe the bug
Definition is incorrect when the focused symbol is the definition.

To Reproduce
Given this javascript file

nvim-ts-error-1

When the cursor is on the variable a (not the function parameter), the function parameter a is highlighted as the definition.
If the parenthesis are removed from the arguments the variable definition is flagged as the definition of the argument.'

nvim-ts-error-2

Expected behavior
Neither one should be highlighted since they are in different scopes and are definitions them self. This may just be an issue with the queries for javascript or the algorithm used for finding definitions.

Output of :checkhealth nvim_treesitter *

Paste the output here

Output of nvim --version

Paste your output here

Additional context
Add any other context about the problem here.

bug

Most helpful comment

@theHamsta , I don't really agree with that, in the case of functions for example, you can find the definition of that function below the cursor (for example in Rust).
Regarding the fact it finds things somewhere else is quite weird, as it should only go upwards in scope hierarchy, that needs a bit of investigation.

All 4 comments

@vigoux It may be. I need to look into a little bit further.

Sorry deleted the coment, but it might be related to locals.

I think the find_definition should always find declarations before the current cursor position.

Consider the following example:

void normalReactionTest(cr::HCSITS& cr, SphereID sp)
{
   contactThreshold = Thresholds<real_t>::contactThreshold();
   // plane at 5,5,5
   // radius 1.1
   sp->setPosition(  Vec3(5,5,6) );
   sp->setLinearVel( Vec3(0,0,0) );
   cr.setErrorReductionParameter( real_t(1.0) ); // <----------------- cursor at beginning of line
   cr.timestep( real_c( real_t(1.0) ) );
}

int main( int argc, char** argv )
{
   cr::HCSITS cr(globalBodyStorage, forest->getBlockStoragePointer(), storageID, hccdID, fcdID); // <-- will find this definition
   return EXIT_SUCCESS;
}
} // namespace walberla

Without #145 it can't recognize the definition of cr as an arguments and finds cr in a completely different scope (no ideas why it can find stuff from a different scope)

@theHamsta , I don't really agree with that, in the case of functions for example, you can find the definition of that function below the cursor (for example in Rust).
Regarding the fact it finds things somewhere else is quite weird, as it should only go upwards in scope hierarchy, that needs a bit of investigation.

Was this page helpful?
0 / 5 - 0 ratings