IssueTracker

Yigit, I suspect you know quicker than I do what to dupe this bug against. (This seems related to all the generic fixes made recently to data binding).

Note, relevant code is (I believe) the state value referenced in the view model:

class MainViewModel : ViewModel() {
    private val _state = MutableLiveData<UiState<Boolean>>()
    val state: LiveData<UiState<Boolean>>
        get() = _state

If I pass the state value as a separate variable (in XML layout) an adjust the references or use a non-generic type then it generates code that compiles (with AGP > 3.5.0). Looking at what was generated in the failing case for executeBindings (LoadingStateBindingImpl.java)

// 3.5.0
 com.example.dbigle.ui.main.UiState state = mState;
// 3.6.1
 com.example.dbigle.ui.main.UiState<?> state = mState;

But perhaps more interesting is that the references to state are missing in BR.java and DataBinderMapperImpl.java

I don't think this is a duplicate of 152781831, I tried renaming according to your suggestion, it did not work. I think the error message is the same purely down to the non-specificity of data binding errors.

I have a similar issue. It looks the change actually happened in 3.5.1 and the databinding compiler tries to generate code with generic wildcards instead of removing generics and the generated type doesn't match up with the Kotlin interop type.

In my case, 3.5.0, for example, generated a value Function2 but 3.5.1 tries to generate Function2<String, Result<? extends ?, ? extends Exception>, Data>, which fails. If I use @JvmSupressWildcards on the Result<@JvmSuppressWildcards T, Exception> type, the generated code changes to Result<?, ? extends Exception> which seems correct, but then it doesn't match up with the value accessed later in the Impl file.

The error then is at viewModelValue = viewModel.getValue() and the Kotlin type from getValue() resolves to Result<? extends capture of ?, ? extends Exception> instead of Result<?, ? extends Exception>.

So it looks like either generics should be erased, or the types resolved by Kotlin interop will need to be fixed.

can you share the layout file? we had to make some backwards incompatible changes to ensure we keep types longer. you may just need to define the generic types in the XML

Hi YB (comment #9), whose comment are you referencing? If mine then the layout is part of the GitHub project I linked in the initial post. I'm keen to see your proposed solution. What I had to do in the mean time to get it to work is to declare state as a separate variable in the layout.

sorry my bad. i'm looking into it.

So what is happening here is that the imported layout does not declare a type for state so it gets resolved as UIState<T> (T is unresolved type variable).

Then when we try to check if viewModel.state can be set to it, we call to java processing's isAssignable API with:

https://docs.oracle.com/javase/7/docs/api/javax/lang/model/util/Types.html#isAssignable(javax.lang.model.type.TypeMirror,%20javax.lang.model.type.TypeMirror)

Can UIState<Boolean> be assigned to UIState<T> which returns false.

Previously we used to drop type args to be more flexible (we would drop Boolean ) which caused other issues.

It is unfortunate not to be able to reply on javax.model API for assignability but i think a possible "proper" fix is to manaully implement assignability where undefined type variables are ignored.

Another quick hack would be to accept erasure assignability albeit with a lower score of confidence such that we'll accept it if there is no better match, which won't break exact match cases but might cause some false positive cases.

also TIL, java is completely happy with these :(

List l;
List<String> stringList = new ArrayList<String>();
l = stringList;
l.add(3);
System.out.println("all cool" + Arrays.toString(stringList.toArray()));

also fine with this:

List l = new ArrayList();
List<String> stringList = new ArrayList<String>();
stringList = l;

i merged a fix where we'll accept assigning List<T> to List but not List to List<T>.

Even though it is inconsistent w/ java, accepting List for List<T> has too many complications.

It should be released in 4.2-canary-8

Is there an ETA on the 4.2-canary-8?

Comment #15, it seems to be out now.

Yup, thanks.