[BUG] Global variable not found

[vadim-96]

Describe the bug If a global variable is set, the extension doesn't see it.

Steps To Reproduce Steps to reproduce the behavior:

1. Create __init__.robot with VAR ${WELCOME} Hello scope=GLOBAL
2. Create test.robot file and write a simple test
3. Add ${WELCOME} in your test
4. See an error Variable '${WELCOME}' not found.robotcode(VariableNotFound) in VS Code

Desktop:

• VS Code Version 1.97.0
• RobotCode Version 0.108.1
• OS: Windows 10
• Python Version 3.13
• RobotFramework Version 7.12

[gohierf]

I believe this question has already been answered here and here.

@vadim-96 do you agree this is the same topic?

[vadim-96]

This is the same topic, but it seems that it's a frequent problem. I don't think that static analyzers in other languages have the same behavior for global vars.

[vadim-96]

By the way the global variables from Robot Framework are parsed without errors, why? https://robotframework.org/robotframework/latest/RobotFrameworkUserGuide.html#automatic-variables

[gohierf]

That is an interesting question. I don't think they are treated as global variables, they are presented as “automatic” variables. And I guess the decision was to add them for autocompletion, but there is no real check of their availability.

In some cases (see availability column) these variables are actually not there, for instance ${KEYWORD STATUS} should not be used outside a keyword. Interestingly enough, neither RobotCode nor Robocop warn about that. I guess this is worth an enhancement request (there it is for Robocop, I am waiting for @d-biehl input here to see if it is worth opening an issue regarding automatic variables for RobotCode).

Note that this case is a simple one, when the availability is "Everywhere" then there is no issue either. But for other availability like "Test Case", "Test Teardown", "Suite Teardown" and "User Keyword Teardown" I am not sure that RobotCode can actually work out if the variable is used in the correct situation, again because of static vs dynamic analysis. Nor would it make a lot of sense to require the user to define them in the variable section to set a default value to remove the warning (it does not seem to be good idea).

I guess we could have a warning like: "${TEST NAME}" variable is used in this keyword, but the keyword is used in a suite setup. (Although there could be a TRY/EXCEPT block, or something else, specifically to deal with this situation, so a warning could be a false positive...).