quote:

---

The effects of list-initialization of an object of type T are:
If T is an aggregate class and the braced-init-list has a single element of the same or derived type (possibly cv-qualified), the object is initialized from that element (by copy-initialization for copy-list-initialization, or by direct-initialization for direct-list-initialization).

---

struct StructToCreate { void DoStuff1() {} };
	
void func()
{
	StructToCreate localFoo1;
	// this code compiles in VS2013 and above, does not compile in VS2012
	auto CreateStructInstance{ localFoo1 };
	// BUG - VA shows no listbox when typing dot after "CreateStructInstance"
	// BUG - Goto Related cannot show members of this type
	CreateStructInstance;
	// this does NOT compile in VS2013, since in VS2013 auto type is std::initializer_list<StructToCreate>
	// this Does compile in VS2015 and above
	CreateStructInstance.DoStuff1();
}

struct Thing1 { void DoStuff1() {} };
struct Thing2 { void DoStuff2() {} };

template<typename T> T GetThing();
template<> Thing1 GetThing<Thing1>() { return Thing1{}; }
template<> Thing2 GetThing<Thing2>() { return Thing2{}; }

void func()
{
	auto Thing{ GetThing<Thing1>() };
	Thing. // <- No autocomplete list here
	GetThing<Thing1>(). // <- this works, autocomplete list shows DoStuff1
}

/**
 * Returns a non-const reference type as const.
 * This overload is only required until the pointer overloads are removed.
 */
template <typename T, SIZE_T N>
constexpr FORCEINLINE const T (&AsConst(T (&Array)[N]))[N]
{
	return Array;
}

quote:

---

Originally posted by feline

Thank you for checking. That seems to rule out a macro for T being a problem, but I am not sure what this leaves us with.

Can you please run Find References on T, and in the Find References Results check and see if any results are hidden. This is listed on the bar where the number of results is listed. If any results are hidden you can unhide them with the context menu filters. Also please check and make sure both:

Search all projects (P)
Show Projects

are turned On.

Would you be able to copy the full results and email me the results as a text file? This will contain details of your code, so I don't know if this will be a concern or not, but I am only interested in looking at the results to see if there is anything that offers a clue about what is going wrong here. If I find anything odd or strange I can try to set up versions of it here.

Assuming you can do so, the problem with this approach is that it doesn't include results from your include directories, only your solution, but hopefully it will still help.

If you are able to send me the results, please send me the files via email:

[email protected]

including this thread ID or URL in the description, so we can match it up.

---

quote:

---

Originally posted by feline

Thank you. The following Find in Files regular expression search is working well for me in VS2019:

^(?([^\r\n])\s)*#(?([^\r\n])\s)*define(?([^\r\n])\s)+T\b

and should catch any #define for T. I am running this with both Match Case and Use Regular Expressions turned On.

The "Look in" pull down dialog offers both "entire solution" and "all visual C++ directories"

If you have the time to leave this running, can you see if it finds anything?

---

quote:

---

Originally posted by feline

In my main test solution here, where the sample code works just fine, doing the Find Symbol search for .T. returns 2,033 results. This is with the same search settings. Most of these results are from the Boost library rather than my solution, but still, it shows that having lots of results for T isn't by its self enough to trigger this bug.

Which version of the IDE are you using? I have put together a regular expression find to look for a macro for T, which works in VS2022, but isn't working in VS2019. So I will just work out a version of the regex that works for your IDE. Maybe an IDE find in files will turn up some clues.

---

quote:

---

Originally posted by feline

I really didn't expect VA to have a problem due to T in the template class. I am not sure what to make of that to be honest.

First, the "easy" test, what do you get in the Find Symbol dialog for the search string:

.T.

to try and make this a bit more focussed, can you please right click in the list of symbols and make sure that you have:

Find Symbol dialog -> Right click menu -> Match case of search strings that contain uppercase letters = ON

just in case there are a load of lower case "t" symbols floating around as well.

To be honest I am not sure what we are looking for here, but macros called T would be my first concern.

You may need to turn Off both:

Find Symbol dialog -> Show only symbols defined in current solution
Find Symbol dialog -> Only classes, structs & namespaces

since we don't want to make any assumptions about where this problem is coming from, or the nature of the symbol behind it. Assuming it is going to show up in the Find Symbol dialog.

Another approach is to select T in the template class and try Alt-Shift-G and see what you get. If the "Goto Member..." dialog actually lists members then that may take us directly to what is confusing VA.

If this doesn't produce any useful clues, how many projects does your solution contain? If there is more than one, I am wondering if you would have the time to load individual projects, to see if we can pin down which project is triggering the problem. This assumes that the problem is triggered by a single project, and not by a global header included in several projects.

---

quote:

---

Originally posted by feline

The timing problem makes sense, since VA's parser takes time to look up all of the symbols in the code, to put it properly into "context" of your solution. This very strongly suggests that something in this block of code that I haven't renamed is the problem.

But this only really leaves us with "T", "test" and keywords.

OK, lets do the fast "fun" test. Can you please open VA's Find Symbol dialog and search for the following strings:

.auto.
.template.
.class.
.void.

dot means start or end of word, so these are whole word only matches. I am guessing one or more of these is going to match something in your main solution, ".auto." seems the most likely, since it is auto variables we are seeing the problem with.

The other test is to rename T to something quite random, in case that makes a difference. Can you please try this?

---

quote:

---

Originally posted by feline

Thank you, that actually makes more sense of this. It doesn't help much with the random element, but it does tell us that something in your main solution is a factor. My first theory, since you can see this in an empty file, is another symbol with the same name, quite possibly a macro, since I have seen odd effects when macros have overlapping names.

So, I have renamed the sample code, hopefully no chance of name clashes with this version:

class FelineVisualAssistAutoContentClass
{
  public:
	void FuncInsideFelineVisualAssist() { }
};

template <class T> T* FelineVisualAssistTemplateAutoItem()
{
	return new T();
}

void test()
{
	auto* felineTestVAVar = FelineVisualAssistTemplateAutoItem<FelineVisualAssistAutoContentClass>();
	felineTestVAVar;
}

do you still see the problem with this renamed version? If this "fixes" the problem it doesn't prove its duplicate symbol names, but it does suggest that's something to check.

---

class FelineVisualAssistAutoContentClass
{
  public:
	void FuncInsideFelineVisualAssist() { }
};

template <class T> T* FelineVisualAssistTemplateAutoItem()
{
	return new T();
}

void test()
{
	auto* felineTestVAVar = FelineVisualAssistTemplateAutoItem<FelineVisualAssistAutoContentClass>();
	felineTestVAVar;
}

quote:

---

Originally posted by feline

This sort of makes sense, in that it suggests VA's parser is getting quite confused about the auto variable. But the random element is quite puzzling, and really unhelpful.

Do you have time to make a simple default C++ console solution, and see if you get the same problem there with a couple of simple template classes? So far I have not seen the problem here, so I am trying to work out if the problem seems to be solution specific or not. I am guessing at the moment that it is solution specific, but that's just a guess.

---

quote:

---

Originally posted by feline

Does this sometimes work and sometimes fail in the same file and location, or does it work in some files / places and fail in other files / places? Hopefully it is location dependent, and not just "random".

If it fails some places, can you try placing the test at the very top of the file and see if this makes any difference? I am wondering if something, quite possibly from a header file, is confusing our parser. If so, then placing the test at the top of the file, before the confusing code, should "fix" it. If so then this is a useful clue.

---

quote:

---

Originally posted by feline

OK, that's not something that I would expect VA to have problems with, and so far no obvious signs of problems here.

First, can you see what you have the two settings:

VA Options -> Editor -> Convert dot to -> in C/C++
Convert dot to -> if operator -> is overloaded

set to? Does turning this On make any difference? The setting is designed to help with smart pointer templates, so may help here.

Beyond that, when you see the problem, can you please place the caret into the variable and see what VA shows in its context and definition fields, these are normally at the top of the editor window and are where the Alt-M list is shown from. This will tell you what VA thinks is the variable type. If they are blank then VA is having problems working out what is going on, which would certainly explain the problem you are seeing. Or VA might have worked out the wrong type, which would also explain the problem.

Either way it hopefully gives us somewhere to start.

---

TestClass * testVar = TestTemplate<TestClass>()

auto * testVar = TestTemplate<TestClass>()

template<class T> T * TestTemplate()

quote:

---

Originally posted by feline

Would you be able to post, or send me, a code sample that shows this problem? For the Unreal Engine case, if I set up a simple test template function that seems to do the same thing, with a different name, then it works correctly. This doesn't much help with the Unreal Engine problem, but it does indicate that there is something odd going on in this case.

If I can reproduce the problem you are seeing, I might be able to do something to help.

Please send me the files via email:

[email protected]

including this thread ID or URL in the description, so we can match it up.

---

class TestClass
{
public:
	void TestFunction() {}
};

template<class T>
T * TestTemplate()
{
	return new TestClass();
}

void test()
{
	auto * testVar = TestTemplate<TestClass>();
	testVar. // <-- point of failure
}

quote:

---

Originally posted by feline

Unfortunately no progress yet. I will have another look at this, to see if some sort of work around helps.

From the bug report its not at all clear what is causing the problem, since the problem only shows up some of the time, so its not even all uses of Cast<> with auto. Very confusing.

---

quote:

---

Originally posted by feline

In general VA's auto handing should work well, but VA can struggle with template code, since templates are instanciated at compile time, and VA does not get to compile the code. Currently auto does not correctly work out the return type from template functions, which is an open bug report. It's possible the same bug is showing up here.

casting should work correctly, but "Cast" is an unreal engine specific function, and is thus different to "normal" casts.

One place auto does work well in my experience is STL style iterators, which tend to have very long types to write out manually. But I don't know how much of this you will be doing in Unreal Engine.

If you place the caret into "Cast" what are you seeing in VA's context and definition fields? For the simple test code:

ACharacter *simpleCharacter;
APawn* pBaseClass = simpleCharacter;
auto characterCast = Cast<ACharacter>(pBaseClass);

I am seeing:

context field = ACharacter
definition field = class ENGINE_API ACharacter : public APawn{...}

which is not right.

---