Open GuLicheng opened 4 years ago
Hi @GuLicheng . How are you configuring the C/C++ Extension? The "sv" literal operator requires C++17. Using the following in my c_cpp_properties.json
, I'm unable to repro any squiggles with the code you provided:
"cppStandard": "c++17",
There is my configuration and code and I use "cppStandard": "c++20":
------------------ 原始邮件 ------------------ 发件人: "Colen Garoutte-Carson"<notifications@github.com>; 发送时间: 2020年10月20日(星期二) 上午6:51 收件人: "microsoft/vscode-cpptools"<vscode-cpptools@noreply.github.com>; 抄送: "Yan"<576356467@qq.com>; "Mention"<mention@noreply.github.com>; 主题: Re: [microsoft/vscode-cpptools] cannot deduced type for opeartor"" (#6343)
Hi @GuLicheng . How are you configuring the C/C++ Extension? The "sv" literal operator requires C++17. Using the following in my c_cpp_properties.json, I'm unable to repro any squiggles with the code you provided:
"cppStandard": "c++17",
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
@GuLicheng Could you provide the following?
c_cpp_properties.json
file. This should tell us how the extension is configured."C_Cpp.loggingLevel": "Debug"
. This would include any errors and information we may have received from the compiler.C/C++: Log Diagnostics
command, after the repro and while the file is still open. This should tell us how we have configured IntelliSense for that file.------------------ 原始邮件 ------------------ 发件人: "microsoft/vscode-cpptools" <notifications@github.com>; 发送时间: 2020年10月20日(星期二) 上午8:49 收件人: "microsoft/vscode-cpptools"<vscode-cpptools@noreply.github.com>; 抄送: "Yan"<576356467@qq.com>;"Mention"<mention@noreply.github.com>; 主题: Re: [microsoft/vscode-cpptools] cannot deduced type for opeartor"" (#6343)
@GuLicheng Could you provide the following?
The contents of your c_cpp_properties.json file. This should tell us how the extension is configured.
The output of the C/C++ Output channel leading up to the issue, with debug logging enabled using "C_Cpp.loggingLevel": "Debug". This would include any errors and information we may have received from the compiler.
The output of the C/C++: Log Diagnostics command, after the repro and while the file is still open. This should tell us how we have configured IntelliSense for that file.
The output of the C/C++ Configuration Warnings output channel, if any.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.
Here is some information:
Cpp_Confugration.json:
{
"configurations": [
{
"name": "Win32",
"includePath": [
"${workspaceFolder}/**"
],
"defines": [
"_DEBUG",
"UNICODE",
"_UNICODE"
],
"windowsSdkVersion": "10.0.18362.0",
"compilerPath": "E:/msys2/mingw64/bin/g++.exe",
"intelliSenseMode": "gcc-x64",
"cStandard": "c11",
"cppStandard": "c++20"
}
],
"version": 4
}
The issue IntelliSence provided:
User-defined literal operator not found C/C++(2486) [14, 15]
User-defined literal operator not found C/C++(2486) [15, 16]
// No quick fixes available
Cpp Code:
constexpr bool operator""_b(unsigned long long x)
{
return x == 0;
}
int main()
{
using namespace std::literals;
auto sv = "string_view"sv; // User-defined literal operator not found C/C++(2486) [14, 15]
auto str = "string"s; // User-defined literal operator not found C/C++(2486) [15, 16]
constexpr auto a = 12_b; // it’s ok
}
I reported a bug on our shared VS component at https://developercommunity.visualstudio.com/content/problem/1227674/cc-gives-error-with-gcc-81-string-view-header-due.html , although it might be duplicate of other issues.
I'm not able to repro this with 1.1.3. Let me know if you're still hitting this.
Yeah, I repro still with gcc 8.1. headers (not 10).
I still have this issue, and here are some reports in my
inline namespace literals { inline namespace string_literals {
_GLIBCXX_DEFAULT_ABI_TAG
inline basic_string<char>
operator""s(const char* __str, size_t __len)
{ return basic_string<char>{__str, __len}; }
_GLIBCXX_DEFAULT_ABI_TAG
inline basic_string<wchar_t>
operator""s(const wchar_t* __str, size_t __len)
{ return basic_string<wchar_t>{__str, __len}; }
// invalid second parameter type("unsigned long long") for literal operator; must be size_t C/C++(2469) // gcc version: 10.2, // platform: Win10
Yes, I also repro it with gcc 10.2 headers via mingw64 (it doesn't repro with gcc 10.2 on Linux).
I have another issue:
#include <iostream>
namespace mode
{
struct lazy { };
struct eager { };
} // namespace mode
template <typename _Derived_Type, typename _Mode = mode::lazy>
class single_object
{
public:
using derived = _Derived_Type;
single_object(const single_object&) = delete;
single_object& operator=(const single_object&) = delete;
static derived* get_instance() noexcept
{
static derived* instance = new derived();
return instance;
}
constexpr static const char* debug() noexcept
{
return "mode is lazy";
}
protected:
constexpr single_object() noexcept = default;
};
template <typename _Derived_Type>
class single_object<_Derived_Type, mode::eager>
{
public:
using derived = _Derived_Type;
single_object(const single_object&) = delete;
single_object& operator=(const single_object&) = delete;
static derived* get_instance() noexcept
{
return instance;
}
constexpr static const char* debug() noexcept
{
return "mode is eager";
}
protected:
single_object() noexcept = default;
inline static derived* instance = new derived(); // ***
};
class foo1 : public single_object<foo1> { };
class foo2 : public single_object<foo2, mode::eager> { };
int main()
{
auto p1 = foo1::get_instance();
auto p2 = foo2::get_instance(); // class "foo2" have no member "get_instance" C/C++(135)
// but if I remove "***" above, it will not repro this issue
std::cout << p1->debug() << std::endl;
std::cout << p2->debug() << std::endl;
}
It also can be compiled