Misreporting no field when defined after a macro (error 136)

[brettcannon]

Type: Bug

If you look in CPython's source code (for example, Python/ceval.c), it reports that struct "_typeobject" has no field "tp_name", and yet if you look in Include/cpython/object.h you will see const char *tp_name;.

My guess is the PyObject_VAR_HEAD macro usage is messing up error detection somehow as Go to Definition worked fine and got me to the correct struct.

Extension version: 1.14.5
VS Code version: Code - Insiders 1.77.0-insider (a5bd844beddef8ca5f9ccfdb1bb7b3b4f8e5204e, 2023-03-22T10:38:48.144Z)
OS version: Windows_NT x64 10.0.22621
Modes:
Sandboxed: Yes
Remote OS version: Linux x64 5.15.90.1-microsoft-standard-WSL2

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-8665U CPU @ 1.90GHz (8 x 2112)
GPU Status	2d_canvas: enabled canvas_oop_rasterization: disabled_off direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled multiple_raster_threads: enabled_on opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok skia_renderer: enabled_on video_decode: enabled video_encode: enabled vulkan: disabled_off webgl: enabled webgl2: enabled webgpu: disabled_off
Load (avg)	undefined
Memory (System)	15.75GB (2.11GB free)
Process Argv	--crash-reporter-id 2f8216b4-0af9-4bf4-a156-6cdcff01b0ab
Screen Reader	no
VM	0%

Item	Value
Remote	Dev Container
OS	Linux x64 5.15.90.1-microsoft-standard-WSL2
CPUs	Intel(R) Core(TM) i7-8665U CPU @ 1.90GHz (8 x 2112)
Memory (System)	7.63GB (5.12GB free)
VM	0%

A/B Experiments

vsliv695:30137379
vsins829:30139715
vsliv368:30146709
vsreu685:30147344
python383:30185418
vspor879:30202332
vspor708:30202333
vspor363:30204092
vswsl492cf:30256198
vslsvsres303:30308271
pythonvspyl392:30422396
pythontb:30258533
pythonptprofiler:30281269
vsdfh931:30280409
vshan820:30294714
pythondataviewer:30285072
vscod805cf:30301675
bridge0708:30335490
bridge0723:30353136
cmake_vspar411:30581797
vsaa593:30376534
pythonvs932:30404738
cppdebug:30492333
vscaat:30438846
vsclangdf:30492506
c4g48928:30535728
dsvsc012cf:30540253
pynewext54:30618038
pylantcb52:30590116
pyindex848:30611229
nodejswelcome1:30587009
pyind779:30611226
pythonsymbol12:30651887
2i9eh265:30646982
showlangstatbar:30659908
pythonb192cf:30661257
azdwalk:30687957
pythonms35:30671666
03d35959:30680466
ecj1e332:30687743

[Colengms]

Hi @brettcannon . I'd like to try to repro the issue, but I'm not able to get a proper configuration from Makefile Tools for that repo. Can you provide more information on how you're configuring the C/C++ extension for that repo?

[brettcannon]

I actually didn't use the Makefile Tools extension (I've been told it can't handle CPython's Makefile; trying to get one extension working at a time 😉). My configuration can be found at https://github.com/brettcannon/cpython/blob/dev-container/.devcontainer/devcontainer.json (obviously ignore the squiggle disablement as that's only there due to this issue).

[brettcannon]

You can also use that branch if you want to test using GitHub Codespaces since that's the key purpose of that branch.

[Colengms]

Hi @brettcannon . In the file you linked, the relevant settings I see are:

                "C_Cpp.default.cStandard": "c11",
                "C_Cpp.default.defines": [
                    "Py_BUILD_CORE"
                ]

With these settings set, I still see squiggles unrelated to (and presumably prior) to the issue you are referring to. On Linux/WSL, I get: cannot open source file "winapifamily.h" (dependency of "Python.h")C/C++(1696)
on #include "Python.h"

And on Windows, I get:
cannot open source file "unistd.h" (dependency of "Python.h")C/C++(1696)

Without a complete configuration, with the relevant defines and compiler switches, there could be any number of prior errors that could lead to the IntelliSense parser being in a bad state by the time it gets to the issue you're referring to.

