#pragma once errors with simple first person UE5 project #22
Comments
|
Some things to try: Make sure you can build successfully first with the 'Editor' suffix config like so: This is a VSCode Build Task. TestFps is the project name and notice the 'Editor' suffix. Win64 might be Mac for you. This will create some files needed for Intellisense if they're missing. Now you'll need to reset your project which will add the new file paths to Intellisense configs. Right click on your *.uproject file and choose Generate Visual Studio Project Files (or something similiar). If you can't find it you can also do this by loading your project in to the UE5 Editor and choose this option from the Tools menu. It's called 'Refresh Visual Studio Code Project'. It's also possible inside VSCode. One of the debug configs is called Generate Project Files. You do need to install the Microsoft C# extension for it to work though. Restart VSCode and see if it works. Another thing to try, maybe the config you're using is bugged. You can click the Win32 which is the name of one of the intellisense configs. Yours will probably be named something different. When you click it you'll get a menu with two choices. Click the opposite config that's currently active. |
|
Thanks for getting back so quickly. I am not sure if it is because I didn't set up the compiler in your extension properly, but I needed to add the following two parameters to the I am not sure if you think it is worth adding this to the extension so it includes these two parameters when it corrects the file. I don't know how to do it, but I think could be marked as a workaround in GitHub. May help other MacOS users. |
|
I do have a compiler path setting in my extension but the includePath making it work is weird. It would mean that it's not using the compile commands file for Intellisense and instead using the cpptools includePath setting. This could also mean you're not using the 'smart' Intellisense and instead using the other intellisense called 'Tag Parser'. Pretty strange. Are you sure you need the includePath setting for it to work? |
|
I'm running on a Mac M1 and I've been using the extension to fix a few IntelliSense problems (thanks by the way), but the whole discovery of files was really really slow. The loading of the symbols and suggestions would take ages. But, after reading the official docs of VSCode about C++ and seeing this issue thread, I decided to add the As a reference, my compiler path is: |
|
@leonfs The compile commands must have include errors which forces VSCode to fall back to instead use Tag Parser Intellisense. |
|
You might be right, actually. How do you find those include errors @boocs? For some reason, navigating with IntelliSense the UE code is super fast, but when I have to navigate my project's code, it is super slow. There is clearly something not right. |
|
Tag Parser Intellisense is super fast but not as smart as the default Intellisense which is fast with cpp files but slow with header files because of how it works(updates too often whenever you type). You should be able to look at the cpptools(C_CPP) extension logs. The setting is called Logging Level. Set it to debug. |
|
Also - In the logs of the C++ extension I see this: |
|
@leonfs I created a new issue for you called M1 Mac issues |
|
@boocs I started a brand new project and set the path in your extension. The settings are as follows: There were no immediate errors, but it was stuck on Loading... for ages. I then got an error with the include path and then it found things. It did take very long in comparison to when the includepath was set before. As far as I can tell, I am using the Default intelliSense. Is that not the proper one? The setting is set as follows: Any way to check if it is using the correct IntelliSense? Also, I haven't switched on your optimisation setting. |
|
I don't know if you have have my latest extension version 3.2.0. But I changed the strict setting documentation to say only use it if the extension's path setting is the full compiler path. Make sure to change it to the full xcode/clang or clang++ path. Makes me think I should just detect if it's a full path and error if it's not(when using the strict setting). If you decide to remove the strict setting you should do a Generate Project File on your project. |
|
I did read that in your extension. However, when you read the output it states that it is better to actually have the box ticked. When you say full path you mean absolute rather than relative, right? |
|
Yep, I guess my extension change wouldn't have worked if /user/bin/clang is also an absolute path on some systems. Maybe I'll just detect it on Mac and make sure if you use the strict setting that xcode is in the path somewhere. So basically on Mac if using the strict setting your path setting should look something like this: |
|
You can also remove the strict setting and Generate Project Files to get back the full xcode clang path in your compile commands file. After you Generate Project Files, you can also check my extension log to see what the compile commands compiler path is being set to by the Unreal Engine. For example, my project's extension log above it says it's using "C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.32.31326\bin\HostX64\x64\cl.exe" |
|
Once you figure out the full path that Unreal chooses you can just copy and paste that into the path setting and reenable the strict setting. Actually since they're going to be the same anything I guess you don't need to use the strict setting if you don't want lol. I'm thinking that maybe the strict setting was a bad idea and just reading the compile commands compiler setting and auto pasting it into the path setting would be better. That way it's up to you to install the correct clang and up to Unreal to detect and use the correct clang. |
|
Here's how I'll fix this.
|
|
I released 3.3.0 with the path fixes. You can remove the strict setting and reset your project(Generate Project Files) to fix it. The path setting will now be auto set based on what compiler Unreal chooses. |
|
I've released my guide on how to check for VSCode config bugs. This is just a partial Include Errors release. Note: This will get reorganized and changed. https://github.com/boocs/Unreal-VSCode-diy-config-check-github |
|
Ok, so I downloaded your latest version. Removed the strict flag and refreshed the project twice from Unreal 5. I checked c_cpp_properties.json and it is set up as follows: I tried adding The current config in Any ideas? |
|
Ok, so it appears that I managed to find a stable configuration. I removed the strict flag and left the compilerPath in your extension blank and restarted VSCode. I have no idea why it doesn't like Any ideas what's happening? |
|
Seems like the project reset isn't working properly. It still has the /usr/bin/clang from the previous time. Would it be possible to create a new project and see what compiler Unreal chooses for the compile commands (by checking extension log)? (remember to leave the strict setting unchecked) I'm also going to update my guide today for different ways to reset your project. Maybe one won't be broken. It'll be funny if it turns out your reset isn't broken and Unreal chooses usr/bin/clang for the compiler. |
|
I’ll quickly create a project and report back. Let’s see what’s happening!
… On 1 Sep 2022, at 17:14, boocs ***@***.***> wrote:
Seems like the project reset isn't working properly. It still has the /usr/bin/clang from the previous time.
Would it be possible to create a new project and see what compiler Unreal chooses for the compile commands (by checking extension log)?
(remember to level strict setting unchecked)
I'm also going to update my guide today for different ways to reset your project. Maybe one won't be broken. It'll be funny if it turns out your reset isn't broken and Unreal chooses usr/bin/clang for the compiler.
—
Reply to this email directly, view it on GitHub <#22 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALL3UBUXDYUXAEWGRDDIKWLV4DI5HANCNFSM575IWEFA>.
You are receiving this because you authored the thread.
|
|
Ok, so I created a new project and let it do its thing. It seems that Unreal is using
I don't know why, but the only way to get it to not fail is to use |
|
Temporarily you can go into the path setting of the extension. It should now have to full xcode/clang++ path there. Remove the ++ from the path and enable strict. Restart VSCode and see if the errors go away with the new project. Enabling strict copies the path setting to your compile commands file overwriting the compiler choice that Unreal chose. |
|
I'm wondering if this is a version issue? Unreal requires specific XCode version for developing. It's XCode 12.4 for Mac development on UE5. It's weird because I thought after the release of 5.0.2 it required XCode 13 but it says only IOS projects require that. https://docs.unrealengine.com/5.0/en-US/hardware-and-software-specifications-for-unreal-engine/ Do you know what version you have? I know diffferent clang or xcode versions can cause problems. On Windows I can't use clang 14 to compile because it has a new warning and Unreal treats warnings as errros. I had to use clang 13 to compile on Windows. |
|
So, I did that and the errors keep on coming back. However, going to definition (F12) works! I wonder why usr/bin/clang works though. |
|
When you Build your project you're building with with XCode/clang++ so it does work. Pretty strange that Intellisense can't use the same compiler path. stdlib.h is a system include and there are a lot of issues people have with them and clang. It could be Unreal isn't including something it should be. It also could be VSCode is failing at polling for system includes. Actually I know they auto poll system includes on Windows but with Mac maybe they don't and use what is listed in the compile commands/rsp(response) files. If you put it back to what works can you check for system includes using my guide? Also feel free to bail and get back to creating Unreal projects lol |
|
I am happy to help, however, I will try it tomorrow. While I have done lots of development experience in Windows, I am totally new to MacOS/iOS. Without your extension, I would have wasted a lot of time trying to figure all this out. Also, kind of keen on understanding how all of these tools are talking to each other! |
|
Ah, never mind about that compilerPath being set to "". I tried it on Windows and my Intellisense failed as well. I wonder how much a cheap mac is that could create UE5 projects? lol |
|
Cheap Macs! lol I noticed that your extension doesn't seem to respect the strict flag. I tried reverting back to /usr/bin/clang and it wrote it over with the long path. However, after overwriting it manually with /usr/bin/clang and resetting the database the errors went away. The C++ extension output mentioned lots of tag parsing though. Anyway, I will try your guide tomorrow and see if I can extract more info. I'm off to have dinner! |
|
Yeah the tag parser can take 15+ minutes when it first parses your project's symbols. You have to wait for it to finish to use my guide. There is another command for, the VSCode cpptool extension, logs but I like the real time logs better (I've had the two different logs disagree before) |
That's just my lazy coding. When you enable the strict flag you have to restart VSCode for it to work ( I guess I should mention that somewhere). |
|
I been thinking about that macFrameworkPath setting and thinking maybe this is the bug this entire time. I think for clang++ to work it needs the full absolute path to the system libraries found in the xcode path. Or maybe the relative paths just aren't working for the full Xcode clang++ path. I found this on stackoverflow: Does your Xcode have a similar path like that? So I would try:
Does it work now? Also can you search "/Applications/Xcode.app/Contents/Developer/Platforms" for stdlib.h to see where it is located? |
|
Ok, gave it a try. Still same errors: Full output of the C++ debug log here https://pastebin.com/67FeQPuC The and I also used Also, I followed your guide. The flame is on. I also tried adding to the macframeworks path /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++` instead of the one you suggested as that contains stdlib.h but still gave same errors. I am surprised that it is not finding it! |
|
Thanks for the logs! Would you be able to post a log file of the same project that's working? (using strict and /usr/bin/clang) It would be interesting to compare the two logs. |
|
Sure, will do.
I think that one defaults to the tag parser though.
Best,
*Max Nicosia*
Director
Cambridge Intelligent Systems UK Ltd.
***@***.***
Salisbury House
Station Road
Cambridge
England
CB1 2LA
…On Fri, 2 Sept 2022 at 11:18, boocs ***@***.***> wrote:
Thanks for the logs!
Would you be able to post a log file of the same project that's working?
(using strict and /usr/bin/clang)
It would be interesting to compare the two logs.
—
Reply to this email directly, view it on GitHub
<#22 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALL3UBQAMQQKEK3QB223GQ3V4HH6HANCNFSM575IWEFA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
Hey, can you message me your email. Apparently, the log is way longer when using /usr/bin/clang and it is beyond the limit for paste bin. |
|
You can cut out all Unreal Paths if that makes it shorter. If it's working but only uses tag parser then that seems weird. I was looking at Macs and Unreal Engine requirements. The only hard requirement is Using the latest Monterey OS. I saw that I can get a ~$200 late 2014 Mac Mini that can run that OS. I just need to be sure it will be able to create Unreal Projects in UE4/UE5. It doesn't even need to run the engine. |
|
Even though I removed all the Epic ones, it still was over pastebin's limit. So, I split it into two. |
|
There is something weird happening. Both logs say your clang gets detected as version 11 When I use clang 13.0.1 on Windows this is what is shown in logs: Will have to research and look at the logs more. |
|
That's pretty weird! Using |
|
In your logs it also shows the clang version as 13.1.6 as well so I still think something is wrong with the mac system includes which is why VSCode detects it as version 11. I was going to rent a cloud Mac to figure this out but if you want to keep going we can. Here's what I want to try:
I want to see any mac paths that are included, if any, without the "macFrameworkPath" setting so we get a baseline. |
|
Happy to keep the helping, but today I am fighting another battle and I will be away on Sunday. Will try on Monday :) |
|
No problem, I decided to rent the mac anyway because I need to test M1 Macs as well. |
|
Don't bother doing it. The framework setting is something else and has nothing to do with includes. VSCode auto includes system paths for Mac just like it does on Windows. So it could be VSCode just isn't including the path to stdlib.h. Still on going but thought I'd give an update. |
|
So this must be a Mac C++ extension bug? I never even used my extension and just used /usr/bin/clang++ in the compile command file and it worked. Looking at the C++ extension logs shows it including a bunch of paths added from here: Also usr/bin/clang works as well. Even when it works it says clang_version=110000 So basically an easy fix for Unreal 5.0.3. I don't need to change anything on MacOS except the compiler path in the compile commands to /usr/bin/clang++ |
|
That's interesting. When I first set up the VSCode in MacOS and used the compiler path it didn't work at all. That's why I went searching and came across your extension. |
|
Yeah that's because the compiler in the compile commands file overrides the compilerPath setting in c_cpp_properties. So I I think I'm going to change my extension and have 2 compiler paths. One for c_cpp_properties.json where I have it as an error if it's set. Having it blank will remove the compilerPath setting from c_cpp_properties. One for compile commands file, compiler path, where I will default it to /usr/bin/clang++ for Macs. Or maybe I just won't auto set it and just explain in the instructions that they should use /usr/bin/clang++ |
|
I think it would be good if you have a setting that, if ticked, it sets it, otherwise it leaves it. I would suggest writing in the setting that if not ticked, the user is responsible to set it for Mac to /usr/bin/clang++. |
|
I just kept it simple. One path setting no strict setting. If path isn't set it gets pulled from compile command compiler path and set. I tested it on my cloud M1 Mac and it works as long as I have the path set to /usr/bin/clang++ |
|
Ok, cool! Have you created a new release? Also, I got two questions you may know about. I cannot find any info atm.
Thanks! |
|
Yep 3.4.0 is released!
That's normal since you're not using the full source build that option wont work.
I don't think so. Sometimes when I'm just testing stuff I don't run debug. I just Build it using one of the VSCode Build Tasks. Once it's done Building successfully I just go to the project folder and double click the *.uproject file to run the project. You must build the 'Editor' suffix build if you want it to load into the Editor.
That's the Build task I usually run on Windows. TestFps is my project name. |
|
Oh, ok, so I don't need to worry about the plain debug one. I guess if I need to inspect variables in VSCode the editor is always killed then. I was hoping I could save the time of restarting the editor each time I hit stop in the debugger. Oh well... |
|
Hey, so it's been a while. I just updated the extension and am getting errors on includes just like before. Settings are as follows: Also, your extension is reporting some other problems. ' ** Error **: 0: Couldn't create compileCommands from /Users/lmnicosia/CIS/Projects/UE5/Test3/.vscode/compileCommands_Default.json with key:MAIN! (not an error with UE 4.25.#) ** Error **: Did not create any compile commands with keyMAIN! (not an error with UE 4.25.#) ** Error **: Error in loadCompileCommandsFromWorkspace! ** Error **: This fixable project hasn't been initialized properly and is invalid. ** Error **: Couldn't create file watchers! *** Number of error messages: 5 Extension is done. I did update XCode recently... Maybe that broke everything... |
|
What XCode version? I know XCode 14/clang 14.0.0 can cause errors on Mac( and Windows). Was this a new project you're trying? |
|
Indeed. I am in the process of downgrading. I bloody hate this walled garden of Eden! |
Really? What errors? I'm on 14 as well. Ah, I see... https://stackoverflow.com/questions/73750260/apples-clang-cant-use-with-stdtuple
https://embeddedartistry.com/blog/2017/02/24/installing-llvm-clang-on-osx/ You could install brew llvm/clang with: Will print the following info at the end of brew install:
$ ls /opt/homebrew/opt/llvm/bin
clang
clang++
...
$ /opt/homebrew/opt/llvm/bin/clang++ --version
Homebrew clang version 15.0.3
Target: arm64-apple-darwin22.1.0
Thread model: posix
InstalledDir: /opt/homebrew/opt/llvm/binTo work with CMake
See https://cmake.org/cmake/help/latest/envvar/CXX.html Perhaps another option: https://code.visualstudio.com/docs/cpp/config-clang-mac The first time you run your program, the C++ extension creates Your new {
"version": "2.0.0",
"tasks": [
{
"type": "shell",
"label": "C/C++: clang++ build active file",
"command": "/usr/bin/clang++",
"args": [
"-std=c++17",
"-stdlib=libc++",
"-g",
"${file}",
"-o",
"${fileDirname}/${fileBasenameNoExtension}"
],
"options": {
"cwd": "${workspaceFolder}"
},
"problemMatcher": ["$gcc"],
"group": {
"kind": "build",
"isDefault": true
},
"detail": "Task generated by Debugger."
}
]
}Change to sth similar to the following (see https://discourse.llvm.org/t/switch-from-apple-clang-to-homebrew-clang-in-vs-code-configuration/63314) {
"version": "2.0.0",
"tasks": [
{
"type": "cppbuild",
"label": "C/C++: clang build active file",
"command": "/usr/local/Cellar/llvm/13.0.1_1/bin/clang",
"args": [
"-fdiagnostics-color=always",
"-g",
"${file}",
"-o",
"${fileDirname}/${fileBasenameNoExtension}"
],
"options": {
"cwd": "${fileDirname}"
},
"problemMatcher": [
"$gcc"
],
"group": {
"kind": "build",
"isDefault": true
},
"detail": "Task generated by Debugger."
}
]
} |
Hi,
I have used your extension to remove most of the problems but I am still getting a few.
Unfortunately, I am required to use macos for this and I am not particularly familiar with various things.
My current setup is an i7 iMac so not on the M1 or anything. I was hoping
I have set up the cppproperties for intelli sense to
"macos-clang-x64".I left the compiler path to the default. Also, I am only using the option from your extension"UEIntellisenseFixes.enableFixes": true, "UEIntellisenseFixes.cppStandard":"c++17"`.Any ideas on what I could do to fix this? I have attached a picture of the errors. Maybe it helps.
Thanks,
M
The text was updated successfully, but these errors were encountered: