Some requests for Visual Studio integration enhancements to support the new age of OO Fortran

[Andrew_Smith]

1. Once you extend a type you can no longer hover over a component to see its value. Adding a watch is time consuming since you need to modify the watch expression to include the full list of extensions back to the base type where the component was declared.

Is it hard to make VS see derived type components the same way the compiler does ? I realize I have asked this before but nothing has come of it and I could not find my previous post.
 

I do not see why Visual studio needs to know about the chain of inheritance. It could show components directly just as we would use them in code, or it could allow both routes to a component like it does in .net languages.

VS gets slower and slower with the length of the watch expression so having components visible directly would improve performance of the debugger.

2. How about making it possible to to view scalar derived type components on arrays of derived types as an array ?

3. Having the watch able to list the contained procedures on an object (derived type instance) might also be useful, again already available in .net languages.

I put the above 3 requests in priority order.

[Lorri_M_Intel]

Hi Andrew -

    Would you mind creating a small example program showing what you want to see?   We did change something in the VS representation of extended types in the hopes of allowing this:
 

type base
    integer b1
end type base

type, extends(base) :: ex1
end type ex1

type(ex1) :: foo

! In Fortran rules you can specify:

foo%b1 = 12

! or you can specify

foo%base%b1 = 17

! It would be nice if the debugger let you do the same

end

If that did not go well, we'd like to hear about it.

And, interesting suggestion about showing the type-bound procedures too. 

             Thanks -

                              --Lorri

[Andrew_Smith]

OK, I will get back to you on that shortly

[FortranFan]

Andrew Smith wrote:

OK, I will get back to you on that shortly

I look forward to your example as it's always useful to have improved functionality in all aspects of a Fortran developer's work process, especially in debugging.  Also, I'm keen to learn what you've in mind because other than for generics, I'm currently quite happy with the support for OO features with Intel Fortran integration with Visual Studio, particularly the debugger; there are a couple of other things I'd like, as explained here and here but these are separate aspects.

If one uses the simple example in post #2 of this thread, the debugger seems to offer good help - so what further features are needed other than of course some clarification with generics?

[Andrew_Smith]

Here is some code to test what I was thinking of. I could not do these things in VS2010 with XE 15.0 update 3 and FortranFan did not demonstrate these things were possible. I used single letter names for the types and local variables but if you use meaningfull names then the watch expressions get very long. They can tax the space on a 1080p screen and can make Visual studio unresponsive.

Being able to see slices of components in arrays of derived types would save having to declare local array pointers for debugging.

[FortranFan]

Andrew Smith wrote:

Here is some code to test what I was thinking of. I could not do these things in VS2010 with XE 15.0 update 3 and FortranFan did not demonstrate these things were possible. I used single letter names for the types and local variables but if you use meaningfull names then the watch expressions get very long. They can tax the space on a 1080p screen and can make Visual studio unresponsive.

Being able to see slices of components in arrays of derived types would save having to declare local array pointers for debugging.

For the benefit of other readers, many of whom may not want to download files to their workstations (I too prefer not to download and like it when folks post their code directly in the comment section using the "{..}code" link), here is the code Andrew posted:

module Mod1
   implicit none
   
   type A
      integer :: aa = 1
      contains
      procedure, nopass :: aaa
   end type
   type, extends(A) :: B
      integer :: bb = 2
      contains
      procedure, nopass :: bbb
   end type
   type, extends(B) :: C
      integer :: cc = 3
      contains
      procedure, nopass :: ccc
   end type
   type, extends(C) :: D
      integer :: dd = 4
      contains
      procedure, nopass :: ddd
   end type
   type, extends(D) :: E
      integer :: ee = 5
      contains
      procedure, nopass :: eee
   end type
contains
subroutine aaa()
end subroutine
subroutine bbb()
end subroutine
subroutine ccc()
end subroutine
subroutine ddd()
end subroutine
subroutine eee()
end subroutine
   
end module

Program Test
   use Mod1
   implicit none
   type(E) foo
   type(E) bar(10)
   integer i
   do i = 1, 10
      bar%aa = i
   end do
   continue ! Place a break point on this line
   !Request 1
   !  Hover the mouse over foo. Can you see the values of all the components without expanding foo ?
   !  Can you do the same for a watch and in the locals window
   !  Can you see the same components under the expanded type ?
   
   !Request 2
   !  Hover mouse over bar%aa. Can you expand the watch to show an array of integer values 1 to 10 ?
   !  Can you do the same for a watch and in the locals window
   
   !Request 3
   !  Hover mouse over foo and expand. Can you see all contained procedures aaa to eee without expanding foo ?
   !  Can you do the same for a watch and in the locals window
   !  Can you see the same procedures under the expanded type ?
end program

So it appears there are a couple of things Andrew is interested in:

