В последних билдах PEVerify выдает предупреждения (8651):

C:\Program Files\Nemerle>peverify Nemerle.Compiler.dll

Microsoft (R) .NET Framework PE Verifier.  Version  3.5.30729.1
Copyright (c) Microsoft Corporation.  All rights reserved.

[IL]: Error: [C:\Program Files\Nemerle\Nemerle.Compiler.dll : Nemerle.Compiler.LibraryReference+ExternalTypeInfo::imembe
r_of_memberinfo][offset 0x000000BC][found ref 'Nemerle.Compiler.MemberInfo'][expected ref 'Nemerle.Compiler.IMember'] Un
expected type on the stack.
1 Error(s) Verifying Nemerle.Compiler.dll

Собственно код этого метода:

      protected imember_of_memberinfo (m : SR.MemberInfo) : IMember
      {
        match (m.MemberType)
        {
          | MemberKinds.Constructor 
          | MemberKinds.Method     => ExternalMethodInfo  (tenv, library, m :> SR.MethodBase) : IMember
          | MemberKinds.Field      => ExternalFieldInfo   (tenv, library, m :> SR.FieldInfo)
          | MemberKinds.Property   => ExternalPropertyInfo(tenv, library, m :> SR.PropertyInfo)
          | MemberKinds.Event      => ExternalEventInfo         (library, m :> SR.EventInfo)
          | MemberKinds.NestedType => library.TypeInfoOfType(m :> System.Type)
          | _ => null
        }
      }

По адресу 0xbc находится инструкция ret, на нее переходят все ветки.
Чуть позже попробую

ExternalMethodInfo  (tenv, library, m :> SR.MethodBase) :> IMember

Теперь второй ахтунг:

C:\Program Files\Nemerle>peverify Nemerle.MSBuild.Tasks.dll

Microsoft (R) .NET Framework PE Verifier.  Version  3.5.30729.1
Copyright (c) Microsoft Corporation.  All rights reserved.

[IL]: Error: [C:\Program Files\Nemerle\Nemerle.MSBuild.Tasks.dll : Nemerle.Tools.MSBuildTask.Ext::Append][offset 0x00000
001] Method is not visible.
[IL]: Error: [C:\Program Files\Nemerle\Nemerle.MSBuild.Tasks.dll : Nemerle.Tools.MSBuildTask.Ext::AppendSwitchIfNotNull]
[offset 0x00000096] Method is not visible.
2 Error(s) Verifying Nemerle.MSBuild.Tasks.dll

Это ни как не связано с тем, что статические классы (Ext объявлен как module) в Nemerle можно наследовать от любых других (отличных от object)?
В C# это запрещено...

Здравствуйте, hardcase, Вы писали:

H>В последних билдах PEVerify выдает предупреждения (8651):
Не только в последних, насколько я помню.

H>

H>[IL]: Error: [C:\Program Files\Nemerle\Nemerle.Compiler.dll : Nemerle.Compiler.LibraryReference+ExternalTypeInfo::imembe
H>r_of_memberinfo][offset 0x000000BC][found ref 'Nemerle.Compiler.MemberInfo'][expected ref 'Nemerle.Compiler.IMember'] Un
H>expected type on the stack.
H>

Тут, насколько помню происходит следующее: ncc видит, что не надо делать преобразование типа и кладёт во всех ветках на не-совсем-типизированный стек значение. В то время как у верификатора по стандарту есть алгоритм вывода типов ячеек стека, который выводит по первым веткам не интерфейс IMember, а общий класс MemberInfo, а потом находит противоречие с ним. Собственно hint на первой ветке не случайно, алгоритм вывода типов Nemerle тут тоже бы ошибся, но при этом хинт не достигает IL.
В багтрекере это есть, ссылку сходу не дам.

H>

H>[IL]: Error: [C:\Program Files\Nemerle\Nemerle.MSBuild.Tasks.dll : Nemerle.Tools.MSBuildTask.Ext::Append][offset 0x00000
H>001] Method is not visible.
H>[IL]: Error: [C:\Program Files\Nemerle\Nemerle.MSBuild.Tasks.dll : Nemerle.Tools.MSBuildTask.Ext::AppendSwitchIfNotNull]
H>[offset 0x00000096] Method is not visible.
H>

Тут мы в статическом методе зовём protected базовый метод, чего вообще-то делать нельзя и тут кривой дизайн, ну или мягче, несовместимость расширяемости наследованием и методами-расширениями.

Да, забыл добавить, что это довольно важные сообщения об ошибках верификации, они лишь по счастливой случайности не проверяются в рантайме, а то получили бы invalid program exception, также ещё имеем шанс его получить в какой-нибудь новой версии .Net.

Здравствуйте, hardcase, Вы писали:

H>В последних билдах PEVerify выдает предупреждения (8651):

