auto deduction with templates

[dvoraen]

Hello! I am not sure if I'm in the right place for this, but by everything I can find, auto keyword type deduction should be functional and a part of the C/C++ extension...? However, it seems to utterly fail on my side for reasons I can't figure out for the life of me.

(The types of pOldParent and pNewParent should show as shared_ptr<node<T>> though it might be getting confused with pOldParent since I have nullptr thrown in there in the ? : expression)

And this is what the debug log of the extension has to say:

(All those hovers are of the auto pOldParent variable.)

If you want full context of the code, below is the link to the folder in question. It's just me relearning red-black trees and trying to get myself up to speed with parts of C++20 at the same time. :)

https://github.com/dvoraen/cpp-research/tree/main/tree

So I have the following questions:

• Am I using the wrong tools for auto deduction in VSCode, or am I falsely under the impression that this is a feature?
• Am I configured correctly?

The snippets below are my C/C++ extension settings and workspace settings. (I have not included User settings for the sake of brevity, and they don't seem to apply here, as they aren't modifying IntelliSense.)

c_cpp_configurations.json

{
    "configurations": [
        {
            "name": "Win32",
            "includePath": [
                "${workspaceFolder}/**"
            ],
            "defines": [
                "_DEBUG",
                "UNICODE",
                "_UNICODE"
            ],
            "windowsSdkVersion": "10.0.22000.0",
            "compilerPath": "cl.exe",
            "cStandard": "c17",
            "cppStandard": "c++20",
            "intelliSenseMode": "windows-msvc-x64"
        }
    ],
    "version": 4
}

settings.json

{
    "C_Cpp.default.cppStandard": "c++20",
    "C_Cpp.autoAddFileAssociations": false,
    "C_Cpp.inlayHints.autoDeclarationTypes.enabled": true,
    "C_Cpp.inlayHints.autoDeclarationTypes.showOnLeft": true,
    "C_Cpp.inlayHints.parameterNames.enabled": true,
    "C_Cpp.inlayHints.referenceOperator.enabled": true,
    "C_Cpp.codeAnalysis.clangTidy.enabled": true,
    "C_Cpp.loggingLevel": "Debug",
}

[Colengms]

Hi @dvoraen . IntelliSense seems to be working correctly in your repro.

In your scenario:

template <copy_orderable T>
void node<T>::rotate_left()
{
    auto pOldParent{ pParent };
    auto pNewParent{ pRight };

Note that the template type (copy_orderable T) is not yet known at this point in the code. Because of this, IntelliSense does not actually yet know the contents of the class that this member function may be expanded for. It's possible you may yet provide a template specialization for node<some_specific_value> with completely different member fields, before calling (and thus expanding) your inline template member function. If you replicate the same pattern, without the use of templates, you should see that the auto type is correctly resolved when hovering over the variable names.

We do have a feature request open to allow the specifying of an arbitrary template parameter types/value for the purpose of IntelliSense, like a similar feature in Visual Studio. This is here: #1946 . However, in your case, since a specialization of the class could change the underlying class used by a member function template, I'm not sure if that would address your scenario.

[dvoraen]

Hi! Thank you for the response!

I guess I'm a little confused and/or have a misconception about IntelliSense with respect to template parameters and auto deduction then.

My thought was that in the snippet you posted, auto would deduce the type of pNewParent to shared_ptr<node<T>>, to match the type of pRight in this case. I don't really need to know what type T is deduced to be, since the template hasn't been instantiated yet in the actual template code, and the concept is meant to filter out the types that aren't valid for T, for the purpose of what I actually do with T (in this code, just copy-initialization and value comparison). But it would be nice to know what the uninstantiated template is for the purpose of making sure my auto variables are having the correct type. Am I more making a feature proposal at this point, or am I simply incorrect in my assumption that IntelliSense should be spitting out types for virtually all uses of auto such as the code I've presented to you here?

To clarify: is it considered more correct to spell out types in template code when writing the code that comprises the template? Are you saying that IntelliSense will only deduce the type of auto after the template is explicitly instantiated, as it is in main.cpp?

[Colengms]

To clarify, as you observed, IntelliSense doesn't appear to be displaying 'auto' variable types unless it's able to (fully) resolve that type.

A simplified example:

template <typename T>
class A
{
public:
	T x;

	void foo();
};

template <typename T>
void A<T>::foo()
{
	auto y = x; // y is of an unknown type, so only 'auto' is displayed.
}

In your case, you're using a concept in place of typename. That filters acceptable types, but the type is still not yet known when evaluating shared_ptr<node<T>>, so falls back to displaying auto.

It would seem possible for it to instead display template<class T> std::shared_ptr<node<T>> (which is displays when hovering over pParent/pRight in your example, where used to construct autos.).

I'd suggest opening a Feature Request by clicking on 'Suggest a Feature' here (against Visual Studio), as this functionality is in common code, which the C/C++ Extension inherits from Visual Studio.