[TG-2365] Parse `BootstrapMethods` attribute #1804

mgudemann · 2018-02-07T08:13:00Z

This is a first step for Java8 lambda support based on invokedynamic. This parses the BootstrapMethods attribute in a class files, verifies that at most one exists and stores the information about referred lambda functions.

This is based on some hypotheses:

lambda function invokedynamic will always use LambdaFactory metafactory or altmetafactory for CallSite generation
compiled lambda functions start with lambda$ name, followed by new$, static$ or $FunctionName$` and running number

If the above hypotheses are not fulfilled, the entry in lambda_method_handles_map is set to UNKNOWN, no explicit invariants are used here beyond class file format restrictions.

smowton · 2018-02-07T10:29:00Z

src/java_bytecode/java_bytecode_parser.cpp

+          u2 arg_index2 = read_u2();
+          u2 arg_index3 = read_u2();
+
+          // skip rest


Clarify in the comment what we lose by ditching this stuff?

smowton · 2018-02-07T10:29:35Z

src/java_bytecode/java_bytecode_parser.cpp

+            real_handle.method_type = pool_entry(arg3.ref1).s;
+            parsed_class.lambda_method_handle_map[parsed_class.name].push_back(
+              real_handle);
+            status()


This is surely debug-level output

smowton · 2018-02-07T10:29:58Z

src/java_bytecode/java_bytecode_parser.cpp

+        }
+        else
+        {
+          // skip arguments here


Again clarify what we're throwing away

smowton · 2018-02-07T10:30:03Z

src/java_bytecode/java_bytecode_parser.cpp

+        lambda_method_handlet empty_handle;
+        parsed_class.lambda_method_handle_map[parsed_class.name].push_back(
+          empty_handle);
+        // skip arguments here


smowton · 2018-02-07T10:32:33Z

src/java_bytecode/java_bytecode_parser.cpp

+  // where $POSTFIX is $FUN for a function name in which the lambda is define
+  //                   "static" when it is a static member of the class
+  //                   "new" when it is a class variable, instantiated in <init>
+  if(has_prefix(id2string(pool_entry(nameandtype_entry.ref1).s), "lambda$"))


else if.

Also remove linebreaks between end of if and start of else if to clarify that they belong together

smowton · 2018-02-07T10:33:04Z

src/java_bytecode/java_bytecode_parser.cpp

+    handle.handle_type = method_handle_typet::LAMBDA_METHOD_HANDLE;
+  }
+
+  else if(


else return false ? This can clearly fail; the caller should do something appropriate in that case

the handle parameter is initialized with UNKNOWN so if nothing matches this simply stays. Overall probably makes more sense to return an optional method handle, though.

majakusber

It looks good to me, just two minor comments. I was also thinking if a unit test would make sense, to test that the parsed info has the expected form in an example. The regression test here only shows that the attribute is processed.

majakusber · 2018-02-07T17:32:27Z

src/java_bytecode/java_bytecode_parser.cpp

+      "only one BootstrapMethods argument is allowed in a class file");
+
+    // mark as read in parsed class
+    parsed_class.read_attribute_bootstrapmethods = true;


Why do we need to mark it read? According to java specification, there cannot be more than one BootstrapMethods attribute.

I think it may be worth sanity checking, that we only have one copy of this attribute.

@svorenova this is to validate that this hypothesis holds

@svorenova the current problem is that this is done in the class loader which is not accessible at the moment.
I agree that a unit test would be good (I had started one but then realized the above) but suggest deferring this to once we now how this information will finally be used and make it accessible in some form then.

majakusber · 2018-02-08T12:17:53Z

src/java_bytecode/java_bytecode_parser.cpp

  typedef java_bytecode_parse_treet::classt::method_handle_typet
    method_handle_typet;
  typedef java_bytecode_parse_treet::classt::lambda_method_handlest
    lambda_method_handlest;


This is renamed in the next line, so should be removed.

thomasspriggs · 2018-02-08T11:23:49Z

src/java_bytecode/java_bytecode_parser.cpp

+    u2 num_bootstrap_methods = read_u2();
+    for(size_t i = 0; i < num_bootstrap_methods; i++)
+    {
+      u2 bootstrap_methodhandle_ref = read_u2();


According to the programming standards, basic words should be separated by _ and abbreviations should be avoided. Therefore bootstrap_methodhandle_ref should be bootstrap_method_handle_reference.

I think the names were taken from the Java spec: https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.7.23
So the question is whether to stay consistent with the spec or with general standards. In other parts of our code for parsing bytecode that I've seen, the names follow the Java spec.

Could we add this link / a reference to the relevant section of the specification in a comment somewhere?

I agree that names corresponding to specific concepts should match the java spec rather than a strict interpretation of our own naming convention.

I am ok with the original java standards naming.

thomasspriggs · 2018-02-08T11:27:52Z

src/java_bytecode/java_bytecode_parser.cpp

+
+// read method handle pointed to from constant pool entry at index, supports
+// reading method handles for bootstrap methods and lambda methods
+void java_bytecode_parsert::parse_methodhandle(


Should parse_methodhandle be parse_method_handle?

I don't mind, but just as the cases above, methodhandle is used like this in the JVM class file format spec

thomasspriggs · 2018-02-08T11:39:04Z

src/java_bytecode/java_bytecode_parser.cpp

+// reading method handles for bootstrap methods and lambda methods
+void java_bytecode_parsert::parse_methodhandle(
+  u2 index,
+  u2 num_bootstrap_arguments,


"num" is an abbreviation which according to the programming standards should be avoided. So, non abbreviated this would be number_bootstrap_arguments, but I think bootstrap_arguments_count might read better.

This is ok, as num_bootstrap_arguments is in the java specification.

thomasspriggs · 2018-02-08T11:40:31Z

src/java_bytecode/java_bytecode_parser.cpp

+    "reference kind of Methodhandle must be in the range of 1 to 9");
+
+  const auto &class_entry = pool_entry(ref_entry.ref1);
+  const auto &nameandtype_entry = pool_entry(ref_entry.ref2);


nameandtype_entry should be name_and_type_entry

This is ok as it matches the java specification.

thomasspriggs · 2018-02-08T12:25:08Z

src/java_bytecode/java_bytecode_parser.cpp

+        {
+          // skip arguments here
+          for(size_t i = 0; i < num_bootstrap_arguments; i++)
+            read_u2();


Although the coding standards states that "Single line blocks without { } are allowed", my preference is that { } is still used for single line blocks. I find that adding the { }, reduces the chance of mistakes when expanding the block to multiple lines later on.

Actually it may be better to use a call to skip_bytes (or a new skip_u2s) method rather than writing an additional loop each time you want to skip things.

thomasspriggs · 2018-02-08T14:39:30Z

src/java_bytecode/java_bytecode_parser.cpp

+/// for a recognized bootstrap method, for a lambda function or unknown
+void java_bytecode_parsert::parse_methodhandle(
+  const pool_entryt &entry,
+  lambda_method_handlet &handle)


Could handle be the return value instead of an output argument?

ok, will change

thomasspriggs · 2018-02-08T14:45:23Z

src/java_bytecode/java_bytecode_parse_tree.h

+      UNKNOWN_HANDLE
+    };
+
+    struct lambda_method_handlet


Could this be a new class instead of a struct?

isn't the main difference that struct members are public by default while class members are private ? But yes, no problem to make this a class.

Yes, C++ doesn't make a large differentiation between the struct and class keywords. I am asking for a class to be used with each of the fields accessed through getter and setter methods instead of publicly accessible fields. The production of the debug text on lines 1480-1485, could then be defined as a method instead of inline at the point of building the class.
I know this is a relatively small example of a class to build with getters/setters which feel like boiler plate code. However I think it gives a superior foundation to build on, leading to more compartmentalised code in the end result, instead of large individual files.

thomasspriggs · 2018-02-08T15:02:03Z

src/java_bytecode/java_bytecode_parser.cpp

+          const pool_entryt &arg3 = pool_entry(arg_index3);
+
+          if(!(arg1.tag == CONSTANT_MethodType &&
+               arg2.tag == CONSTANT_MethodHandle &&


Why do we check the tag of arg2 and throw the value away instead of storing for later use?

this is just to validate that the format is what we expect a lambda entry to look like

thomasspriggs · 2018-02-08T15:10:12Z

src/java_bytecode/java_bytecode_parser.cpp

+              << id2string(real_handle.lambda_method_name) << " in class \""
+              << parsed_class.name << "\""
+              << "\n  interface type is "
+              << id2string(real_handle.interface_type = pool_entry(arg1.ref1).s)


Why are we performing an assignment in the middle of a status output? Wasn't real_handle.interface_type already assigned to pool_entry(arg1.ref1).s back on line 1476?

good catch, definitely a copy&paste bug

thomasspriggs · 2018-02-08T15:11:37Z

src/java_bytecode/java_bytecode_parser.cpp

+              << "\n  interface type is "
+              << id2string(real_handle.interface_type = pool_entry(arg1.ref1).s)
+              << "\n  method type is "
+              << id2string(real_handle.interface_type = pool_entry(arg3.ref1).s)


Shouldn't real_handle.interface_type = pool_entry(arg3.ref1).s be real_handle.method_type?

thomasspriggs · 2018-02-08T15:57:41Z

src/java_bytecode/java_bytecode_parser.cpp

+    {
+      u2 bootstrap_methodhandle_ref = read_u2();
+      const pool_entryt &entry = pool_entry(bootstrap_methodhandle_ref);
+      u2 num_bootstrap_arguments = read_u2();


"num" is an abbreviation, so according to the standards this should be number_bootstrap_arguments, but I think bootstrap_arguments_count would read better.

This is the naming from the java standards, so it is ok.

thomasspriggs · 2018-02-08T17:20:13Z

src/java_bytecode/java_bytecode_parser.cpp

+          {
+            lambda_method_handlet empty_handle;
+            parsed_class.lambda_method_handle_map[parsed_class.name].push_back(
+              empty_handle);


If there are cases where we may need to deal with empty / missing handles, then perhaps the type of the lambda_method_handle_map should be std::map<irep_idt, optionalt<lambda_method_handlest> > instead of std::map<irep_idt, lambda_method_handlest>

Or perhaps it isn't worth adding them to the map at all?

best would probably to have a mapping from pairs of class name and entry number to the handle, then a non-existing (or non-parsable) lambda method handle would simply not exist in the map

thk123

Only reviewed first commit so far.

thk123 · 2018-02-08T18:23:01Z

src/java_bytecode/java_bytecode_parser.cpp

  }
+  else if(attribute_name == "BootstrapMethods")
+  {
+    INVARIANT(


Preferably comment with relevant spec that says this

Java 8 class file spec §4.4.10

thk123 · 2018-02-08T18:28:00Z

src/java_bytecode/java_bytecode_parser.cpp

+    + id2string(pool_entry(nameandtype_entry.ref2).s);
+
+  if(
+    method_name ==


Eek! Perhaps we need some kind of interface that specifies whether for a given method name whether it can handle it? Could you add to the PR a summary of how this step is structured:

stores the information about referred lambda functions.

thk123

mid way through reviewing but have a meeting so thoughts so far (I strongly agree with @svorenova that unit tests would allow much more precise evaulation of whether the parse tree looks like what we want it to)

thk123 · 2018-02-09T10:43:57Z

src/java_bytecode/java_bytecode_parser.cpp

          }
          else
          {
+            real_handle.interface_type = pool_entry(arg1.ref1).s;


This needs some kind of comment to explain why arg1.ref1 is the interface type!

thk123 · 2018-02-09T11:08:34Z

regression/cbmc-java/lambda1/CustomLambda.java

@@ -0,0 +1,3 @@
+interface CustomLambda<T> {


Why not both? 😛

thk123 · 2018-02-09T11:20:09Z

src/java_bytecode/java_bytecode_parser.cpp

+    for(size_t i = 0; i < num_bootstrap_methods; i++)
+    {
+      u2 bootstrap_methodhandle_ref = read_u2();
+      const pool_entryt &entry = pool_entry(bootstrap_methodhandle_ref);


Consider adding invariant that this entry is a CONSTANT_MethodHandle_info?

I see this is actually handled in parse_methodhandle

thk123 · 2018-02-09T11:20:55Z

src/java_bytecode/java_bytecode_parser.cpp

  }
+  else if(attribute_name == "BootstrapMethods")
+  {
+    INVARIANT(


Probably pull out rBootStrapMethods_attribute method

thk123 · 2018-02-09T11:21:29Z

src/java_bytecode/java_bytecode_parser.cpp

  }
+  else if(attribute_name == "BootstrapMethods")
+  {
+    INVARIANT(


Java 8 class file spec §4.4.10

thk123 · 2018-02-09T11:23:52Z

src/java_bytecode/java_bytecode_parser.cpp

+      status() << "INFO: parse BootstrapMethod handle "
+               << num_bootstrap_arguments << " #args"
+               << eom;
+      parse_methodhandle(entry, handle);


Why not have this return the handle?

thk123 · 2018-02-09T11:26:32Z

src/java_bytecode/java_bytecode_parser.cpp

+    {
+      u2 bootstrap_methodhandle_ref = read_u2();
+      const pool_entryt &entry = pool_entry(bootstrap_methodhandle_ref);
+      u2 num_bootstrap_arguments = read_u2();


Rather than reading the arguments below - I'd be tempted to read them all now into an appropriate vector so there's no chance of missing a byte (e.g. if we add more handle_types)

thk123

Got to the bit where we start comparing method_name. Up until the end was looking good, but I think the last view decoding steps are too dense to really follow along even with the spec open next to it.

I also think that we need to design exactly how these different supported times are structured, potentially outside the scope of this PR, which would just read the information into some kind of primitive structure.

thk123 · 2018-02-09T16:03:53Z

src/java_bytecode/java_bytecode_parser.cpp

+  const auto &ref_entry = pool_entry(entry.ref2);
+  INVARIANT(
+    (entry.ref1 > 0 && entry.ref1 < 10),
+    "reference kind of Methodhandle must be in the range of 1 to 9");


Perhaps add reference to §5.4.3.5

thk123 · 2018-02-09T16:11:08Z

src/java_bytecode/java_bytecode_parser.cpp

+  INVARIANT(
+    entry.tag == CONSTANT_MethodHandle,
+    "constant pool entry must be a MethodHandle");
+  const auto &ref_entry = pool_entry(entry.ref2);


Not new code - but I'm a bit confused by this, the spec seems to suggest that a pool entry is a u1 tag followed by an array of u1s dependent on the tag. But our pool_entryt is two u2s, a string, a u8 and an expression. Perhaps should raise a technical debt to have a different class for each pool entry type or at least have the pool_entryt mirror how it looks in the bytecode and have methods that look like:

u1 get_method_handle_reference_kind(const pool_entryt &entry) { INVARIANT(entry.get_tag()==CONSTANT_MethodHandle); return entry.data[0]; }

I think as a minimum you should introduce that latter method for the new pool_entryt so that is at least obvious that entry.ref2 is the reference_index

thk123 · 2018-02-09T17:08:25Z

src/java_bytecode/java_bytecode_parser.cpp

+    (entry.ref1 > 0 && entry.ref1 < 10),
+    "reference kind of Methodhandle must be in the range of 1 to 9");
+
+  const auto &class_entry = pool_entry(ref_entry.ref1);


This bit is kind of complex to follow, suggest mirroring the spec to first create an enum for the different values of the reference_kind:

REF_getField REF_getStatic REF_putField REF_putStatic REF_invokeVirtual REF_invokeStatic REF_invokeSpecial REF_newInvokeSpecial REF_invokeInterface

Then switch on these in the same way, breaking into rFieldref_info

I'm pausing here as it has got hard to follow - but the special casing of dealing with which factories we actually support should be abstracted far away from the parse tree IMO (in fact potentially not even part of this PR?)

thk123 · 2018-02-09T17:44:48Z

For unit tests, can you not do something like:

SCENARIO(
"rclass_attribute",
"[core][java_bytecode][java_bytecode_parse_generics]")
{
  ui_message_handlert message_handler;
  java_bytecode_parse_treet parse_tree;
  java_bytecode_parse("/home/tkiley/workspace/cbmc/regression/cbmc-java/lambda1/Lambdatest.class", parse_tree, message_handler);

  REQUIRE(parse_tree.loading_successful);


  REQUIRE(parse_tree.parsed_class.lambda_method_handle_map.size() > 0);
  // etc.

}

(note this currently fails on the Lambdatest.class - don't know if this is correct (i.e. should there be something in the lambda_method_handle_map) but I think the principle is OK.

I had originally hoped you could test the individual read methods, but of couse you don't know how far through the bytecode you need to go to start reading the class attributes for example. Of course, really nice would be to rather than using real class files, we write subsections of class files that explore all the ways the bytecode for that structure can be. But that is for perhaps another day.

thomasspriggs · 2018-02-13T14:00:52Z

src/java_bytecode/java_bytecode_parser.cpp

+
+  const auto &class_entry = pool_entry(ref_entry.ref1);
+  const auto &nameandtype_entry = pool_entry(ref_entry.ref2);
+


I think there should be a double check here that name_and_type_entry.tag is set to CONSTANT_NameAndType

I believe this comment is addressed by mgudemann#1

thomasspriggs · 2018-02-13T14:08:10Z

src/java_bytecode/java_bytecode_parser.cpp

+                    << "\n  interface type is "
+                    << id2string(pool_entry(interface_type_argument.ref1).s)
+                    << "\n  method type is "
+                    << id2string(pool_entry(method_type_argument.ref1).s)


Can you refactor the generation of this debugging text into a std::string pretty() method of lambda_method_handlet class? I think it would be useful to be able to generate this later whilst debugging lambda functionality, instead of just at the point where the lambda function is parsed.

thk123 · 2018-02-14T16:12:12Z

@mgudemann I have created mgudemann#1 to address the comments I made, if you like them, I guess you can merge the PR with a rebase and they will appear here?

thk123 · 2018-02-15T13:51:06Z

As discovered when writing unit tests for this (btw - a strong argument for unit tests 😛 ) - the classt::swap method needs updating as part of this PR

thk123 · 2018-02-15T15:04:52Z

So I see by removing the special handling in the parse_method_handle I deactivated the code that actually turns the lambdas into the actual function it corresponds to.

That is, we first read a method handle that corresponds to (probably) a lambdafactory method. We then assume the parameters meet a certain criteria that allows us to get a second methodhandle that is referring to the implementation of the lambda.

I had hoped to avoid cluttering the bytecode parsing with the specifics of how lambads work, but since we loose the constants pool we need to do something.

I suggest rather than reusing the lambda_method_handle for both, I introduce another method_handle_infot for the general case, then we have a separate class that takes these, and the constants pool and converts them into a lambda_method_handle to go into the table.

I'll put the first part in an update to mgudemann#1 and carry on with the unit tests. If you'd be able to pull out the bit that starts with // try parsing bootstrap method handle into a separate file then we'll have a good base to build on.

thk123 · 2018-02-15T15:55:50Z

I've updated mgudemann#1 with the suggested change while leaving the special case handling in java_bytecode_parser.cpp - will now do what I should have been doing and actually write the unit tests!

mgudemann · 2018-02-19T14:20:20Z

@thk123 is there a special reason why you'd like to have the parsing refactored into a separate file? I currently refactored it into its own method in java_bytecode_parsert that is called from rclass_attribute

thk123 · 2018-02-19T14:56:39Z

@mgudemann Only that it feels like it might expand if/when we support other methods called by invoke_dynamic (and the file is already quite large). I think a similar argument could be made for the structured pool stuff.

mgudemann · 2018-02-20T09:59:56Z

@thk123 ok then I'll split the bootstrapmethods parsing and the structured constant pool stuff into an extra file within the java_bytecode folder. How about a java_lambda_functions file?

thk123 · 2018-02-20T10:18:47Z

@mgudemann I would put the constants pool stuff into a structured_constant_pool_entries.cpp as I have a vague hope that we can transition to that for all the constants to give us a bit more structure when converting constants.

Parses some class files with different lambda functions, matches status output of found references to lambdas.

…e code

Moved general parsing of a CONSTANT_methodhandle_info into a strcutured class

majakusber

Looks good, love the regression/unit tests.

thomasspriggs · 2018-02-27T15:07:18Z

src/java_bytecode/java_bytecode_parser.cpp

If parse_method_handle returns an empty optionalt then the code will reach this line and crash due to a failed assertion on .has_value() inside the implementation of the -> operator in optionalt. If we mean to halt execution in this case then we should have a CHECK_RETURN() on the return from parse_method_handle. Assuming of course that we don't have a more elegant way of handling this without halting execution.

Looks like this is now handled ok.

thomasspriggs · 2018-02-27T15:18:35Z

src/java_bytecode/java_bytecode_parser.cpp

When I first read this I thought - "Why are we using .swap rather than just assignment with =?" Then I realised that this was an optimisation to avoid having two copies of the data in the vector in memory at once. The C++11 way to do this would be lambda_method_handle.u2_values = std::move(u2_values); I think this makes the intent clearer.

thomasspriggs · 2018-02-27T16:35:18Z

src/java_bytecode/java_bytecode_parser.cpp

A minor optimisation would be to use u2_valuest u2_values(num_bootstrap_arguments);, so that the vector is created with the correct amount of elements reserved instead of resized as we add them.

thomasspriggs

Ok, can we get this merged now?

mgudemann requested review from cesaro, peterschrammel, smowton and thk123 as code owners February 7, 2018 08:13

mgudemann self-assigned this Feb 7, 2018

mgudemann force-pushed the feature/parse_bootstrapmethods_attribute branch 2 times, most recently from 014540e to 257e5e2 Compare February 7, 2018 09:18

smowton reviewed Feb 7, 2018

View reviewed changes

thk123 requested a review from majakusber February 8, 2018 10:17

majakusber reviewed Feb 8, 2018

View reviewed changes

thomasspriggs suggested changes Feb 8, 2018

View reviewed changes

thomasspriggs reviewed Feb 8, 2018

View reviewed changes

thk123 reviewed Feb 8, 2018

View reviewed changes

thk123 reviewed Feb 9, 2018

View reviewed changes

thomasspriggs reviewed Feb 13, 2018

View reviewed changes

thk123 mentioned this pull request Feb 14, 2018

Applying suggestions for review comments to parse_bootstrap methods mgudemann/cbmc#1

Merged

mgudemann force-pushed the feature/parse_bootstrapmethods_attribute branch from ddbf4f5 to 44b9f07 Compare February 19, 2018 14:01

mgudemann force-pushed the feature/parse_bootstrapmethods_attribute branch from e097cb1 to bf53c54 Compare February 21, 2018 08:25

Matthias Güdemann and others added 12 commits February 27, 2018 16:50

Initial support for reading BootstrapMethods attribute

e79a655

Add regression test for lambda functions

603aced

Parses some class files with different lambda functions, matches status output of found references to lambdas.

status()->debug()

01dcda5

Rename, some more comments

f765a0d

Use optionalt<lambda_method_handlet> as return value

6d44836

Adding validation on the type of descriptor found

0e40081

Introduce classes representing relevant constant pool entries

3ac7d09

Use the strcutured classes to simplify and make more explict the code

e3ff312

Fix missing swap for classt

b56e42e

Fixup Use the strcutured classes to simplify and make more explict th…

ca5dae4

…e code

Refactor parse_method_handle to just deal with the lambda special case

463ffe1

Moved general parsing of a CONSTANT_methodhandle_info into a strcutured class

Refactor BootstrapMethods attribute reading into function

e0ccb12

mgudemann force-pushed the feature/parse_bootstrapmethods_attribute branch from c8bc9cf to 5daf6e1 Compare February 27, 2018 15:52

majakusber approved these changes Feb 27, 2018

View reviewed changes

thomasspriggs suggested changes Feb 27, 2018

View reviewed changes

thomasspriggs reviewed Feb 27, 2018

View reviewed changes

mgudemann force-pushed the feature/parse_bootstrapmethods_attribute branch 2 times, most recently from a347a2e to 552c7ae Compare February 27, 2018 16:53

Matthias Güdemann and others added 6 commits February 27, 2018 18:32

Fix format and account for reviewer's comments

f79e895

Adding utiltiy functions required for unit tests

ebdcfb1

Adding tests for static lambdas

ba8b958

Adding tests for local lambdas

db1f3b5

Adding tests for lambdas as member variables

9b8a73e

Adding tests for inner classes that capture outer class variables

76d4014

mgudemann force-pushed the feature/parse_bootstrapmethods_attribute branch from 552c7ae to 76d4014 Compare February 27, 2018 17:32

thomasspriggs approved these changes Feb 27, 2018

View reviewed changes

thk123 approved these changes Feb 28, 2018

View reviewed changes

thk123 merged commit 5cdfa94 into diffblue:develop Feb 28, 2018

mgudemann deleted the feature/parse_bootstrapmethods_attribute branch February 28, 2018 10:07


		const auto &class_entry = pool_entry(ref_entry.ref1);
		const auto &nameandtype_entry = pool_entry(ref_entry.ref2);

[TG-2365] Parse BootstrapMethods attribute #1804

[TG-2365] Parse BootstrapMethods attribute #1804

Uh oh!

Conversation

mgudemann commented Feb 7, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

majakusber left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

thomasspriggs Feb 8, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

[TG-2365] Parse `BootstrapMethods` attribute #1804

[TG-2365] Parse `BootstrapMethods` attribute #1804

thomasspriggs Feb 8, 2018 •

edited

Loading