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

[Atsushi Eno]

Hello,

I uploaded the updated patch here:
http://www24.brinkster.com/ginga/mcs-location-1228.diff
It includes the implementation of Ben's "checkpoint" idea,
fixed variable namings, and eliminates "location.Row" usage
in report.cs (now uses location.ToString()).

But I think I had better eliminate more "lexer.Location"
for expressions. So lemme make advanced patch for it.

Atsushi Eno

Miguel de Icaza wrote:
> Hello,
> 
> 
>>I put a performance comparison here (I think it is not so bad):
>>http://www24.brinkster.com/ginga/perf-org.txt
>>http://www24.brinkster.com/ginga/perf-loc.txt
>>(In short: 53724KB -> 55684KB)
> 
> 
> This in general looks good, but there are a few variable names that must
> be changed (pascalCased variables should be turned into split_words).
> 
> 
>>It also fills location for SymbolWriter.
>>
>>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(!).
>>
>>	  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).
>>
>>	  So which is the preferable solution, to use long or not?
> 
> 
> To not use long, that is a price too high to pay.
> 
> 
>>	- In report.cs, there are many places that directly uses
>>	  Location members instead of Location.ToString(). Is there
>>	  any reason to do so?
> 
> 
> Might just be historic.
> 
> Miguel
>