Sysprogs forums › Forums › VisualGDB › CLANG INTELLISENSE: THE SELECTED LOCATION DOES NOT REFER TO A C/C++ ENTITY
- This topic has 10 replies, 2 voices, and was last updated 4 years, 11 months ago by support.
-
AuthorPosts
-
November 29, 2019 at 18:25 #26660mattiaParticipant
Hello,
I have a strange behaviour in my program (an STM32L100 uC written in plain C). I’m using VisualGDB 5.4R12 build 3309.
When I use the code completion for some entities, it is working correctly: this is a part of my code:
HAL_GPIO_WritePin(RELE_VEL1_GPIO_Port, RELE_VEL1_Pin, GPIO_PIN_RESET); //spengo VEL1 HAL_GPIO_WritePin(RELE_VEL2_GPIO_Port, RELE_VEL2_Pin, GPIO_PIN_RESET); //spengo VEL2 HAL_GPIO_WritePin(RELE_VEL3_GPIO_Port, RELE_VEL3_Pin, GPIO_PIN_RESET); //spengo VEL3 HAL_GPIO_WritePin(RELE_RES_50_GPIO_Port, RELE_RES_50_Pin, GPIO_PIN_RESET); //spengo VEL1 HAL_GPIO_WritePin(RELE_RES_100_GPIO_Port, RELE_RES_100_Pin, GPIO_PIN_RESET); //spengo VEL2
I use code completion for RELE_VEL1_Pin, completing the word. If I hover the mouse over the word or using CTRL+click is, it is correctly identified;
After compiling, the links are lost, RELE_VEL1_Pin is now RELE_VEL2_Pin, RELE_VEL2_Pin is now RELE_VEL3_Pin, all shifted down.
However, during the debugging the code is handled correctly.
It seems as if the program still contains some cache. I already tried to delete the VisualGDBCache, but it doesn’t work.
Do you have an idea of what it could be?
Thank you,
Mattia Berton
November 29, 2019 at 18:28 #26661supportKeymasterHi,
It looks like your technical support has expired. In order to continue receiving technical support, please renew your support here: https://sysprogs.com/splm/mykey
December 3, 2019 at 12:49 #26704mattiaParticipantHello,
I renewed the support.
December 3, 2019 at 18:35 #26710supportKeymasterThanks for renewing your support. VisualGDB indeed has an IntelliSense cache located in the CodeDB directory (the exact location depends on the project type). Please try closing the solution, deleting the CodeDB directory and reopening it.
If it doesn’t help, please clarify what exactly do you mean by “all links are lost”. If you could attach a screenshot highlighting the problem, it should be easy for us to understand what is going on and suggest a more specific solution.
December 5, 2019 at 19:23 #26741mattiaParticipantHello,
I tried to remove che CodeDB directory, but without success.
Anyway, this is what I mean for “lost links”. If I make a code completion (CTRL+Space), the code is correctly interpreted, as you can see in the image named “correct”: I hovered the mouse over the “RELE_VEL1_GPIO_Port” label, and you can jump over its definition without problem.
If I compile the project, it appears it loses the links, like in image “faulty”: I hovered the mouse over the “RELE_VEL1_GPIO_Port” label, it is now “RELE_VEL2_GPIO_Port” and with CTRL+click I go to the wrong label. Sometimes, when the links are no more present, the message “the selected location does not refer to a C/C++ entity” appears, like in the “miss link” image.
Can you help me?
Thank you,
Mattia Berton
Attachments:
You must be logged in to view attached files.December 6, 2019 at 06:01 #26752supportKeymasterSorry, could you please post a screenshot of the entire VS window as well. It really shows a lot of important information about the state of the Clang engine (see this explanation). Otherwise, it’s virtually impossible to guess what is going on.
Second of all, does the problem happen with GPIO_PIN_Reset? If yes, please try the following:
- Try simplifying the expression as much as possible. E.g. “int x = GPIO_PIN_Reset”. Does this still reproduce the problem? If not, is there any specific change between the repro code and the “int x” example that changes the behavior?
- If the simple case still triggers the problem, does moving right after the preamble (i.e. block of #include<>’s) change anything?
- What happens if you add another enum (not just another value to an existing enum) near the place where GPIO_PIN_Reset is defined? Will it trigger the problem as well?
- If yes, what if you move the newly added enum to the source file that triggers the problem (try putting it before and after the #include<> block)?
December 6, 2019 at 10:18 #26753mattiaParticipantHello,
the problem appears with almost a lot of labels. I’m attaching the errors to the following message, including the activity log on the left. I included because an error appears when I try to CTRL+click for the first time a function (it says: “An exception of type “OperationCanceledExeption” has been encountered. This may be caused by an extension), and it could be related to the problem above.
Regarding your points:
- I put the inctruction “int x = GPIO_PIN_RESET;” almost everywhere, but it doesn’t solve the problem.
- I put it anywhere, problem is still there.
- Problem is still there
- Problem is still there
I don’t know if it can help, but my system is a Win7 platform working in a small local network. I have stopped the service Windows Update and Windows installer.
Thank you,
Mattia Berton
Attachments:
You must be logged in to view attached files.December 6, 2019 at 10:27 #26758mattiaParticipantAlso, this is the configuration for Intellisense, as attached.
Thank you,
Mattia Berton
Attachments:
You must be logged in to view attached files.December 6, 2019 at 18:06 #26779supportKeymasterThanks for posting the screenshots. It looks like the in the “correct” step the file is not saved. Could you please check whether the problem gets immediately triggered by saving the file, rather than building the project?
Also please try replacing the entire contents of the main file with this:
enum { MY_TEST_ENUM = 1 }; void test() { int x = MY_TEST_ENUM; }
Then save the file and try going to definition of MY_TEST_ENUM. Does it work? If yes, try reverting to the old file contents and putting both the definition and the use just after the #include<> block.
If this doesn’t work, try putting it before the #include<> block.
If placing it just after #include<> block works, try keeping the definition on top and moving the use at the end of the file. If this triggers the problem, try locating a specific spot in the source file, after which the go-to-definition stops working. Most likely, it has some special character that confuses Clang. If you could eliminate the references to external code (so that it would load on our side), zip the repro file (to preserve encoding) and send it to us, we should be able to fix this.
December 11, 2019 at 18:45 #26852mattiaParticipantHello,
I have been able to find the instruction which creates the problem, however I can’t understand why. I can send you the sln, just tell me the mail where to send.
Anyway let me explain: I followed your instruction, and the problem gets triggered with the “save” button. I replaced the main file (commenting the intere file) with the snippet, and Clang works if the snippet is placed before the comment, while it gives a mistake if it is placed at the end of the comment.
Then I placed the snippet after the #include block, and Clang works. However it stop working if I put it after the variable declaration:
BARRIERA_STATO stato_barriera; //uso solo le velocità
where BARRIERA_STATO is an enum defined as follows:
typedef enum
{
BARRIERA_STATO_OFF = 0, //bit 2-1-0
BARRIERA_STATO_ON,
BARRIERA_STATO_DUMMY2,
BARRIERA_STATO_DUMMY3,
BARRIERA_STATO_DUMMY4,
BARRIERA_STATO_DUMMY5,
BARRIERA_STATO_DUMMY6,
BARRIERA_STATO_DUMMY7,BARRIERA_VARIANTE = 8, //bit 3 (0 = veriante1)
BARRIERA_VELHI = 16, //bit 5-4
BARRIERA_VELMED = 32,
BARRIERA_VELLO = 48,BARRIERA_RES_50 = 64, //bit 7-6
BARRIERA_RES_100 = 128,
BARRIERA_DUMMY8 = 192
}BARRIERA_STATO;included in an header file. From my point view, I can’t find why this enum confuses the Clang. Do you have an idea?
Thank you,
Mattia Berton
December 11, 2019 at 19:22 #26855supportKeymasterMost likely, the file contains some invisible Unicode character that confuses Clang. Please send an archive with the project to support@sysprogs.com and we will investigate it (please delete the .vs, CodeDB and VisualGDB subdirectories before archiving the project).
-
AuthorPosts
- You must be logged in to reply to this topic.