There is no reason that "the module of a group that has the same name than the group and that is implicitly designated in importations when only the group's name is given" is not a concept of the model with a simple name name and a fully specified semantic.
A step toward #721 and maybe a help for #693
Pull-Request: #753
Reviewed-by: Alexandre Terrasa <alexandre@moz-code.org>
import platform
import abstract_compiler
-import common_ffi
-intrude import common_ffi::extra_java_files
+import ffi
+intrude import ffi::extra_java_files
import android_annotations
redef class ToolContext
module compiler_ffi
intrude import abstract_compiler
-intrude import common_ffi
+intrude import ffi
import nitni
redef class MModule
return table_send(mmethod, arguments, mmethod.const_color)
end
- # Handel common special cases before doing the effective method invocation
+ # Handle common special cases before doing the effective method invocation
# This methods handle the `==` and `!=` methods and the case of the null receiver.
# Note: a { is open in the generated C, that enclose and protect the effective method invocation.
# Client must not forget to close the } after them.
#
# The value returned is the result of the common special cases.
- # If not null, client must compine it with the result of their own effective method invocation.
+ # If not null, client must compile it with the result of their own effective method invocation.
#
# If `before_send` can shortcut the whole message sending, a dummy `if(0){`
# is generated to cancel the effective method invocation that will follow
var indirection_sig = mproperty.build_csignature(mclass_type, mmodule, "___cpp_impl_mid", long_signature, internal_call_context)
## In C file (__ffi.c)
-
+
# Declare the indirection function in C
ecc.body_decl.add("{indirection_sig};\n")
# FFI concers common between the compilers and the interpreter.
# Offers services to compile modules using foreign code. Mainly allows
# to wrap foreign code in Nit methods.
-module common_ffi
+module ffi
import modelbuilder
# does the super module has inherited dependancies?
var hd = m.header_dependencies
- if not hd.is_empty then
+ if not hd.is_empty then
header_dependencies.add_all(hd)
end
# Returns the list of C functions to link with extern Java methods, as required
# to enable this callback from Java code.
- #
+ #
# Return used by `MModule::ensure_linking_callback_methods`
#
# TODO we return an Array to support cast and other features like that
private fun jni_type: String do return "jint"
# JNI short type name (for signatures)
- #
+ #
# Is used by `MMethod::build_jni_format` to pass a Java method signature
# to the JNI function `GetStaticMetodId`.
private fun jni_format: String do return "I"
redef class MMethod
# Returns the JNI signature format of this Nit method
- #
+ #
# Example: a Nity signature `(Bool, Int, Float, JavaString)` is represented by
# the JNI format `(ZIDLjava/lang/string;)V"
private fun build_jni_format(recv_mtype: MClassType, from_mmodule: MModule): String
# The type associated the a formal parameter generic type of a class
#
# Each parameter type is associated to a specific class.
-# It's mean that all refinements of a same class "share" the parameter type,
-# but that a generic subclass has its on parameter types.
+# It means that all refinements of a same class "share" the parameter type,
+# but that a generic subclass has its own parameter types.
#
# However, in the sense of the meta-model, a parameter type of a class is
# a valid type in a subclass. The "in the sense of the meta-model" is