search

microsoft / vscode-cpptools

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

Annoying false-positives in C code #12394

Open al20878 opened 2 months ago

al20878 commented 2 months ago

Environment

Version: 1.90.2 (system setup) Commit: 5437499feb04f7a586f677b155b039bc2b3669eb Date: 2024-06-18T22:34:26.404Z Electron: 29.4.0 ElectronBuildId: 9728852 Chromium: 122.0.6261.156 Node.js: 20.9.0 V8: 12.2.281.27-electron.0 OS: Windows_NT x64 10.0.19045

Bug Summary and Steps to Reproduce

Bug Summary:

VSCode constantly mis-detects "FILE" as "undefined", even though one can trace it all the way back to the structure definition using "Go to definition"(F12).

Steps to reproduce:

  1. Clone https://github.com/open-simh/simh

  2. Open "scp.c" from the top-level directory

  3. Observe 250+ errors of

    "resource": "/g:/cygwin/simh/simh/scp.c",
"owner": "C/C++: IntelliSense",
"code": "20",
"severity": 8,
"message": "identifier \"FILE\" is undefined",
"source": "C/C++",
"startLineNumber": 462,
"startColumn": 46,
"endLineNumber": 462,
"endColumn": 50
}]

Meanwhile clicking on the squiggled "FILE" for "definition", brings up this code snippet (code active) from <stdio.h>:

#if __POSIX_VISIBLE >= 200809 || _XSI_VISIBLE
/* As in stdio.h, <sys/reent.h> defines __FILE. */
#if !defined(__FILE_defined)
typedef __FILE FILE;
# define __FILE_defined
#endif
#endif

And then clicking on __FILE for definition again, opens its true struct view, from <sys/reent.h>

#if defined (__LARGE64_FILES) || defined (__CYGWIN__)
#ifdef __CYGWIN__
#define _fpos64_t _fpos_t
#endif

struct __sFILE64 {
  unsigned char *_p;    /* current position in (some) buffer */
  int   _r;     /* read space left for getc() */
  int   _w;     /* write space left for putc() */
  short _flags;     /* flags, below; this FILE is free if 0 */
  short _file;      /* fileno, if Unix descriptor, else -1 */
  struct __sbuf _bf;    /* the buffer (at least 1 byte, if !NULL) */
  int   _lbfsize;   /* 0 or -_bf._size, for inline putc */

  struct _reent *_data;

  /* operations */
  void *    _cookie;    /* cookie passed to io functions */

  _READ_WRITE_RETURN_TYPE (*_read) (struct _reent *, void *,
                       char *, _READ_WRITE_BUFSIZE_TYPE);
  _READ_WRITE_RETURN_TYPE (*_write) (struct _reent *, void *,
                        const char *,
                        _READ_WRITE_BUFSIZE_TYPE);
  _fpos_t (*_seek) (struct _reent *, void *, _fpos_t, int);
  int (*_close) (struct _reent *, void *);

  /* separate buffer for long sequences of ungetc() */
  struct __sbuf _ub;    /* ungetc buffer */
  unsigned char *_up;   /* saved _p when _p is doing ungetc data */
  int   _ur;        /* saved _r when _r is counting ungetc data */

  /* tricks to meet minimum requirements even when malloc() fails */
  unsigned char _ubuf[3];   /* guarantee an ungetc() buffer */
  unsigned char _nbuf[1];   /* guarantee a getc() buffer */

  /* separate buffer for fgetline() when line crosses buffer boundary */
  struct __sbuf _lb;    /* buffer for fgetline() */

  /* Unix stdio files get aligned to block boundaries on fseek() */
  int   _blksize;   /* stat.st_blksize (may be != _bf._size) */
  int   _flags2;        /* for future use */

  _off64_t _offset;     /* current lseek offset */
  _fpos64_t (*_seek64) (struct _reent *, void *, _fpos64_t, int);

#ifndef __SINGLE_THREAD__
  _flock_t _lock;   /* for thread-safety locking */
#endif
  _mbstate_t _mbstate;  /* for wide char stdio functions. */
};
typedef struct __sFILE64 __FILE;

So what IS the problem???

Another thing is that if I open PDP11/pdp11_rh.c and look for "RH11" symbol, it's a macro that uses OPT_RH11, line 148. Going for definition for OPT_RH11 shows it in the file pdp11_defs.h in the same folder. BUT: trying to find references of OPT_RH11 says there are NONE (either "Show references" or "Show All References")!

Simple "grep" through the sources in this directory reveals that OPT_RH11 is used 4 times in pdp11_cpumod.h, not to mention it's absolutely used in the initial pdp11_rh.c file where we started from.

These false-positives are extremely annoying!

I'm using VSCode on top on CYGWIN, with the following config file attached to the workspace (which is the checked out SimH directory from github).

Cygwin is installed into the "standard" location C:\Cygwin64, and VSCode opens include files from there.

FILE

Configuration and Logs

