public inbox for kawa@sourceware.org
 help / color / mirror / Atom feed
From: Panicz Maciej Godek <godek.maciek@gmail.com>
To: kawa@sourceware.org
Subject: Re: Expected Field Type Signature
Date: Fri, 13 Jan 2023 10:27:20 +0100	[thread overview]
Message-ID: <CAMFYt2ZTE3GtPUFqVN9aXOpXOs4LCr3XcFq2fN0LyTMBULKV1g@mail.gmail.com> (raw)
In-Reply-To: <CAMFYt2Zw=p2VA4OHj_WwGjjNtnCnfrQKCXz8c=U=8yU+_8P1Gg@mail.gmail.com>

[-- 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?
>
>

      reply	other threads:[~2023-01-13  9:27 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-28 16:23 Panicz Maciej Godek
2023-01-13  9:27 ` Panicz Maciej Godek [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAMFYt2ZTE3GtPUFqVN9aXOpXOs4LCr3XcFq2fN0LyTMBULKV1g@mail.gmail.com \
    --to=godek.maciek@gmail.com \
    --cc=kawa@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).