1. 28 Jul, 2016 1 commit
  2. 19 Jul, 2016 1 commit
  3. 18 Jul, 2016 2 commits
  4. 15 Jul, 2016 1 commit
  5. 14 Jul, 2016 1 commit
  6. 17 May, 2016 2 commits
  7. 11 May, 2016 1 commit
  8. 25 Apr, 2016 1 commit
  9. 22 Apr, 2016 5 commits
  10. 15 Apr, 2016 2 commits
  11. 14 Apr, 2016 1 commit
  12. 12 Apr, 2016 1 commit
  13. 09 Apr, 2016 6 commits
  14. 07 Apr, 2016 2 commits
    • Andrew Twyman's avatar
      Merge pull request #199 from PSPDFKit-labs/peter/format-pedantic-warning-fix · 3f0ff223
      Andrew Twyman authored
      Xcode 7.3 adds a warning if we print an Objective-C class as a pointer...
      3f0ff223
    • Peter Steinberger's avatar
      Update test files. · 5cc3e12c
      Peter Steinberger authored
      ```
      Test Suite 'DBTokenTests' passed at 2016-04-07 17:39:19.383.
      	 Executed 5 tests, with 0 failures (0 unexpected) in 0.002 (0.005) seconds
      Test Suite 'DjinniObjcTestTests.xctest' passed at 2016-04-07 17:39:19.384.
      	 Executed 46 tests, with 0 failures (0 unexpected) in 0.057 (0.161) seconds
      Test Suite 'All tests' passed at 2016-04-07 17:39:19.384.
      	 Executed 46 tests, with 0 failures (0 unexpected) in 0.057 (0.196) seconds
      ** TEST SUCCEEDED **
      ```
      5cc3e12c
  15. 31 Mar, 2016 1 commit
    • Jakob Petsovits's avatar
      Fix shadowing of C++ type names by similar method names. · 5d0e60b8
      Jakob Petsovits authored
      This can be triggered by the following kinds of methods:
      
      ```
      Conflict = interface +c {
      }
      conflict_user = interface +c {
          # Invalid method:
          # std::shared_ptr<Conflict> Conflict();
          # The template argument refers to the method name, not the type.
          Conflict(): Conflict;
      
          # Invalid method:
          # void conflict_arg(const std::set<std::shared_ptr<Conflict>>& cs);
          # The other method name still shadows the 'Conflict' type.
          conflict_arg(cs: set<Conflict>): bool;
      }
      ```
      
      (This is more of an issue when the target C++ naming convention
      uses lower-case names for both types and methods, as is common
      in e.g. Boost or C++ standard library names.)
      
      Both are fixed by using the type's fully qualified name
      if the scope contains conflicting names/symbols.
      5d0e60b8
  16. 01 Mar, 2016 3 commits
  17. 29 Feb, 2016 1 commit
  18. 22 Feb, 2016 1 commit
  19. 19 Feb, 2016 1 commit
  20. 13 Feb, 2016 1 commit
    • Andrew Twyman's avatar
      Merge pull request #203 from guycnicholas/feature_184_take_3 · a656d150
      Andrew Twyman authored
      Configurable paths for extended record headers.
      *** POTENTIAL BREAKING CHANGE ***
      If you're using extended records, you may need to pass these two command-line arguments to Djinni to maintain the old behavior:
      --cpp-extended-record-include-prefix "../"
      --objc-extended-record-include-prefix "../"
      a656d150
  21. 10 Feb, 2016 1 commit
  22. 09 Feb, 2016 4 commits
    • Guy Nicholas's avatar
      Merge branch 'master' into feature_184_take_3 · c7a95dd5
      Guy Nicholas authored
      Conflicts:
      	src/source/CppGenerator.scala
      	test-suite/generated-src/cpp/extended_record_base.hpp
      	test-suite/generated-src/objc/DBExtendedRecord+Private.h
      	test-suite/handwritten-src/cpp/extended_record.hpp
      c7a95dd5
    • Guy Nicholas's avatar
      *** POTENTIAL BREAKING CHANGE *** · 06cdb828
      Guy Nicholas authored
      When extending a record using the +c or +o option the resultant Objective C code includes/imports the subclass assuming it is one level above the generated source. i.e.
      #include "../myExtendedRecord.h"
      To make the code positioning more flexible a pair of options were added to allow the developer to indicate the path prefix:
      cpp-extended-record-include-prefix
      objc-extended-record-include-prefix
      
      To use these options you would write something like this:
      djinni/src/run \
      --cpp-extended-record-include-prefix "path_to_my_src/"
      
      doing this will result in an include of the form:
      #include "path_to_my_src/myExtendedRecord.h"
      
      The breaking change part of this is that the default is now no path, so if you are now not compiling, you probably just need to add the following to your djinni run command
      --cpp-extended-record-include-prefix "../"
      06cdb828
    • Andrew Twyman's avatar
      Merge pull request #196 from guycnicholas/fix_forward_declare_extended_record · b3beb0e2
      Andrew Twyman authored
      Extended records forward declare
      b3beb0e2
    • Guy Nicholas's avatar