[Mono-devel-list] "precise location handling" patch for mcs

[Ben Maurer]

On Fri, 2004-12-24 at 03:12 +0900, Atsushi Eno wrote:
> I have some problems/questions to solve:
> 
> 	- In location.cs, I dare set token field as int. Thus when
> 	  there are many files to compile, it won't provide column
> 	  information nicely (those information are kept compact).
> 
> 	  For example, our mscorlib.dll have nearly 1200 files and
> 	  mcs does not provide column numbers at best 7(!).

So you need 11 bits for the file name. For any file less than 8000
lines, you can give up to 256 cols. The line / col tradeoff could be
done per file: a file with lots of lines won't get column number
information. You could also give fuzzy col numbers (does it matter if it
tells me col `57' or `58'?). This could save some bits.

Another way I can think of to solve the problem: Every 256 lines you
parse, make an entry into a table that looks like this:

checkpoint [i ++] = { "file name", segment line number }

So, this means every 256 lines you have a `checkpoint', with this
information. You then can encode location to look like:


[ checkpoint (16 bits) ] [ line delta (8 bits) ] [ col num (8 bits)]

`line delta' is how many lines after the checkpoint this location is.
Col number is the column number. To make this encoded location into a
string you say:

filename = checkpoint [loc.checkpoint].filename
line = loc.linedelta + checkpoint [loc.checkpoint].line
col = loc.col

The only problem with this is `what do you do when you run out of
checkpoints?' One idea is that you reserve the upper bit of `checkpoint'
to mean `overflow'. If this bit is set, just encode a file in the first
16 bits and a line number in the second 16 bits, and bail out on col
numbers. 


> 	  If I modify token field from int to long, it will mostly
> 	  handle precise columns more, but it results in huge memory
> 	  consumption (like from 55k to 72k for building mcs).
How much does the RSS memory used by `ps' change? That is the number
that really matters.

> 	  So which is the preferable solution, to use long or not?
> 
> 	- In report.cs, there are many places that directly uses
> 	  Location members instead of Location.ToString(). Is there
> 	  any reason to do so?

You could make properties to get needed information.

-- Ben