U compiler/blockutl.pas
U compiler/jvm/njvmutil.pas
U compiler/jvm/pjvm.pas
U compiler/ncal.pas
U compiler/ninl.pas
U compiler/pdecl.pas
U compiler/pdecsub.pas
U compiler/pdecvar.pas
U compiler/pexpr.pas
U compiler/pgenutil.pas
U compiler/pmodules.pas
U compiler/pparautl.pas
U compiler/pstatmnt.pas
U compiler/psub.pas
U compiler/psystem.pas
U compiler/ptype.pas
U compiler/symcreat.pas
U compiler/symdef.pas
U compiler/symsym.pas
U compiler/symutil.pas
--- Recording mergeinfo for merge of r42998 into '.':
U .
--- Merging r43116 into '.':
G compiler/symsym.pas
A tests/webtbf/tw36114.pp
--- Recording mergeinfo for merge of r43116 into '.':
G .
# revisions: 42998,43116
git-svn-id: branches/fixes_3_2@43442 -
line number information of the method declaration if it's in the current
unit, and otherwise the first line of the current unit (mantis #14399)
git-svn-id: trunk@37961 -
abstract method wrappers using default(resulttype), because "resulttype"
may not be visible in the current unit. Fixes win32 build after r34127
git-svn-id: trunk@34137 -
methods. Implementing a fully functional g_external_wrapper() for llvm is
quite hard, and the regular wrapper method that calls FPC_ABSTRACTERROR can
in principle be optimized to a plain jump by tail call optimisation on other
targets (to the extent that this matters, because most of them will be
smartlinked away, and the ones that are executed will trigger an exception)
o this means that the synthetic method generation needs to be run for all
objectdefs on all platforms now, rather than only for Java classes
git-svn-id: trunk@34127 -
those will never call a nested routine using Pascal-level support
for accessing local variables (even if the nestedvars stayed empty,
this caused a stack frame to be allocated because a temp of 0
bytes is rounded up to 4 bytes)
git-svn-id: trunk@32739 -
Supporting such a prefix of course means that all section handling code ("var", "type", etc.) needs to respect the case of a "generic" token followed by "function", "procedure" or "class" and thus abort doing its own business.
Maybe I'll find the time somewhen in the future to rework the parser (plus scanner?) a bit so that code like this gets more easy to add and more importantly less ugly.
pdecsub.pas:
* extend parse_proc_dec() and parse_record_method_dec() so that they can be told that they are supposed to handle the to be parsed function/procedure/method header as a generic
pdecvar.pas:
+ new entry for tvar_dec_option named "vd_check_generic" to tell read_var_decls() and read_record_fields() to look out for "generic"
* extend read_var_decls() and read_record_fields() to check for "generic" if needed and to clean up correctly if it is encountered
pdecl.pas:
* the section handling procedures types_dec(), resourcestring_dec(), var_dec(), threadvar_dec() and consts_dec() all return whether they had encountered a "generic" token that was followed by one of $
pdecobj.pas:
* extend method_dec() to take a parameter that says whether the method is supposed to be a generic one
* parse_object_members: while read_record_fields() can handle "generic" we also need to handle the case of "generic" if no fields are allowed anymore
psub.pas:
* extend read_proc() by the possibility to tell it that the procedure/function to be parsed is supposed to be generic
* adjust read_declarations() and read_interface_declarations() to keep track of parsed "generic" tokens and to pass them on accordingly
ptype.pas:
* parse_record_members: same remark as for pdecobj.parse_object_members
git-svn-id: trunk@32380 -
the defs and syms (recursively) referred by inline routines and by the WPO
info
o defs and syms are no longer added immediately to the module's deflist/
symlist, even if they are created as "registered". Instead,
"doregister=true" simply means "add it to the symbol table at the
top of the symtable stack"
o normally only when a sym/def is deref'ed, it gets added to the module
symlist/deflist and defid/symid gets a (unique) value
o in cases where we use(d) the defid to construct unique names within the
current module, you now have to call call the tdef.new unique_id_str()
method. If the def was not yet registered, we will reserve room for it
in the deflist (to get a unique id), but the defid gets set to a
negative value computed from its position in the deflist. Should it
have to be written to the ppu file later on, the defid will be
modified to the actual position in the deflist. For both values,
new unique_id_str() will return the same result so that references
to this def before and after actual registrations are the same (needed
for the JVM backend, but also a good principle in general)
Overall: don't directly use symid/defid anymore to get unique identifiers,
but use tdef.new unique_id_str() instead (if necessary, a similar routine
for tsym can be added)
The result is the ppu file size gets reduced significantly after its big
increase as a result of the high level typed constant builder (which creates
a lot of defs). The result is even more efficient than before, as other
unneeded defs/syms from the localsymtables don't get saved/restored anymore
either.
git-svn-id: trunk@32153 -
* for now all typesyms are created as registered
Note: an additional parameter instead of an overload is used for ttypesym.create as otherwise both constructors would need to be overridden in potential descendant CPU-specific classes...
git-svn-id: trunk@31591 -
interface of a unit, or forward declared, and then the implementation turns
out to be external. We now properly generate a wrapper routine at the
Pascal level for the original declaration that calls through to the
external routine
git-svn-id: trunk@31285 -
(abstract)recordsymtables, so that these settings don't depend on the
current user settings when internally creating record definitions
git-svn-id: branches/hlcgllvm@30343 -
procvar in the local state of the block, and then call it insde the
generated invoke routine. We can't call it directly there, because
due to visibility reasons it may not be accessible from a regular
procedure (e.g. if it is a strict private method)
git-svn-id: branches/blocks@28234 -
o blocks are implemented as a variation of procedure variables
o declaration of a block variable: "test: procedure(c: char) is block;"
(C equivalent: (void)(^test)(char c) )
o the compiler automatically converts procedures/functions whose address
is passed to a block parameter or assigned to a block variable into
a "block". This consists of
1) generating a block descriptor (containing the size of the "block
literal" (see below) and the signature of the invocation function
encoded as an Objective-C selector)
2) generating a wrapper function around the original funcion (with C
calling convention), that has an extra first hidden parameter
(marked as vo_is_parentfp in the compiler) whose type is a pointer
to the describing "block literal"
3) generating the "block literal", which contains a pointer to an
external variable indicating whether this block captures context or
not, some flags (see compiler/blockutl.get_block_literal_flags for
info), a pointer to the wrapper function and a pointer to the
descriptor. In the future, it will also contain captured variables.
o right now, only global procedures/functions can be converted to blocks
(because they don't require state capturing). The next steps are (Object
Pascal) methods (not Objective-C methods, because Objective-C method
procvars don't exist) and finally nested functions
o on Mac OS X, the functionality will only work on Mac OS X 10.7 and later,
because we have to use the so-called "ABI.2010.3.16" to ensure that
our blocks aren't called as variadic functions by the runtime (which
came out after the Mac OS X 10.6 release)
o while the currently implemented functionality does not require any
library support at all, there's no use enabling it on other platforms
because unless it has been confirmed to work with a blocks runtime,
there's no point in using blocks (they're just somewhat bulky procvars
right now). Enabling it on other platforms (in combination with the
GNUStep Objective-C run time), should simply be a matter of adding
the right {$linklib xxx} statement to rtl/inc/blockrtl.pp file, adding
that file to Makefile.fpc for that platform and adding that platform
to the compiler/systems.systems_blocks_supported set
git-svn-id: branches/blocks@28232 -
symsym.pas, tfieldvarsym:
+ add new field fieldvarsym which holds a reference to a tfieldvarsym if the static sym was created based on such a symbol
+ add necessary methods and code to correctly load from and store to PPU
+ add new constructor create_from_fieldvar
symcreat.pas, make_field_static:
* use new create_from_fieldvar constructor instead of the default one
hlcgobj.pas, finalize_static_data:
* check whether the static var is based on a generic's class var
ppu.pas:
* increase PPU version
+ added test
git-svn-id: trunk@27466 -
o made all (non-abstract) tdef and tsym constructors virtual
o added c*def/c*sym classref types for every (non-abstract) t*def/t*sym
class
o added cpusym unit for every architecture that derives a tcpu*def/tcpu*sym
class from the base classes, and initialises the c*def/c*sym classes with
them. This is done so that the llvm target will be able to derive from
the tcpu*def/sym classes without umpteen ifdefs, and it also means that
the WPO can devirtualise everything because the c* variables are only
initialised with one class type
o replaced all t*def/t*sym constructor calls with c*def/c*sym constructor
calls
git-svn-id: trunk@27361 -
JVM target, since Java bytecode itself has no support for properties and
hence exposing properties to external Java code can only be done through
getters/setters. Use the new parameters to do so:
-CTautogetterprefix=XXX
-CTautosetterprefix=YYY
The getter/setter will get the same visibility as the property. If a
getter/setter with the same naming convention was already specified for a
property and this getter/setter is declared in the same class as the
property, then the visibility of this existing getter/setter is
modified and no new routine is generated.
Newly generated getters/setters are virtual methods, because that is
the only way in Java bytecode to allow redefining these getters/setters
in child classes. However, that also means that using these switches can
change the behvaviour of code, since normally the used property definition
is only determined by the declared type of its associated class instance,
and not by the actual instance type. The compiler will therefore warn when
such an automatically generated getter/setter is overridden by another
automatically generated getter/setter in a child class.
git-svn-id: trunk@22959 -
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 -
class before its VMT has been built, because that's the process that looks
for inherited abstract methods that are overridden -> instead use a new
synthetic method kind (tsk_callthrough_nonabstract) that will call
through to another method (in this case a constructor) if the owning
class does not contain any abstract methods, and generates an
empty routine otherwise
git-svn-id: branches/jvmbackend@20589 -
(= 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 -
are used to implement procvar types, and add a constructor to the procvar
types that accept an instance implementing this interface -> much easier
and more natural to use procvar types from Java code
git-svn-id: branches/jvmbackend@19216 -
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 -
constructors, inherited virtual class methods) when deciding which
overloaded version of a routine to call. Otherwise they can change
which variant is called compared to code on platforms where such
implicit methods are not added
git-svn-id: branches/jvmbackend@18752 -
type is a forward-defined class whose full definition hasn't been parsed
yet and if the full definition changes the external name of the class
git-svn-id: branches/jvmbackend@18727 -
on the JVM target (at the Pascal level), by automatically generating
getters/setters of the same visibility as the property that are used
instead of directly accessing the fields when translating the property
git-svn-id: branches/jvmbackend@18724 -
(make_field_static() ) and replaced semi-duplicates of that
code with calls to this routine
* made the handling of static fields for the JVM target more
similar to that on the other targets, so that class properties
now also work there (-> updated JVM-specific code in several
places to deal with this new handling)
git-svn-id: branches/jvmbackend@18723 -
deep copy, and for those records no longer call the inherited clone.
Instead, declare a local variable of the record type, assign its
address to the function and then copy all field contents to this local
variable. Since it's dynamically allocated at the JVM level, it will
survive the function exit.
The problem with calling the inherited clone function is that it will
copy the pointers of the implicit pointer fields (records, sets, …)
from the old to the new instance, and that we (currently) have no way
at the Pascal level to change those and make them point to new
instances.
git-svn-id: branches/jvmbackend@18721 -
actual recordtype into FpcBaseRecordType so we can also use
the deep copy routine in the RTL
+ added abstract fpcDeepCopy() declaration to FpcBaseRecordType class
git-svn-id: branches/jvmbackend@18718 -
