symsym.pas:
- remove "tgenericconstraintdata" and any using/loading/writing of it in "ttypesym"
- remove "tgenericconstraintflag"
symdef.pas:
+ add "tgenericconstraintdata"
+ load and write "genconstraintdata" in "tstoreddef"
symconst.pas:
+ add "tgenericconstraintflag" so it can be used in "ppudump" as well
defcmp.pas, compare_defs_ext:
* as we allow global operator overloads we can't really determine whether two defs are compatible, because a valid operator for the specialization types might just happen to be in scope of the generic; so for now constraints are only strictly checked when declaring a specialization
pgenutil.pas:
* adjust "parse_generic_parameters" and "check_generic_constraints" to the new location of the constraint data
ppudump.pp:
* corrrectly parse defs which contain generic constraints
git-svn-id: trunk@24628 -
symdef.pas, tstoreddef:
+ comment that the list is allocated on demand (and thus should be checked for Nil)
+ fillgenericparas: create the list when adding at least one generic parameter symbol
- create & ppuload: don't create list instance anymore
+ is_generic & is_specialization: check whether the list is assigned
defcmp.pas, compare_defs_ext:
+ check whether "genericparas" list is assigned
pgenutil.pas:
+ check_generic_constraints: check whether "genericparas" is assigned
+ insert_generic_parameter_types: create list before adding generic parameters
git-svn-id: trunk@24627 -
using less than 8 bits per element the same as regular char arrays as far
as automatic type conversions are concerned (they have to be explicitly
packed/unpacked) (mantis #24013)
git-svn-id: trunk@23739 -
defcmp.pas, compare_defs_ext:
use "equal_defs" instead of a reference comparison to check whether the type defs are equal
pgenutil.pas, insert_generic_parameter_types:
* add to each (specialized) generic parameter the "sp_generic_para" flag so that it will be added to the "genericparas" list upon ppu loading
* add the generic parameter to the genericparas list as well, so that the comparison in "compare_defs_ext" is triggered at all... (up to now the list was always empty -.-)
ppu.pas:
* increase PPU version
git-svn-id: trunk@23149 -
* defcmp.pas, compare_defs_ext:
use the new genericparas list to check whether two specializations of the same generic can be considered equal
+ added test
git-svn-id: trunk@22454 -
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 -
