since they require function calls and it's not possible to call functions
inside constant blocks (and because current_procinfo is not necessarily
valid when a constant block is parsed, this moreover crashes the compiler)
git-svn-id: trunk@22018 -
simplified via typeconvnode (corrects resultdef of "qword(1) shl 33",
mantis #22133)
* simplify shl/shr nodes after their resultdef has been set, so the
resultdef used during simplify is set (fixes same expression as above
when it is calculated by an inline function)
git-svn-id: trunk@21394 -
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 -
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 -
- warn if compiler finds implicit or explicit string type conversion from a form of ansi string to a form of unicode string and vice versa
- mark explicit warnings as OFF by default
- warn if compiler finds an assignment of an unicode char const to ansi string or char type (warn for assignment of unicode string const to be implemented)
- revert a piece of code from r19457 regards shortstring handling because shortstring handling should not differ from ansistring in this paticular case
git-svn-id: trunk@19574 -
- 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 -
* Patch from Inoussa:
* defcmp.pas
** ansistring to/from RawByteString are evaluated "te_equal"
** ansistring to UTF8string is evaluated (te_convert_l1,tc_string_2_string)
* ncnv.pas
** "ttypeconvnode.typecheck_char_to_string" : WideChar to AnsiString/ShortString
is possible if the source code page is not utf8
** "ttypeconvnode.typecheck_char_to_char" : WideChar to AnsiChar
is possible if the source code page is not utf8
* ncon.pas
** "tstringconstnode.changestringtype" : Unicode to utf8string bug fix(set the encoding),
constants in the source code with code page set utf8 should be converted back to utf8
* nopt.pas
** "genmultistringadd" : fpc_<stringname>_concat_multi have a new parameter "cp"
to indicate the "DestS" code page if the variable content is nil. This is required
in order not to loose the declared code page.
* pinline.pas
** "inline_setlength" : a new parameter "cp" to indicate the code page if the variable content
is nil. This is required in order not to loose the declared code page.
* ptconst.pas
** "parse_arraydef" : for string const to array of ansichar/widechar conversion check for wide string and
convert if it is required. For char const to array of ansichar/widechar conversion check for wide char and
convert if it is required.
git-svn-id: trunk@19113 -
consistency with other helpers
+ added lowercase(unicodechar) and lowercase(unicodestring) overloads (for some
reason only upcase() existed for them)
git-svn-id: branches/jvmbackend@18881 -
platforms after r18561 (newly introduced element-to-open-array type
conversion retains the value location on those platforms)
git-svn-id: branches/jvmbackend@18793 -
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 -
cpu64bitaddr is not defined rather than if cpu64bitalu is not
defined, because whether or not operations should be 64 bit by
default depends on cpu64bitaddr, and even if a cpu can perform
64 bit alu operations, 32 bit ones are likely faster
git-svn-id: branches/jvmbackend@18748 -
o every porocedural variable type is represented by a class with one
public "invoke" method whose signature matches the signature of the
procvar
o internally, dispatching happens via java.lang.reflect.Method.invoke().
WARNING: while this allows calling private/protected or other methods
that are normally not accessible from another context, a security
manger can override this. If such a security manager is installed,
most procvars will cause security exceptions
o such dispatching also requires that all arguments are wrapped, but
that's done in the compiler-generated body of the invoke method,
so that procvars can also be called conveniently from Java code
o typecasting between a procedure of object and tmethod is supported,
as well as Delphi-style replacing of only the method pointer via
@procvar1=@procvar2.
o nested procvars are not yet supported, but most of the basic
infrastructure for them is already present
* all units/programs now get an internal __FPC_JVM_Module_Class_Alias$
type when compiled for the JVM target, which is an "external" class
that maps to the unit name. This is required to look up the
JLRMethod instances for regular functions/procedures
+ new tabstractprocdef.copyas() method that allows to create a procvar
from a procdef and vice versa
git-svn-id: branches/jvmbackend@18690 -
JDK class-style enums rather than plain ordinals like in Pascal
o for Pascal code, nothing changes, except that for the JVM target
you can always typecast any enum into a class instance (to interface
with the JDK)
o to Java programs, FPC enums look exactly like Java enum types
git-svn-id: branches/jvmbackend@18620 -
(non-dynamic arrays, records, shortstrings)
- removed the ability to typecast such types directly into related class
types, you have to use the @-operator first now to get a pointer to
the type
o updated the RTL and internal compiler code to properly use this
new convention
o allowed removing several special cases from
tjvmtypeconvnode.target_specific_general_typeconv(), and that
method can probably be removed completely over time
* no longer give compile time errors for pointer-related typecasts that
will fail at run time, because the checking was too complex and could
be worked around via actual pointer typecasts anyway
* removed some unnecessary checkcast operations (for shortstring/
shortstringclass)
git-svn-id: branches/jvmbackend@18574 -
o support for ansistring constants. It's done via a detour because the
JVM only supports UTF-16 string constants (no array of byte or anything
like that): store every ansicharacter in the lower 8 bits of an
UTF-16 constant string, and at run time copy the characters to an
ansistring. The alternative is to generate code that stores every
character separately to an array.
o the base ansistring support is implemented in a class called
AnsistringClass, and an ansistring is simply an instance of this
class under the hood
o the compiler currently does generate nil pointers as empty
ansistrings unlike for unicodestrings, where we always
explicitly generate an empty string. The reason is that
unicodestrings are the same as JLString and hence common
for Java interoperation, while ansistrings are unlikely to
be used in interaction with external Java code
* fixed indentation
git-svn-id: branches/jvmbackend@18562 -
so it can be intercepted by the JVM backend (it has to create an actual
array)
+ JVM support for the elem_2_open_array hook
git-svn-id: branches/jvmbackend@18561 -
var/out parameter (these conversions are replaced by another
construct on non-JVM targets, so didn't cause a problem there)
git-svn-id: branches/jvmbackend@18555 -
cannot insert typecasting checks on the assignment side, only on the
values that are being assigned
o since valid_for_assignment() is called in tassignmentnode.typecheckpass()
after typecheckpassing left and right, moved the conversion of the
typecheck nodes into JVM-specific constructs from typecheckpass to
pass_1, so that they can use the information whether they are on
the assignment side or not
* forbid casting a child type to a parent type on the assignment side on
managed platforms, because that circumvents the type checking
git-svn-id: branches/jvmbackend@18515 -
