Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
This implements new type checking for pointer assignments, especially procedure pointers. The idea is to allow assignments even between different signatures, as long as they are compatible (e.g. Integer and Long are different types, but compatible on 32bit). This was already done for normal pointers, e.g. Integer Ptr and Long Ptr are treated as compatible on 32bit, even though they're different types. I think it'd be useful to have this for procedure pointers (i.e. function result and parameter types) too. For example: declare function f() as integer dim p as function() as long = @f Previously, this triggered a "suspicious pointer assignment" warning, but now it will be allowed (on 32bit), because the signatures are compatible. (on 64bit it will still result in a warning) There are several interesting cases where compatibility is possible despite the signature being different: * Different integer types, but same size (Integer vs Long/LongInt, signed vs. unsigned), see the example above. * Byref + UDT up-casting: type A extends object end type type B extends A end type declare sub f( byref as A ) dim p as sub( byref as B ) = @f This pointer assignment can be allowed, because in a p() call, a B object has to be passed. It will be passed to f() which expects an A. It's ok because a B is an A. (of course, the opposite direction would not be safe) This isn't even entirely new - the old symbIsEqual() already had an inheritance-related check that almost made this work for function results, no matter whether BYVAL or BYREF. In case of BYVAL paramaters/function results it is generally not safe to allow this though (because in this case caller and callee have to agree on the size of the passed object). The code to handle this is currently commented out in the new typeCalcMatch() function, and I'm going to add that fix as a separate commit, because it was a problem before this one already, and isn't really related to the purpose of this commit. * CONSTness: Just like the following is allowed: dim i as integer dim p as const integer ptr = @i we can allow this: declare sub f( byref as const integer ) dim p as sub( byref as integer ) = @f f promises to never modify the given integer, so it doesn't matter whether a pointer to f uses CONST or not. (here, too, the opposite direction would not be safe) In general, this patch removes symbIsEqual() and adds some new functions, affecting the following areas in the compiler: * astPtrCheck() type checks, which determine when "suspicious pointer assignment" or "passing different pointer type" warnings are shown. This is now more permissive, i.e. less warnings are shown than before. * Overload resolution, which has to do very similar checks anyways and now re-uses the new functions, which at the very least makes it more consistent with normal assignment/parameter passing checks. * Virtual method overriding, whose existing method signature comparison function is the base for the new more generic procedure signature compatibility checking function, also re-uses the new functions. Overriding virtuals is basically just assigning function pointers (in the vtable) anyways, and the same rules can be applied. This change is useful for new 64bit-compatible Windows API headers. The Windows API has a lot of callback functions returning a 32bit integer. In fbc's old headers, that was translated as Integer, but in the new 64bit-compatible headers it has to be translated as Long. This caused warnings to appear for existing code which implemented such callbacks using Integer. With this change, the existing code will keep compiling fine on 32bit, and only cause warnings on 64bit. Also, this change implements feature request #289 (Covariant parameters and function results), at least what I had in mind.
- Loading branch information
Showing
70 changed files
with
5,160 additions
and
2,522 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.