-
Notifications
You must be signed in to change notification settings - Fork 450
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IntelliSense uses the short name from the variants file for buildType #2120
Comments
We can start by looking at logs. With version 1.8.1 installed, can you:
Please also share which version of CMake you are using and your operating system. |
CMake 3.21.1 1.8.1
1.7.3
|
Ok, so the extension doesn't seem to be sending the configuration over to cpptools. Can you set the |
Let me know if I strip too much. 1.8.1
1.7.3
|
Hmm... Everything looks normal in those logs. Can you do a search in the I might need to add some additional logging to figure this out since I don't have access to your project. |
Yes, the file name is present in the target*.json files. |
I also have the excatly same problem, roll back to 1.7.3 works for me |
I have the same (or very similar) problem. VSCode 1.60.2, CMake-Tools 1.8.1. Cmake by itself is working fine and my project compiles even though IntelliSense is confused silly. Some additional information:
When I run "CMake: Configure", the command completes successfully. I set cmake.debugLevel to "debug", and here is the output:
FYI, my compiler is installed on the system path, if it makes any difference. Here is the output of the command "C/C++: Log Diagnostics":
The used compiler is arm-none-eabi-gcc, which can be confirmed in the first log output above. Somehow IntelliSense insists on using clang. I have no idea where the discrepancy originates. As with other users, downgrading to 1.7.3 fixes the issue. 1.8.0 shows the same behavior as 1.8.1. |
I also have the same problem, roll back to 1.7.3 works for me. |
I have a VSIX with the new logging available. You can download it here: https://github.com/microsoft/vscode-cmake-tools/suites/3885617265/artifacts/96792132 Then you just unzip it and run the |
@bobbrow I'm unable to configure my project with the provided VSIX. Rolled back to 1.7.3, and it configures normally.
|
Can you configure with 1.8.1, but not this VSIX? Did you select a VS 2019 Kit that doesn't have the v141 toolset installed with it? |
Yep, I can configure with 1.8.1, but not with VSIX. I'm not changing anything else other than the extensions version, the kit stays the same -Visual Studio Community 2019 Release - x86. |
Hmm. We didn't change much since 1.8.1, but perhaps it could have been this change: https://github.com/microsoft/vscode-cmake-tools/pull/2089/files. Let me see if I can build you a new VSIX without that to verify. |
@ghuser404 I tried to repro your issue locally but was unsuccessful. Can you share the full cmake command that the extension uses to configure your project? It was trimmed from your previous comment. You can hide project specific |
And here also is a VSIX with #2089 removed in case you think trying that would be faster than trying to help me get a repro on my end. |
@bobbrow Yes, this VSIX configures.
and this in cmake-variants.json
|
Great! 👍 If you have a working configuration now, can you send the output of the |
Yep, here is the output of
|
Ok. So you've configured the project but the code model wasn't loaded. Do you still have the files mentioned in your previous logs on disk?
Does that folder exist and are there several JSON files in it? |
Yeah, there is a mention in
|
I got a repro with the settings you shared. We should be able to debug this locally now. You can ignore my previous questions. 😄 |
Unfortunately, I was incorrect about getting a repro for this case. I did fix the other thing about the v141 toolset though. One thing I missed from your log earlier is that the extension thinks you have no targets. How do you configure your project such that there are no targets? I'm not sure how a |
@bobbrow I'm using many different variants with various arguments. I can confirm that if I name a variant plain "Debug", then everything works fine. Although I wouldn't say I'm doing something wrong here. My variants look something like this:
As you can see I'm using "short", but not using "long" here. If "short" isn't equal to "Debug", then IntelliSense fails. I tried using Anyway, well done on finding this issue! Hopefully this can be fixed soon'ish. PS. Please let me know if you can repro this. Thanks! |
Thanks for the info about your variants and I'm glad to hear that there's a temporary workaround! I just got another response on one of the other similar issues (#2105) that their problem is with variants as well. We'll debug this a bit more now that we know where to look. The fix probably won't make it to 1.9.1, but I'll post a VSIX here or we'll schedule a 1.9.2 for this one once we have a fix. |
@ghuser404, @ZJUGuoShuai, @tntodorov, @LoSealL, we just released CMake Tools 1.9.1 today which may fix the problems that you are seeing. We can't confirm exactly if that is the case since we don't have a repro but we addressed several issues that look related to what is described in this bug report. Can you upgrade the CMT extension in VSCode and let us know if this problem was fixed or if you encounter any other issues? We are not closing this until we hear from you. |
@andreeis I can confirm the fix works. However... I think the message is somewhat misleading... So if the short name for my variant is "this-is-short-name-for-my-variant", then the following message appears
IMO, the extension should not care about what name I choose for the variant, currently it mistakenly tries using it for |
We will fix the short name bug too. The time was tight though and I didn't have a chance to investigate the root cause of your issue. @andreeis we'll make this bug about the short name being used instead of the buildType when variants are used. |
IntelliSense now uses buidType from variants file instead of short name
We plan to release the fix for the short name bug on Monday. If you would like to verify the fix in a pre-release version of the extension, please do the following:
|
The fix for this has been released in 1.9.2. |
I've been having many issues with this extension, and was always hoping it would improve with future versions. The changes came very slowly, but I was still hoping for better. The issues were mostly related to go-to-definition, it either jumped into wrong places or didn't work at all.
With 1.8.1 everything stopped working. All my includes are red-squiggled (except maybe one or two headers, system headers and standard headers), F12 doesn't open those includes, for the most part it doesn't work on function/objects - just says "No definition found for...", but those functions/objects are not even red-squiggled.
I went back to 1.7.3, for now it works for me.
Please let me know how I can assist you in fixing this.
PS. Unfortunately, I can't share the code, it's commercial.
The text was updated successfully, but these errors were encountered: