Author Topic: Another 'auto' in C++ range based for loop with wrong evaluated type  (Read 1072 times)

rowbearto

  • Senior Community Member
  • Posts: 2162
  • Hero Points: 132
I have another testcase where SE incorrectly determines the evaluated type of an 'auto' in a range based for loop in C++. It is likely different from my other post.

Look for auto_protobuf.tar.gz on support.

The README file has detailed information about reproducing the issue.

Dennis

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 3606
  • Hero Points: 480
Re: Another 'auto' in C++ range based for loop with wrong evaluated type
« Reply #1 on: January 24, 2022, 04:20:26 pm »
Also added to my list.

rowbearto

  • Senior Community Member
  • Posts: 2162
  • Hero Points: 132
Re: Another 'auto' in C++ range based for loop with wrong evaluated type
« Reply #2 on: January 24, 2022, 04:32:13 pm »
Thanks Dennis. Would be helpful if you could at least see if you reproduce it, but not necessarily solve it, so that I can adapt the example in case you can't reproduce. I wouldn't expect you to solve it right away, but if you can't repro it I may need to go back and change my testcase. If it is in your list without repro and you don't get to it for a while it may be difficult for me to recall the details and get myself back up to speed.

rowbearto

  • Senior Community Member
  • Posts: 2162
  • Hero Points: 132
Re: Another 'auto' in C++ range based for loop with wrong evaluated type
« Reply #3 on: January 24, 2022, 04:38:36 pm »
Additionally my 'real application' that the testcase is based on changes over time and may not be the same as when I created the testcase, and I may not be able to get the old one back.

Dennis

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 3606
  • Hero Points: 480
Re: Another 'auto' in C++ range based for loop with wrong evaluated type
« Reply #4 on: March 09, 2022, 04:57:58 pm »
This bug exposed another subtle C++ parsing bug with using statements behaving as typedefs.  Will be fixed in 26.0.2.

Thanks again for the patience and detailed sample code and reproducible test case.