"..." prevents proper parsing of source files

[andreeis]

@andreeis I have also been having problems with IntelliSense not working on my project. Luckily I stumbled upon this issue here and this helped me to figure out that it is my makefile that was the problem. I have this rule:

$(OBJ)/%.o: %.c
    @echo Compiling $<...
    $(CC) $(CFLAGS) $(IFLAGS) -o $(OBJ)/$*.o $<

It turns out to be those ... characters in the echo line that cause the problem as they prevent the .c file from being found. The output in dryrun.log is:

echo Compiling MyFile.c...

When I add a space before the ... then it works:

echo Compiling MyFile.c ...

I didn't see any mention in the documentation (https://marketplace.visualstudio.com/items?itemName=ms-vscode.makefile-tools) of the filenames needing to be printed somewhere in the dryrun.log file (without trailing ...!) in order for IntelliSense to work. IntelliSense configuration with the makefile plugin is rather black magic at the moment, so could I suggest a bit more explanation of how it works in the documentation? It would help people to debug their problems.

Even better, when outputting the dry run information in the output window, if no files are found, output a message at the end telling the user this, and giving them tip that the names of the files should be listed in the dryrun.log output. I see that there is positive confirmation when a file is found (Sending configuration for file \cygdrive\d\Source\ClassAct\Examples\Label\LabelExample.c -----------------------------------) but it would be good to also have negative confirmation.

Handling those trailing ... would be nice too, if possible. That had me scratching my head for a while. :-)

Originally posted by @hitman-codehq in https://github.com/microsoft/vscode-makefile-tools/issues/173#issuecomment-871117837

[hitman-codehq]

Hi @andreeis I have been away on holiday but now I am back it is time to continue with this issue. :-)

I am not really sure how to approach this problem as it is quite complicated. It seems that on MacOS, everything is working almost perfectly, even with the "..." problem mentioned above. It is only on Windows that it seems to not work. Unless the problem has been fixed since I reported it?

The only thing that doesn't work on MacOS is that whenever I follow a symbol I get the following warning:

Configuration for file /Users/colinward/Source/StdFuncs/StdWindow.cpp was not found. CppTools will set a default configuration.

And yet everything is working, including following symbols with F12. It works whether following a local symbol or whether following a symbol into my cross compiler's includes in /opt/amiga.

Do you have any idea what this message means?

[hitman-codehq]

I did some more research and found some interesting results. With my "special" cross-compiler setup, the makefile plugin works perfectly on MacOS, but with the same setup, does not work on Windows! It cannot find system headers and (sometimes) local headers. I suspect it might be a forward slash (/) -vs- backslash () issue. When I compile manually with -v to get the list of system headers the compiler uses, I get the following (shortened) output:

$m68k-amigaos-g++ -v main.cpp

include <...> search starts here:

c:/amiga-gcc/include c:/amiga-gcc/lib/gcc/m68k-amigaos/6.5.0b/include/c++ c:/amiga-gcc/lib/gcc/m68k-amigaos/6.5.0b/include/c++/m68k-amigaos c:/amiga-gcc/lib/gcc/m68k-amigaos/6.5.0b/include/c++/backward c:/amiga-gcc/lib/gcc/m68k-amigaos/6.5.0b/include c:/amiga-gcc/m68k-amigaos/ndk-include c:/amiga-gcc/m68k-amigaos/sys-include c:/amiga-gcc/m68k-amigaos/include

Could it be that the fact that it is outputting c:/ instead of c:\ is the problem?

I have attached a simple example that demonstrates the problem. Unfortunately, to reproduce the problem you have to install an Amiga cross-compiler. Sorry, I hope you don't mind! You can download setup-amiga-gcc.exe version 6.5.0b 210321150254 from https://github.com/bebbo/amiga-gcc/releases. It will install to c:\amiga-gcc so just add c:\amiga-gcc\bin to your path to be able to compile.

If you now unzip the attached missing_paths.zip file and open VS Code in that directory, you should be able to reproduce the problem. Make sure that "AmigaOS3" is the currently set build configuration in VS Code, and in the makefile configuration pane, select "OS3 Debug" as the Configuration and "all" as the Build target. If you want to test that the project builds you'll have to make a debug directory manually as the mkdir etc. commands do not come with the compiler (I have them installed separately).

