TG-374 Feature/java support generics #1322

mgudemann · 2017-09-01T15:05:35Z

No description provided.

thk123

It is a big ask, but what would really help to understand what this new data means would be some unit tests on the results of the parsing. If you look in cbmc/unit/java_bytecode/java_bytecode_convert_class you should find some inspiration on how you might go about this.

thk123 · 2017-09-01T16:16:29Z

src/java_bytecode/java_types.cpp

+    }
+    c_pos++;
+    // limit depth to sensible values
+    assert(depth<=(src.size()-open_pos));


Shouldn't this be an invariant?

thk123 · 2017-09-01T16:19:54Z

src/java_bytecode/java_bytecode_parser.cpp

-    for(std::size_t i=0; i<local_variable_table_length; i++)
+    INVARIANT(
+      local_variable_type_table_length<=method.local_variable_table.size(),
+      "LVT must have at least as many elements as the type table.");


I would expression the condition and the comment in the same way:

method.local_variable_table.size() >= local_variable_type_table_length

I would probably also use variable table instead of LVT to be consistent with type table (or change both to acronyms, as I initially assumed LVT=LVTT).

thk123 · 2017-09-01T16:24:34Z

src/java_bytecode/java_types.h

+}
+
+/// class to hold type with generic type variable
+class java_type_with_generic_typet:public reference_typet


Sorry, I know we talked about it, but what is the difference between this and just a java_generic_typet?

peterschrammel · 2017-09-04T07:57:51Z

src/java_bytecode/java_bytecode_parse_tree.h

