From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from aibo.runbox.com (aibo.runbox.com [91.220.196.211]) by sourceware.org (Postfix) with ESMTPS id 6089A3857C7B for ; Wed, 10 Feb 2021 15:36:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 6089A3857C7B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=bothner.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=per@bothner.com Received: from [10.9.9.73] (helo=submission02.runbox) by mailtransmit03.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1l9rXU-00037q-KL; Wed, 10 Feb 2021 16:36:24 +0100 Received: by submission02.runbox with esmtpsa [Authenticated alias (524175)] (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) id 1l9rX6-0005WD-QS; Wed, 10 Feb 2021 16:36:01 +0100 Subject: Re: Value of given type cannot be case to its own type. To: "J. Vincent Toups" , kawa@sourceware.org References: From: Per Bothner Message-ID: <9a702bae-a8f6-1dbf-dc27-b5c0702f4219@bothner.com> Date: Wed, 10 Feb 2021 07:35:57 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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: Wed, 10 Feb 2021 15:36:29 -0000 On 2/10/21 7:12 AM, J. Vincent Toups via Kawa wrote: > I'm seeing this error: > > Value 'lib.mecs@131a7516' for variable 'm' has wrong type (lib.mecs) > (lib.mecs cannot be cast to lib.mecs) > > Which on the face of things is kind of flabbergasting. The specific > line of code which causes the issue suggests that it is indeed the > case that the value lib.mecs@etc... is a lib.mecs instance and its > being used as a lib.mecs instance. We cannot possibly diagnose this without a test-case. There are various possibilities. The one that first comes to mind is a class-loader problem: There are two classes named lib.mecs, loaded using two different classloaders, and thus they are incompatible. Though that would be more likely to show up at run-time rather than compile-time. It is also possible that one of the "lib.mecs" is not a reference to an instance of the lib.mecs class (which would normally be the case), but some type that the Kawa compiler displays as lib.mecs. Off-hand I can't think of what that could be, but I would not be surprised to see that. This could be a Kawa bug, of course. -- --Per Bothner per@bothner.com http://per.bothner.com/