* When building the typename for a generic use the full typename
including it's surrounding object- or abstractrecorddefs. This allows
that a nested non-generic type of a generic type A can be used as
type arguments for more than one specialization of another generic B
(there were some problems when B e.g. defined a pointer to the type
argument's type)
* Always CRC the constructed specialization name as otherwise it might
reach the limit of 255 characters (not yet including unit name,
method name or method arguments)
Note: Errors like "expected XYZ, but got ABC" will need to be
adjusted to use the prettyname...
* increased PPU version
+ added test for above's point 1
git-svn-id: trunk@20149 -
of a property with nf_no_lvalue flag, and check that such nodes are
never used in direct assignments (fixes mantis #21087 and a couple of
other cases of invalid assignments to properties)
git-svn-id: trunk@20140 -
Hash, paszlib, fcl-process and fpmkunit itself are build using
fpmkunit_bootstrap. The fpmkunit-Makefile.fpc still contains dependencies
on hash,paszlib and fcl-process because the packages depending on fpmkunit
needs those. For fpmkunit itself those dependencies are ignored by directly
setting the unit-search path to the rtl-unit search path.
git-svn-id: trunk@20115 -
o allows converting indices to the proper type if required (such as
variant, mantis #20873)
o do not create temporary defs for this type checking anymore if not
necessary
o makes sure that errors are thrown in case of conversions considered
as invalid by the compiler rather than that wrong code is silently
generated (such as in mantis #20873 before this change)
git-svn-id: trunk@20108 -
* A second attempt to remove unconditional pi_needs_implicit_finally from constructors, should hopefully be correct this time due to the changes described above.
+ Test (a copy of tctr1.pp with additional {$implicitexceptions off} directive)
git-svn-id: trunk@19955 -
in "array_dec" and "procvar_dec" "parse_generic" needs to be true if the currently
parsed declaration (array or procvar) is declared inside a generic, because only then
specializations of other types (it does not matter whether they are inline or in a type
section of the current generic) are parsed correctly (this fixes Mantis #20577 and
Mantis #20955 )
+ add tests for the mentioned bug reports (testing only the array case) (tests\webtbs) and
tests for the procvar case (tests\test)
git-svn-id: trunk@19953 -
whose type is an objc type (objcclass, objcprotocol): they only need
objc-style rtti, which is generated elsewhere (and to prevent bugs
they give an internal error if we try to generate FPC-style rtti for
them) (mantis #20876)
git-svn-id: trunk@19861 -
(= 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 -
classes, interfaces, dynamic arrays, ...) as "array of JLObject",
but instead as an array of the actual pointed-to type. The reason
for the previous behaviour was mainly that the JVM threadvar
implementation internally stores all threadvars that are
such double pointer types into an "array of JLObject". Type casting
this array to e.g. an "array of array of byte" causes an exception
even if it only contains "array of byte" instances (since the outer
array type is different). This is now solved by first taking the
element of the array and then typecasting it to the destination
type (so dynarrbyte(arr[0]) instead of pdynarrbyte(arr)^[0]).
The reason for the new (more accurate) behaviour is because the
old one caused type errors in case a double pointer field was
internally created for the nestedfpstruct support (see added
test)
git-svn-id: branches/jvmbackend@19821 -
Also adjusted test for report 20836 (removed unneeded units and the {$R ...} directive completely and added a "%NORUN" modifier).
git-svn-id: trunk@19817 -
* In win32/sysinitXX units, rename EntryInforation
to SysInitEntryInformation.
include new win/systlsdir.inc file from
win/syswin.inc for win64 target
and from win32/sysinit.inc for win32 target.
Set fields of both SysInitEntryInformation and EntryInformation
by converting them into typed constants.
git-svn-id: trunk@19779 -
------------------------------------------------------------------------
r19731 | svenbarth | 2011-12-03 11:53:02 +0100 (Sa, 03 Dez 2011) | 2 lines
pexpr.pas, post_comp_expr_gendef:
This is not the result you are looking for: The result of "postfixoperators" is only set to true if either "again" was "true" once or the node was changed to an errornode. So using the result for deciding whether we overwrite the def or not is incorrect. So just call "postfixoperators" and process the returned node accordingly.
------------------------------------------------------------------------
r19723 | svenbarth | 2011-12-02 15:28:23 +0100 (Fr, 02 Dez 2011) | 1 line
Added a few more tests. All except tgeneric65.pp (object inside generic record) and tgeneric68.pp (object inside generic object) are successfully compiled.
------------------------------------------------------------------------
r19722 | svenbarth | 2011-12-02 15:12:42 +0100 (Fr, 02 Dez 2011) | 1 line
Fix a remaining artefact from the overloaded symbols approach (just a comment, but nevertheless a change...)
------------------------------------------------------------------------
r19721 | svenbarth | 2011-12-02 15:11:56 +0100 (Fr, 02 Dez 2011) | 3 lines
ptype.pas, read_named_type, expr_type:
* Adjust a comment.
* Add an additional check for the owning symtable of the dummy symbol and the current_structdef just to be on the save side (it's not needed inside specializations)
------------------------------------------------------------------------
r19720 | svenbarth | 2011-12-02 15:11:06 +0100 (Fr, 02 Dez 2011) | 1 line
Fix the test. It's mode Delphi, but does not compile in Delphi, because "TSomeRecord" and "TSomeRecord<T>" are different identifiers.
------------------------------------------------------------------------
r19719 | svenbarth | 2011-12-02 15:10:06 +0100 (Fr, 02 Dez 2011) | 18 lines
Fix introduced regressions.
pgenutil.pas, generate_specialization:
* If we are parsing the result type of a function or operator that belongs to a generic (parse_generic is true) we need to accept also "_LT" and "_GT" as for this the "block_type" is NOT set to one of "bt_type", "bt_var_type", "bt_const_type" and only there "_LSHARPBRACKET" and "_RSHARPBRACKET" are returned by the scanner. This is part of the fix for webtbs\tw18567.pp.
* In non—Delphi modes if we encounter a specialization of the currently parsed class/record (using "specialization"!) the given "tt" will be an errordef (because the def of the generic's symbol was not yet set to "current_structdef"). To solve this we check in this case whether the calculated generic name is equal to that of the "current_structdef" and simply return that as specialized def. This fixes test\tgeneric11.pp.
* When searching for the generic symbol search if the generic belongs to a class or record then we need to search for it in the class or record. This fixes webtbs\tw16090.pp.
ptype.pas
* parse_nested_types: We now return the generic defs for specializations inside generics instead of an undefined def, so we must also parse nested type usages correctly, so that type checks don't fail (undefined defs circumvent them mostly). This fixes webtbs\tw10247.pp.
* single_type: We need to allow _LT as an indication for a Delphi specialization as return types are parsed with block_type not in "bt_type", "bt_var_type", "bt_const_type". This is also a fix a part of the fix for webtbs\tw18567.pp.
* read_named_type, expr_type:
Fixes for test\tgeneric17.pp and test\tgeneric22.pp:
(a) In non-Delphi modes we might encounter usages of the generic dummy symbol inside the generic class belonging to it. This is basically a specialization, but as the reference from the dummy symbol to the "current_structdef" is not yet established (this is done after "read_named_type" in "types_dec" returns) we need to use other ways to check for the valid use of the dummy symbol (basically we check whether the name of the dummy symbol and the name of the current_structdef without the type count match)
(b) For specializations we can check whether the genericdef of the currently parsed structdef (the specialization) is the same as the typedef of the encountered dummy symbol.
pexpr.pas, factor, factor_read_id:
Fixes for test\tgeneric17.pp and test\tgeneric22.pp:
To allow the mentioned fixes in ptype for the same tests to be usable at all we must not return an "identifier not found" error if we encounter such a valid use of a generic dummy symbol.
------------------------------------------------------------------------
r19718 | svenbarth | 2011-12-02 15:08:46 +0100 (Fr, 02 Dez 2011) | 3 lines
generate_specialization:
* Remove some unused variables
* Fix a comment
------------------------------------------------------------------------
r19685 | svenbarth | 2011-11-25 16:25:10 +0100 (Fr, 25 Nov 2011) | 1 line
Incorporate the changes from trunk into "postfixoperators" and "handle_factor_typenode". The latter needed to be extended by a parameter "typeonly" which is "false" in almost all calls except the one inside "factor_read_id" where the "typeonly" parameter of "factor" is used.
------------------------------------------------------------------------
r19676 | svenbarth | 2011-11-24 17:48:47 +0100 (Do, 24 Nov 2011) | 4 lines
Rebase to revision 19673
pexpr.pas: Changes in postfixoperators and the base of handle_factor_typenode not yet incorporated (the code from trunk was simply commented for now)
------------------------------------------------------------------------
r19675 | svenbarth | 2011-11-24 15:42:42 +0100 (Do, 24 Nov 2011) | 11 lines
Somehow the changes regarding tf_methods_specialized weren't commited, thus here they are again:
* symconst.pas: remove tf_methods_specialized
* psub.pas: remove check for/inclusion of tf_methods_specialized as this isn't needed anymore since the generic is specialized in a temporary symtable
pgenutil.pas: remove merge artifacts
pdecl.pas: fix compilation ("s" was duplicate)
pexpr.pas:
* fix calling of generate_specialization
* disable the goto in sub_expr for now; this will be enabled again once right hand sides work as well
------------------------------------------------------------------------
r19674 | svenbarth | 2011-11-24 11:19:57 +0100 (Do, 24 Nov 2011) | 3 lines
Rebase to revision 19078 (directly before the merge of cpstrnew)
The changes regarding pretty names for generics and token buffer endianess were integrated into my changes. Not every call to generate_specialization is fixed though, so compilation will fail.
------------------------------------------------------------------------
r19671 | svenbarth | 2011-11-23 18:25:09 +0100 (Mi, 23 Nov 2011) | 79 lines
Merge branch 'unique-syms'
Conflicts:
compiler/pdecl.pas
compiler/pexpr.pas
compiler/pgenutil.pas
compiler/ptype.pas
The original log messages as git was a bit forgetting here :( (newest at the top):
?commit 7ef252de8023494ee6d39910e289f9e31658d47b
Author: Sven Barth <pascaldragon@minerva>
Date: Mon Nov 21 17:13:36 2011 +0100
Fix the compilation of inline specializations of which the generic is derived from another generic.
pgenutil.pas, generate_specialization:
* Set the "block_type" to "bt_type" when parsing the type parameters, so that the nodes are returned as "ttypenode" instead of e.g. "tloadvmtaddrnode" in case of classes outside of type sections.
* Set the "block_type" to "bt_type" before calling "read_name_type", so that no unexpected sideeffects happen, because types like classes normally only are declared inside type sections (e.g. for the case a generic class is derived from another generic class a classrefdef for the specialized parent class will be created inside the derived specialized class if the block type is not a type one).
commit 1041a8f7a3a41f4fdf2975ce40055c698281ce71
Author: Sven Barth <pascaldragon@minerva>
Date: Fri Nov 18 19:03:50 2011 +0100
Improve inline specializations a bit, so now expressions like "TSomeGeneric<TSomeType>.SomeClassProc OP SomeNonGeneric" is possible. Using another class function of a generic as the right side is not yet working (that still needs some thinking).
To achive this the generalization code must basically continue directly after the "factor" call, so that the operator and the right side are correctly parsed when walking up the call stack. This is done by jumping from the end of the specialization code in the "<"-case to the start of "sub_expr". The freshly generated node (in the above example a callnode) will be passed down the callstack through a new parameter "factornode". If that is set (currently only in the case of a specialization on the left side) "factor" won't be called and the right side will be parsed with the "factornode" as the left side. If it is not set (which is the case for all other calls to "sub_expr" in the unit) then the usual call to "factor" will be done and the result will be used as the left side.
commit a01ccd265f8d6cc5a2f3e88e23afbcd3d5960afb
Author: Sven Barth <pascaldragon@minerva>
Date: Fri Nov 18 18:37:04 2011 +0100
Fix compilation of ppudump.
symconst.pas:
* Remove sto_has_generic, which was the last remainer of my "overloaded type symbols" approach.
* Remove df_methods_specialized, as it isn't needed anymore with the recent "temporary symtable" solution.
psub.pas, specialize_objectdefs, process_abstractrecorddef:
Remove the checks for/inclusion of df_methods_specialized.
utils/ppudump.pp:
Add "sp_generic_dummy" to the symbol options.
commit d16deac060e65d4b53e8fe9c27fe7e1f6d00a416
Author: Sven Barth <pascaldragon@minerva>
Date: Wed Nov 16 16:34:51 2011 +0100
Fix compilation of "gset.pp" from fcl-stl.
nld.pas:
Extend ttypenode by a reference to the type symbol. Normally this is simply the typesym of the given def, but for specializations in type sections of generics this is not the case, because generate_specialization will return a reference to the generic definition and not the new one (thus the symbol will be wrong).
ppu.pas:
Increase PPU version because of the extension of ttypenode.
pexpr.pas:
* handle_factor_typenode: Extend the function by a "sym" parameter which will normally be "nil". In that case it is set to the def's typesym. The "typesym" field of the created type node is then set to this sym.
* For now pass nearly always "nil" for the above mentioned sym except inside factor_read_id when we've encountered a typesym.
ptype.pas, read_named_type, expr_type:
Exchange the "is_owned_by" check with a "sym_is_owned_by" check so that we can correctly detect that we are using a specialized type declaration inside a generic (once nested generic are allowed this condition needs to be checked).
commit 23668d2fc9070afc26b4288ed0db9a8eaf6f40e6
Author: Sven Barth <pascaldragon@minerva>
Date: Wed Nov 16 07:51:12 2011 +0100
psub.pas:
* tcgprocinfo.parse_body: Methods of generic classes need to set "parse_generic" as well, so that variables for "stacked generics" (generic array => generic record) inside the method body are handled correctly.
* specialize_objectdefs: Don't try to generate method bodies for abstract methods.
pdecvar.pas, read_property_dec:
Allow specializations for the return types of properties (should they be allowed for index types as well?).
symtable.pas:
Add a new class "tspecializesymtable" which is basically a globalsymtable but is always assuming to be the current unit. This symtable is used in "generate_specializations" (see below) and is needed to allow visibilty checks for "private", etc. to succeed.
pgenutil.pas, generate_specializations:
Instead of hackily pushing a symtable that may contain conflicting symbols onto the symtable stack for the specialization, a temporary global symtable using the above mentioned "tspecializesymtable" is created and pushed. After the specialization is done all symbols and defs that were added to the temporary symtable are moved to their final symtable (either the global- or localsymtable of the unit, depending on the current position of compilation). This way symbols are correctly added to a top level symtable, but without potential side effects like resolving the wrong symbol.
------------------------------------------------------------------------
r19435 | svenbarth | 2011-10-09 18:16:19 +0200 (So, 09 Okt 2011) | 1 line
Set "current_structdef", "current_genericdef" and "current_specializedef" to values that were valid during the declaration of the generic when specializing it ("current_genericdef" and "current_specializedef" might need to still be corrected though)
------------------------------------------------------------------------
r19434 | svenbarth | 2011-10-09 18:15:26 +0200 (So, 09 Okt 2011) | 2 lines
Arrays and procvars inside a generic declaration are not declared as generic/specialization anymore (this partly reverts a previous commit). This reduces the problematic cases in the check whether a found def was specialized inside the class (the changed check in read_named_type.expr_type).
It's still not an ideal solution as the usage of generic classes/records (without specialization!) that are declared inside the current parsed class/record will compromise this check again.
------------------------------------------------------------------------
r19433 | svenbarth | 2011-10-09 18:14:33 +0200 (So, 09 Okt 2011) | 1 line
Extend the test with a usage of "TTestInteger" and correct the comments a bit.
------------------------------------------------------------------------
r19432 | svenbarth | 2011-10-09 18:13:30 +0200 (So, 09 Okt 2011) | 9 lines
We need to flag specializations of record-/objectdef once we have generated their methods otherwise an interesting situation might occur:
The classes in "fgl.pas" implement an enumerator in the generic class "TFPGListEnumerator" and "specialize" that inside themselves. If we now specialize one of the generic classes (e.g. "TFPGList") the "TFPGListEnumerator" is really specialized as well. That means a def is added to the global symtable (the local one in case of a program or library file). If we now use the enumerator class in the same file (e.g. by using a "for ... in", which has a temporary variable of that type) then the methods of the enumerator are specialized again (the def itself is not). To avoid this (and time consuming searches for existing method specializations) we flag the specialized def as "done" once we're finished.
symconst.pas
* add a new flag "df_methods_specialized" to the "tdefoption" enumeration
psub.pas, process_abstractrecorddef
* check the def for the "df_methods_specialized" flag and continue only if that is not set
* set the "df_methods_specialized" flag before leaving the function
------------------------------------------------------------------------
r19431 | svenbarth | 2011-10-09 18:12:25 +0200 (So, 09 Okt 2011) | 1 line
This check was commited by accident; it was a remain from an experimental solution to the "fix compilation of fgl"-problem.
------------------------------------------------------------------------
r19430 | svenbarth | 2011-10-09 18:11:31 +0200 (So, 09 Okt 2011) | 19 lines
Fix compilation of unit "fgl.pp" and of test "tests/test/tgeneric29.pp".
symtable.pas:
* reduce the "childdef" parameter of "is_owned_by" from "tabstractrecorddef" to "tdef", so that more primitive defs can be checked as well
* add a new function "sym_is_owned_by" which is similar to "is_owned_by", but takes a symbol and a symtable as parameter; the owner chain of the symtable is checked until a non-object- and non-record-symtable is reached
ptype.pas:
* extend "id_type", so that the symbol and the symtable that belongs to the returned def is returned as well
* this is needed to check inside "single_type" whether a def that is a generic was specialized inside another generic, because in that case the genericdef is returned by "generate_specialization" and not a new specialized def, but the corresponding type symbol (which is different from "hdef.typesym") belongs to the class itself; I need to admit that this solution isn't very clean and one could try to circumvent some of the checks, so I need to find a better detection for such a case (concrete example: the enumerator specialization inside the classes of "fgl.pas")
* in "read_named_type.expr_type" the check for "df_generic" is extended analogous to the previous change, but instead of relying on the symbol it uses the def. This is needed so that types like method pointers that are defined inside the current generic are not disallowed as they contain the "df_generic" flag as well; like the previous change this change isn't clean either and maybe it's better to remove the inclusion of the "df_generic" flag from everything except records and "objects" inside records/"objects" again. Such a solution will "only" reduce the problem to records and "objects" though...
pgenutil.pas:
* only add a new undefined def if we're not parsing the parent class or interfaces ("parse_class_parent" is true), otherwise the InternalError regarding the "equal count of defs" will trigger
* there are now two cases where we need to return a generic def instead of a undefined one when we're parsing a generic:
a) we have the previously mentioned case that "parse_class_parent" is true
b) an undefined def was added, but we need to return a generic def, so that checks can be passed
* use the correct variable when building the generic name, otherwise we get errors like "identifier '$1' not found"
* don't push the symtable if we're currently parsing the list of interfaces or the parent class, because then e.g. a generic interface will be included in the symtable of the implementing class which isn't what we want; the current solution is not clean though, so this needs to be investigated more
* Note: In the current state of "generate_specialization" the function could be simplyfied a bit more; this will be done when the implementation is satisfactory enough
------------------------------------------------------------------------
r19429 | svenbarth | 2011-10-09 18:10:28 +0200 (So, 09 Okt 2011) | 20 lines
Allow generics to be overloaded by variables.
* symconst.pas:
add an entry for the generic dummy symbol to the symbol options enumeration
* pgenutil.pas:
- extend "generate_specialization" by the possibility to pass a symbol name instead of a def
- if "symname" is given that is used; otherwise "genericdef" or "tt" is used
* pexpr.pas:
- in case of "<" we are trying to receive a generic dummy symbol from the left node (new function "getgenericsym")
- it's name is then passed to "generate_specialization" which in turn fills genericdef
- adjust call to "generate_specialization"
* pdecl.pas:
- we can now check for "sp_generic_dummy instead of "not sp_generic_para" to check whether we've found the dummy symbol of a previous generic declaration
- if a new dummy symbol is created we need to include "sp_generic_dummy"
- if we've found a non-generic symbol with the same name we need to include the "sp_generic_dummy" flag as well
* symtable.pas
- add a new function "searchsym_with_symoption" that more or less works the same as "searchsym", but only returns successfully if the found symbol contains the given flag
- "searchsym_with_symoption" and "searchsym" are based on the same function "maybe_searchsym_with_symoption" which is the extended implementation of "searchsym" (note: object symtables are not yet searched if a symoption is to be looked for)
- add a function "handle_generic_dummysym" which can be used to hide the undefineddef symbol in a symtable
- correctly handle generic dummy symbols in case of variables in "tstaticsymtable.checkduplicate"
------------------------------------------------------------------------
r19428 | svenbarth | 2011-10-09 18:09:09 +0200 (So, 09 Okt 2011) | 3 lines
types_dec:
- fix a comment
- the created undefineddef must not be freed, as the count of the list the def is contained in, is used to find other defs again
------------------------------------------------------------------------
r19427 | svenbarth | 2011-10-09 18:08:15 +0200 (So, 09 Okt 2011) | 14 lines
Corrected the handling of hint directives.
pgenutils.pas/generate_specialization:
- parse hint directives of the generic if they are recorded
- output hint messages of the generic after the ">" is successfully parsed
pexpr.pas:
- factor: don't display hints of a potential generic type if the next token is a "<"
- sub_expr:
* added two inline methods which
a) checks whether a node is a typenode or a loadvmtaddrnode with a typenode
b) returns the typedef of such a node
* check hint directives for the first parsed type argument of a specialization
* in the case of parsing a non-generic type the hints of the left and right node of the resulting "<" node need to be checked (the right ones only if another "<" is following)
------------------------------------------------------------------------
r19426 | svenbarth | 2011-10-09 18:07:22 +0200 (So, 09 Okt 2011) | 5 lines
generate_specialization needs to return the correct generic def if the parent classes are parsed, so that that the usage of generic interfaces is allowed.
This fixes the compilation of test tests\test\tgeneric29.pp and the reminder in pdecobj.pas is not needed anymore.
Note: Perhaps this behavior should be enabled in general if "parse_generic" is true (and not only if parse_parent_class if true as well).
------------------------------------------------------------------------
r19425 | svenbarth | 2011-10-09 18:06:31 +0200 (So, 09 Okt 2011) | 1 line
Added two reminders for me
------------------------------------------------------------------------
r19424 | svenbarth | 2011-10-09 18:05:31 +0200 (So, 09 Okt 2011) | 32 lines
Switching from overloaded type symbol to unique symbol per generic.
Reasons for the "unique symbol" approach:
- no special search operations for cross unit search needed (which is supported by Delphi) => less performance impact
- no special care needed to really find the correct generic => less increase of parser complexity
Currently all generic tests except tgeneric29.pp compile and inline specializations work as well.
The changes in detail:
* pdecl.pas/types_dec:
- The variables used to hold the final name of the symbol are now prefixed with "gen". In case of non-generics the prefixed ones are equal to the non-prefixed ones (e.g. orgtypename=genorgtypename). In case of a generic symbol the "gen"-variants contain the type parameter count suffix (e.g. '$1' in case of 'TTest<T>') as well.
- The unmodified pattern is used to insert and detect a dummy symbol with that name, so that type declarations and - more important - inline specializations can find that symbol.
- In non-Delphi modes this symbol is also used to detect whether we have a type redefinition which is not allowed currently; its typedef points to the generic def.
- In mode Delphi the def of that dummy symbol (which contains an undefineddef) is modified when a corresponding non-generic type is parsed, so that it contains the def of the real type.
* pdecsub.pas/parse_proc_head
- consume_generic_type_parameter now only parses the type parameters and picks the generic with the correct amount of parameters. The verification of the order and names of the parameters needs to be added again.
- it also does not use "def" anymore, but it sets "srsym"
- in parse_proc_head the symbol (srsym) is only searched if the symbol isn't assigned already; in case of a generic in mode FPC it will find the dummy symbol that points to the generic def
* pexpr.pas
- in factor_read_id there are three cases to handle:
+ the symbol is not assigned => error
+ a possible generic symbol (either an undefined def or the non-generic variant) => no error and no hints
+ a non-generic symbol => hints
Point 1 is handled correctly, point 2 and 3 aren't currently and also they might be needed to be moved somewhere else
- sub_expr:
+ a node can be a tloadvmtaddrnode as well if the non-generic variant of a generic symbol is a class
+ we can only check afterwards whether the specialization was successful
* pgenutil.pas/generate_specialization
using the count of the parsed types the correct symbol can be found easily
------------------------------------------------------------------------
r18005 | svenbarth | 2011-07-16 18:19:33 +0200 (Sa, 16 Jul 2011) | 1 line
Rebase to revision 18000
------------------------------------------------------------------------
r18004 | svenbarth | 2011-07-16 16:13:56 +0200 (Sa, 16 Jul 2011) | 1 line
pexpr.pas, sub_expr: Added support for "as" and "is" operators if the right hand side is an inline specialization (currently detected by the next token being a "<"). This could potentially introduce some problems if the right hand side isn't a specialization but a "<" comparison together with some overloaded operators (I still need to find a case for such a problem)...
------------------------------------------------------------------------
r18003 | svenbarth | 2011-07-16 16:13:11 +0200 (Sa, 16 Jul 2011) | 5 lines
factor_read_id:
don't accept the generic dummy symbol if the next token isn't a "<"
sub_expr:
generate an error if we had a normal "<" comparison containing the dummy symbol on the left side instead of a specialization
------------------------------------------------------------------------
r18002 | svenbarth | 2011-07-16 16:12:25 +0200 (Sa, 16 Jul 2011) | 17 lines
Implement support for nested non-generic types inside generic types. This is mostly for records, classes and objects ("structures") as those didn't work at all, but the others (arrays, procvars) weren't done cleanly either.
pobjdec.pas (object_dec) / ptype.pas (record_dec, array_dec, procvar_dec):
- enable "parse_generic" if a nested type is parsed and we're already inside a generic (this prevents code to be generated for the nested type's methods)
- set the "df_specialization" flag so that the code for generating the methods (and thus resolving the forwards declarations) is called for this symbol
pexpr.pas:
add "post_comp_expr_gendef" which basically calls "handle_factor_typenode" and "postfixoperators" as those aren't exported from the unit themselves
ptype.pas, read_named_type.expr_type:
- use "post_comp_expr_gendef" to parse the use of nested types (e.g. "var t: TTest<T>.TTestSub")
psub.pas, specialize_objectdefs:
implement the generation of the method bodies for nested structures (resolves the forward declarations)
pdecl.pas, types_dec:
when we encounter a nested structure inside a specialization of a structure, we need to find the corresponding generic definition so that the generic can be correctly parsed later on.
------------------------------------------------------------------------
r18001 | svenbarth | 2011-07-16 16:11:31 +0200 (Sa, 16 Jul 2011) | 1 line
Finally fixed the handling of hint directives and added a comment explaining the situation in the context of generics.
------------------------------------------------------------------------
r17999 | svenbarth | 2011-07-16 16:10:34 +0200 (Sa, 16 Jul 2011) | 2 lines
* Reordered the conditions for the inline spezialization as the "isgeneric" boolean is not needed
* As "handle_factor_typenode" is now available the classrefdef wrapper is not needed anymore
------------------------------------------------------------------------
r17998 | svenbarth | 2011-07-16 16:09:38 +0200 (Sa, 16 Jul 2011) | 1 line
Removed the remaining traces of the type overloads and increased PPU version to differ from trunk.
------------------------------------------------------------------------
r17997 | svenbarth | 2011-07-16 16:08:49 +0200 (Sa, 16 Jul 2011) | 1 line
Integrated the changes from trunks's postfixoperators into my own and removed the local version again.
------------------------------------------------------------------------
r17996 | svenbarth | 2011-07-16 16:08:03 +0200 (Sa, 16 Jul 2011) | 5 lines
generate_specialization needs to return the correct generic def if the parent classes are parsed, so that that the usage of generic interfaces is allowed.
This fixes the compilation of test tests\test\tgeneric29.pp and the reminder in pdecobj.pas is not needed anymore.
Note: Perhaps this behavior should be enabled in general if "parse_generic" is true (and not only if parse_parent_class if true as well).
------------------------------------------------------------------------
r17995 | svenbarth | 2011-07-16 16:07:20 +0200 (Sa, 16 Jul 2011) | 1 line
Added two reminders for me
------------------------------------------------------------------------
r17547 | svenbarth | 2011-05-23 22:52:51 +0200 (Mo, 23 Mai 2011) | 1 line
Rebase to revision 17533
------------------------------------------------------------------------
r17542 | svenbarth | 2011-05-23 21:47:09 +0200 (Mo, 23 Mai 2011) | 4 lines
Added some tests for:
- multiple symbols with a similar name
- hint directives
- inline specializations
------------------------------------------------------------------------
r17541 | svenbarth | 2011-05-23 21:19:12 +0200 (Mo, 23 Mai 2011) | 3 lines
Allow typecasts to inline specializations as well.
For this the code which handles this inside factor_read_id had to be moved to local unit scope and is named handle_factor_typenode.
------------------------------------------------------------------------
r17540 | svenbarth | 2011-05-23 21:17:53 +0200 (Mo, 23 Mai 2011) | 1 line
Remove the (now) non-functional check for inline specialization.
------------------------------------------------------------------------
r17539 | svenbarth | 2011-05-23 21:16:39 +0200 (Mo, 23 Mai 2011) | 14 lines
Corrected the handling of hint directives.
pgenutils.pas/generate_specialization:
- parse hint directives of the generic if they are recorded
- output hint messages of the generic after the ">" is successfully parsed
pexpr.pas:
- factor: don't display hints of a potential generic type if the next token is a "<"
- sub_expr:
* added two inline methods which
a) checks whether a node is a typenode or a loadvmtaddrnode with a typenode
b) returns the typedef of such a node
* check hint directives for the first parsed type argument of a specialization
* in the case of parsing a non-generic type the hints of the left and right node of the resulting "<" node need to be checked (the right ones only if another "<" is following)
------------------------------------------------------------------------
r17538 | svenbarth | 2011-05-23 21:15:36 +0200 (Mo, 23 Mai 2011) | 5 lines
generate_specialization needs to return the correct generic def if the parent classes are parsed, so that that the usage of generic interfaces is allowed.
This fixes the compilation of test tests\test\tgeneric29.pp and the reminder in pdecobj.pas is not needed anymore.
Note: Perhaps this behavior should be enabled in general if "parse_generic" is true (and not only if parse_parent_class if true as well).
------------------------------------------------------------------------
r17537 | svenbarth | 2011-05-23 21:14:33 +0200 (Mo, 23 Mai 2011) | 1 line
Added two reminders for me
------------------------------------------------------------------------
r17536 | svenbarth | 2011-05-23 21:13:51 +0200 (Mo, 23 Mai 2011) | 1 line
This test does not need to be run
------------------------------------------------------------------------
r17535 | svenbarth | 2011-05-23 21:12:50 +0200 (Mo, 23 Mai 2011) | 32 lines
Switching from overloaded type symbol to unique symbol per generic.
Reasons for the "unique symbol" approach:
- no special search operations for cross unit search needed (which is supported by Delphi) => less performance impact
- no special care needed to really find the correct generic => less increase of parser complexity
Currently all generic tests except tgeneric29.pp compile and inline specializations work as well.
The changes in detail:
* pdecl.pas/types_dec:
- The variables used to hold the final name of the symbol are now prefixed with "gen". In case of non-generics the prefixed ones are equal to the non-prefixed ones (e.g. orgtypename=genorgtypename). In case of a generic symbol the "gen"-variants contain the type parameter count suffix (e.g. '$1' in case of 'TTest<T>') as well.
- The unmodified pattern is used to insert and detect a dummy symbol with that name, so that type declarations and - more important - inline specializations can find that symbol.
- In non-Delphi modes this symbol is also used to detect whether we have a type redefinition which is not allowed currently; its typedef points to the generic def.
- In mode Delphi the def of that dummy symbol (which contains an undefineddef) is modified when a corresponding non-generic type is parsed, so that it contains the def of the real type.
* pdecsub.pas/parse_proc_head
- consume_generic_type_parameter now only parses the type parameters and picks the generic with the correct amount of parameters. The verification of the order and names of the parameters needs to be added again.
- it also does not use "def" anymore, but it sets "srsym"
- in parse_proc_head the symbol (srsym) is only searched if the symbol isn't assigned already; in case of a generic in mode FPC it will find the dummy symbol that points to the generic def
* pexpr.pas
- in factor_read_id there are three cases to handle:
+ the symbol is not assigned => error
+ a possible generic symbol (either an undefined def or the non-generic variant) => no error and no hints
+ a non-generic symbol => hints
Point 1 is handled correctly, point 2 and 3 aren't currently and also they might be needed to be moved somewhere else
- sub_expr:
+ a node can be a tloadvmtaddrnode as well if the non-generic variant of a generic symbol is a class
+ we can only check afterwards whether the specialization was successful
* pgenutil.pas/generate_specialization
using the count of the parsed types the correct symbol can be found easily
------------------------------------------------------------------------
r17534 | svenbarth | 2011-05-23 21:11:50 +0200 (Mo, 23 Mai 2011) | 1 line
This fixes an access violation when compiling tests\test\tgeneric30.pp
------------------------------------------------------------------------
r17405 | svenbarth | 2011-05-04 12:43:13 +0200 (Mi, 04 Mai 2011) | 11 lines
*pexpr.pas:
- moved "postfixoperators" from local declaration of "factor" to implementation declarations of the unit, so it can be used in "sub_expr"
- for this a parameter "getaddr:boolean" needed to be added, because it used the parameter that was defined by "factor"
=> adjustments inside "factor" for calls to "postfixoperators"
- extended the "_LT" ("<") case of "sub_expr" with handling of inline generic specializations. If a potential generic is detected (Delphi mode, left and right node are type nodes, next token is ">" or ",") it is tried to parse the generic declaration and generate a specialization. If this succeeds, potential postfix operators are parsed and a node <> caddnode is returned.
*pgenutil.pas:
"generate_specialization" was extended so that the first type identifer can already have been parsed (which is the case in inline specializations)
*ptype.pas
adjustments because of the extension of "generate_specialization"
------------------------------------------------------------------------
r17404 | svenbarth | 2011-05-04 12:40:07 +0200 (Mi, 04 Mai 2011) | 1 line
Moved "parse_generic_parameters" and "insert_generic_parameter_types" from "pdecl.pas" to "pgenutil.pas"
------------------------------------------------------------------------
r17403 | svenbarth | 2011-05-04 12:35:23 +0200 (Mi, 04 Mai 2011) | 1 line
Moved "generate_specialization" from "ptype.pas" to "pgenutil.pas"
------------------------------------------------------------------------
r17397 | svenbarth | 2011-05-02 22:22:41 +0200 (Mo, 02 Mai 2011) | 3 lines
Added a file which will hold the various functions related to generic parsing. The header copyright notice and the info comment might not yet be final.
Note: I've added this mostly empty, because I used SVN instead of GIT SVN, as I don't know whether it would handle the properties for this new file correctly.
------------------------------------------------------------------------
r17396 | svenbarth | 2011-05-02 21:47:53 +0200 (Mo, 02 Mai 2011) | 6 lines
consume_generic_type_parameter now parses the available parameters first before deciding which generic def is the correct one (this is stored in the "def" variable of the parent frame). The count of the parameters and the order is checked.
parse_proc_head itself uses the correct def (the def found by consume_generic_type_parameter in mode Delphi and the first generic def of the symbol in the other modes) which is available in the "def" variable.
Status of generics:
Non-Delphi generics now work as before and declarations of Delphi generics work as well. Inline specialisations don't work currently.
------------------------------------------------------------------------
r17395 | svenbarth | 2011-05-02 21:46:41 +0200 (Mo, 02 Mai 2011) | 1 line
Added two TODOs for places that I'll need to adjust for inline specializations.
------------------------------------------------------------------------
r17394 | svenbarth | 2011-05-02 21:45:34 +0200 (Mo, 02 Mai 2011) | 12 lines
* ptype.pas:
"generate_specialization" now parses the generic parameters without verifying them. The verification is done after their count is known and thus the correct generic def can be determined.
Note: It does currently only work with the first found symbol, the extended lookup needs to be implemented yet (including the unit name works though)
* pexpr.pas:
In "factor_read_id" an "identifer not found" error is generated if the undefined non-generic def is used (e.g. as a type for a variable)
Note: This check needs to be adjusted for the case "typeonly=false".
Status of generics:
Specializations can now be parsed, but declarations containing methods are still broken, because the correct def is not yet resolved (not even talking about inline specializations yet ;) )
------------------------------------------------------------------------
r17393 | svenbarth | 2011-05-02 21:44:14 +0200 (Mo, 02 Mai 2011) | 9 lines
*type symbol overloads are only allowed in mode Delphi
*a check for overloads with the same count of arguments is not yet in place
*in non-Delphi modes overloads need to be checked for non-generics as well, e.g. "TTest<T>" is already defined and now a "TTest" is declared
*when a generic is encountered and the symbol does not yet exist, a new symbol with an undefineddef is added and the generic def is added as an overload; if the symbol already exists, the generic is just added
*if a non-generic is parsed and the symbol is already defined (but the typedef is still an undefineddef) then the typedef is updated
*the symtable tree (up to the unit symtable (global or local)) gets the "sto_has_generic" flag which will be used when searching generics with the same name, but different parameter counts in different units
State of generics:
broken, because the generic defs are not yet searched/found
------------------------------------------------------------------------
r17392 | svenbarth | 2011-05-02 21:42:40 +0200 (Mo, 02 Mai 2011) | 1 line
Extend ttypesym by a list that will contain all generic "overloads" of this symbol.
------------------------------------------------------------------------
r17341 | svenbarth | 2011-04-18 23:15:52 +0200 (Mo, 18 Apr 2011) | 1 line
Rebase to revision 17340
------------------------------------------------------------------------
r17316 | svenbarth | 2011-04-14 09:11:07 +0200 (Do, 14 Apr 2011) | 1 line
Created a branch for working on various aspects of generics
------------------------------------------------------------------------
git-svn-id: trunk@19763 -
pexpr.pas: Changes in postfixoperators and the base of handle_factor_typenode not yet incorporated (the code from trunk was simply commented for now)
git-svn-id: branches/svenbarth/generics@19676 -
The changes regarding pretty names for generics and token buffer endianess were integrated into my changes. Not every call to generate_specialization is fixed though, so compilation will fail.
git-svn-id: branches/svenbarth/generics@19674 -
using the type name of the interface/protcol/category (they are not
entities themselves on which you can invoke those methods,
mantis #20661)
git-svn-id: trunk@19651 -
implicit pointer types into the nestedfpstruct, so that the original
parameter is properly changed when updated from inside nested routines
git-svn-id: branches/jvmbackend@19645 -
+ -CTcompactintarrayinit command line option to change the code generation
for typed array of some kind of integer-type initialization so that it
takes up less space in the bytecode (because the bytecode for all
routines, including the class initialization code that contains the
typed constant init code, is limited 64kb, large array or multiple
array constants could fairly easily bump into that limit)
git-svn-id: branches/jvmbackend@19638 -
set the external name of the underlying class type to the internal name
instead of to an (invalid) empty string
git-svn-id: branches/jvmbackend@19555 -
+ test from bug report
- remove $A+ from jedi include header: $A+ makes no sense for api headers, the records should be layouted with $packrecords c, second part to resolve#20525
git-svn-id: trunk@19533 -
- 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 -
implementation (Delphi-compatible in case multiple overloads exist in
the current unit, and in other cases avoids compiler crashes in case
of circular implementation dependencies)
* ignore other symbol options (deprecated, legacy, platform, ...) as far as
the interface crc is concerned to avoid trouble in case they appear in the
implementation but not in the interface (to prevent compiler crashes)
git-svn-id: trunk@19492 -
U compiler\pdecsub.pas
U compiler\symdef.pas
U compiler\pdecobj.pas
U compiler\htypechk.pas
U compiler\ncal.pas
U compiler\symtable.pas
--- Recording mergeinfo for merge of r19281 into '.':
U .
--- Merging r19282 into '.':
A tests\webtbf\tw19975.pp
--- Recording mergeinfo for merge of r19282 into '.':
G .
git-svn-id: trunk@19343 -
This change is required since CodePage to CodePage name conversions are required in other parts of RTL. Moreover those codepage identifiers are windows codepage identifiers and thus must be compatible with codepage identifiers used by delphi.
git-svn-id: trunk@19330 -
* ToLower is functional for all characters including those outside of the BMP
* ToUpper is functional for all characters including those outside of the BMP
* Other methods using "const AString : UnicodeString; AIndex : Integer" are
functional for all characters including those outside of the BMP
git-svn-id: trunk@19286 -
- add TTagHashSet class descendant of THashSet with an ability to has also a LongWord value together with key
- change TAsmData.ConstPools[] to be an indexed property to properly initialize ConstPool class, remove pool initialization from all other units
- add ansistring constants to pool together with their encoding to distinct the same text constants with different codepage
+ test
git-svn-id: trunk@19261 -
* moved console io on embedded systems into a seperate unit, this unit might setup input/output e.g. to be redirected to a serial port
* cleanup of the embedded system unit
git-svn-id: trunk@19168 -
- emit ansistring constants with compiler codepage if no codepage is explicitly set
- set default compiler codepage to default system codepage (delphi compatible)
+ tests
git-svn-id: trunk@19145 -
- a set of rtl changes from AnsiString to RawByteString to various conversion functions
- a test which proves output in cp1251 and cp866 codepages (standard for Russian windows)
git-svn-id: trunk@19093 -
o don't try to create .class files for generic types
o still generate all JVM-specific wrappers for generic types even though they
won't be written out, because when specializing all the defid's have to
match exactly
o add synthetic routine implementations after generating the specializations,
so that the synthetic routines for those specializations are also generated
(we don't specialize generic versions of the synthetic generic routines
because it's not easy or even always possible to create valid generic
versions of synthetic routines)
o Note: these are Pascal-style generics, not Java-style generics. The generic
types nor their specializations are usable from Java code (specializations
may become usable in the future)
git-svn-id: branches/jvmbackend@19047 -
* Allow properties of type interface to implement not just the same interface, but also any of its ancestors.
* Allow a single property to implement multiple interfaces.
git-svn-id: trunk@18983 -
the JVM target, and pos/insert/delete/val/str/uniquestring/setstring/
stringofchar/... are now also available for ansistrings on the JVM
target
git-svn-id: branches/jvmbackend@18906 -
val/str for enums for now) for the JVM target: insert/delete/pos/...
* use generic unicodestring helper routines where possible for the JVM
target (not that many as for shortstrings since unicodestring is
handled using java.lang.String)
+ complete widestring manager implementation for the JVM target. It uses
a class with virtual methods rather than a record with function pointers
for speed reasons though (since no existing widestring manager will be
compatible anyway, that shouldn't cause any problems)
git-svn-id: branches/jvmbackend@18882 -
* converts the embedded information into controller specific records (arm and avr)
* new cpu-specific units for several Stellaris (Fury and Tempest class) targets,
+ STM32F103RB
- old Stellaris unit has been removed
git-svn-id: trunk@18848 -
jsstringh.inc -> use generic inc/sstrings.inc
* added a bunch of extra {$ifdef FPC_HAS_XXX} protections around
routines in inc/sstrings.inc and implemented those routines for
the JVM target in java/jsstrings.inc
* use the majority of the generic routine in sstrings.inc now also
for the JVM target! Only a few changes were needed:
o in a few places, calls to move() for copying shortstring->shortstring
or shortstring->chararray were replaced with calls to a new inline
helper that calls move() in the version in inc/sstrings.inc, and
JLSystem.arraycopt() in in the version in java/jsstrings.inc
o changed the currency argument to str() for the JVM target to constref
so its address can be taken (has to be typecasted to int64 without
changing the value), and similarly changed the temporary result
inside that routine to an array of 1 elements so the address can be
taken
o don't typecast the real value to a record type in str_real for the
JVM target, but work via an int64 instead to extract sign/mantissa/exp
o everything else compiled and worked as is!!
-> val, str, hexstr/octstr/binstr, delete, pos, insert, setstring and
comparetext now all work for shortstrings on the JVM target
git-svn-id: branches/jvmbackend@18836 -
resultdef for internally generated method calls
* force the resulttype of methods used to build non-unicode string
constants on the JVM platform to the stringconstn's resultdef
git-svn-id: branches/jvmbackend@18832 -
resource compilation happens and that the standard FPC resource
helpers are not available. What happens is that all files specified
in {$r xxx} statements are packed together into an <appname>.jar
file, under the namespace "org.freepascal.rawresources". They
can be loaded using the java.lang.Class.getResource/getResourceAsStream()
api
git-svn-id: branches/jvmbackend@18776 -
in the system unit for easier debugging)
* disabled a bunch more feature flags by default for the JVM target
* incorporate modified version of inc/systemh.inc (split into two parts:
jsystemh_types.inc and jsystemh.inc, because some of the types are
required for the declaration of the shortstring/ansistring/set/...
classes, which in turn are required for the routine declarations) and
inc/system.inc (as jsystem.inc)
o moved some routines around from old to new locations based on where
they appear in the common files
o added a number of defines that allow skipping more common implementations
in case a platform-specific one is already available
* all base classes (AnsistringClass etc) are now descendants of
JLObject rather than TObject, because their declaration is now parsed
before TObject is known (and there's no need for them to inherit from
TObject)
* incorporate modified version of inc/system.inc
* use the common version of generic.inc, currh.inc, gencurr.inc and
genmath.inc (with small modification to those files)
+ addition of quite a bit of system unit functionality (halt, runerror,
random, round, str() for integer types, abs, odd, endian swapping helpers,
bit scanning, trigonometric functions, ln, exp, ...)
o round()/trunc() for comp-types has been renamed trunc_comp() on the
JVM target because their JVM signature conflicts with trunc(currency)
o the unsigned versions of swapendian() and other endian helpers are not
available on the JVM target because of JVM signature conflicts
git-svn-id: branches/jvmbackend@18746 -
+ include mathh.inc in the system unit, implement most routines based
on java.lang.Math, and use (an unmodified!) genmath for the rest
- removed now obsolete jmathh.inc (was partial copy of mathh.inc)
- removed commented out overrides for several math routines in
njvminl (doesn't make sense to handle them inline in the compiler)
git-svn-id: branches/jvmbackend@18742 -
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 -
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 -
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 -
o since the JVM target has no stack/framepointer that can be passed
on to nested routines, all local variables and parameters accessed
from nested routines are grouped into a local record whose address
is passed to nested routines. The same technique is also required
for LLVM in the future
git-svn-id: branches/jvmbackend@18588 -
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 -
it can either generate an asmlist containing data definitions (like
it does now), or a node tree with explicit initialisation statements
(for the JVM target)
git-svn-id: branches/jvmbackend@18471 -
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 -
implemented via classes, all descending from system.FpcBaseRecordType
(records are also considered to be "related" to system.FpcBaseRecordType
on the JVM target)
* several routines are auto-generated for all record-classes: apart
from a default constructor (if there is none), also clone (which
returns a new instance containing a deep copy of the current
instance) and deepCopy (which copies all fields of one instance
into another one)
o added new field "synthetickind" to tprocdef that indicates what
kind of synthetically generated method it is (if any), and
mark such methods also as "synthetic" in the JVM assembler code
o split off the JVM-specific parser code (e.g., to add default
constructors) into pjvm.pas
git-svn-id: branches/jvmbackend@18450 -
artificially generated stuff rather than directly working with defs/syms
problems
o scanner state saving/restoring, and avoiding problems in case of
errors in the injected strings
o in case of the actual application (adding overriding constructors):
the parameters may be of types not visible in the current unit to
newly written code -> can't just use the scanner...
git-svn-id: branches/jvmbackend@18427 -
svn r17068,17071,17081,17136
* changed all init_paras code in both thlcgobj and ncgutil to use
location_get_data_ref() instead of direct a_load_loc_reg()/
ref.base:=reg so it also works with the JVM target
* changed all init_paras code so it works with targets that do
not pass an implicit high parameter for open array (and a similar
fix in ncgcal)
+ added support for initializing array (both regular and open)
"out" parameters of reference counted types on the JVM target
(the arrays will be initialised with nil rather than an empty
array for implementation reasons, see comments in compproc.inc)
* factored out calling of functions in the system unit directly
from hlcgobj
git-svn-id: branches/jvmbackend@18421 -
unit for at least java.lang.*, java.util.* java.io.* and java.security.*,
using the following command line paramters:
-a sun. -a com.sun. -a javax. -protected java.lang. java.util. java.io. java.security. -o java_base
git-svn-id: branches/jvmbackend@18405 -
o support for copying value parameters at the callee side if they were
passed by reference in hlcg
o JVM g_concatcopy() implementation for arrays
o moved code to get length of an array from njvminl to hlcgcpu so it can
be reused elsewhere as well
o export array copy helpers from system unit for use when assigning one
array to another
o some generic support for types that are normally not implicit pointers,
but which are for the JVM target (such as normal arrays)
* handle assigning nil to a dynamic array by generating a setlength(x,0)
node instead of by hardcoding a call to fpc_dynarray_clear, so
target-specific code can handle it if required
* hook up gethltemp() for JVM ttgjvm so array temps are properly
allocated
git-svn-id: branches/jvmbackend@18388 -
o always create exceptvarsym entry for on-nodes (on all targets) to remove
some special cases when an unnamed exception was caught
o the JVM tryfinally node generates the finally code twice: once for the
case where no exception occurs, and once when it does occur. The reason
is that the JVM's static bytecode verification otherwise cannot prove
that we will only reraise the caught exception when we caught one in
the first place (the old "jsr" opcode to de-duplicate finally code
is no longer used in JDK 1.6 because it suffered from the same problem,
see Sun Java bug
http://webcache.googleusercontent.com/search?q=cache:ZJFtvxuyhfMJ:bugs.sun.com/bugdatabase/view_bug.do%3Fbug_id%3D6491544 )
git-svn-id: branches/jvmbackend@18387 -
o since the JVM does not support call-by-reference, setlength() works
by taking an argument pointing to the old array and one to the new
array (the latter is always created in advance on the caller side,
even if not strictly required, because we cannot easily create it
on the callee side in an efficient way). Then we copy parts of the
old array to the new array as necessary
o to represent creating a new dynamic array, the JVM target uses
an in_new_x tinlinenode
+ tasnode support for the JVM. Special: it can also be used to convert
java.lang.Object to dynamic arrays, and dynamic arrays of java.lang.Object
to dynamic arrays with more dimensions (arrays are special JVM objects,
and such support is required for the setlength support)
+ check whether explicit type conversions are valid, and if so, add the
necessary conversion code since we cannot simply reinterpret bit patterns
in most cases in the JVM:
o in case of class and/or dynamic array types, convert to an as-node
o in case of int-to-float or float-to-int, use java.lang.Float/Double
helpers (+ added the definitions of these helpers to the system unit)
git-svn-id: branches/jvmbackend@18378 -
do nothing for finalization, assign nil pointer for dynamic arrays
and refcounted strings (not required for JVM per se, but required
because programmer's may use them without initialising them first
and then they should be empty rather than invalid)
git-svn-id: branches/jvmbackend@18368 -
nutils.pas into virtual class methods of a new tnodeutils class defined
in ngenutil (global factory: cnodeutils), so they can be overridden by
architecture-specific implementations (required by the JVM backend)
git-svn-id: branches/jvmbackend@18364 -
o self is encoded as "this" for javac compatibility
+ ait_jvar (for the above) and ait_jcatch (similar, for future try/catch
support) classes
+ support for smallset JVM type encoding (as int)
git-svn-id: branches/jvmbackend@18354 -
u64bit division/mod, and no overflow checking for divisions
(none yet for add nodes either, but that has to be implemented
in hlcgcpu rather than in the add-nodes themselves)
git-svn-id: branches/jvmbackend@18331 -
support), passed through to original ncgutils version in thlcg2ll
+ thlcgobj.location_force_mem() implementation
* order parameters for jvm similar to those for i386 without fixed_stack,
so we don't need temporary paralocations
* converted most of ncgcal to thlcg
* disabled special handling for virtual methods for jvm in ncgcal, as all
invocations are name-based there
+ njvmcal with special jvm callnode support:
o always move the function result into a memory temp
o when freeing an unused function result, use a_pop(2) and adjust
the internal evaluation stack height counter
o after the call instruction, adjust the evaluation stack height counter
by subtracting the number of the pushed parameter slots, adjusted for
the slots taken up by the function result
git-svn-id: branches/jvmbackend@18325 -
as well as insert_regalloc_info_all()
+ "register" allocator for the jvm target, which simply replaces every
virtual register with a temp. This is done for all register types in
one pass, so that the temps can be easily reused without worrying
about conflicts. Small optimisation: alloc/store/dealloc/load
sequences for a single reg are removed (many of these are generated
because most cg nodes return their value in a register which is then
immediately consumed by the parent)
* map addressregisters to integer registers with size R_SUBD, because
they require one stackslot (the subregister type is used by rgcpu
to determine the size of the temp it has to allocate)
git-svn-id: branches/jvmbackend@18316 -
+ basic target information for jvm target (assembling/linking
helpers are still dummies for now)
+ basic jasmin assembler writer
+ cpunode and cputarg units to include the target units in the
compiler
git-svn-id: branches/jvmbackend@18309 -
+ added arrayreftype field to treference for the jvm, because
array loads have to be performed using special instructions,
so this information has to be passed on to the code generator.
This information will have to be added in t(cg)vecnode.
* moved concatenating the generated code for a procedure to the
al_procedures list to thlcg.record_generated_code_for_procdef(),
which is overridden by jvm/hlcgcpu to attach that code to the
procdef it belongs with. The reason is that a Java class file
can only contain code for one class, so we have to write out
the assembler grouped per class instead of in the order the
routines appear in the source code
* also committed forgotten changes in psub after moving the
register allocator initialisation to hlcgobj
git-svn-id: branches/jvmbackend@18308 -
on the evaluation stack, while on the callee side they are placed
in local variables 1..n
o the jvm only supports call-by-value. call-by-reference parameters
will have to be emulated at a higher level
o similarly, ret_in_param() always returns false
o all function results are returned on the evaluation stack (both
on the caller and callee side)
git-svn-id: branches/jvmbackend@18306 -
(single, double, string, widestring), basic constructors,
spilling_get_operation_type() implementation
o special: O_MOV_SOURCE/O_MOV_DEST don't make sense for this target,
since it's stack based
git-svn-id: branches/jvmbackend@18294 -
o special things:
* no tasmcond (conditions are currently encoded in opcode names,
may be changed later)
* no actual registers, just a couple of fake ones to indicate
the locals stack and the operands/evaluation stack
* no registers for the return value; they're returned on the
evaluation stack; may be handled like the x87 in the future
git-svn-id: branches/jvmbackend@18291 -
whether the mangled name is for defining a symbol, or for referencing
it later (e.g. for a call or load of its address). The reason is that
on the JVM both cases are different.
+ jvmdef unit to encode types according to the JVM rules
+ tprocdef.jvmmangledname() to encode a procdef's JVM mangled name
(the common part of defining/referencing it; tprocdef.mangledname
afterwards adorns it as required)
git-svn-id: branches/jvmbackend@18288 -
* made ttgobj.create virtual, added a "tgobjclass: class of ttgobj = ttgobj"
variable and use that one to instantiate new temp allocators
* created ttgjvm descendant that only allows allocations of 4 or 8 bytes
(rounding allocations < 4 bytes up to 4 bytes), and that divides the
offsets/sizes by 4 so we get stack slot numbers
git-svn-id: branches/jvmbackend@18282 -
interface as cgobj, except that all type parameters are defs instead
of tcgsize. Also includes some procedures from ncgutil (over time,
all of ncgutil will probably integrated here so it can be easily
overridden)
+ hlcg2ll: pass-through implementation of thlcg that forwards everything
either to cgobj or ncgutil, for use by the classic code generator
clients (all current platforms)
+ added "def" field to tcgpara to record the tdef of the parameter
(used by the high level code generator)
git-svn-id: branches/jvmbackend@18279 -