c_cpp_properties.json as found in .vscode for the SimH workspace (top level)
{
    "configurations": [
        {
            "name": "Win32",
            "includePath": [
                "${workspaceFolder}/",
                "${workspaceFolder}/PDP11",
                "C:/Cygwin64/usr/include/**",
                "C:/Cygwin64/lib/gcc/x86_64-pc-cygwin/11/include/**"
            ],
            "defines": [
                "_DEBUG",
                "UNICODE",
                "_UNICODE",
                "_GNU_SOURCE=1",
                "__CYGWIN__",
                "VM_PDP11=1",
                "SIM_HAVE_DLOPEN=1"
            ],
            "windowsSdkVersion": "10.0.17763.0",
            "compilerPath": "C:/cygwin64/bin/gcc.exe",
            "cStandard": "c17",
            "cppStandard": "c++17"
        }
    ],
    "version": 4
}

User's settings.json stored in AppData\Roaming\Code\User:
{
    "git.ignoreMissingGitWarning": true,
    "extensions.autoUpdate": true,
    "C_Cpp.default.systemIncludePath": [
        "c:/cygwin64/lib/gcc/x86_64-pc-cygwin/11/include",
        "c:/cygwin64/usr/include",
        "c:/cygwin64/usr/include/w32api"
    ],
    "C_Cpp.default.includePath": [],
    "arduino.ignoreBoards": [

    ],
    "editor.useTabStops": false,
    "telemetry.telemetryLevel": "off",
    "C_Cpp.intelliSenseCacheSize": 0,
    "editor.rulers": [
    80, 132
    ],
    "update.enableWindowsBackgroundUpdates": false,
    "extensions.autoCheckUpdates": false,
    "files.autoSave": "afterDelay",
    "cmake.showOptionsMovedNotification": false,
    "workbench.localHistory.enabled": false
}

Other Extensions

None of other extensions have anything to do with the issues above

Additional context

No response

sean-mcmanus commented 2 months ago

@al20878 You should remove the system includes from your includePath

            "C:/Cygwin64/usr/include/**",
            "C:/Cygwin64/lib/gcc/x86_64-pc-cygwin/11/include/**"

and

"C_Cpp.default.systemIncludePath": [
    "c:/cygwin64/lib/gcc/x86_64-pc-cygwin/11/include",
    "c:/cygwin64/usr/include",
    "c:/cygwin64/usr/include/w32api"
],

and instead rely on the compiler querying to provide those. You would only provide those if your compiler can't be queried, and if that's the case you should not use ** with system includes because ** puts the paths in a non-deterministic order and the order of system includes paths is important.

al20878 commented 2 months ago

@sean-mcmanus

Those paths are there because otherwise, I was getting squiggles all over the place.

At any rate, I'd understand that inquiring the compiler would have probably resolved the "FILE" undefined issue (I'll try that to see if it does), but what about the "OPT_RH11" issue, I also described? That has nothing to do with the system includes, does it?

al20878 commented 2 months ago

At any rate, I'd understand that inquiring the compiler would have probably resolved the "FILE" undefined issue (I'll try that to see if it does

It seems like it actually helped resolve FILE being undefined. Thanks for that. (I had that config in place for many years -- I had to place all those things in because it wasn't working correctly otherwise, back then.)

I also checked the OPT_RH11 issue just now, having cleaned the settings, but unfortunately (and as I thought) it is still there.

github-actions[bot] commented 1 month ago

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

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

al20878 commented 1 month ago

The problem #2 described in this issue is still not gone in the latest VC

Version: 1.91.1 (system setup)
Commit: f1e16e1e6214d7c44d078b1f0607b2388f29d729
Date: 2024-07-09T22:06:49.809Z
Electron: 29.4.0
ElectronBuildId: 9728852
Chromium: 122.0.6261.156
Node.js: 20.9.0
V8: 12.2.281.27-electron.0
OS: Windows_NT x64 10.0.19045

(I updated today, actually).

Going to the definition of a symbol (from a point of its use) does not then work finding the references (none found at all!). I already described the steps to reproduce. The OPT_RH11 (macro) cannot show its references.

github-actions[bot] commented 2 weeks ago

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

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

al20878 commented 2 weeks ago

@sean-mcmanus :

This issue still exists ( https://github.com/open-simh/simh ):

is that if I open PDP11/pdp11_rh.c and look for the "RH11" symbol, it's a macro that uses OPT_RH11, line 148. Going for definition for OPT_RH11 shows it in the file pdp11_defs.h in the same folder. BUT: trying to find references of OPT_RH11 says there are NONE (either "Show references" or "Show All References")!

Simple "grep" (search) through the sources in this directory reveals that OPT_RH11 is used 4 times in pdp11_cpumod.h, not to mention it's absolutely used in the initial pdp11_rh.c file where we started from.

VSCode:

Version: 1.92.2 (system setup)
Commit: fee1edb8d6d72a0ddff41e5f71a671c23ed924b9
Date: 2024-08-14T17:29:30.058Z
Electron: 30.1.2
ElectronBuildId: 9870757
Chromium: 124.0.6367.243
Node.js: 20.14.0
V8: 12.4.254.20-electron.0
OS: Windows_NT x64 10.0.19045