-
Notifications
You must be signed in to change notification settings - Fork 266
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow specifying an outer namespace when translating #4591
Allow specifying an outer namespace when translating #4591
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mostly looks great, and nice that the actual implementation is pretty simple (especially compared to #4601 :)
Looks like this is just for Java and C#, which is fine for now, but will will need the other backends at some point. Make sure we either keep #4322 open or cut fresh issues for the remaining backends. The PR description is also a bit out of date.
@@ -239,7 +239,7 @@ public class LitTests { | |||
return false; | |||
} | |||
|
|||
if (arguments.Any(arg => arg is "/compile:3" or "/compile:4" or "run" or "translate")) { | |||
if (arguments.Any(arg => arg is "/compile:3" or "/compile:4" or "run")) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't seem right to me, I added "translate" because there were important backend-specific tests that weren't being run for all backends before that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there were important backend-specific tests that weren't being run for all backends before that.
Are you saying there were tests using dafny translate
that you converted to use %testDafnyForEachCompiler
?
I doubt that because I don't think you can test dafny translate
without back-end specific code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No I couldn't convert them to %testDafnyForEachCompiler
as you say, but I did manually add missing backend cases. https://github.com/dafny-lang/dafny/blob/master/Test/comp/separate-compilation/usesTimesTwo.dfy for example.
The name NeedsConverting()
is a bit out of date, since the idea is just to identify tests that use backends but don't test all backends.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the use of adding // NONUNIFORM: using dafny translate
to all tests that exercise dafny translate
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought NONUNIFORM
meant you are consciously only testing some back-ends, but now you're suggesting it will mean that you're not using %testDafnyForEach...
For run
you commonly should be able to use %testDafnyForEachCompiler
, so I think it makes sense there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can do that by looking for dafny translate !
The idea was to have // NONUNIFORM
on all tests that don't automatically pick up new compilers, regardless of why. We could modify https://github.com/dafny-lang/dafny/blob/master/.github/workflows/msbuild.yml#L59-L60 to look for dafny translate
as well if you want.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The idea was to have // NONUNIFORM on all tests that don't automatically pick up new compilers, regardless of why
What's the use? The reason you gave was that so you can "periodically audit the non-uniform tests and at least manually add new backends", but you don't need this semantic comment for that. Any test that specifies a target, either using --target
, or using dafny translate
, is non-uniform.
What I think is useful, is to complain about usages of dafny run
, dafny build
or dafny test
that don't use --target
, because they are uniform and could be tested against all back-ends, so it's wasted tested opportunity not to do so.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
btw, do you know why a file like this one https://github.com/dafny-lang/dafny/blob/master/Test/c%2B%2B/extern.dfy#L1 isn't flagged by the check?
// RUN: %dafny /compile:3 /spillTargetCode:2 /compileTarget:cpp /unicodeChar:0 "%s" ExternDefs.h > "%t"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't offhand, I'll look into it separately from this PR. And that means for now I won't object to this change. :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After offline conversation I realize this is a good change - // NONUNIFORM should only be used for tests of backend-specific behaviour, like ExternJavaString.dfy. as part of my action item I'll remove the tag from tests like that.
70581d2
to
6801e50
Compare
…to translatePrefix
Switched back to a unified option for all back-ends, since the new implementation guarantees a unified interface for all back-ends. |
@@ -171,6 +183,17 @@ public abstract class IExecutableBackend { | |||
/// </summary> | |||
public abstract void InstrumentCompiler(CompilerInstrumenter instrumenter, Program dafnyProgram); | |||
|
|||
public static readonly Option<string> OuterModule = | |||
new("--outer-module", "Nest all code in this module. Can be used to customize generated code. Use dots as separators (foo.baz.zoo) for deeper nesting. The first specified module will be the outermost one."); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
new("--outer-module", "Nest all code in this module. Can be used to customize generated code. Use dots as separators (foo.baz.zoo) for deeper nesting. The first specified module will be the outermost one."); | |
new("--outer-module", "Nest all code in this module. Can be used to customize generated code. Use dots as separators (foo.baz.zoo) for deeper nesting."); |
That last sentence is a leftover from the previous design AFAICT.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was not. Doesn't it help to indicate which module will be the outermost one?
…ors, to work with C++ (::, ::, ->) and JS (_, ., .) well
Fixes #4322
Changes
--outer-namespace
:Nest all code in this module. Can be used to customize generated code. Use dots as separators (foo.baz.zoo) for deeper nesting. The first specified module will be the outermost one.
Testing
--outer-namespace
for C#, Java, Go, Python and JavaScript__init__.py
By submitting this pull request, I confirm that my contribution is made under the terms of the MIT license.