ICE: попытка добавить локальную переменную с тем же именем, но разными типами. во время [_RegisterClipboardFormat] - PullRequest
Новая
       35

ICE: попытка добавить локальную переменную с тем же именем, но разными типами. во время [_RegisterClipboardFormat]

0 голосов
/ 07 октября 2019

У меня есть PoC для использования некоторой существующей Java-кодовой базы в некоторых UWP-приложениях, использующих самую последнюю версию Visual Studio Community 19 версии 16.3.2 и последнюю версию IKVM 8.1.7195.0. Приложение собирается и работает нормально в режиме отладки, но не в состоянии собрать уже в режиме выпуска со следующей ошибкой:

MCG0004: InternalAssert Assert Failed: ICE: при попытке добавить локальную переменную с помощьюто же имя, но разные типы. во время [_RegisterClipboardFormat] Ams.Oms.Poc

RegisterClipboardFormat является частью IKVM: 

@DllImportAttribute.Annotation(value = "user32.dll", EntryPoint = "RegisterClipboardFormat")
private native static int _RegisterClipboardFormat(String format);

@cli.System.Security.SecuritySafeCriticalAttribute.Annotation
private static int RegisterClipboardFormat(String format)
{
    return _RegisterClipboardFormat(format);
}

https://github.com/ikvm-revived/ikvm/blob/master/openjdk/sun/awt/IkvmDataTransferer.java#L95

Что мне интереснок какой локальной переменной относится сообщение об ошибке? Может быть что-то добавлено неявно или может иметь отношение к String в Java против string в C #? ОТО, этот файл имеет четкое имя .java.

В общем, ничего не говорится о сообщении об ошибке, только следующие две ссылки кажутся более интересными:

Переменные, имеющиеодно и то же имя, но другой тип Почему C # не позволяет мне использовать одно и то же имя переменной в разных областях?

Так что в настоящее время я даже не уверен, откуда приходит сообщение,Visual Studio / C # напрямую или IKVM во время выполнения кода во время сборки Release-режима. Я сильно подозреваю, что ошибка исходит от Visual Studio / C #.

Поиск самой функции также не помогает:

Извините, AWT неподдерживаемая часть IKVM.

https://sourceforge.net/p/ikvm/bugs/225/

Другие, похоже, имели ту же проблему, потому что CN1 просто полностью отключил этот код в своем форке IKVM: 

//@DllImportAttribute.Annotation(value = "user32.dll", EntryPoint = "RegisterClipboardFormat")
//private native static int _RegisterClipboardFormat(String format);

@cli.System.Security.SecuritySafeCriticalAttribute.Annotation
private static int RegisterClipboardFormat(String format)
{
    throw new Error("Not implemented");
    //return _RegisterClipboardFormat(format);
}

https://github.com/ams-ts-ikvm/cn1-ikvm-uwp/blob/master/openjdk/sun/awt/IkvmDataTransferer.java#L95

Есть идеи? Спасибо!

1 Ответ

0 голосов
/ 24 октября 2019

Кажется, что есть обходной путь , вообще не меняющий код: в настройках Release-build есть флажок, если использовать для сборки встроенную панель инструментов .NET, которая включена по умолчанию,Отключение того, что сборка завершается успешно без какого-либо изменения кода и выполняется так же быстро, как и отладочная сборка. До того, как это изменить, сборка релиза тоже заняла много времени.

Не знаю, что это означает в отношении фактического вызова нативного кода, если он не работает или нет, потому что мое приложение их не использует. Я предполагаю, что это потерпит неудачу, в зависимости от того, работает ли он в Debug или нет. Кроме того, я не уверен, что магазин Windows принимает такую ​​модифицированную Release-сборку, но, поскольку приложения UWP вообще не вынуждены использовать нативный код, я думаю, есть хорошие шансы, что все заработает.

Clipboard01 Clipboard02 Clipboard03

...