Skip to content
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

fix: Java --unicode-char mode coercion improvements #3630

Merged
merged 120 commits into from
Feb 27, 2023

Conversation

robin-aws
Copy link
Member

@robin-aws robin-aws commented Feb 24, 2023

Fixes #3413.

Addresses the issues uncovered during #2818 by adding a --unicode-char mode version of Test/comp/Arrays.dfy, which all stem from incomplete handling of manual boxing/unboxing of the CodePoint type at various Java code generation points. Note this is still incomplete as there must be other spots that do not handle coercion correctly in general, but these changes at least cover Arrays.dfy.

It turned out that handling arrow coercion as in the Go compiler was not necessary for Java, because the initial casting of a function reference as a lambda is where the necessary boxing/unboxing needs to happen instead anyway. That is, a reference to a Dafny function f(x: char): char has to end up as a Java Function<CodePoint, CodePoint> and therefore be eta expanded from the start.

Also removed the fail-fast behavior from %testDafnyForEachCompiler as I found it more useful for debugging that way.

Also implemented ConcreteSyntaxTree.Comma as part of an initial implementation of Java arrow conversion, which ended up not directly used but seems useful enough to keep (and I refactored one spot to use it as an example).

Edit: I've also added a few more similar cases exposed as part of enabling /unicodeChar:1 by default for Dafny 4.0: #3635

By submitting this pull request, I confirm that my contribution is made under the terms of the MIT license.

This solution uses an AutoGeneratedToken when filling in an omitted size. Previously, the code looked at the LiteralExpr in ArrayDimensions[0], which had the effect of also eliding a programmer-supplied size. Also, the previous implementation would crash if a size was given but wasn’t a LiteralExpr.
* Remove duplicate check
* Add omitted check
* Change error message to talk about “memory limit” rather than some C# property
…a-unicode-char-improvements

# Conflicts:
#	Source/DafnyCore/Compilers/GoLang/Compiler-go.cs
#	Source/DafnyCore/Compilers/Java/Compiler-java.cs
#	Source/DafnyCore/Compilers/Python/Compiler-python.cs
#	Source/DafnyCore/Compilers/SinglePassCompiler.cs
#	Source/DafnyRuntime/DafnyRuntime.py
#	Source/DafnyRuntime/DafnyRuntimeGo/DafnyRuntime.go
#	Test/unicodechars/comp/Arrays.dfy
#	Test/unicodechars/comp/Arrays.dfy.expect
@@ -1339,7 +1347,8 @@ protected class ClassWriter : IClassWriter {
} else if (member is Function fn) {
var wr = new ConcreteSyntaxTree();
EmitNameAndActualTypeArgs(IdName(member), TypeArgumentInstantiation.ToActuals(ForTypeParameters(typeArgs, member, false)), member.tok, wr);
if (typeArgs.Count == 0 && additionalCustomParameter == null) {
// TODO: needs to check for argument conversions as well
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you intend to act on this TODO in this PR? If not, I suggest adding a failing test case to Test/wishlist or somewhere.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I intended to leave it for now, but you're right a negative test would be a good idea. But I think it's just easier to implement this too - it's a fluke that Arrays.dfy exposed the return value problem, I should really add dedicated tests for this in something like Strings.dfy instead.

@@ -1367,7 +1376,15 @@ protected class ClassWriter : IClassWriter {
}
prefixWr.Write(") -> ");
wr.Write(")");
return EnclosedLvalue(prefixWr.ToString(), obj, $".{wr.ToString()}");

// TODO: Need to check arguments as well. Probably could use something like EmitCoercionIfNecessary
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you intend to act on this TODO in this PR? If not, I suggest adding a failing test case to Test/wishlist or somewhere.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As above, fixed the gap instead.

Source/DafnyCore/Compilers/Java/Compiler-java.cs Outdated Show resolved Hide resolved
Source/DafnyCore/Compilers/Java/Compiler-java.cs Outdated Show resolved Hide resolved
Source/DafnyCore/Compilers/Java/Compiler-java.cs Outdated Show resolved Hide resolved
Source/DafnyCore/Compilers/SinglePassCompiler.cs Outdated Show resolved Hide resolved
@RustanLeino
Copy link
Collaborator

This PR fixes #3413, right?

@robin-aws robin-aws merged commit de510d9 into dafny-lang:master Feb 27, 2023
robin-aws added a commit that referenced this pull request Feb 27, 2023
Picking up recent changes from master, especially #3630 as those fixes
are necessary to unblock #3635.

<small>By submitting this pull request, I confirm that my contribution
is made under the terms of the [MIT
license](https://github.com/dafny-lang/dafny/blob/master/LICENSE.txt).</small>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Missing coercions in edge cases for characters in Java with --unicode-char
3 participants