CPP 20 requires clause and Intellisense Error

[grindstaffp]

Hello,

I have run across what seems to be a bug somewhere in the intellisense engine. I am not sure if it falls under the scope of VisualGDB or not but thought I’d bring it to attention in case it does.

When creating function templates that utilize concepts, the placement of the requires clause seems to impact intellisense from the declaration of that function on. By that, I mean intellisense remains functional on any code prior to the requires clause, but any code after is not recognized by intellisense. The intellisense log does not provide any errors but it does seem that the placement of a requires clause determines if there is an issue or not.
For example, the following function template results in intellisense not functioning on code after this function:

template <typename T>
requires std::integral<T>
void update_attribute(T new_value) {...}

However, if the requires clause is moved to the end of the function signature, intellisense behaves normally.

template <typename T>
void update_attribute(T new_value) requires std::integral<T> {...}

• This topic was modified 2 years, 5 months ago by support. Reason: formatting

[support]

Hi,

Thanks, we are aware of this. It is caused by a limitation of Clang 6.0 used by our IntelliSense engine. We are planning to move to the latest Clang 13.0 in the next major version of VisualGDB, that should resolve the issue.

[PeterU]

Hi,

Does Sysprogs have a planed release date for the next major version of VisualGDB, as I have notice the next major version mentioned in a few posts.

Thanks

[support]

Hi,

No problem, we will clarify. We usually release a major version every year, with many smaller beta/bugfix releases in between, following the cycle below:

1. We pick the features from the backlog based on the number of users that would be interested in it, and their impact. We run some internal tests and assess the feasibility/complexity.
2. We then release a few beta versions, gradually introducing the new features (and often, new bugs) and rely on the beta feedback to perfect them.
3. Once we are confident with the quality of the recently introduced features, the beta branch becomes the stable branch.
4. Once the stable release is out, we release updates to the BSPs, toolchains, etc., that were not released in parallel with the product development.
5. Until we are ready to introduce the next beta, we publish bugfix releases (R2, R3, etc.) that resolve issues and introduce smaller and less riskier features.

Sometimes, features initially considered for a major release get delayed and grouped with other features. E.g. we have received many requests for different smaller smart tags (e.g. generate C++ operators) and ended up introducing RefactorScript – a universal mechanism that allows defining custom code generation patterns, rather than having a hardcoded smart tag for each specific case. In general, we look for the number of users that could be interested in a specific scenario, and by how much their productivity will be improved by a certain feature.

Currently, we have just released stable VisualGDB 5.6 that includes most of the features requested earlier. We are now working on a few BSP updates and new device family integrations. We will then proceed with the internal experiments on a few major features, and once their complexity and possible drawbacks are clear, we will begin rolling out beta versions and gathering feedback.

When it comes to updating the Clang engine, it usually results various minor glitches, that take some trial and error to get resolved. We will analyze the changes in the latest Clang 13.0 during the next few months (the exact timeframe depends on the feedback on other features and the number of BSP-related changes) and will either assign a specific timeframe to it, or will push it to the next version. Based on our current understanding, the glitches arising from the currently used Clang 6.0 have relatively simple workarounds, so it is not a high priority. If this is a blocking issue for you, please let us know and we will try to assign a higher priority to it.

[PeterU]

Hi,

Thanks for the feed back. The clang version is not a blocking issue, I have been trying out the .clang_format for code formatting and there are options that are available in later versions that would be useful.

I had noticed that VisualGDB has been at v5.x for a number of years and had assumed the next major version in your answer meant v6.o. From your answer it seems that v5.6 is a major version and the next would major version will be v5.7

[Author]

Posts