• Home
  • History
  • Annotate
  • only in /frameworks/data-binding/compiler/src/main/java/android/databinding/tool/expr/
History log of /frameworks/data-binding/compiler/src/main/java/android/databinding/tool/expr/
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
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
racketExpr.java
xpr.java
ieldAccessExpr.java
roupExpr.java
dentifierExpr.java
ethodCallExpr.java
naryExpr.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
xpr.java
xprModel.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
itShiftExpr.java
racketExpr.java
astExpr.java
omparisonExpr.java
xpr.java
xprModel.java
ieldAccessExpr.java
dentifierExpr.java
nstanceOfExpr.java
athExpr.java
ethodCallExpr.java
esourceExpr.java
ymbolExpr.java
ernaryExpr.java
naryExpr.java
0c2ed0cbaee2f206e926bfc780b05e9f1e52b551 24-Jun-2015 Yigit Boyar <yboyar@google.com> Remove guava dependency from the plugin

This CL is the first step in getting rid of guava dependency.
It removes guava from compilerCommon which in return removes
the dependency for the gradle plugin.

This CL also fixes compiler tests which were broken by the
listener CL.

Bug: 22047836
Change-Id: I43f87885c5291174f5bc694487fc6c075b480194
xprModel.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
xpr.java
xprModel.java
ieldAccessExpr.java
ec2f3896c21a504b464bf591cdb45b62692b6760 10-Jun-2015 Yigit Boyar <yboyar@google.com> Improve static method / field handling

Previously, we would allow access to static fields via instance
variables but it would not work for methods. Moreover, the behavior
was not exactly the same with how java handles it. In java, the
instance can be null but our binding code would not evaluate it
if instance is null.

This CL fixes these bugs by adding static resolution support to
methods and replacing their variable identifiers with static
identifiers while the method is being resolved so that the rest
of the system is still consistent.

Bug: 20412284
Change-Id: Id97ce564c312b97d5a0e60d7d7a5bbd06b131071
xprModel.java
ieldAccessExpr.java
ethodCallExpr.java
c4a07bddb4dd5c3bfbecf4d87909c5b447ae56dc 05-Jun-2015 George Mount <mount@google.com> Only create case statements for Bindable attributes.

Bug: 21571818
Change-Id: Id03c7a7de6e39d7f59da6cda11d3311f072addd0
ieldAccessExpr.java
24ff3c01534a5e4dc9f65796009debe7fd87c1be 20-May-2015 Yigit Boyar <yboyar@google.com> Merge "Handle inter-expr dependencies properly"
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
xpr.java
xprModel.java
ersionProvider.java
c96847768305d83c6bc4919432af9bd9bfe4c08e 20-May-2015 George Mount <mount@google.com> Fix String.format expression.

An expression @{String.format("%s", "test")} was failing
for two reasons: the L.d was doing string concatenation
and String wasn't imported and considered a StaticIdentifier.

Change-Id: I67b4c880f1e147a5c1aac15b3b845d4112c6d00b
xprModel.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
xpr.java
xprModel.java
e9b33bac04bb1ce1444d7f1744fcec1ecd3a57da 30-Apr-2015 Yigit Boyar <yboyar@google.com> Support multi-param adapters in code generation

Bug: 19800022

Change-Id: I40c4ac72f24f965db12fd1c7dec6591184160ae5
rgListExpr.java
xpr.java
xprModel.java
ieldAccessExpr.java
d1369ca2b7114fa456293695f3850e5be5e6d21e 23-Apr-2015 Yigit Boyar <yboyar@google.com> Add placeholder flag for invalidate any
xpr.java
xprModel.java
658c71b9ba3211ac5c10f261a8c6f38b1916d3bf 22-Apr-2015 Yigit Boyar <yboyar@google.com> Fix invalidate any flag.

This CL also adds a new build target to move folders to an EAP folder that
can be shipped to early access partners.
I've also changed the demo to use android emojis
xprModel.java
11e3c78221d957e86be098255ccd0f8f28280cff 20-Apr-2015 George Mount <mount@google.com> Merge changes If9ddfd09,I310535e6

* changes:
Support array length.
Added some missing expressions.
c6bcb7bf9cab139b3141c4644e5b3267deed5213 20-Apr-2015 George Mount <mount@google.com> Added some missing expressions.

unary: +/-/~/!
shift: >>/>>>/<<
logical: &&/||
bit: &/|/^
instanceof

Change-Id: I310535e67c8fda2f067a62079e1b609a11bda741
itShiftExpr.java
xprModel.java
nstanceOfExpr.java
naryExpr.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
xpr.java
xprModel.java
ieldAccessExpr.java
ethodCallExpr.java
96e1c821dd446d1ed78f8ae61131550588f60a24 10-Apr-2015 George Mount <mount@google.com> Support merge tags.

This also drops the requirement for include tags to have an ID.

Each root view tag is given a numeric suffix, starting with 0.
Merge tags can have multiple roots, the first of which always
is suffixed with 0. The remainder have tag identifiers that
are interspersed with the tags used with expressions. The
numeric suffix is used to identify the View in the mapBindings
call.

Include tag information now uses the tag of its parent so that
its parent will search for the includes within it. When
mapBindings is looking at the parent, it looks for all direct
children with the appropriate tag of the format "layout*/name_0".
Then it searches for all siblings with the same prefix and different
numeric suffixes. Any that are found are considered part of the
same merged include. If it finds another with _0, it knows that
a new include was found.

Change-Id: Idd1144d9037648193724667320744bd079791476
ymbolExpr.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
xpr.java
xprModel.java
fead9ca09b117136b35bc5bf137340a754f9eddd 23-Mar-2015 George Mount <mount@google.com> Move to package android.databinding.
racketExpr.java
astExpr.java
omparisonExpr.java
ependency.java
xpr.java
xprModel.java
ieldAccessExpr.java
roupExpr.java
dentifierExpr.java
athExpr.java
ethodCallExpr.java
esourceExpr.java
taticIdentifierExpr.java
ymbolExpr.java
ernaryExpr.java