Now if you open main.cpp in VS Code, you should see some red squiggly lines under the #include paths. Strangely enough, the behaviour I see in this little example project is different to the behaviour I see in my main project! So there is definitely something strange happening here with the plugin.

If everything is working then you should be able to successfully do 3 things:

1) Put the cursor on MyLocalHeader.h and hit f12 to open it 2) Put the cursor on proto/exec.h and hit f12 to open it 3) Put the cursor on Wait() and hit f12 to go to its definition

If these don't work for you then you have a use case you can debug. :-)

I've put lots of comments in both the main.cpp file and the c_cpp_properties.json file that should help explain things.

What is interesting is that this exact same setup on MacOS (with paths modified to use the compiler in /opt/amiga/bin instead of c:\amiga-gcc\bin) works perfectly! And you don't even need to manually set the paths to the compiler in includePath - the makefile plugin finds the paths automatically. That's why I'm wondering if this is a problem related to backslashes.

Unfortunately, there is no prebuilt MacOS cross compiler and I had to compile it myself so you can't try it yourself. But given that it is working perfectly on MacOS, this shouldn't be a problem.

Also, you will get some errors like this when opening some files for the first time:

Configuration for file d:\Source\missing_paths\main.cpp was not found. CppTools will set a default configuration.

But after some further research, I suspect these problems are due to the CppTools plugin and not the makefile plugin.

Hopefully we now have a good use case to get to the bottom of my problem!

missing_paths.zip

[hitman-codehq]

By the way, I forgot to say that the originally reported problem about the "..." causing issues turned out to be incorrect, so we can ignore that. The long description that I put in the last comment is the most up to date information now.

[andreeis]

@hitman-codehq, it was now my turn to be out of office on leave :). Back now and ready to help you out. I have a mac and I can also try your amiga compiler. But while I catch up on things, you can do something to simplify my reproducing experience. We could skip over using any compiler if you share the build log relevant for the issues you are seeing. I can hook that up via "makefile.buildLog" and avoid any compilation, while only focusing on the parsing problems.

[hitman-codehq]

@andreeis been busy myself with a new job but have enough time to support you now.

When you say "build log" what do you mean exactly? The really strange thing is that the problem comes and goes and I only see it on my Windows machine, not my MacOS system (but that could be just luck). In my c_cpp_properties.json file I have a makefile configuration and a CMake configuration, containing the following lines:

"configurationProvider": "ms-vscode.makefile-tools"

and:

"configurationProvider": "ms-vscode.cmake-tools"

The CMake version works but the makefile version doesn't work - sometimes! It has been broken for two weeks and this morning I rebooted my PC and now it is working again. All Amiga symbols are found successfully and can be followed, so the makefile plugin is giving the right configuration information.

Interestingly, even when it's working I get the following message whenever I open a new file:

Configuration for file was not found. CppTools will set a default configuration.

And this is before I have built anything, when just the CppTools have done their parsing. I've attached a log containing a successful makefile configure. Perhaps that gives some clues.

I'll keep an eye out for the next time it stops working and can gather logs for you.

[andreeis]

@hitman-codehq, when IntelliSense appears to be working, it is only because CppTools is smart in finding defaults. It appears inconsistent because finding these defaults depends on many things, like what other sources are opened and other user led operations.

Once you see the message "Configuration for file [] was not found. CppTools will set a default configuration", you can be sure that Makefile Tools is not contributing to the IntelliSense for that file.

If you see in the ".vsocde/extension.log" or in the Makefile Tools output channel that the extension does send IntelliSense information ("Sending configuration for file...") for that file, double check the paths in these both messages. The slightest mismatch will cause this problem. And since you say it only happens on windows, I am almost sure that is it.

I don't see the successful configure log that you say you attached. Send that again and also a build log, by which I mean you go in your development terminal, in the root of your project, you build it full and clean ("make" with whatever commands you normally use) while outputting > "customBuild.log".

For your windows project, do you use MinGW by any chance? When the extension is run from a MinGW environment, it solves automatically some incompatibilities between windows style and linux style paths. This might unblock you.

