public inbox for kawa@sourceware.org
 help / color / mirror / Atom feed
* Expected Field Type Signature
@ 2022-10-28 16:23 Panicz Maciej Godek
  2023-01-13  9:27 ` Panicz Maciej Godek
  0 siblings, 1 reply; 2+ messages in thread
From: Panicz Maciej Godek @ 2022-10-28 16:23 UTC (permalink / raw)
  To: kawa

[-- Attachment #1: Type: text/plain, Size: 3797 bytes --]

I ran into a weird problem.
When I build a simple Android project, everything works fine.
But when I add my modules to this project, tgings complicate,
First, because the android activity needs to be compiled with the -P and -T
options in order to run properly, I compile the modules and the activity in
two separate passes: the modules are being compiled without the -P and -T
options (otherwise the interdependent modules can't see each other, ans
compilation results in an error)

But the second stage doesn't always pass - I've found that there are three
modules which -- if I include them in the build, cause the second stage to
terminate with the following error:

Exception in thread "main"
java.lang.reflect.GenericSignatureFormatError: Signature Parse error:
Expected Field Type Signature
	Remaining input: Z>;
	at java.base/sun.reflect.generics.parser.SignatureParser.error(SignatureParser.java:124)
	at java.base/sun.reflect.generics.parser.SignatureParser.parseFieldTypeSignature(SignatureParser.java:291)
	at java.base/sun.reflect.generics.parser.SignatureParser.parseFieldTypeSignature(SignatureParser.java:277)
	at java.base/sun.reflect.generics.parser.SignatureParser.parseTypeArgument(SignatureParser.java:420)
	at java.base/sun.reflect.generics.parser.SignatureParser.parseTypeArguments(SignatureParser.java:380)
	at java.base/sun.reflect.generics.parser.SignatureParser.parsePackageNameAndSimpleClassTypeSignature(SignatureParser.java:335)
	at java.base/sun.reflect.generics.parser.SignatureParser.parseClassTypeSignature(SignatureParser.java:304)
	at java.base/sun.reflect.generics.parser.SignatureParser.parseFieldTypeSignature(SignatureParser.java:283)
	at java.base/sun.reflect.generics.parser.SignatureParser.parseFieldTypeSignature(SignatureParser.java:277)
	at java.base/sun.reflect.generics.parser.SignatureParser.parseTypeSignature(SignatureParser.java:469)
	at java.base/sun.reflect.generics.parser.SignatureParser.parseTypeSig(SignatureParser.java:188)
	at java.base/sun.reflect.generics.repository.FieldRepository.parse(FieldRepository.java:53)
	at java.base/sun.reflect.generics.repository.FieldRepository.parse(FieldRepository.java:42)
	at java.base/sun.reflect.generics.repository.AbstractRepository.<init>(AbstractRepository.java:74)
	at java.base/sun.reflect.generics.repository.FieldRepository.<init>(FieldRepository.java:49)
	at java.base/sun.reflect.generics.repository.FieldRepository.make(FieldRepository.java:66)
	at java.base/java.lang.reflect.Field.getGenericInfo(Field.java:109)
	at java.base/java.lang.reflect.Field.getGenericType(Field.java:276)
	at gnu.bytecode.Field.getType(Field.java:75)
	at gnu.expr.ModuleInfo.setupModuleExp(ModuleInfo.java:197)
	at kawa.standard.require.importDefinitions(require.java:313)
	at kawa.standard.ImportFromLibrary.handleImport(ImportFromLibrary.java:487)
	at kawa.standard.ImportFromLibrary.scanImportSet1(ImportFromLibrary.java:296)
	at kawa.standard.ImportFromLibrary.scanImportSet(ImportFromLibrary.java:264)
	at kawa.standard.ImportFromLibrary.scanForm(ImportFromLibrary.java:97)
	at kawa.lang.Translator.scanForm(Translator.java:1615)
	at kawa.lang.Translator.scanBody(Translator.java:1672)
	at kawa.standard.begin.scanForm(begin.java:23)
	at kawa.lang.Translator.scanForm(Translator.java:1615)
	at gnu.kawa.lispexpr.LispLanguage.parse(LispLanguage.java:117)
	at gnu.expr.Language.parse(Language.java:765)
	at gnu.expr.Language.parse(Language.java:759)
	at gnu.expr.Language.parse(Language.java:753)
	at kawa.repl.compileFiles(repl.java:768)
	at kawa.repl.processArgs(repl.java:451)
	at kawa.repl.main(repl.java:830)


When I use those modules for building or running the desktop client or
the terminal client (the build happens in a single pass), there is no
problem.

How do I even go about debugging this?

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Expected Field Type Signature
  2022-10-28 16:23 Expected Field Type Signature Panicz Maciej Godek
@ 2023-01-13  9:27 ` Panicz Maciej Godek
  0 siblings, 0 replies; 2+ messages in thread
From: Panicz Maciej Godek @ 2023-01-13  9:27 UTC (permalink / raw)
  To: kawa

