Commented Unassigned: Dafny crash when same module is imported with two different names [125]

The following code causes Dafny to crash:

abstract module AbstractModuleA
{
type T
}

abstract module AbstractModuleB
{
import opened AMA as AbstractModuleA

method Foo(t:T)
}

abstract module AbstractModuleC refines AbstractModuleB
{
import opened AMA2 as AbstractModuleA
}

Here's the stack trace:

> DafnyPipeline.dll!Microsoft.Dafny.Translator.TrType(Microsoft.Dafny.Type type) Line 6866 C#
DafnyPipeline.dll!Microsoft.Dafny.Translator.GenerateMethodParametersChoose(Microsoft.Boogie.IToken tok, Microsoft.Dafny.IMethodCodeContext m, Microsoft.Dafny.Translator.MethodTranslationKind kind, bool includeReceiver, bool includeInParams, bool includeOutParams, Microsoft.Dafny.Translator.ExpressionTranslator etran, out System.Collections.Generic.List<Microsoft.Boogie.Variable> inParams, out System.Collections.Generic.List<Microsoft.Boogie.Variable> outParams) Line 6669 C#
DafnyPipeline.dll!Microsoft.Dafny.Translator.GenerateMethodParameters(Microsoft.Boogie.IToken tok, Microsoft.Dafny.Method m, Microsoft.Dafny.Translator.MethodTranslationKind kind, Microsoft.Dafny.Translator.ExpressionTranslator etran, out System.Collections.Generic.List<Microsoft.Boogie.Variable> inParams, out System.Collections.Generic.List<Microsoft.Boogie.Variable> outParams) Line 6650 C#
DafnyPipeline.dll!Microsoft.Dafny.Translator.AddMethod(Microsoft.Dafny.Method m, Microsoft.Dafny.Translator.MethodTranslationKind kind) Line 6266 C#
DafnyPipeline.dll!Microsoft.Dafny.Translator.AddClassMembers(Microsoft.Dafny.ClassDecl c) Line 1435 C#
DafnyPipeline.dll!Microsoft.Dafny.Translator.Translate(Microsoft.Dafny.Program p) Line 523 C#
dafny.exe!Microsoft.Dafny.DafnyDriver.ProcessFiles(System.Collections.Generic.IList<string> fileNames, Microsoft.Dafny.ErrorReporter reporter, bool lookForSnapshots, string programId) Line 165 C#
dafny.exe!Microsoft.Dafny.DafnyDriver.ThreadMain(string[] args) Line 96 C#
dafny.exe!Microsoft.Dafny.DafnyDriver.Main.AnonymousMethod__0() Line 33 C#

Comments: Below is an excerpt From Rustan's email. consider the following situation: module LibA { // ...things declared here... } module LibB { // ...things declared here... } module R { import opened LibA // ...things declared here... } module S refines R { import opened LibB // ...declared here... } Now: · If module R declares a TopLevelDecl “G”, then we should report an error if S attempts to declare an incompatible TopLevelDecl “G”. Dafny does this already today. (What I have said in this bullet should apply whether or not LibA and LibB declare something called “G”.) · If LibA declares a TopLevelDecl “G” but R does not directly declare any TopLevelDecl G”, then we should also issue an error for any TopLevelDecl “G” in S. This behavior is missing in Dafny today. (What I have said in this bullet should apply whether or not LibB declares something called “G”.) · If each of LibA and LibB declares some TopLevelDecl “G”, but neither R nor S directly declares any TopLevelDecl “G”, then no error should be issued, and any use of “G” in S should resolve to the “G” in LibA. This is different from the behavior today—with today’s behavior, an ambiguity error is issued if “G” is used in S. In other words, whereas today’s behavior is that “G” in R could refer to either LibA.G and LibB.G (which would be ambiguous), the new behavior I’m proposing is that LibA.G takes precedence over LibB.G as far as the resolution of “G” in R is concerned. I think these changes will also fix #125. In AbstractModuleC, the type of the parameter of the inherited method Foo will still be AMA.T, just like in AbstractModuleB. (Because Jay’s example uses “as” imports, it is as if AMA and AMA2 are two separate modules—they are modules, each of which adheres to AbstratModuleA.