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

Improve error messages and generate operator<< for records #4

Open
wants to merge 21 commits into
base: master
Choose a base branch
from

Conversation

danyowdee
Copy link

@danyowdee danyowdee commented Aug 23, 2018

This PR adds support for the following djinni construct:

enum Currency {
    USD;
    EUR;
};

Product = record {
    name: string;
    identifier: string;
    price: i64;
    currency: Currency;
} deriving (show)

ShoppingCart = record {
    items: list<Product>;
} deriving (show)

So you can write the following C++ code:

Product p{"Little Red Corvette", "v0KpfrJE4zw", 1983, Currency::USD};
Product q{"Breakfast Can Wait", "CzWX1gv6u2s", 2013, Currency::EUR};
ShoppingCart c{{p, q}};
std::cout << c << std::endl; /* prints
"""ShoppingCart{ items:[
Product{ name:Little Red Corvette, identifier:v0KpfrJE4zw, price:1983, currency:Currency::USD },
Product{ name:Breakfast Can Wait, identifier:CzWX1gv6u2s, price:2013, currency:Currency::EUR },
] }"""

If Amount would be missing the declaration of conformance to show, the error message from running Djinni would clearly say so:

Record 'Amount' not deriving required operation(s): 'show'

louiswins and others added 16 commits February 22, 2018 15:37
…opbox#352)

* Update parameter names in documentation

Because parameter names may not be written in the same format between
C++, Objective-C, and Java, it is impossible to have doxygen- or
javadoc-style @param annotations that match for all languages. This
change simply looks for "@param <PARAMNAME>" in the docstring and
rewrites it the same way as the sourcecode does.

* Replace all occurrences of parameter name in docstring

* Also update Java for static methods

* Add multi-word parameter name to test suite

And reference it from the docstring.

* Revert "Add multi-word parameter name to test suite"

This reverts commit 785a226.

* Add multi-word parameter name to test suite

And reference it from the docstring.
* Generate an XCode like bridging header.

Generates also the version number and name variable.

* Add new generated headers.

* Changes naming accorging to comments.

* Update generated variable names.
* Got a basic version of constexpr in headers working

* got enum values to work as well

* can't do enums because interface headers forward declare so you can't set it there. So only primitives allowed

* fixing const enums in obj-c, which apparently never worked to begin with
Separate constant_enum to constant_enum.djinni, to exclude it from
common.djinni, so that it wouldn’t be picked up by Python in
python branch.

Otherwise it causes failure in python branch since constant enum feature is
not implemented for Python.
* rename destroy to __destroy

* update generated-src in test-suite

* use _djinni_destroy

* _djinni_private_destroy
* Added:

+ brace matcher
+ highlight for keywords

* Revert license

* Fix nullability bug

* Update version
* Provides compatibility for clang

Without this, clang will treat it as an error that `jniDefaultSetPendingFromCurrent` could potentially throw an uncaught exception.

* Update djinni_support.cpp

typo

* Renamed function and added comment for rationale.

* Whitespace for proper alignment

* Check for Duplicate Output Paths

This adds some simple logic to check whether files are set to overwrite each other. This is especially helpful for newcomers who are confused when the default settings cause this issue.

* Revert "Check for Duplicate Output Paths"

This reverts commit 06441f4.
* Check for Duplicate Output Paths

This adds some simple logic to check whether files are set to overwrite each other. This is especially helpful for newcomers who are confused when the default settings cause this issue.

* Simplified Implementation

I realized that the existing codebase actually already does this for files created by the same generator. This change makes it apply to all generators, preventing cross-language overwriting.
* Merge mrdomino's Java interface change with a more recent version of the repo.

* Make generating interfaces instead of abstract classes optional.

* Allow generation of Java interfaces when the Djinni interface is a +c interface and when the Djinni interface includes constants.

* Also omit "public" from constants in a Java interface.

* Revert "Also omit "public" from constants in a Java interface."

This reverts commit a4245b3.

* Omit "public" from constants in a Java interface.

* If Java interfaces were requested, generate them regardless of whether the interfaces include static methods.

* Keep CppProxy private if not generating interfaces.

* Change the java tests' target java version to 1.8.

* Place static natic methods in an inner class.

* Remove the StaticNative class and just use CppProxy.

* Minor edits.

* Don't use  --java-generate-interfaces in the yaml test, in order to exercise the code that runs when  --java-generate-interfaces isn't used.

* Revert "Don't use  --java-generate-interfaces in the yaml test, in order to exercise the code that runs when  --java-generate-interfaces isn't used."

This reverts commit cd86c27.

* Build the example Android project with Java 8.
When the CDPATH environment variable is set, the cd command prints the path of the directory to stdout. Redirect that output to /dev/null to avoid it being mistakenly included in the base_dir variable, which then causes cryptic errors.
* Implement comments support, tests and readme documentation

* improve code comments and documents comments parser when the two types of comments are one after the other

* improve tests
@danyowdee danyowdee force-pushed the daniel/deriving-show branch from 18679c2 to 5dff1b2 Compare August 24, 2018 14:42
Generating a description of a record is mostly trivial.
In fact, this already happens for Objective-C and Java — only C++ is missing.
Instead of generating this code unconditionally, this commit introduces something equivalent to Haskell’s `Show` typeclass for Djinni records.
It can be written using the regular `deriving (…)` syntax, using the keyword `show`.

Due to how resolver.scala is implemented, this diff is enough to get an error message telling if a nested record isn’t deriving `show` (the message is bad, though).
@danyowdee danyowdee force-pushed the daniel/deriving-show branch from 5dff1b2 to adc5509 Compare November 9, 2018 23:56
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.

10 participants