[-- Attachment #1: Type: text/plain, Size: 5100 bytes --]

Recently I managed to learn a bit more about this problem.
It appears when I define a parameter whose content type is a primitive type
(like boolean or char), as in, say:

(define p :: parameter[boolean] (make-parameter #f))

If I change the type to something else (like Object or any type defined by
define-simple-class), the problem disappears.
The problem is critical with the above compilation scheme (i.e. when a
module that depends on modules that contain the definition is compiled
separately). If all the modules are compiled all at once, Kawa somehow
manages to circumvent this problem (it doesn't crash) -- but even then,
during the dexing phase, the d8 tool complains:

Invalid signature 'Lgnu/mapping/LocationProc<Z>;' for field p.
Signature is ignored and will not be present in the output.
Parser error: Expected L, [ or T at position 28
Lgnu/mapping/LocationProc<Z>;
                           ^

So it seems to me that something might be wrong with code generation for
parameters with primitive types.



pt., 28 paź 2022 o 18:23 Panicz Maciej Godek <godek.maciek@gmail.com>
napisał(a):

> I ran into a weird problem.
> When I build a simple Android project, everything works fine.
> But when I add my modules to this project, tgings complicate,
> First, because the android activity needs to be compiled with the -P and
> -T options in order to run properly, I compile the modules and the activity
> in two separate passes: the modules are being compiled without the -P and
> -T options (otherwise the interdependent modules can't see each other, ans
> compilation results in an error)
>
> But the second stage doesn't always pass - I've found that there are three
> modules which -- if I include them in the build, cause the second stage to
> terminate with the following error:
>
> Exception in thread "main" java.lang.reflect.GenericSignatureFormatError: Signature Parse error: Expected Field Type Signature
> 	Remaining input: Z>;
> 	at java.base/sun.reflect.generics.parser.SignatureParser.error(SignatureParser.java:124)
> 	at java.base/sun.reflect.generics.parser.SignatureParser.parseFieldTypeSignature(SignatureParser.java:291)
> 	at java.base/sun.reflect.generics.parser.SignatureParser.parseFieldTypeSignature(SignatureParser.java:277)
> 	at java.base/sun.reflect.generics.parser.SignatureParser.parseTypeArgument(SignatureParser.java:420)
> 	at java.base/sun.reflect.generics.parser.SignatureParser.parseTypeArguments(SignatureParser.java:380)
> 	at java.base/sun.reflect.generics.parser.SignatureParser.parsePackageNameAndSimpleClassTypeSignature(SignatureParser.java:335)
> 	at java.base/sun.reflect.generics.parser.SignatureParser.parseClassTypeSignature(SignatureParser.java:304)
> 	at java.base/sun.reflect.generics.parser.SignatureParser.parseFieldTypeSignature(SignatureParser.java:283)
> 	at java.base/sun.reflect.generics.parser.SignatureParser.parseFieldTypeSignature(SignatureParser.java:277)
> 	at java.base/sun.reflect.generics.parser.SignatureParser.parseTypeSignature(SignatureParser.java:469)
> 	at java.base/sun.reflect.generics.parser.SignatureParser.parseTypeSig(SignatureParser.java:188)
> 	at java.base/sun.reflect.generics.repository.FieldRepository.parse(FieldRepository.java:53)
> 	at java.base/sun.reflect.generics.repository.FieldRepository.parse(FieldRepository.java:42)
> 	at java.base/sun.reflect.generics.repository.AbstractRepository.<init>(AbstractRepository.java:74)
> 	at java.base/sun.reflect.generics.repository.FieldRepository.<init>(FieldRepository.java:49)
> 	at java.base/sun.reflect.generics.repository.FieldRepository.make(FieldRepository.java:66)
> 	at java.base/java.lang.reflect.Field.getGenericInfo(Field.java:109)
> 	at java.base/java.lang.reflect.Field.getGenericType(Field.java:276)
> 	at gnu.bytecode.Field.getType(Field.java:75)
> 	at gnu.expr.ModuleInfo.setupModuleExp(ModuleInfo.java:197)
> 	at kawa.standard.require.importDefinitions(require.java:313)
> 	at kawa.standard.ImportFromLibrary.handleImport(ImportFromLibrary.java:487)
> 	at kawa.standard.ImportFromLibrary.scanImportSet1(ImportFromLibrary.java:296)
> 	at kawa.standard.ImportFromLibrary.scanImportSet(ImportFromLibrary.java:264)
> 	at kawa.standard.ImportFromLibrary.scanForm(ImportFromLibrary.java:97)
> 	at kawa.lang.Translator.scanForm(Translator.java:1615)
> 	at kawa.lang.Translator.scanBody(Translator.java:1672)
> 	at kawa.standard.begin.scanForm(begin.java:23)
> 	at kawa.lang.Translator.scanForm(Translator.java:1615)
> 	at gnu.kawa.lispexpr.LispLanguage.parse(LispLanguage.java:117)
> 	at gnu.expr.Language.parse(Language.java:765)
> 	at gnu.expr.Language.parse(Language.java:759)
> 	at gnu.expr.Language.parse(Language.java:753)
> 	at kawa.repl.compileFiles(repl.java:768)
> 	at kawa.repl.processArgs(repl.java:451)
> 	at kawa.repl.main(repl.java:830)
>
>
> When I use those modules for building or running the desktop client or the terminal client (the build happens in a single pass), there is no problem.
>
> How do I even go about debugging this?
>
>

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2023-01-13  9:27 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-10-28 16:23 Expected Field Type Signature Panicz Maciej Godek
2023-01-13  9:27 ` Panicz Maciej Godek

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).