1. see components and procedures without having to explicitly "unfold" a derived type in the debugger: this is per his request 1 and 3.  Perhaps Andrew can clarify, but I take this to mean that Andrew is asking for the default view in the debugger for a derived type not to be the collapsed form as it currently is (with the right-pointing triangle to the left of the type) but a fully expanded one.  Currently the user has to hover the cursor over the right-pointing triangle to start unfolding the type i.e., expanding the type component information to see what all it contains.  If this is what Andrew means, then I don't know what to say.  I think the current functionality in the debugger is just fine - the user doesn't need to click anything; just hover the cursor appropriately and information gets revealed.  For my complicated derived types, I worry things will slow down considerably if the fully unfolded state of the type were to be displayed whenever I hover the cursor over it.  Hopefully Intel folks and other readers can chime in and provide their comments.  Unless Andrew can elaborate further, I don't think though that requests 1 and 3 pertain to any gaping debugging holes which adversely constrain a Fortranner employing the OO capabilities in Fortran 2003 and beyond.
2. request 2 seems to suggest an expanded list view of a particular scalar component in an array of derived types - the specific example might involve being to able to generate an expanded list of 10 values: bar(1)%aa; bar(2)%aa, bar(3)%aa, ... bar(10)%aa as if one were looking at an array variable, say integer :: arr_aa(10).  Note Fortran supports the array type of assignment (see the line bar%aa = i), but the debugger currently does not support array type of viewing, either when one hovers over it or enters bar%aa in a watch window.  One has to hover through each array element and its subcomponents to see aa.  Now Andrew can confirm this is indeed what he means.  I feel very neutral about this: yes, it will be nice to have such a capability if one keeps the broad the user base in mind but if the users don't mind using the ASSOCIATE construct, they can work around this gap (which is what I do in the rare instances I need something like this).  Nonetheless, this has less to do with the specific OO features introduced in Fortran 2003 standard and expanded upon in Fortran 2008, but it is probably something that has been around since the early days of Intel Fortran supporting derived types from the Fortran 90 standard.

Thanks for initiating a good discussion, 

[Andrew_Smith]

I agrea with you comment that the initial state should not be expanded. Sorry I missed a step in all my requests 1 to 3 in they alll require the user to expand them once first. The difference for request 1 is that the user would no longer require multiple expansions to see components burried in a long chain of type names. So in my example the debugger would show foo%aa : 1 rather than foo%d%c%b%a%aa : 1

In request 2 it would show bar%aa as a 10 element array rather than having to set multiple watches, one for each element.

[FortranFan]

Andrew Smith wrote:

.. The difference for request 1 is that the user would no longer require multiple expansions to see components burried in a long chain of type names. So in my example the debugger would show foo%aa : 1 rather than foo%d%c%b%a%aa : 1

..

In the watch window, the debugger does work ok if something like foo%aa is used; one does not need to supply the full inheritance chain of foo%d%c%b%a%aa.  So the question is how it should work when one hovers the cursor over foo, or looks at foo in the Locals window.  To me, it appears the current behavior of Intel Fortran in Visual Studio is indeed consistent with OO-based languages in Microsoft's own .NET environment e.g., C#.  That is, in the C# code I work with, an extended class (equivalent of foo) shows up folded when I hover the cursor above it and when I unfold it, the parent class (similar to type d in the above example) is listed as base and I have to unfold it to view its contents along the lines of this.base..  So it's not as though the components of base class show up in the extended class in the fashion of foo%aa; it's more like foo%d%...  So Intel may have to deviate from the Microsoft's convention in this regard to enable your request.

Separately, as I indicated earlier, an ASSOCIATE construct can be handy while working with extended derived types even though I appreciate the fact that not everyone will be enamored with it:

[Andrew_Smith]

FortranFan wrote:

“In the watch window, the debugger does work ok if something like foo%aa is used; one does not need to supply the full inheritance chain of foo%d%c%b%a%aa.”

I tried this in VS2010 for C# and Fortran. Only C# allows it but neither language worked with hover over.

[FortranFan]

Andrew Smith wrote:

FortranFan wrote:

“In the watch window, the debugger does work ok if something like foo%aa is used; one does not need to supply the full inheritance chain of foo%d%c%b%a%aa.”

I tried this in VS2010 for C# and Fortran. Only C# allows it but neither language worked with hover over.

..

Hmm.. that's strange.  foo%aa in watch window does work for me, and I think such a feature has been available to me for quite a while now, I'm guessing since compiler 14.  So not sure why it does not work for you - something worth following up on with Intel.

[Andrew_Smith]

Intel: I get "Invalid structure member" when watching a component of a derived type where the component is declared in a parent class. This happens with XE 15.0 integration in VS 2010 or VS 2012. FortranFan is not seeing this error. What versions of VS and Fortan integration should this work in ?

[Steven_L_Intel1]

Andrew, please provide us a test case and we'll look into it for you.

[FortranFan]

Steve Lionel (Intel) wrote:

Andrew, please provide us a test case and we'll look into it for you.

Steve, see message #6 and #8 which has the test case.  Or do you want Andrew to supply you with his Visual Studio solution and project files as well?

[Steven_L_Intel1]

Andrew's example in post 6 doesn't match the problem description. For one thing, it has no class declarations!

[FortranFan]

Steve Lionel (Intel) wrote:

Andrew's example in post 6 doesn't match the problem description. For one thing, it has no class declarations!

Steve,

In message #8, Andrew is trying to draw a comparison to what coders using OO techniques with C# .NET can do in Visual Studio debugger versus what Fortran coders of similar OO approaches can achieve with Intel Fortran integration in Visual Studio.  You'll notice from the original post that this is the theme of this thread.  So in the image in message #8, the left half is C# window and Fortran is on the right half.

You only need to focus on the Fortran half of the image.  You'll notice he has added "foo%aa" to the Watch window in debugger but it says "Invalid structure member".  I do not have this issue  - I can indeed see the value for foo%aa (I should feel special, may be! :-).  I've Intel Fortran XE 2015 update 4 as well as 16.0 beta, update 2 installed and integrated with VS 2013. 

[Andrew_Smith]

My bad, I should have said "parent type", not "parent class" in the first paragraph of my recent post.

My post on Fri, 06/19/2015 - 15:18 shows the problem. It uses the code I posted earlier. It relates to request 1 in my first post.

Although I use XE 15.0 integration, I use the compiler setting for an earlier version. Could that be the cause ? I guess I can easily try that myself.

[Steven_L_Intel1]

It is very likely related to the compiler, since the compiler puts out the symbol information. Please try the newer compiler.