| f58c3bd412f9bdc5ec589fdcfed470889abb6ea6 |
|
26-Mar-2016 |
Yigit Boyar <yboyar@google.com> |
Fix expression evaluation problem
This CL fixes a bug in expression evaluator where we would
elevate a conditional dependency by mistake when it is not
read completely. This was caused by marking bit paths as
read in the same cycle.
There is still a potential bug in the code path where we
detect a variable would've already been calculated for a
dependency to be calculated (e.g. a ? a : b) but this
change is a fairly safe compared to making a big change
in that logic.
Bug: 895468
Change-Id: I60a704a59c3b5b8e4f833f060c6233d356dab6c8
/frameworks/data-binding/compiler/src/main/java/android/databinding/tool/expr/Expr.java
|
| bb4a033fcd5cd20e5be46ef8ead442dc7db2454d |
|
18-Feb-2016 |
George Mount <mount@google.com> |
Have two-way binding use localized variables to prevent NPE.
Bug 26962999
Two-way binding was using the inverted expressions directly
without localizing variables. That meant that if there was
a variable set to null during evaluation, it may get a
NullPointerException even though it checked for null
on the value previously. This CL localizes the variables
so that cannot happen.
Change-Id: Ia55955ce0f1cb750e6a678e72e0cda03f0e3c9b6
/frameworks/data-binding/compiler/src/main/java/android/databinding/tool/expr/Expr.java
|
| 6047998943beebd81e0ae1068df39c0cbee38628 |
|
02-Feb-2016 |
Yigit Boyar <yboyar@google.com> |
Lambda In da house
This CL adds support for assigning callbacks to listeners using lambda expressions.
These expressions can receive either 0 or N arguments where N is equal to the
number of parameters in the callback function.
These expressions are evaluated when the callback is invoked. In other words, they
are independent from the rest of the ExprModel except the Identifier expressions.
Since these are limited to 1 full expression and they don't have any invalidation
flags; we use a verbose branching code generation mode where we calculate all possible
execution paths, eliminate trivial ones and generate the code. This allows callbacks
to be thread safe as well. See ExecutionPath class for details.
It is not efficient but since these are rere occasions, should be OK.
Callback expressions are still forced to be expressions that return value. To handle
`void` case, I've added `void` and `Void` as acceptable symbols. Also, if the callback
method returns void, the expression is free to return `void` or any other value.
¯\\_(ツ)_/¯
I've also moved kotlin to rc0. Although rc0 is unrelated to this task, it made more
sense to upgrade here because most changes it will ask for were already done in
this branch.
Bug: 26849440
Change-Id: I805b3d470f85df9c2ce3f3ed5ca74925a08bb7a5
/frameworks/data-binding/compiler/src/main/java/android/databinding/tool/expr/Expr.java
|
| d3f2b9229472c9dae9bf4ae8b3e2d653b5653b01 |
|
17-Sep-2015 |
George Mount <mount@google.com> |
Two-way binding
Bug 1474349
Bug 22460238
This adds two-way data binding for those attributes
on Views that also have event listeners for them.
General use is also supported, but event listeners
are required to notify when those properties change.
Change-Id: Iedc66a604257930265f9d661f69658a0a0c3208b
/frameworks/data-binding/compiler/src/main/java/android/databinding/tool/expr/Expr.java
|
| 59229481aec5a284d322a2ca80dff836485feb0c |
|
30-Oct-2015 |
Yigit Boyar <yboyar@google.com> |
upgrade kotlin to 1.0-beta1
Change-Id: I62b77fd118e2715d272a16d96b9083d2347f5fb1
/frameworks/data-binding/compiler/src/main/java/android/databinding/tool/expr/Expr.java
|
| 9784c9aaedeb863018f5fcaa0a598e8e2f8ed2f3 |
|
13-Oct-2015 |
Yigit Boyar <yboyar@google.com> |
Data binding as studio dep + java6
This CL gets rid of the gradle plugin and instead provides
DataBindingBuilder for the gradle plugin to directly use.
Now, everything that is deployed via SDK Manager (lib and adapters)
are included as prebuilts so that we avoid accidently changing
them w/o an SDK manager release.
There is still work to do:
> re-enable proguard for externel dependencies
> release a batch to ensure everything works
Bug: 22516688
Change-Id: I83ace15bd6d3d23bf5b4ad850f36453dd23ebd43
/frameworks/data-binding/compiler/src/main/java/android/databinding/tool/expr/Expr.java
|
| 09aeb26073fc8a98263806f53e44819ebe5046c6 |
|
09-Oct-2015 |
Yigit Boyar <yboyar@google.com> |
Handle constant predicate in ternary
If a ternary expressions's predicate is constant, we would never evaluate it
which means we would never evaluate the ternary unless some other expression
depends on it.
This CL changes ExprModel to move such constant expressions into pending list
so that they can be evaluated + necessary flags are set.
We can actually avoid this process by replacing TernaryExpression with something
else when this case is detected but that would be a bigger change and not safe
shortly before the release.
Hopefully, codegen logic will be refactored into a more well defined process.
Bug: 24768154
Change-Id: I0918568414b64d64f070978f1f8e77cc3b6c85fd
/frameworks/data-binding/compiler/src/main/java/android/databinding/tool/expr/Expr.java
|
| eebcbdd5d35e56a2c8ef37feeb65df46130d001d |
|
26-Aug-2015 |
Yigit Boyar <yboyar@google.com> |
Fix the bug about marking expressions as read early
@{obj4.text}
@{obj4.useHello ? obj4.text : `hello`}
This case was broken and would not re-read obj4.text if
only obj4.useHello is invalidated. It was partially fixed in
Change-Id: Id449c8819b8dc0301a7ab893002478914780d480 but
but it was bringing it down to exact equality which would
mean we could fail to mark sth as read.
The coverage logic we use in expressions when marking them
as read was giving false positives, which results in
marking expressions as read before they are fully read.
This CL fixes that bug. The safe fix introduces some false
negatives when a conditional is behind another conditional.
We can address this post v1.
There was also another bug about setting conditional flags
even though the ternary does not need to be calculated.
@{obja.boolMethod(a)}
@{a ? objb.boolMethod(b) : objc.boolMethod(c)}
When obja is invalidated, it would re calculate the second
binding expression too even though it is never used (because
that expression is not invalidated). The re-calculation would
happen because we would calculate the value of `a` and set
the conditional flags w/o checking invalidation.
This would result in unnecessary calculations. I've also fixed
it for first degree where the ternary is not under another
ternary. The proper fix would requires bigger effort, post V1.
bug: 22957203
Change-Id: Ib73f31eac358f2ad7652395a021baaa93b79adf7
/frameworks/data-binding/compiler/src/main/java/android/databinding/tool/expr/Expr.java
|
| 793e979f25e190162eacf46d6a4efc3efc1d2f91 |
|
31-Jul-2015 |
George Mount <mount@google.com> |
Support different event handlers having different API levels.
Bug 22957226
Change-Id: Ia08bcb857872eccad3340c14b8d10b78198b90a6
/frameworks/data-binding/compiler/src/main/java/android/databinding/tool/expr/Expr.java
|
| e52882df6130221462bf07f5f2b52de5c4b0f8de |
|
30-Jul-2015 |
George Mount <mount@google.com> |
Move toCode to Expr classes.
It turns out that toCode as part of Java is just
about as readable as in kotlin and it makes much
more sense than using instanceof (equivalent).
Change-Id: Ic2a0de5c4376dafa487d048e6a9420fab9e7f22a
/frameworks/data-binding/compiler/src/main/java/android/databinding/tool/expr/Expr.java
|
| d615f15f0f0cc4c4de7570119d181e13d44e708a |
|
05-Aug-2015 |
George Mount <mount@google.com> |
Fixed: conditional expression not always waiting for its dependencies.
Bug 22957203
Some conditional expressions were not waiting for all of their
dependencies to be evaluated before evaluting the expression.
Change-Id: Id449c8819b8dc0301a7ab893002478914780d480
/frameworks/data-binding/compiler/src/main/java/android/databinding/tool/expr/Expr.java
|
| 731b74f7f44e67312a1fc4161c4e0aae221b2417 |
|
25-Jun-2015 |
Yigit Boyar <yboyar@google.com> |
Introduce Scopes to track logical stack traces
This CL introduces a static class called Scope, which is
used the logical processing stack for data binding.
These scopes are used to generate meaningful error messages
when an error is detected.
Bug: 21953001
Change-Id: I5470a8c4ad94401d34a140762baae9d53c5a0402
/frameworks/data-binding/compiler/src/main/java/android/databinding/tool/expr/Expr.java
|
| c1560e6b00b398867da12fbdc5a1fcd1d50b801c |
|
25-Jun-2015 |
Yigit Boyar <yboyar@google.com> |
Carry over location information from parser to annotation processor
This CL changes LayoutParser to use Antlr which provides us the location
information. This information is now serialized inside the bundle so
that we can read it in the annotation processor, enabling better error
logs with location information.
Bug:21953001
Change-Id: If9b5cf2f87598a609ddf77235decc17098a46a6b
/frameworks/data-binding/compiler/src/main/java/android/databinding/tool/expr/Expr.java
|
| 2611838bffef5a009ca71e3e9e59a93f29b098ed |
|
24-Jun-2015 |
Yigit Boyar <yboyar@google.com> |
Remove guava from compiler
This CL removes all dependency from guava and replaces it w/ either plain
java or some utilities.
Bug: 22047836
Change-Id: I94be54ed992ab6b5f27c47a8cf400ae60aef02f8
/frameworks/data-binding/compiler/src/main/java/android/databinding/tool/expr/Expr.java
|
| 716ba89e7f459f49ea85070d4710c1d79d715298 |
|
18-Jun-2015 |
George Mount <mount@google.com> |
Support calling listener methods without interfaces.
Bug 21594573
It is convenient to be able to assign event listeners by just
referencing a method, similar to the way onClick="handler" works.
This adds a whole lot of listeners for the framework. Additional
listeners must be added for support library components.
This isn't perfect in resolving listeners. Perfect resolution
requires that each expression is evaluated in its own context
within the binding statement. If, for example, the same method
name is used for a listener and an accessor, we will assume
that the listener is used always and there will be a compilation
failure.
Change-Id: If4705122b67a451430451b6e7d890eb813af1c5c
/frameworks/data-binding/compiler/src/main/java/android/databinding/tool/expr/Expr.java
|
| 7b07818f07c28c6dec34ca2a9ab5f61e86afb493 |
|
20-May-2015 |
Yigit Boyar <yboyar@google.com> |
Handle inter-expr dependencies properly
We had a bug where we would never be able to solve a case if there
are two expressions that trigger a circular dependency.
a ? b : c
b ? a : d
We actually had some logic to partially elevate conditional
dependencies but there were two issues with it:
* LayoutInflator was caching shouldReadFlags permanently
* There was a bug in how we resolve whether all potential evaluation
paths are covered. (we were not using a cloned bitset but rather
updating the original).
I've fixed these two issues and added logic to partially elevate
conditional expressions if they cannot be marked as fully read.
Bug: 21324645
Change-Id: I779afb6dae48920196404d3cfbb5f8774686404d
/frameworks/data-binding/compiler/src/main/java/android/databinding/tool/expr/Expr.java
|
| 8533f27db6c31b0c295ae62d314dbf07ea640571 |
|
19-May-2015 |
Yigit Boyar <yboyar@google.com> |
Properly handle constant binding expressions
Previously, we would assign each binding expression a flag id even
if it is constant. This was necessary to be able to implement
invalidateAll.
Later, we've changed how invalidateAll works and assigned it a separate
flag. Unfortunately, we were still incrementing ids for such binding
expressions, causing index out of bounds exceptions during code generation
in certain situations.
This CL fixes that bug and does not add flags to constant binding expressions
anymore.
Bug: 21284295
Change-Id: I114bf34520d0b246426ce7d45b8c511cf6709778
/frameworks/data-binding/compiler/src/main/java/android/databinding/tool/expr/Expr.java
|
| e9b33bac04bb1ce1444d7f1744fcec1ecd3a57da |
|
30-Apr-2015 |
Yigit Boyar <yboyar@google.com> |
Support multi-param adapters in code generation
Bug: 19800022
Change-Id: I40c4ac72f24f965db12fd1c7dec6591184160ae5
/frameworks/data-binding/compiler/src/main/java/android/databinding/tool/expr/Expr.java
|
| d1369ca2b7114fa456293695f3850e5be5e6d21e |
|
23-Apr-2015 |
Yigit Boyar <yboyar@google.com> |
Add placeholder flag for invalidate any
/frameworks/data-binding/compiler/src/main/java/android/databinding/tool/expr/Expr.java
|
| 019c36b97c7c172ac03997f6bf170e65b2ed7fe4 |
|
17-Apr-2015 |
Yigit Boyar <yboyar@google.com> |
Fix how final fields are handled
There was a bug in Expression analyzer where if a field is final,
it would return dynamic=false although its parent is dynamic.
This CL changes that behavior such that if the parent of a field
access is dynamic, then field access is dynamic unless it is
static & final.
If parent is not dynamic, (e.g. android.view.View) field is
dynamic if an only if itself is dynamic.
This CL also fixes another bug where if you have a bunch of
expressions none of which can be invalidated, there would not
be any flags to set thus we would not generate proper if statements.
We were resolving tree properly but code-generation never worked
in that situation. To overcome this issue, since there should always
be a way to invalidate all bindings, I've added a flag to invalidate
all, which is automatically included in each invalidate flag set.
This does not bring any serious cost because we have flag inheritance
in the generated code.
I've also removed some code from LayoutBinderWriter that may create
duplicate names. This was failing a test where a variable and View
were given the same names. I changed these name uniqueness to be
scope based so that we can create most readable w/o sacrificing
correctness.
Bug: 20341011
Change-Id: I0e98a5e28f250c36ae5de306f5ed99adffd20b59
/frameworks/data-binding/compiler/src/main/java/android/databinding/tool/expr/Expr.java
|
| 74f72d77b1db2b78ee6422da2ec94de12edcb6dc |
|
27-Mar-2015 |
Yigit Boyar <yboyar@google.com> |
Fix bugs related to how we handle Ternary ops
This CL fixes two bugs.
1) When a Ternary operation was inside another operation, we were
not handling dependecies properly and model would think that
the container expression can be evaluated before Ternary is evaluated,
eventually causing an exception in code-gen because Ternay is not
calculated yet.
2) This also fixes another bug where when ?? is used, we would put
ifTrue and ifFalse statements in wrong order and eventually evaluate
!??.
Bug: 19939148
Change-Id: I3e1d2bee172e47412bb8ef9e7c785aef47337155
/frameworks/data-binding/compiler/src/main/java/android/databinding/tool/expr/Expr.java
|
| fead9ca09b117136b35bc5bf137340a754f9eddd |
|
23-Mar-2015 |
George Mount <mount@google.com> |
Move to package android.databinding.
/frameworks/data-binding/compiler/src/main/java/android/databinding/tool/expr/Expr.java
|