Can you provide a simplified or otherwise stand-alone repro that highlights incorrect IntelliSense behavior, with everything necessary to repro it?

[brettcannon]

I just landed a dev container in https://github.com/python/cpython , so you should be able to launch that and get the same environment I had when I ran into this (although you will probably have to turn off the deactivation of squiggles that's set in devcontainer.json).

[Colengms]

Hi @brettcannon . I don't think the settings from your devcontainer.json (mentioned above) would be sufficient to configure IntelliSense for that codebase, whether it's locally opened or opened using a container or Codespace.

I tried creating a new GitHub Codespace, with a fork of your cpython fork, and opening ceval.c. I used only the C_Cpp settings you provided (your devcontainer.json is no longer available at that link, so just what I quoted above). That results in a similar error to the one I get locally.

Can you provide self-contained instructions for a repro that configures IntelliSense for the project, that I can use to further investigate the issue you're reporting that occurs later in that file? Without an IntelliSense configuration that can successfully interpret the code leading up to the issue, the cause could be due to prior misinterpreted code.

[brettcannon]

For some reason the extension is deciding that NT_THREADS is defined and that PC/pyconfig.h should be used over the top-level pyconfig.h even though this is a Fedora image and the PC directory isn't open.
What may have happened for me is the squiggles on the headers disappear (inconsistently) when I drill into the header files, so I must have drilled in to check what the problems are, had the files open, and then opened the issue. For that red herring, I apologize.

I noticed your comment for the Makefiles extension, so I was starting to contemplate writing out c_cpp_configuration.json as part of devcontainer.json (CPython has a rule that no editor-specific settings can be checked into the repo), but then I noticed there were matching "defaults" settings. So I started to plug in header file paths and after some fiddling I think I resolved the error! Once again, I do apologize if this was a waste of time in the end for you.

But I did find a different error. 😅 With the following settings:

                "C_Cpp.default.compilerPath": "/usr/bin/clang",
                "C_Cpp.default.cStandard": "c11",
                "C_Cpp.default.defines": [
                    "CONFIG_64",
                    "Py_BUILD_CORE"
                ],
                "C_Cpp.default.includePath": [
                    "${workspaceFolder}/*",
                    "${workspaceFolder}/Include/**"
                ]

I am having things choke on something else, though, even with those settings:

The odd thing is other such files that have the same macro with the same arguments, like https://github.com/brettcannon/cpython/blob/8c711566006d339d67230d046f1789c8c762fd57/Objects/moduleobject.c#L68 and https://github.com/brettcannon/cpython/blob/8c711566006d339d67230d046f1789c8c762fd57/Python/ceval.c#L2747 , are not reporting the error. Would you prefer I repurpose this error or open a new one (or did I do something silly again? 😅)?

[brettcannon]

@Colengms while I wait to hear about the other error I have run into, I have gone ahead and pushed the settings I outlined above up to CPython (while retaining the setting turning the squiggles off).

[Colengms]

Hi @brettcannon . I needed to get a fully working IntelliSense configuration before I could investigate further. The best way to configure IntelliSense is based on the same command line used to compile the file(s). I mentioned Makefile Tools, as the project appears to be built using a Makefile, and that might allow import of exactly the same command line as used to build the file.

As I built the project manually, I saw build command lines like the following:

gcc -pthread -c -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O3 -Wall    -std=c11 -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration -fvisibility=hidden  -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o Python/ceval.o Python/ceval.c

So, I was able to get a proper configuration just by pasting that command line directly in a compilerPath first. However, the important bits seem to be:

{
    "C_Cpp.default.cStandard": "c11",
    "C_Cpp.default.defines": [
        "Py_BUILD_CORE"
    ],
    "C_Cpp.default.compilerPath": "gcc",
    "C_Cpp.default.includePath": [
        "${workspaceFolder}/Include/internal",
        "${workspaceFolder}",
        "${workspaceFolder}/Include"
    ]
}

So, I'm able to replicate the original issue (struct "_typeobject" has no field "tp_name"). However, I'm still trying to figure out how to reduce it to a simpler example in order to open a bug for it internally.