and if the result does not depend on the types of the arguments (to
prevent "qwordconst>int64const" being turned into
"int64(qwordconst)>int64const" and thereby potentially change the outcome)
(mantis #19622)
git-svn-id: trunk@21395 -
try_make_mul32to64()
* when inserting a 32x32->64 multiplication, change the typeconversions
of the original nodes into internal type conversions, because they
may have been currency (e.g., in case of an integer-to-currency
conversion, which is performed via integer*currency(10000)) and
since r21097 implicit conversions from currency to ordinal are no
longer allowed
git-svn-id: trunk@21112 -
new ShortString->(Some)String precedence: ShortString, UTF8String, AnsiString, AnsiString(CodePage) and RawByteString, UnicodeString, WideString and other string types
new AnsiString->(Some)String precedence: RawByteString, UTF8String, AnsiString, AnsiString(CodePage), UnicodeString, WideString, ShortString and other string types
The new logic makes UTF8String more preferrable than other AnsiString types, AnsiString more preferrable than other AnsiStrings(codepage) and also makes UnicodeString more preferrable than WideString.
git-svn-id: trunk@21057 -
* created separate version of fpc_AnsiStr_Concat_multi() after all
because it contains a punicodechar(unicodestring) typecast, which
can't be supported on the JVM target (and splitting it out in the
generic code seems like a bit overkill), and restored original
generic version of fpc_AnsiStr_Concat_multi() (slightly faster
than version partially adapted for jvm)
git-svn-id: branches/jvmbackend@20903 -
o support for the new codepage-aware ansistrings in the jvm branch
o empty ansistrings are now always represented by a nil pointer rather than
by an empty string, because an empty string also has a code page which
can confuse code (although this will make ansistrings harder to use
in Java code)
o more string helpers code shared between the general and jvm rtl
o support for indexbyte/word in the jvm rtl (warning: first parameter
is an open array rather than an untyped parameter there, so
indexchar(pcharvar^,10,0) will be equivalent to
indexchar[pcharvar^],10,0) there, which is different from what is
intended; changing it to an untyped parameter wouldn't help though)
o default() support is not yet complete
o calling fpcres is currently broken due to limitations in
sysutils.executeprocess() regarding handling unix quoting and
the compiler using the same command lines for scripts and directly
calling external programs
o compiling the Java compiler currently requires adding ALLOW_WARNINGS=1
to the make command line
git-svn-id: branches/jvmbackend@20887 -
if expr1 has sideeffects. This can't be done safely even in case of
short boolean evaluation, because expr1 may return the inverse the
second time its called (and "0 or 1" is not the same as "0", and
neither is "1 and 0"), based on comment by Michael Karcher
* perform a full string compare when comparing stringconstnodes
before the string constant labels have been generated (patch by
Michael Karcher, mantis #21255)
git-svn-id: trunk@20485 -
- don't pass CP_NONE encoding to internal functions. They handled it as 0 encoding. This will optimize the generated code a bit.
- convert all king of string/char/pchar constants to local ansistring def if they needs to be passed to rawbytestring type. They should not get a CP_NONE codepage (delphi compatible)
- don't convert left and right arguments of string concatenation to ansistring type if they are already ansistrings but with different codepage - RTL already handles different codepages in concat routine
- fix resultdef for ansistring concatenations inside assignments - return def of left assignment operand if it is already ansistring - this reduces amount of unneeded condepage conversions since concat functions can return result in any desired codepage
rtl: remove CP_NONE comparisions from most of RTL functions, replace 0 constant with CP_ACP
tests: add test to check various conversions to RawByteString type
git-svn-id: trunk@19519 -
- add helper function getansistringcodepage which returns explicitly set codepage or 0 in other case
- add helper function getansistringdef which return a def with explicitly set codepage or cansistringtype in other case
- change tstoreddef.createnai constructor to allow set codepage in constructor
- don't convert string constants to rawbytestring. if string constant already has a codepage - preserve it or convert to ansistring codepage (delphi compatible)
- don't perform string conversion from ansistring to strings with explicitly set codepage (by directive or by compiler switch) and vice versa (delphi compatible)
+ test which covers most of the cases
git-svn-id: trunk@19510 -
defcmp: Address code paged' string type comparison taking care of the code page
ncnv: Remove un-needed code page comparison to CP_UTF8, some fixes regarding shortstrings and wide char/string
ncon: For the case of tstringconstnode.changestringtype (ncon.pas) where the code page are of CP_NONE or 0 no translation is done as :
* CP_NONE is compatible to all
* For 0 the raw bytes are just copied.
My changes:
- change ascii2unicode to allow pass source codepage,
- convert in both cases when source or destination is UTF8
git-svn-id: trunk@19457 -
*In normal procedure "var" and "out" RawByteString parameters does not accept other string types. Procedures with
"compilerproc" directive or the newly added "rtlproc" directive accept that. Please note that it is up to the
procedure coder to ensure the correctness of the code page in that case. The new directive is needed to handle
the RTL procedures/functions that are not marked as "compilerproc" such as "UniqueString", "Insert" and "Delete".
*Correct "fpc_ansistr_concat" to handle code page correctly.
*Default "ansitring" type is now created with code page set to "0" instead of "65535". Before that change it was
impossible to distinguish a "RawByteString" with the default "ansistring". At runtime "ansistring" variable'code
page is set to DefaultSystemCodePage
*UniqueString flavor of "SetLength" has been updated to release memory when shrinked to at least 50%, like ansitring
does.
git-svn-id: trunk@19118 -
targets:
o initialize managed temps that are passed as var-parameters to the
dests-parameter of the concat routines, because they will be read and
stored in the var-parameter array (they are finalized and hence work
fine on native targets, but finalization is a nop on the JVM target)
o do not take the shortcut of comparing with nil when checking for an
empty ansi/unicodestring on managed VM targets
git-svn-id: branches/jvmbackend@18909 -
unicodestring = java.lang.String. The reason this was the default in
the past is that this was the first string type that was implemented,
and without it being the default most code involving string operations
would fail. Now the default strings types are the same as for other
targets
+ new {$modeswitch unicodestrings} directive, that when activated
*together* with {$h+},
1) changes char into an alias for widechar
2) changes string into an alias for unicodestring
3) changes the preferred string evaluation type (in case of uncertainty)
to unicodestring
{$modeswitch unicodestrings} with {$h-} does not change anything at all
regarding the string type (it still changes the char type)
+ new uuchar unit that redefines char as widechar, and which is automatically
included by the compiler if {$modeswitch unicodestrings} is enabled
git-svn-id: branches/jvmbackend@18781 -
o sets of enums are handled as JUEnumSet instances, others as JUBitSet
derivatives (both smallsets and varsets, to make interoperability with
Java easier)
o special handling of set constants: these have to be constructed at run
time. In case of constants in the code, create an internal constsym to
represent them. These and regular constsyms are then aliased by an
another internal staticvarsym that is used to initialise them in the
unit initialisation code.
o until they are constructed at run time, set constants are encoded as
constant Java strings (with the characters containing the set bits)
o hlcgobj conversion of tcginnode.pass_generate_code() for the genjumps
part (that's the only part of the generic code that's used by the JVM
target)
o as far as explicit typecasting support is concerned, currently the
following ones are supported (both from/to setdefs): ordinal types,
enums, any other set types (whose size is the same on native targets)
o enum setdefs also emit signatures
o overloading routines for different ordinal set types, or for different
enum set types, is not supported on the JVM target
git-svn-id: branches/jvmbackend@18662 -
only JVM constructs that are already implemented, but also ones that
will be supported in the future but that aren't implemented yet (to
make it easier to already adapt code to the future changes)
git-svn-id: branches/jvmbackend@18498 -
is unicodestring (does *not* change the type of "char" to "unicodechar"
(yet)). Not yet (un)selectable via a directive.
+ systems_default_unicodestring set containing systems on which the
default string type is unicodestring
git-svn-id: branches/jvmbackend@18415 -
is real before transforming a multiply into an sqr operation (fixes make
cycle after r18252, don't know where or even how it caused a wrong
optimization)
git-svn-id: trunk@18257 -
- allow pointermath for pchar, pwidechar, array[] of char and array[] of widechar without pointermath directive,
- don't check tpointerdef().has_pointer_math if this is not a tpointerdef
This fixes testsuite regression (tbs/tb0439.pp)
git-svn-id: trunk@16679 -
is_implicit_pointer_object_type() to better indicate the purpose of
that routine, and to avoid having to change its name every time
a new object type with this property is added
git-svn-id: trunk@16664 -
from the unit initialisation sections to the variable declaration sections
to prevent the base units from overriding derived classes (based on patch
by Hans-Peter Dietrich, mantis #17516)
git-svn-id: trunk@16118 -
