pexpr.pas:
* initialize srsym in the classrefdef case; it should not have let to problems, because it's only used if erroroutp1 is false which is only the case if the symbol is assigned, but better save then sorry...
git-svn-id: trunk@31887 -
resourcestring data .rsj files in case the source file is interpreted as
UTF-8. Previously, the individual UTF-8 bytes were each stored in a
separate widechar in the Json file (mantis #28717)
* due to the fact that rstconv didn't use the cwstring unit on Unix, rstconv
until now just concatenated the bytes stored in the widechars of the Json
file on those platforms, i.e., the strings put in the resource file were
byte for byte equal to what was in the source file. On Windows, these bytes
were interpreted as individual widechars, converted to the
DefaultSystemCodePage and then written. This means that for anything but
ISO-8859-1 (where every widechar from #0000 to #0255 maps to #0 to #255),
the output got corrupted.
In order to keep compatibility with the old behaviour whereby rstconv wrote
the resource strings using the same encoding as in the source file (except
if the data got completely corrupted, in which case compatibility is
useless), we now store all resourcestrings twice in the .rsj file: once as
the exact byte sequence from the source file, and once (properly) encoded
in UTF-16.
By default, rstconv will use the byte string and just write that one to the
resource file. Additionally, there is a new -p option that accepts a code
page name (see rstconv -h for the list of supported names), which can be
used to make rstconv use the UTF-16 version and convert that to the desired
code page (as long as the system on which rstconv runs supports that
codepage).
And this also finally resolves mantis #6477.
git-svn-id: trunk@31881 -
* postfixoperators: generate specialize nodes in mode Delphi
* factor: don't call postfixoperators() if returned node is a specialize node
* sub_expr: handle specialize nodes
* sub_expr: extract common code handling specializations in < and as/is into a nested function
git-svn-id: trunk@31859 -
* extend handle_specialize_inline_specialization() with the ability to handle generic functions
* have handle_factor_typenode() and postfixoperators() make use of this extension
git-svn-id: trunk@31856 -
was correct before the ansistrings with codepage support had been
implemented, and by accident kept working afterwards on platforms that
don't use UTF-8 as defaultsystemcodepage, but after r31831 it started
failing. This commit fixes it again, in combination r31847 (by ensuring
that the string data passed to ansistart/endtext is encoded in
defaultsystemcodepage).
git-svn-id: trunk@31848 -