Он выдавал эти предупреждения и года полтора назад, когда я писал первую версию сборочного скрипта NemerleAll.nproj. Собственно именно по этой причине в скрипте ошибки верификации трактуются как предупреждения. Когда проблема будет решена, нужно будет подправить скрипт.

Заменить вот это:

<Exec Command="$(PEVerify) %(Asm3.FullPath)" ContinueOnError="True" />

На это:

<Exec Command="$(PEVerify) %(Asm3.FullPath)" ContinueOnError="False" />

Здравствуйте, Иванков Дмитрий, Вы писали:

ИД>Здравствуйте, hardcase, Вы писали:

H>>В последних билдах PEVerify выдает предупреждения (8651):
ИД>Не только в последних, насколько я помню.

H>>

H>>[IL]: Error: [C:\Program Files\Nemerle\Nemerle.Compiler.dll : Nemerle.Compiler.LibraryReference+ExternalTypeInfo::imembe
H>>r_of_memberinfo][offset 0x000000BC][found ref 'Nemerle.Compiler.MemberInfo'][expected ref 'Nemerle.Compiler.IMember'] Un
H>>expected type on the stack.
H>>

ИД>Тут, насколько помню происходит следующее: ncc видит, что не надо делать преобразование типа и кладёт во всех ветках на не-совсем-типизированный стек значение. В то время как у верификатора по стандарту есть алгоритм вывода типов ячеек стека, который выводит по первым веткам не интерфейс IMember, а общий класс MemberInfo, а потом находит противоречие с ним. Собственно hint на первой ветке не случайно, алгоритм вывода типов Nemerle тут тоже бы ошибся, но при этом хинт не достигает IL.
ИД>В багтрекере это есть, ссылку сходу не дам.

Как все же чинить это ?

Здравствуйте, _nn_, Вы писали:

__>Как все же чинить это ?

Начнем с более простого теста воспроизводящего багу:

interface ITest { }

class A { }
class B : A, ITest { }
class C : A, ITest { }

module Program
{
  Test() : ITest
  {
    def x = 1;
    match (x)
    {
      | 1 => B() : ITest
      | _ => C()
    }
  }

  Main() : void
  {
    _ = Test();
  }
}

Здравствуйте, VladD2, Вы писали:

VD>Начнем с более простого теста воспроизводящего багу:...

А вот его IL:

.method private hidebysig static class ITest Test() cil managed
{
  .maxstack 4
  .locals init (
    [0] int32 x)
  L_0000: nop 
  L_0001: nop 
  L_0002: ldc.i4.1 
  L_0003: stloc.0 
  L_0004: nop 
  L_0005: ldloc.0 
  L_0006: ldc.i4.1 
  L_0007: beq L_0012
  L_000c: nop 
  L_000d: br L_0020
  L_0012: nop 
  L_0013: nop 
  L_0014: nop 
  L_0015: nop 
  L_0016: newobj instance void B::.ctor()
  L_001b: br L_0027
  L_0020: nop 
  L_0021: nop 
  L_0022: newobj instance void C::.ctor()
  L_0027: nop 
  L_0028: nop 
  L_0029: nop 
  L_002a: ret 
}

Остается понять что в нем не так и как это исправить.

Здравствуйте, VladD2, Вы писали:

VD>Остается понять что в нем не так и как это исправить.

Код должен быть примерно таким:

  L_0008: newobj instance void B::.ctor()
  L_000d: br.s L_0019
  L_000f: newobj instance void A::.ctor()
  L_0014: castclass ITest

то есть нужен castclass ITest

Здравствуйте, _nn_, Вы писали:

__>Как все же чинить это ?

Починил в ревисии 9021.

Дело было в оптимизации устраняющей "лишниие" up cast-ы. Сделал тупо — если тип к которому требуется приведение типов — это интерфейс, то эмитить up cast. Не знаю дает ли эта оптимизация что-то для скорости. Если — да, то мое решение не самое эффективное, так как приводит к тому, что в некоторых случаях (когда базовый класс реализует интерфейс) будут лишние up cast-ты. Но думаю, что это все фигня.

Здравствуйте, VladD2, Вы писали:

VD>Починил в ревисии 9021.

Да... тест я не написал, так как там нужно как-то программно поднять апи PEVerify-я и им проверить тестовую сбрку. У меня на это просто не было времени. Плиз, добавь такой тест, если не сложно.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, VladD2, Вы писали:

VD>>Починил в ревисии 9021.

VD>Да... тест я не написал, так как там нужно как-то программно поднять апи PEVerify-я и им проверить тестовую сбрку. У меня на это просто не было времени. Плиз, добавь такой тест, если не сложно.

А может стоит все тесты проверять через PEVerify ?

Здравствуйте, _nn_, Вы писали:

__>А может стоит все тесты проверять через PEVerify ?

Боюсь это сильно замедлит и так не быструю сборку.

Можно это делать, но только в при полной проверке DevBuildFull и InstallerFull.