Re: [RFC] Use wide chars to represent Fortran source internally

[FX <fxcoudert at gmail dot com>]

> -fbackslash
>   Change the interpretation of backslashes in string literals from  
> a single backslash character to "C-style" escape characters.  The  
> following combinations are expanded \a, \b, \f, \n, \r, \t, \v, \,  
> and \0 to the ASCII characters alert, backspace, form feed,  
> newline, carriage return, horizontal tab, vertical tab, backslash,  
> and NUL, respectively.  All other combinations of a character  
> preceded by \ are unexpanded.

I used your proposition and changed the wording a bit, so here's what  
I committed (not show as a diff because it makes it less readable):

Change the interpretation of backslashes in string literals from a  
single
backslash character to ``C-style'' escape characters. The following
combinations are expanded @code{\a}, @code{\b}, @code{\f}, @code{\n},
@code{\r}, @code{\t}, @code{\v}, @code{\\}, and @code{\0} to the ASCII
characters alert, backspace, form feed, newline, carriage return,
horizontal tab, vertical tab, backslash, and NUL, respectively.
Additionally, @code{\x}@var{nn}, @code{\u}@var{nnnn} and
@code{\U}@var{nnnnnnnn} (where each @var{n} is a hexadecimal digit) are
translated into the Unicode characters corresponding to the specified  
code
points. All other combinations of a character preceded by \ are
unexpanded.

> >   -- modify show_locus to display large character source lines, by  
> > escape-encoding characters that are not ASCII-printable (extending  
> > what was previously done)
> I think we need to update the algorithm. As soon as non ASCII  
> characters are used, the error location is wrong.
>
> Example:
>
> print *, 'Hello World'wrong  ! position is OK
>                     1
> Error: Syntax error in PRINT statement at (1)
>
> print *, 'Hello W\xC3\xB6rld'wrong ! Position is misleading
>                      1
> Error: Syntax error in PRINT statement at (1)
>
> (This is not a regression as the current version behaves exactly  
> the same, however, the use of non-ascii characters will increase  
> and thus it makes sense to implement this, e.g. by returning the  
> number of (ascii) characters printed via print_wide_char and adding  
> this number to the column number.)

Yep, I know about that. I have opened PR 36160 and assigned it to me,  
I'll deal with it.

> > As a consequence of this patch, memory usage to store the source  
> > file roughly quadruples.I've not seen a single case where it gives  
> > a significant memory increase on the total amount used during  
> > compilation higher than 7%
> It would be great if a implementaion could be found which reduces  
> the memory maximally needed for compilation, which is not a  
> maintenance burden.


I have been thinking about it, and have not yet come up with anything  
that would not increase maintainance or CPU usage (or, most often,  
both).

Committed as rev. 134992, thanks for the review!

FX

--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/