[andreeis]

This could be the same as https://github.com/microsoft/vscode-makefile-tools/issues/219, I'll confirm once I see both logs.

[hitman-codehq]

Hello again @andreeis.

I have attached a zip file that contains quite a few files. Firstly, it contains the contents of my .vscode directory. My c_cpp_properties.json file is a little bit complicated so perhaps something in there will be a hint for you. It also contains the .log files generated by the makefile plugin during configuration, so perhaps there is a clue in there for you.

The output from my build is in the customBuild.log file, as you requested.

But actually, when everything is working, symbol lookup works (meaning that IntelliSense is working) even before a compilation. Just opening VS Code is enough. A good sign of whether it is working is whether the #include statements at the top of my code have squiggles or not.

I did some experiments where I clean my build by deleting my build directory and also by deleting .vscode*.log and then starting VS Code. A "clean" start like this usually results in a working configuration. However, if I then restart VS Code, it doesn't work! My #include statements have red squiggly lines and the "Configuration for file [] was not found. CppTools will set a default configuration." message appears.

A little more strange is that sometimes these messages also appear even if the configuration was successful after a clean import. I have included two files in the zip file: good_configuration.log and bad_configuration.log. In this case you can see that both say "Sending configuration for file..." but only good_configuration.log results in working IntelliSense.

A clue: In bad_configuration.log it says:

Configuring from cache: d:\Source\Brunel.vscode\configurationCache.log Load configuration from cache elapsed time: 0.125

In the configurationCache.log file are some strange Cygwin style paths such as /cygdrive/d.

But I am not using a Cygwin based compiler. The GCC version I am using is MSYS2 based.

Hopefully there are some clues in here! I think we are getting closer to solving this problem.

log_files.zip

[andreeis]

@hitman-codehq, I am working on fixing this and I am not ready yet but it would help if you install this vsix and let me know how it works for you. Even if the coding of the fix is still in the experimental/hacky phase, it should be functional and verifying if it works or not would help us continue on the right track.

1. Extensions panel from the left side of VSCode
2. Context menu of "..." in the upper right of the extensions panel window.
3. Run "Install from vsix" and point to what you download from this link.

[hitman-codehq]

@andreeis many thanks! I installed it and have noticed some differences. I have a test case that I follow:

1) Delete .vscode*.log 2) Import project 3) Ensure that symbol lookup works 4) Ensure that there are no red squiggles under #include statements 5) Restart VS Code and repeat 3 and 4

The reason for 5 is because the presence of the .log files seems to make a difference.

Results:

With old v0.2.2 plugin 3 and 4 work after cleaning .vscode*.log 3 and 4 do not work after restarting VS Code

With new 0.3.0 beta plugin: 3 works after cleaning .vscode*.log AND after restarting VS Code 4 does not work after cleaning .vscode*.log OR after restarting VS Code

My c_cpp_properties.json file has the following:

"includePath": [ "${workspaceFolder}/**", "c:/amiga-gcc/lib/gcc/m68k-amigaos/6.5.0b/include/c++", "c:/amiga-gcc/lib/gcc/m68k-amigaos/6.5.0b/include/c++/m68k-amigaos", "c:/amiga-gcc/m68k-amigaos/clib2/include", "c:/amiga-gcc/m68k-amigaos/ndk-include", "c:/amiga-gcc/m68k-amigaos/sys-include" ],

It seems this is somehow lost with the new 0.3.0 beta plugin.

If you need more information, don't hesitate to ask!

[hitman-codehq]

By the way, I can make you a little "hello world" program that shows the two problems I mentioned above (symbol lookup not working and include files not being found) if that would help. You would have to install the GCC cross compiler I am using to see it of course, but it would make it much easier to debug the problem.

Let me know if you would like to have it.

[hitman-codehq]

I had to switch back to v0.2.2 as the beta v0.3.0 just stopped working. It couldn't find any symbols and even cleaning out the .log files didn't make it work again. Something very strange going on here.

[andreeis]

@hitman-codehq, yes help me reproduce the problem on my side: hello world program, compiler and tools install/usage instructions. I will have soon a new vsix with more bug fixes but the best is to debug on my side and offer a real fix instead of guesses.

[andreeis]

