search

microsoft / vscode-cpptools

Official repository for the Microsoft C/C++ extension for VS Code.
Other
5.51k stars 1.55k forks source link

debugger still thinks the project is still giving UNICODE errors after switching to utf-8 #5244

Closed CieroCeramics closed 3 years ago

CieroCeramics commented 4 years ago

Type: Debugger

The debugger is still giving me an error : "message": "argument of type \"char \" is incompatible with parameter of type \"wchar_t \"", this error is not processed by the build. when I switch the project encoding to UNICODE the error DOES show up in the build log and the compile fails. as expected however switching back to multibyte the build compiles the program correctly while in the "Problems" log remains the error message. not the worst thing but it does get distracting and I would like it to go away.

I am using ms build with .vcxproj files to build my project. but the settings.json and the .vcxproj files specify UTF-8

Steps to reproduce the behavior:

  1. create a unicode project
  2. cast a char to a wchar_t
  3. change the projects encoding to UTF-8
  4. incompatibility error doesn't go away
chrisant996 commented 4 years ago

Yeah, this lists thousands of problems in my projects, and they're all false positives. It makes the Problems log useless, because it's too expensive to sift through thousands of false positives to try to find a couple accurate Problem reports.

Colengms commented 3 years ago

@WardenGnaw

chrisant996 commented 3 years ago

Just to be clear: the issue is the cpp tools assume all projects are compiled with #define UNICODE. So any project that compiles as multibyte gets every char vs TCHAR flagged as a Problem. That can easily be thousands of false positives in a medium size perfect. Even in a small project it can be hundreds, which skews the signal to noise ratio of the Problems log to the point of being unusable.

There needs to be a way to tell the cpp tools whether the project is Unicode or multibyte.

chrisant996 commented 3 years ago

FOUND IT!

The FAQ mentions that preprocessor directives can be edited via the C/C++ Edit Configurations (UI) command. Invoking that command reveals that UNICODE and _UNICODE are listed by default. I've removed them and anticipate that will resolve the issue.

I feel it would be beneficial if the documentation more overtly called out that the UNICODE vs ANSI compile "mode" issues can be resolved by editing the preprocessor configuration there. Yes, it's possible to find it if you know what you're looking for, but it's still pretty hidden.

sean-mcmanus commented 3 years ago

@CieroCeramics We thought this issue was a debugger bug, but according to @chrisant996 it sounds like a language service configuration issue that is resolved as @chrisant996 describes. Can we close this issue?

@chrisant996 I don't fully understand what doc change would be best. You could file a doc issue at https://github.com/microsoft/vscode-docs/issues . The default defines are shown at https://code.visualstudio.com/docs/cpp/config-msvc#_cc-configurations .

CieroCeramics commented 3 years ago

thank you @chrisant996 for being so keen on this issue. it was absolutely impossible to include DevIL as an image library for my rendering engine. @sean-mcmanus it has been a fair amount of time since I have looked at this file. but I recall editing the configurations and it still not fixing the issue. to be honest the rendering engine hasn't been a priority at the moment. however, I am so close to escaping the use of Visual studio proper for C++ graphics applications. so I still want to check. I'll have to locate some of my un committed changes and I'll provide you with an update.

chrisant996 commented 3 years ago

@CieroCeramics We thought this issue was a debugger bug, but according to @chrisant996 it sounds like a language service configuration issue that is resolved as @chrisant996 describes. Can we close this issue?

The defines property solved the issue for me. But I'm having to manually clean it up in every project, because each project had UNICODE injected into it. I can sort of understand that approach, except that since defines appeared to be empty I didn't know the UNICODE value was being stamped into every project.

@chrisant996 I don't fully understand what doc change would be best. You could file a doc issue at https://github.com/microsoft/vscode-docs/issues . The default defines are shown at https://code.visualstudio.com/docs/cpp/config-msvc#_cc-configurations .

What could have made things much more straightforward and understandable would have been if the Settings UI showed the actual default value, instead of empty.

  1. It's non-intuitive that I have to use a different UI than Settings, to change the settings.
  2. Very early on, I found the C_Cpp.default.defines section. But it was empty. So that makes it looks as though that's not where the "UNICODE" define was coming from.
  3. Having -- or not having -- a "UNICODE" define is such a fundamental setting for a Windows program that I think it would make sense for the FAQ and core cpptools configuration documentation to specifically use it as an example. Especially since there is a hidden implicit hard-coded default if defines isn't set in any of the many places it could be set.
  4. Ideally the Settings UI should show the real default value of defines, instead of empty.
github-actions[bot] commented 3 years ago

Hey @sean-mcmanus, this issue might need further attention.

@CieroCeramics, you can help us out by closing this issue if the problem no longer exists, or adding more information.

github-actions[bot] commented 3 years ago

This issue has been closed automatically because it needs more information and has not had recent activity.