Description
_cpp_function_match in src/physicscode_science/parsers/basic.py misidentifies single-letter variable names and words inside comments as function symbols. These artifacts score a perfect 1.0 on symbol search for almost any query (any query containing that letter matches, since a one-character string is a substring of nearly everything), then carry that perfect score unchallenged through fusion, reranking, and context expansion.
Plugins
No response
PhysicsCode version
No response
Steps to reproduce
Observed on OPALX (src/Utilities/ComplexErrorFun.cpp:57 and src/AbsBeamline/BendFieldModel.h:159).
Case 1
constructor-style initializer misread as a call:
std::complex s(0.0); // s_{N}
_cpp_function_match splits on the first (: before_paren = "std::complex s". It has no =, [, or ], so it passes the exclusion guard, and raw_name = before_paren.split()[-1] = "s". This is a variable declaration, not a function definition or call.
Case 2
a word inside a comment mistaken for a symbol:
double curvature;
There is no function call on this line at all — the only (/) pair is inside the Doxygen comment. Because the matcher never strips comments before scanning, raw_name = before_paren.split()[-1] = "h", the last word preceding that parenthesis in the comment text.
In both cases _could_match also fails to reject the line: it only excludes lines starting with //, using, typedef, return, etc., and lines ending in ;/,/. Both example lines end in a trailing comment rather than ;, so the semicolon-ending exclusion doesn't catch them.
Where
Where this shows up
- Parser: src/physicscode_science/parsers/basic.py, _cpp_function_match / _could_match
- Symbol scoring: src/physicscode_science/retrieval/symbol.py
- Context expansion picking up bogus neighbors: src/physicscode_science/graph/context.py
Screenshot and/or share link
No response
Operating System
No response
Terminal
No response
Description
_cpp_function_match in src/physicscode_science/parsers/basic.py misidentifies single-letter variable names and words inside comments as function symbols. These artifacts score a perfect 1.0 on symbol search for almost any query (any query containing that letter matches, since a one-character string is a substring of nearly everything), then carry that perfect score unchallenged through fusion, reranking, and context expansion.
Plugins
No response
PhysicsCode version
No response
Steps to reproduce
Observed on OPALX (src/Utilities/ComplexErrorFun.cpp:57 and src/AbsBeamline/BendFieldModel.h:159).
Case 1
constructor-style initializer misread as a call:
std::complex s(0.0); // s_{N}
_cpp_function_match splits on the first (: before_paren = "std::complex s". It has no =, [, or ], so it passes the exclusion guard, and raw_name = before_paren.split()[-1] = "s". This is a variable declaration, not a function definition or call.
Case 2
a word inside a comment mistaken for a symbol:
double curvature;
There is no function call on this line at all — the only (/) pair is inside the Doxygen comment. Because the matcher never strips comments before scanning, raw_name = before_paren.split()[-1] = "h", the last word preceding that parenthesis in the comment text.
In both cases _could_match also fails to reject the line: it only excludes lines starting with //, using, typedef, return, etc., and lines ending in ;/,/. Both example lines end in a trailing comment rather than ;, so the semicolon-ending exclusion doesn't catch them.
Where
Where this shows up
Screenshot and/or share link
No response
Operating System
No response
Terminal
No response