From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from MTA-10-4.privateemail.com (mta-10-4.privateemail.com [198.54.122.62]) by sourceware.org (Postfix) with ESMTPS id EE1A63858001 for ; Tue, 7 Sep 2021 19:46:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EE1A63858001 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=eatonphil.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=eatonphil.com Received: from mta-10.privateemail.com (localhost [127.0.0.1]) by mta-10.privateemail.com (Postfix) with ESMTP id E1B7818000BE for ; Tue, 7 Sep 2021 15:46:12 -0400 (EDT) Received: from mail-vs1-f52.google.com (unknown [10.20.151.230]) by mta-10.privateemail.com (Postfix) with ESMTPA id C688E18000BD for ; Tue, 7 Sep 2021 15:46:12 -0400 (EDT) Received: by mail-vs1-f52.google.com with SMTP id i23so383525vsj.4 for ; Tue, 07 Sep 2021 12:46:12 -0700 (PDT) X-Gm-Message-State: AOAM531D2thC40s50CNbdHKBMucKgiQfeKC9sveKCgpH7Oathic1wI6/ Hk112Itf1TGRbpxO0mXWnYXOMd1gnTK6/VNmAN0= X-Google-Smtp-Source: ABdhPJxPGUZ8OdXYXE7yUs0cpZDdkvZfHqgAb3VgIEbRjckxf0U1kO41g02gr2+WbFaqrwSbI3UFyaoqem9ED2xpbuw= X-Received: by 2002:a05:6102:7a4:: with SMTP id x4mr10728580vsg.10.1631043967695; Tue, 07 Sep 2021 12:46:07 -0700 (PDT) MIME-Version: 1.0 References: <7042c6a7-b4a4-e2a8-f67a-cd420ef1f90c@bothner.com> In-Reply-To: <7042c6a7-b4a4-e2a8-f67a-cd420ef1f90c@bothner.com> From: Phil Eaton Date: Tue, 7 Sep 2021 15:45:56 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Receiver class does not define or inherit an implementation of the resolved method To: Per Bothner Cc: spellcard199 , kawa mailing list X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00, HTML_MESSAGE, KAM_DMARC_STATUS, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: kawa@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Kawa mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2021 19:46:15 -0000 > Also note that it does not generate $X suffixes - but suffixes of the form $nn where nn is an integer. Sorry I was unclear. From my javap dump in a previous message the problem was about methods called `apply` and `apply$1`. When I said $X I meant where X is some integer. I did do a bunch of grepping but it hadn't turned up yet. Since that gnu/expr/LambdaExp.java code is adding a literal $X I don't think that's what I'm looking for. On Tue, Sep 7, 2021 at 3:31 PM Per Bothner wrote: > On 9/7/21 6:02 AM, Phil Eaton wrote: > > Separately, I was messing around in Kawa trying to understand where this > $X suffix is generated on duplicate methods. I did find fixParamNames in > gnu/bytecode/Scope.java:110. It has a note saying that $X suffix was > required because of _Android_/dex. I commented this method out and > recompiled and ran my example but it still generated the $X suffix. So I > guess that's not the place where the method name is generated for bytecode > compilation. > > From what I can tell/remember. fixParamNames has nothing to do with > method names. > It avoids duplicates in *variable* names, which apparently dex > complains/complained about. > (These local variable names are only used for debugging.) Also note that > it does not > generate $X suffixes - but suffixes of the form $nn where nn is an integer. > > If you're on a Unix-like system with a shell that understands **, > then the following is a useful trick: > > grep '"[$]X"' **/*.java > > That takes you gnu/expr/LambdaExp.java, where "$X" is added when the > method > takes an extra CallContext parameter (which is related to the tail-call > support). > > When it comes to having multiiple methods with the same name, same > parameter types, > but different return types that is allowed by the JVM but not by the Java > source language. However, Java 5 introduced "covariant return types": > Consider class T extends class S, and class S has a method f() return S. > It is often useful for class T to override f such that it returns a T. > (Or more generally an overriding method returns a subtype of the method it > overrides.) To implement this, javac will generate two methods: one that > returns a T, and additionally an artifical "bridge method" that calls the > former but whose return type is S. > > If I recall correctly, Kawa doesn't support covariant return types, > though it would be a nice feature to add. That might be the problem > you're having, but I'm not sure. > -- > --Per Bothner > per@bothner.com http://per.bothner.com/ >