@@ -54,6 +54,8 @@ class java_bytecode_parse_treet
  class membert
  {
  public:
+    std::string descriptor;
+    bool hasSignature=false;


has_signature

peterschrammel · 2017-09-04T07:58:45Z

src/java_bytecode/java_bytecode_parser.cpp

+  else if(attribute_name=="Signature")
+  {
+    u2 signature_index=read_u2();
+    //method.hasSignature=true;


remove code that is commented out (several instances)

peterschrammel · 2017-09-04T08:06:35Z

src/java_bytecode/java_types.cpp

@@ -241,6 +291,83 @@ typet java_type_from_string(const std::string &src)
        return nil_typet();
      std::string class_name=src.substr(1, src.size()-2);

+      std::size_t f_pos=src.find('<', 1);


This looks very error-prone. Is there no better way of parsing this? At least some unit tests would be good.

why would it be error prone? The idea is to identify corresponding opening and closing > to see where the type variables are defined or substituted.
The java_generics_find_closing deals this by counting the opening and closing >.

thk123 · 2017-09-04T09:52:22Z

src/java_bytecode/java_types.cpp

 #include <cctype>

 #include <util/prefix.h>
 #include <util/std_types.h>
 #include <util/c_types.h>
 #include <util/std_expr.h>
 #include <util/ieee_float.h>
+#include <util/invariant.h>
+#define DEBUG


Don't check in with this define

thk123

I have some concerns about the fields added to the type - I fear we pass ireps by value and hence non-tracked fields might be sliced away (perhaps unit tests will prove I am wrong).

I think the naming change will significantly aid understanding.

thk123 · 2017-09-04T10:11:47Z

src/java_bytecode/java_types.h

+{
+public:
+  typet bound;
+  const irep_idt &type_var_name;


Is it OK for this to be a reference?

thk123 · 2017-09-04T10:17:51Z

src/java_bytecode/java_types.h

+class java_generic_typet:public reference_typet
+{
+public:
+  typet bound;


Is it OK to add fields to a irep class? I would worry that sometimes they are passed around by value - though I don't know, if there are other irep's that do this I guess it is fine?

Specifically, we return typet by value from java_type_from_string in java_types.cpp, won't these extra fields be sliced away?

thk123 · 2017-09-04T10:19:33Z

src/java_bytecode/java_types.h

+class java_type_with_generic_typet:public reference_typet
+{
+public:
+  typedef std::vector<typet> type_parameterst;


Could this be a std::vector<java_generic_typet>?

Also I think this might be sliced away.

thk123 · 2017-09-04T10:38:51Z

src/java_bytecode/java_types.cpp

+    INVARIANT(src[src.size()-1]==';', "Generic type name must en on ';'.");
+    irep_idt type_var_name(src.substr(1, src.size()-2));
+    return java_generic_typet(type_var_name);
+  }
  case 'L':
    {


Consider pulling this case out into its own function

I agree with this assessment as a matter of consistency with the other cases.

this seems consistent with the other more complex case 'L'

thk123 · 2017-09-04T10:49:19Z

src/java_bytecode/java_types.h

+
+/// class to hold a Java generic type
+/// upper bound can specify type requirements
+class java_generic_typet:public reference_typet


I think I get it - this is type that is a generic parameter (either with a bound or it is a java_inst_generic_typet if we know the actual type). Consider renaming to java_generic_parameter_typet since a generic type in Java normally means a type that has generic parameters rather than the parameters themselves.

thk123 · 2017-09-04T10:49:52Z

src/java_bytecode/java_types.h

+/// elements, each of type `java_generic_typet`, in `HashMap<Integer, V>` it
+/// would contains two elements, the first of type `java_inst_generic_typet` and
+/// the second of type `java_generic_typet`.
+class java_type_with_generic_typet:public reference_typet


You might consider calling this java_generic_typet though if you wish to keep it as this since more explicit then that's fine.

NlightNFotis · 2017-09-04T11:12:01Z

src/java_bytecode/java_bytecode_parser.cpp

+      t=java_type_from_string(f.signature);
+    }
+    else
+      t=java_type_from_string(f.descriptor);


The fact that the if statement has braces around its body, but else doesn't, and is also followed by another statement immediately after its body. This is inviting bugs and confusion in the future, I think.

NlightNFotis · 2017-09-04T11:17:19Z

src/java_bytecode/java_types.cpp

+    INVARIANT(src[src.size()-1]==';', "Generic type name must en on ';'.");
+    irep_idt type_var_name(src.substr(1, src.size()-2));
+    return java_generic_typet(type_var_name);
+  }
  case 'L':
    {


I agree with this assessment as a matter of consistency with the other cases.

mgudemann · 2017-09-15T15:04:34Z

@NlightNFotis @thk123 @peterschrammel maybe you could have another look
as @NlightNFotis has begun working on this branch, I have not yet squashed rebased this.

thk123

I will review the unit tests tomorrow but this looks good. No major changes but a few bits of tidy up.

thk123 · 2017-09-04T14:30:14Z

src/java_bytecode/java_bytecode_parser.cpp

    get_class_refs_rec(t);
  }

  for(const auto &m : parse_tree.parsed_class.methods)
  {
-    typet t=java_type_from_string(m.signature);
+    typet t;


Nit:

const typet &t=java_type_from_string(m.has_signature ? m.signature : m.descriptor);

Since reduces duplication and allows const-correctness on t.

agreed, but then we will have to split up again when doing this in a try block to fall-back to parsing the descriptor in case we hit a signature we do not support yet

thk123 · 2017-09-18T13:40:20Z

regression/cbmc-java/enum1/test.desc

@@ -1,4 +1,4 @@
-CORE
+KNOWNBUG


I remain slightly concerned about turning tests off (even with issues to turn them back on). Did this do anything useful that it now no longer does?

it fails to parse the signature and therefore bails out with an invariant violation, same for the two other cases
This will be restored temporally once we ignore signatures we cannot parse currently, and then be fixed once we can parse classes with instantiated signatures.

thk123 · 2017-09-18T13:58:40Z

src/java_bytecode/java_bytecode_convert_class.cpp

+    else if(is_java_generic_inst_parameter(field_type))
+    {
+      UNREACHABLE;
+      java_generic_inst_parametert &inst_gen_type=to_java_generic_inst_parameter(field_type);


I'm not sure there should be code after UNREACHABLE;. Consider converting the if to an assertion?

thk123 · 2017-09-18T14:01:44Z

src/java_bytecode/java_bytecode_convert_class.cpp

+  {
+    field_type=java_type_from_string(f.signature, id2string(class_symbol.name));
+
+    if(is_java_generic_parameter(field_type))


For convenience, could you add a comment suggesting what kind of field would take this path. I think this would be:

T f;

(I.e. a field whose type is a generic parameter)

thk123 · 2017-09-18T14:02:34Z

src/java_bytecode/java_bytecode_convert_class.cpp

+      field_type=reference_type(inst_gen_type.subtype());
+    }
+
+    else if(is_java_generic_type(field_type))


As above, a comment saying what kind of field would follow this path. I think:

List<Float> List<T>

thk123 · 2017-09-18T16:50:44Z

src/java_bytecode/java_types.h

+
+/// Class to hold a class with generics, extends the java class type with a
+/// vector of java_generic_type variables.
+class java_generics_class_typet:public java_class_typet


As with others - I think a comment showing the kind of Java that would have this type:

/// For example, a class definition `class MyGenericClass<T>`

thk123 · 2017-09-18T16:51:28Z

src/java_bytecode/java_types.h

+/// \return the type variable of t at the given index
+inline const typet &java_inst_get_inst_type(
+  size_t index,
+  const typet &t)


Nit: const java_generic_typet &t

thk123 · 2017-09-18T16:56:37Z

src/java_bytecode/java_types.h

+/// \return the name of the generic type variable of t at the given index
+inline const irep_idt &java_generics_class_type_var(
+  size_t index,
+  const typet &t)


Prefer const java_generic_class_typet &t then you can drop the precondition

thk123 · 2017-09-18T16:58:38Z

src/java_bytecode/java_types.h

+/// \return the type of the bound of the type variable
+inline const typet &java_generics_class_type_bound(
+  size_t index,
+  const typet &t)


Prefer const java_generic_class_typet &t then you can drop the precondition

thk123 · 2017-09-18T17:07:13Z

src/java_bytecode/java_types.cpp

@@ -158,7 +162,48 @@ exprt java_bytecode_promotion(const exprt &expr)
    return typecast_exprt(expr, new_type);
 }

-typet java_type_from_string(const std::string &src)
+/// find corresponding closing '>' which may be hierarchic
+size_t java_generics_find_closing(const std::string &src, size_t open_pos)


You might consider unit testing this since this is the kind of thing it is a) easy to unit test and b) easy to make silly mistakes. It also has the added benefit of documenting the "fence post" behaviour (e.g. does it return the position immediately before or after the closing >)

You might also consider pulling it into a utility and taking the bracket as an arg as I guess this is quite a common thing to want to do.

thk123

There is a reasonable amount of duplication in the unit tests that I think would massively help readability if tidied up. In particular, you can nest the Catch macros as much as needed

thk123 · 2017-09-19T08:59:44Z

unit/java_bytecode/java_bytecode_parse_generics/parse_generic_class.cpp

+  {
+    WHEN("Parsing a class with type variable")
+    {
+      java_lang->parse(java_code_stream, "generics$element.class");


To aid test readability - you might want to pull you the parse/typecheck/final into a utility function at the top:

void load_and_parse(std::unique_ptr<languaget>java_lang, const std::string class_path, symbol_tablet &out_symbol_table) { java_lang->parse(... java_lang->typecheck(out_symbol_table, ""); java_lang->final(out_symbol_table) }

thk123 · 2017-09-19T09:27:34Z

unit/java_bytecode/java_bytecode_parse_generics/parse_generic_class.cpp

+      REQUIRE(new_symbol_table.has_symbol("java::generics$element"));
+      THEN("The symbol type should be generic")
+      {
+        const symbolt &class_symbol=new_symbol_table.lookup("java::generics$element");


This looks to overlap with the above test - probably better to have more REQUIREs in one test than duplicate it as it makes it hard to see what is being tested. (It can go in a separate THEN block but the common loading code can be shared. something like THEN("The class symbol should be generic")...THEN("The element should be a generic parameter")

thk123 · 2017-09-19T09:42:44Z

unit/java_bytecode/java_bytecode_parse_generics/parse_generic_class.cpp

+          java_generics_class_type.get_component("elem");
+        const typet &elem_type=java_class_type.component_type("elem");
+
+        REQUIRE(is_java_generic_parameter(elem_type));


Can we add some more assertions here (e.g. is there a way to find out the generic parameter name is "E"?)

thk123 · 2017-09-19T09:43:34Z

unit/java_bytecode/java_bytecode_parse_generics/parse_generic_class.cpp

+        const symbolt &class_symbol=new_symbol_table.lookup("java::generics$element");
+        const typet &symbol_type=class_symbol.type;
+
+        class_typet class_type=to_class_type(symbol_type);


Again - try and combine the overlap with the above tests and just have different THEN blocks for documenting different checks

thk123 · 2017-09-19T10:07:33Z

unit/java_bytecode/java_bytecode_parse_generics/parse_generic_class.cpp

+        const symbolt &class_symbol=new_symbol_table.lookup("java::generics$bound_element");
+        const typet &symbol_type=class_symbol.type;
+
+        REQUIRE(symbol_type.id()==ID_struct);


For clarity, you might want to pull these checks into a single function:

java_class_typet CheckIsJavaClass(const typet &type) { REQUIRE(symbol_type.id()==ID_struct); class_typet class_type=to_class_type(symbol_type); REQUIRE(class_type.is_class()); return to_java_class_type(class_type); }

I've done something like this in an unrelated PR: write_expr.cpp which you might consider using as a model. I think it helps keep the intent of the tests clear and reduces total number of lines in the test.

thk123 · 2017-09-19T10:24:07Z

unit/java_bytecode/java_bytecode_parse_generics/parse_generic_class.cpp

+  {
+    WHEN("Parsing a class with generic return type of methods")
+    {
+      java_lang->parse(java_code_stream, "generics$bound_element.class");


Overlap with the other test that parses this file to keep tests together and to reduce duplication

thk123

The unit tests look great! Just a few nits to apply as you see fit but no need to get re-approved. Could you however create a bumping PR on test-gen to check it doesn't break anything downstream.

thk123 · 2017-09-19T16:56:42Z

src/java_bytecode/java_bytecode_parser.cpp

-    get_class_refs_rec(t);
+    typet field_type;
+    if(field.has_signature)
+      field_type=java_type_from_string(


Nit: multi-line body of if should be wrapped in braces

thk123 · 2017-09-19T16:57:03Z

src/java_bytecode/java_bytecode_parser.cpp

-    for(const auto &var : m.local_variable_table)
+    typet method_type;
+    if(method.has_signature)
+      method_type=java_type_from_string(


Nit: multi-line body should be wrapped in braces

thk123 · 2017-09-19T16:57:16Z

src/java_bytecode/java_bytecode_parser.cpp

-      typet var_type=java_type_from_string(var.signature);
+      typet var_type;
+      if(var.has_signature)
+        var_type=java_type_from_string(


Nit: multi-line body should be wrapped in braces

thk123 · 2017-09-19T16:57:58Z

src/java_bytecode/java_types.cpp

@@ -158,11 +163,34 @@ exprt java_bytecode_promotion(const exprt &expr)
    return typecast_exprt(expr, new_type);
 }

-typet java_type_from_string(const std::string &src)
+/*******************************************************************\


Old comment style; should be doxy

And do please document class_name as this is not obvious what it does

thk123 · 2017-09-20T09:22:41Z

src/java_bytecode/java_bytecode_parser.cpp

@@ -1401,3 +1443,40 @@ bool java_bytecode_parse(

  return java_bytecode_parse(in, parse_tree, message_handler);
 }
+
+void java_bytecode_parsert::parse_local_variable_type_table(methodt &method)


Nit: a summary of what a lvtt in doxygen comment might be good

thk123 · 2017-09-20T09:26:07Z

src/java_bytecode/java_utils.cpp

+    // limit depth to sensible values
+    INVARIANT(
+      depth<=(src.size()-open_pos),
+      "No closing \'>\' found in generic type.");


Should probably use close_char rather than >

thk123 · 2017-09-20T09:31:23Z

src/java_bytecode/java_utils.h

@@ -66,4 +66,6 @@ irep_idt resolve_friendly_method_name(
 /// \param type: expected result type (typically expr.type().subtype())
 dereference_exprt checked_dereference(const exprt &expr, const typet &type);

+size_t find_closing_delimiter(const std::string &, size_t, char, char);


Nit: name the parameters so users of the function can know which char does what. You might also consider overloading this with a method that takes just one char (say '(') and figure out the closing one.

thk123 · 2017-09-20T09:34:49Z

unit/java_bytecode/java_bytecode_parse_generics/parse_generic_class.cpp

+  {
+    WHEN("Parsing a class with bounded type variable")
+    {
+      REQUIRE(new_symbol_table.has_symbol("java::generics$bound_element"));


How come this works, you only parse the generics.class file? Does it auto pull in the others as dependencies?

NlightNFotis

Some comments with small requests for documentation changes. Nothing too big I think, and they are non-blocking changes (feel free to merge without them)

NlightNFotis · 2017-09-20T12:52:49Z

src/java_bytecode/java_types.h

+public:
+  typedef std::vector<java_generic_parametert> generic_type_variablest;
+
+  explicit java_generic_typet(const typet &_type) : reference_typet(_type, 64)


Why is it config.ansi_c.pointer_width in some calls to the reference_typet constructor, but it's a hardcoded 64 here? Is there any significance to this value here?

NlightNFotis · 2017-09-20T12:58:19Z

src/java_bytecode/java_types.h

+{
+public:
+  explicit java_generic_inst_parametert(const typet &type) :
+    java_generic_parametert(irep_idt(), type)


Can this be documented why this happens? Why when we create a new java_generic_inst_parametert we pass an empty string essentially to the java_generic_parametert constructor, causing an empty symbol to be pushed to type_variables?

NlightNFotis · 2017-09-20T13:02:25Z

src/java_bytecode/java_types.h

+}
+
+/// \param type: source type
+/// \return cast of type into an instantiated java_generic_type


Doesn't this return an instantiated java_generic_parameter?

NlightNFotis · 2017-09-20T13:29:05Z

src/java_bytecode/java_bytecode_parser.cpp

+        "java::"+id2string(parse_tree.parsed_class.name));
+    }
+    else
+      method_type=java_type_from_string(method.descriptor);


Can there be some spacing, or better yet, some curly braces enclosing the else statement to better denote intention?

NlightNFotis · 2017-09-20T13:31:57Z

src/java_bytecode/java_bytecode_convert_class.cpp

+    field_type=java_type_from_string(f.signature, id2string(class_symbol.name));
+
+    /// this is for a free type variable, e.g., a field of the form `T f;`
+    if(is_java_generic_parameter(field_type))


This is part of the rest of the work to support generics, right?

NlightNFotis · 2017-09-20T13:33:55Z

src/java_bytecode/java_bytecode_parse_tree.h

@@ -174,7 +178,8 @@ class java_bytecode_parse_treet

    typedef std::list<irep_idt> implementst;
    implementst implements;
-
+    bool has_signature=false;
+    std::string signature;


I support the usage of optional here, and around lines 107 in the same file.

NlightNFotis · 2017-09-20T13:41:20Z

src/java_bytecode/java_types.h

+}
+
+/// \param type: the type to check
+/// \return true if type is a java class type with generics


This is a cast, and doesn't return a boolean value.

Change from descriptor to signature for class / method / field

NlightNFotis

LGTM

d0d3620 Merge remote-tracking branch 'upstream/develop' into security-scanner-support 875d554 Merge branch 'develop' of github.com:diffblue/cbmc into develop 3a06eda don't rely on index expressions to be vector or arrays 6d6e1df Merge pull request diffblue#1407 from jasigal/fix/instantiate-not-contains#TG-592 8da3eef Merge pull request diffblue#1414 from antlechner/antonia/Character 0b56d97 Fix signatures for methods in java.lang.Character e4e2b10 TG-592 Implemented the correct instantiation procedure for not contains constraints ae83e4e Added install command for required projects. 0e70863 Merge pull request diffblue#1279 from NathanJPhillips/feature/expr_dynamic_cast 1e9837e Merge pull request diffblue#1405 from smowton/cleanup/remove_instanceof 7eb3c76 Merge pull request diffblue#1411 from diffblue/revert-1322-feature/java_support_generics 3b3fee3 Revert "TG-374 Feature/java support generics" 0e14431 Merge pull request diffblue#1408 from reuk/reuk/regression-filenames 2ddb0bc Simplify remove_instanceof logic b4f57ee Merge pull request diffblue#1410 from LAJW/fix-test-gen bcfb914 Remove invariant causing failure in unit test generation involving CharSequences 93149be Merge pull request diffblue#1322 from mgudemann/feature/java_support_generics c731b98 Merge pull request diffblue#1404 from LAJW/string-refinement-functional e5f5e8b Use `optionalt` for signature f68e817 Parse LocalVariabletypetable / Signature attributes use in types 585fb66 Merge pull request diffblue#1400 from reuk/reuk/enable-compile-commands da4df03 Switch from pointers to optionalt 413fc1b Automatically deduce test names from dir names 05d5a9b Address commenters' suggestions c48170e Merge pull request diffblue#192 from diffblue/smowton/feature/split_frontend_final_stage 0823f05 allow goto-cc -E 00cbad7 test for va_args 96f2d9e Added a PRECONDITION assert/invariant b8ab624 Code review fixup 775d9dd Renamed can_cast_expr c372eb3 Used typeinfo functions instead of rolling own 95f6505 Comment on types for which expr_dynamic_cast is not implemented d35710f Made validate_expr non-template de8a8d0 Implementation of expr_dynamic_cast f763691 Tidy up remove_instanceof f4df5c6 Add tests for mixed GOTO and C input 215d5bf Split the entry-point-generation phase into two parts ab347d5 Merge pull request diffblue#195 from diffblue/bugfix/missing-const_cast 73fba6e Fixed missing const_cast 751e8f5 Adhere to lintage b544a4b Fix unit test build 9b8a025 Fix get lambdas bee20f1 Remove unused add_lemma parameter d03866d static add axioms for string assings 1531f0e static debug_model f5c1b29 static get_array 7f11ccf static set_char_array_equality 229568a static Instantiate not contains 78303df Static concretize strings, lengths and results 918297c static concretize length a4c8cf5 Static index set functions e5e1ff4 static index_set functions 65ad3db Public methods made public 2eed573 Static add_axioms for strings 666c146 make static check_axioms bcd6111 Static is_axiom_sat 01b8301 static is_valid_string_constraint cfb47db Remove unused functions from string_refinement header 8e69d6d Make functions static 0cec13d Merge pull request diffblue#1360 from KPouliasis/konst_splice_call 9f9f30d fixup return value eaf97f6 Simplify remove_instanceof logic bc30987 Merge pull request diffblue#1235 from romainbrenguier/feature/string-max-input-length#948 0323ed0 Merge pull request diffblue#1349 from peterschrammel/cleanup/use-preformatted-output 621da87 Tests for new option string-max-input-length 440d19f Adding string max input length option e957025 Print results to result stream instead of status ad6484e Print XML and JSON objects on message stream 4969295 Tidy up remove_instanceof 6cb2f90 Merge pull request diffblue#1398 from diffblue/json_direct_return f365afe Merge pull request diffblue#1392 from reuk/reuk/fixup-appveyor-regressions 4a1565b Enable compile command output 523f028 Merge pull request diffblue#1368 from diffblue/use_size_t 358b435 prefer a ranged for over indexed iteration 69a8eaf use std::size_t for container indices cef7659 counters need to be size_t 2a7a0e8 the step number needs to be a size_t 9d48225 json_irept now returns ireps and jsont directly f22a864 Merge pull request diffblue#1386 from diffblue/return_directly 2b050a0 Merge pull request diffblue#1372 from diffblue/preconditions 6a509a8 goto-instrument no longer needs partial inlining by default e3f75d3 fixup coverage tests 1ff6bf2 missing include ac022e2 inlined functions are no longer ignored when doing coverage 4cb72b3 check error message in test 3a4ebeb use preconditions in the library f443b18 partial inlining is no longer needed 5624b15 instrumentation for preconditions 54e80da added __CPROVER_precondtion(c, d) 1d81035 Merge pull request diffblue#1393 from diffblue/byte_extract_is_binary 4e1fe93 Merge pull request diffblue#1396 from diffblue/String6-fixup 9497b02 Merge pull request diffblue#1395 from diffblue/msvc_unistd 17c6ca0 MSVC doesn't have strcasecmp and strncasecmp; use header for free() 237b31a Visual Studio doesn't have unistd.h; signal.h isn't needed for the MSVC build 5ef9c17 Revert 20e4def (preformatted_output flag) 3d4c794 Pass ostream instead of using cout in natural_loops 2716410 Update linter to cope with CBMC subtree 63fc53b Stop using sed to modify scripts! 58b75cf Merge pull request diffblue#1307 from zemanlx/coverity da91319 Adapt to upstream change in write_goto_binary interface and languaget 177a13d Add Coverity scan 22fb7c1 added splice-call feature in goto instrument It prepends a nullary function call say foo in the body of another call say moo when called as --splice-call moo,foo added tests a400c23 Merge pull request diffblue#1387 from thk123/feature/disable-mac-builds 68f2862 byte_extract expressions are binary expressions ec6ad09 Merge pull request diffblue#1379 from diffblue/remove-symex 1c1d3c2 remove path-symex and the symex tool f96ff48 Merge pull request diffblue#1384 from thk123/bugfix/regresssion-makefile 785bf43 Disable OSX builds 428b985 return STL containers directly for some variants of compute_called_functions 4bdd9c4 Corrected regression makefile 2b2a841 Convert display_index_set to a free function 9fff116 Remove constructor boilerplate 150bab1 Group string_refinement arguments 317c1c6 Group bv_refinement config variables bf47f81 Use expr_cast in string_exprt casts c5fa708 Refactor integer conversions f99c8ff Replace exceptions with optional git-subtree-dir: cbmc git-subtree-split: d0d3620

mgudemann self-assigned this Sep 1, 2017

mgudemann requested review from thk123 and NlightNFotis September 1, 2017 15:05

thk123 reviewed Sep 1, 2017

View reviewed changes

peterschrammel reviewed Sep 4, 2017

View reviewed changes

thk123 reviewed Sep 4, 2017

View reviewed changes

thk123 suggested changes Sep 4, 2017

View reviewed changes

NlightNFotis reviewed Sep 4, 2017

View reviewed changes

mgudemann force-pushed the feature/java_support_generics branch 4 times, most recently from 37b8e38 to 1fe1111 Compare September 8, 2017 15:53

thk123 suggested changes Sep 18, 2017

View reviewed changes

thk123 suggested changes Sep 19, 2017

View reviewed changes

thk123 approved these changes Sep 20, 2017

View reviewed changes

mgudemann added the new feature label Sep 20, 2017

mgudemann force-pushed the feature/java_support_generics branch 5 times, most recently from 9b4cb13 to bfe7ea4 Compare September 20, 2017 12:16

NlightNFotis reviewed Sep 20, 2017

View reviewed changes

mgudemann and others added 2 commits September 20, 2017 16:24

Parse LocalVariabletypetable / Signature attributes use in types

f68e817

Change from descriptor to signature for class / method / field

Use optionalt for signature

e5f5e8b

mgudemann force-pushed the feature/java_support_generics branch from bfe7ea4 to e5f5e8b Compare September 20, 2017 14:25

NlightNFotis approved these changes Sep 20, 2017

View reviewed changes

mgudemann merged commit 93149be into diffblue:develop Sep 20, 2017

mgudemann deleted the feature/java_support_generics branch September 20, 2017 15:06

smowton mentioned this pull request Sep 21, 2017

Revert "TG-374 Feature/java support generics" #1411

Merged

thk123 mentioned this pull request Oct 2, 2017

Generics support #1434

Merged

		@@ -1,4 +1,4 @@
		CORE
		KNOWNBUG

TG-374 Feature/java support generics #1322

TG-374 Feature/java support generics #1322

Conversation

mgudemann commented Sep 1, 2017

thk123 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

thk123 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mgudemann commented Sep 15, 2017

thk123 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

thk123 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

thk123 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

NlightNFotis left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

NlightNFotis left a comment

Choose a reason for hiding this comment