Expressions Estimates

[Sami Wagiaalla <swagiaal at redhat dot com>]

Here is a summary of the issues Keith and I have identified and some 
rough estimates. We have dug more deeply into some of these than we have 
into others so some are more like intelligent guesses than accurate 
estimates. Also, we may have missed some issues here. But, over this 
summary should definitely assist in constructing the road map.

Between the two of us we have test cases for all of these issues.

* Namespaces and classes cannot own 'using' declarations nor namespace
  aliases. My suggestion to solve this problem is to provide "block"
  representation of namespaces and classes. Once that is done lookup
  methods should be connect with this. This will solve this problem
  and simplify other lookup issues.

Estimate [two months]

* gdb does not understand Koenig lookup.

Estimate [three weeks]


* gdb is *very* inconsistent with spaces in type names.
  For example, while "print" may print "void *",
  "info func" will use "void*".

* gdb is also very inconsistent with the const keyword. Sometimes it
  puts "const" before the '*'/'&' (with or without a space), sometimes
  after.
  For example, "print 'base::operator*'" will return
  "{base (const base * const, const base &)} 0x8049444
  <base::operator*(base const&) const>"
  Note that the parameter to the method is "const base &" in the type,
  declaration, but "base const&" in the parameter list.

* The type "long" is sometimes converted to "long int", "short" is
  sometimes converted to "short int".
  For example, look at the output of "info func long": it defies logic.

The three issues above and general inconsistencies about gdb's 
presentation and understanding
of types can be hacked around in a couple of week. Fixing it properly 
will take longer
so we will add this as an optional item [one month].

* Manipulating template functions and typedefs of template functions is
  inconsistent. Users must name functions exactly as they are
  represented in gdb's internal structures, and single quoting is
  sometimes required.

* functions must exactly match internal gdb representation. The
  particular example we ran into was with const overladed functions.
  User must say {break,print,...} 'base::overload() const'
  for it work.

The theme here is more intelligent matching between what the user 
specifies and what gdb has in its internal data structures, for better 
usability

Estimate [one month]

* Manipulating constructors and destructors is broken. This item has a
  dependency on having proper namespace/class lookup.

Estimate [one month]

* Tap completion of c++ structures requires a single quote at the
  beginning of the line:
  (gdb) break 'base::<TAB><TAB>

* Single quotes are required sometimes to placate the lexer. For this
  and other lexer issues that we have run into more c++ intelligence
  needs to be added to the lexer.

Estimate [one month]

* gdb does not understand variable length arrays
(gdb) list
1
2       int main(){
3         int n = 5;
4
5         int array[n++];
6         int array2[n++];
7         int array3[5];
8         return 0;
9       }
(gdb) print array3
$1 = {0, -1078038600, 134513881, 5127397, 3825652}
(gdb) print sizeof array3
$2 = 20
(gdb) print array2
$3 = 0x607ff4
(gdb)

Estimate [one month]

Comments, corrections additions are welcome.