@hitman-codehq, we just released 0.3.0 and we are planning a quick update (weeks away, as opposed to months away) with localization support and into which we can also include any other additional bug fixes to improve your experience.

To investigate your project, we need new logs from you after updating to 0.3.0. The dryrun is probably the same, so no need for a new one, but extension.log reflects some bug fixes we did and reading through that will help me see what else is wrong, because we definitely fixed some of the old problems. We have other users that confirmed the beta vsix worked fine. And don't forget to mention which c/c++ file is having red squiggle, so that I focus on that file in extension.log.

So, either help me create a project and all the needed environment over here or you recreate extension.log after a clean configure command (delete all logs first to start fresh) after you update to 0.3.0. I am hoping you won't have to revert to 0.2.2 again, but let's see.

[hitman-codehq]

Hello @andreeis.

I have made a little hello world project that shows the problem on Windows. It is attached as a zip file. Included are the exact c_cpp_properties.json and settings.json files that I am using as well as a .cpp file and a makefile.

To reproduce the issue:

1) Download and install the Amiga GCC cross compiler from https://github.com/bebbo/amiga-gcc/releases/tag/y%C3%BCtosikanom%C3%B6 2) Add c:\amiga-gcc\bin to your PATH variable so you have access to m68k-amigaos-g++ 3) Start VS Code from the HelloAmiga directory (so that it inherits the path) 4) On the bottom right of VS Code, ensure that the AmigaOS3 configuration is selected 5) Open HelloAmiga.cpp

At this point, you might have red squiggles under the #include paths or you might not. I have added lots of OS symbols in this file that should be able to be opened with if everything is working properly. Looking at my VS Code right now, my #include paths all have red squiggles and yet I can look up the symbols with !

Whether it works or not seems almost random. The only thing that does really make a difference is that if you delete the .vscode*.log files and open VS Code then it usually works. Closing VS Code and opening it again (using the cached .log files) always results in a broken configuration.

By the way, the "Win32" and "Win32 GCC" configurations in the c_cpp_properties.json file are not required. I wanted to give you the exact same c_cpp_properties.json that I am using, not some edited one. So just make sure that the AmigaOS3 configuration is selected as the symbol lookup in the example won't work for the Win32 targets.

And many thanks for looking at this! I know I've been bugging you for a while, but hopefully with this example you will be able to easily reproduce it. :-)

HelloAmiga.zip

[andreeis]

@hitman-codehq, excellent I will try this repro and let you know what I find. So, it's still happening with the official 0.3.0 release?

[hitman-codehq]

@andreeis yes it is still happening with 0.3.0. At first it seemed to be partially improved, but then it got worse and I had to go back to 0.2.2. The whole thing is almost random, almost like it is caused by some uninitialised variable that gets random values at startup. But only on Windows! On MacOS everything seems to work fine.

[andreeis]

@hitman-codehq, it appears that this problem had two parts. The Makefile Tools one was fixed in 0.3 (related to the paths used when registering the IntelliSense information, windows style versus linux). The CppTools team is investigating now something in the includes parsing. We will keep you posted.

https://github.com/microsoft/vscode-cpptools/issues/8496

[hitman-codehq]

Many thanks @andreeis! I will be curious to know what the problem is. 👍

[hitman-codehq]

I see that a new release of CppTools has already been released that fixes this. I am on holiday without access to a Windows machine at the moment but will check as soon as I get home next week.

Many thanks @andreeis for supporting me with my obscure use case of cross compiling for an obsolete computer with a community built compiler on Windows. :-)

[andreeis]

@hitman-codehq, thank you also for very valuable feedback and interesting real world code scenarios for testing. Whenever you have the chance, if you would like, you can give us a review on Market Place.

[hitman-codehq]

@hitman-codehq, thank you also for very valuable feedback and interesting real world code scenarios for testing. Whenever you have the chance, if you would like, you can give us a review on [Market Place]

Ok, just gave you a shining 5 star review. Many thanks again helping to sort out my problem and have a relaxing holiday over the next couple of weeks, because I'll probably be back with a new bug next year. :-)

[andreeis]

@hitman-codehq, thank you very much for the review. We are ready to have a look at the new bug :).