type conversions (those should always re-interpret the raw bits),
except for variants (because those are sometimes generated internally)
-- done so that -gt code at the node tree level can insert explicit
typecasts to integer types without triggering overloaded explicit
typecast operators such as in tests/test/terecs14
git-svn-id: trunk@21381 -
- prefer UnicodeString, WideString, PWideChar, PAnsiChar, AnsiString, ShortString when passing a string constant if default string is UnicodeString,
- change default string type to UnicodeString for MODE DelphiUnicode
git-svn-id: trunk@21094 -
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 -
- for AnsiChar prefer ShortString, AnsiString, UnicodeString, WideString, ... (LongString?)
- for WideChar prefer UnicodeString, WideString, AnsiString, ShortString, ... (LongString?)
- remove old code from htypechk which made AnsiChar const = AnsiString,ShortString and WideChar const = WideString,UnicodeString - it is no longer needed since defcmp performs the required comparisons
+ test
git-svn-id: trunk@20348 -
* defcmp.pas:
+ Extend compare_def_ext by the possiblity to specify whether strict or
loose comparison of undefined defs should be applied.
* in strict mode undefined defs are incompatible to all other defs
except other undefined defs
* in loose mode undefined defs are equal to anything (this is how
FPC behaved up to now)
+ Enable the strict mode in compare_paras so that overloads with
generic type parameters are possible
* ptype.pas, single_type:
If the generic dummy of the currently parsed generic is encountered in
non-Delphi modes then we need to return the current genericdef. This
condition needs to be checked using the ObjName of the def, because
the link from the type symbol to the current def is not yet
established
+ added test for bug report
git-svn-id: trunk@20345 -
- treat the defs equal when convert from rawbytstring to any ansistring type (delphi compatible)
- set result of ansistring copy() function to the type of first argument for ansistring arguments and to ansistring for pchar and char array arguments (delphi compatible)
+ test
git-svn-id: trunk@20285 -
(= Android 4.0) java headers: java.*, javax.*, org.*, junit.*, android.*).
The RTL can also be used to target earlier versions of the Android
platform, but you manually have to take care of not using APIs that
weren't available yet. Adding separate units for separate platform
versions would only partly solve the problem, because some of the
classes used inside the system unit have also changed across
versions.
Use -Tandroid while compiling to select the Android OS as target
platform.
git-svn-id: branches/jvmbackend@19830 -
- 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 -
* 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 -
+ support parsing of strings with code page specification
+ added encoding and elementsize field to ansi- and unicodestring records
+ some basic rtl support routines for encoding aware strings
+ DefaultSystemCodePage
+ DefaultUnicodeCodePage
+ ppu writing/loading of code page aware strings
git-svn-id: trunk@19080 -
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 -
(so that you can override a method in a child class with one that
returns a descendent of the original return type -- since the JVM
will always select the version with the most specific return type,
that even corresponds perfectly to standard JVM behaviour)
git-svn-id: branches/jvmbackend@18706 -
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 -
in a single statement, to be added later)
o the unicodestrings are internally simply java.lang.String instances
o at the language level, the unicodestrings are assignment-compatible
with java.lang.String
o constant strings can be implicitly converted to java.lang.String
o since java.lang.String is immutable, in particular changing a
single character in a string is extremely inefficient. This could
be solved by letting unicodestring map to java.lang.StringBuilder,
but that would make integration with plain Java code harder
git-svn-id: branches/jvmbackend@18470 -
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 -
o support formal external definitions (like for objcclass)
o allow specifying an "import_dll" for external Java classes, which can
be used to specify the Java package name (like the dll for cppclass)
o take the package name into account when mangling the Java class name
o several messages that were specific to Objective-Pascal classes have
been generalised because they also apply to Java classes, same for
several compiler function names
o disabled some proccall directives for Java, but more needs to happen
(Java methods are always either instance-virtual or class-static)
git-svn-id: branches/jvmbackend@18319 -
as te_exact rather than as te_equal (otherwise you get compilation errors
if only a formal external definition is in scope in the interface, but
the full definition is in scope in the implementation)
git-svn-id: trunk@17201 -
* Dispinterfaces can be assigned/typecasted to Variants and vice-versa.
* At the same time, disabled corbainterface assignment compatibility with Variants. Simply intermixing COM and CORBA interfaces is wrong since it causes reference counting calls on CORBA interfaces.
* Dispinterfaces are returned in parameter, similar to regular interfaces.
* Fixed crash in comobj.pp due to incorrect typecast.
* Fixed incorrect dispinterface declarations in the test itself. Now it compiles and works (if MS Excel is installed).
git-svn-id: trunk@16835 -
- allow operator also if return type match the structure type (before at least one parameter had to match)
- search both operands symbol tables for a suitable assignment operator
- test
based on patch of Blaise Thorn (issue #0018490)
git-svn-id: trunk@16762 -
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 -
those for variants. All defined operators are guaranteed to be valid by
the code that checks them when they are defined (mantis #17846)
git-svn-id: trunk@16449 -
the IInterface implementation to be XPCom-compatible
--- Merging r15997 through r16179 into '.':
U rtl/inc/variants.pp
U rtl/inc/objpash.inc
U rtl/inc/objpas.inc
U rtl/objpas/classes/persist.inc
U rtl/objpas/classes/compon.inc
U rtl/objpas/classes/classesh.inc
A tests/test/tconstref1.pp
A tests/test/tconstref2.pp
A tests/test/tconstref3.pp
U tests/test/tinterface4.pp
A tests/test/tconstref4.pp
U tests/webtbs/tw10897.pp
U tests/webtbs/tw4086.pp
U tests/webtbs/tw15363.pp
U tests/webtbs/tw2177.pp
U tests/webtbs/tw16592.pp
U tests/tbs/tb0546.pp
U compiler/sparc/cpupara.pas
U compiler/i386/cpupara.pas
U compiler/pdecsub.pas
U compiler/symdef.pas
U compiler/powerpc/cpupara.pas
U compiler/avr/cpupara.pas
U compiler/browcol.pas
U compiler/defcmp.pas
U compiler/powerpc64/cpupara.pas
U compiler/ncgrtti.pas
U compiler/x86_64/cpupara.pas
U compiler/opttail.pas
U compiler/htypechk.pas
U compiler/tokens.pas
U compiler/objcutil.pas
U compiler/ncal.pas
U compiler/symtable.pas
U compiler/symsym.pas
U compiler/m68k/cpupara.pas
U compiler/regvars.pas
U compiler/arm/cpupara.pas
U compiler/symconst.pas
U compiler/mips/cpupara.pas
U compiler/paramgr.pas
U compiler/psub.pas
U compiler/pdecvar.pas
U compiler/dbgstabs.pas
U compiler/options.pas
U packages/fcl-fpcunit/src/testutils.pp
git-svn-id: trunk@16180 -
+ support for nested procedural variables:
o activate using {$modeswitch nestedprocvars} (compatible with all
regular syntax modes, enabled by default for MacPas mode)
o activating this mode switch changes the way the frame pointer is
passed to nested routines into the same way that Delphi uses (always
passed via the stack, and if necessary removed from the stack by
the caller) -- Todo: possibly also allow using this parameter
passing convention without enabling nested procvars, maybe even
by default in Delphi mode, see mantis #9432
o both global and nested routines can be passed to/assigned to a
nested procvar (and called via them). Note that converting global
*procvars* to nested procvars is intentionally not supported, so
that this functionality can also be implemented via compile-time
generated trampolines if necessary (e.g. for LLVM or CIL backends
as long as they don't support the aforementioned parameter passing
convention)
o a nested procvar can both be declared using a Mac/ISO Pascal style
"inline" type declaration as a parameter type, or as a stand-alone
type (in the latter case, add "is nested" at the end in analogy to
"of object" for method pointers -- note that using variables of
such a type is dangerous, because if you call them once the enclosing
stack frame no longer exists on the stack, the results are
undefined; this is however allowed for Metaware Pascal compatibility)
git-svn-id: trunk@15694 -
- add own symbol table for enumeration to store enumeration elements
- reimplement enumeration member traverse using symbol table instead of firstenum/nextenum - that members are removed
- implement TEnum.Element access syntax - element is searched in the enumeration symtable in this case instead of global/local symtables
- implement {$SCOPEDENUM ON/OFF} local switch
+ tests
git-svn-id: trunk@15051 -
- add an option to skip varspez during parameters comparison
- skip varspez comparison when searching a property reader candidate if $VARPROPSETTER is ON
git-svn-id: trunk@15020 -
passing any value to that parameter which has the same size as the
parameter (it basically acts as if there is an explicit type conversion
to the parameter type around the value at the caller side). If a procvar
has an univ parameter, all procvars whose corresponding parameter
has the same size as that univ parameter are similarly compatible.
This transparent compatibility can however cause crashes in case of
of the procvars when one of the types is passed on the stack and the
other isn't (because then the called routine will a) load the parameter
from a wrong location and b) pop the wrong amount off of the stack at
then end). Therefore FPC will warn in most cases where this can happen.
(mantis #15777)
git-svn-id: trunk@15010 -
starting with a previous 2.3.1 or compiler built from the objc branch
+ added basic objcprotocol support (only for external protocols
currently)
o use in type declaration: "type xp = objcprotocol ... end;"
o when defining a root class that implements it:
"type yc = objcclass(xp) ... end" (note: no support yet
for something like "objcclass(id,xp)" or so)
o when defining a non-root class that implements a protocol:
"type zc = objcclass(nsobject,xp) ... end"
o includes support for "required" and "optional" sections
o no support yet for the objcprotocol(<protocol>) expression
that enables getting a class instance representing the
protocol (e.g., for use with "conformsToProtocol:")
o message names have to specified in protocol declarations,
but if an objcclass implements a protocol, the message names do
not have to be repeated (but if they are, they have to match;
the same goes when overriding inherited methods)
+ allow specifying the external name of Objective-C classes and
protocols, since classes and protocols can have the same name
(and you cannot use the same Pascal identifier in such caseq)
+ added NSObject protocol, and make the NSObject class use it
+ added missing NSObject class methods that have the same name
as instance methods (added "class" name prefix to avoid clashes)
* fixed several cases where the compiler did not treat Objective-C
classes/protocols the same as Object Pascal classes/interfaces
(a.o., forward declarations, alignment, regvars, several type
conversions, ...)
* allow "override" directive in objcclass declarations, and print
a hint if it's forgotten in an external declaration (because it
doesn't really matter there, and may make automated header
conversion harder than necessary) and an error if will be used in
a non-external declaration (because it is not possible to start
a new vmt entry-tree in Objective-C, you can only override parent
methods)
* reject objcclasses/protocols as parameters to typeof()
* don't try to test VMT validity of objcclasses/protocols
git-svn-id: branches/objc@13375 -
sized integer (succeed for Delphi, fail for objfpc)
* fixed compiler so it only allows typecasting a class/interface to a
differently sized integer in Delphi mode
git-svn-id: trunk@13152 -
mode (mantis #11859)
* cleaned up some superfluous "eq=te_incompatible" checks (probably from
copy/pasting conditions from elsewhere)
git-svn-id: trunk@13050 -
for qwordbool) + test:
o assigning true to such a variable now sets them to $ff/$ffff/$ffffffff
o these types are now all signed
o converting an integer type to a byte/word/long/qwordbool using an
explicit type cast keeps the integer's original value stored in the
bool, instead of forcing it to ord(true)/ord(false)
(mantis #10233 and #10613, implemented for all architectures, testsuite
tested for ppc32, sparc and x86)
* fixed some places where the rtl depended on longbool(true) having the
value 1
* extended several boolean tests (and adapted some to no longer assume
that byte/word/long/qwordbool(true)=1)
+ support for converting to qwordbool in second_int_to_bool for x86, ppc
and sparc
git-svn-id: trunk@9898 -
treats equal open arrays, open strings and arrays of const
(implicitly also open) as exactly matching (since you
cannot declare such types on their own, so they will
never match exactly)
* require that forward declared procedures match the
implementation exactly for both the parameters (with
the above modification) and result type (mantis
#10425 and the related webtbf/tw10425a.pp)
git-svn-id: trunk@9484 -
source value to convert_l3, instead of only those with a destination
type whose size is < source size (like Delphi) + test -> fixes
toperator6 along with a host of wrong tordconst typeconversions in
the compiler sources themselves (although most are harmless)
git-svn-id: trunk@8323 -
properly converted. The conversion is done at runtime to generate
a two pointer memory reference as result location, something
which the code generator can handle very well, which minimizes
the chance of side effects.
git-svn-id: trunk@7978 -
are equal and the range of the from type fits in the to type. I.e.
conversion from -10..10 to shortint is considered equal. This is correct
because in this case, the from type can be used wherever the to type is
used, i.e. the compiler never needs to do conversion at compile or run
time.
git-svn-id: trunk@7814 -
operator for a non-variant type (was already intended that way,
but checks didn't work) (mantis #7070) + tests
* some tab->spaces in defcmp.pas
git-svn-id: trunk@7359 -
* symtables based on TFPHashObjectList and TFPObjectList
* rename torddef.typ to torddef.ordtype
* rename tfloatdef.typ to tfloatdef.floattype
* rename tdef.deftype to tdef.typ
* remove obsolete browser code, browcol is kept so the ide
can still be compiled
git-svn-id: trunk@5192 -
macpas after discussion on macpascal mailing list. The only thing left
is automatic conversion of constant strings of length 4 to 32 bit ints.
* adapted tests to this
* fixed FOUR_CHAR_CODE and FCC functions in MacPas unit for little
endian
+ FourCharArray type in macpas unit wich can be used to typecast
int's "back" to an array[1..4] of char (though the characters
will be in reverse on little endian systems in that case)
git-svn-id: trunk@5154 -
