IssueTracker

Which version of R8 are you using?

In order to diagnose this we would probably need to be able to reproduce this issue.

Would it be possible for you to share a compiler dump file that contains the inputs to R8 (i.e., the Java class files and the keep rules going into R8)? That way we should be able to reproduce the build. You can generate this as below and could share this privately with christofferqa@google.com and sgjesse@google.com.

./gradlew assembleRelease --no-daemon -Dcom.android.tools.r8.dumpinputtodirectory=/path/to/dumps

Do you know if the class ViewEventSinkImpl is instantiated using reflection? If so, do you know if there is a corresponding keep rule for the class?

Can you try if the following rule "fixes" the issue:

-keep,allowobfuscation,allowshrinking class org.chromium.content.browser.ViewEventSinkImpl

When this rule is present, R8 should account for the fact that ViewEventSinkImpl may be instantiated by reflection, which I suspect may fix the issue you are seeing.

Hi! I have also encountered a problem with r8 in --classfile mode incorrectly removing a null check, and curiously enough it also happened in and around ViewEventSinkImpl. I tried with the R8 version in Chromium and also with latest main branch local build from the repo which was be29229a110ce06989f6f3a63b0a83015ed3fefe.

The issue I'm seeing is from code which effectively does

public final class ViewEventSinkImpl ... {
    private @Nullable Boolean mHasViewFocus;  // not written to anywhere else

    public void onViewFocusChanged(boolean gainFocus) {
        if (mHasViewFocus != null && mHasViewFocus == gainFocus) return;
        mHasViewFocus = gainFocus;
        ....
    }
}

and after r8 with --classfile, the null check gets removed and the code is guaranteed to crash. Without --classfile, the null check remains in the dex. Note: for me, the code (with or without the check) was inlined at the only callsite to onViewFocusChanged.

Adding

-keep,allowobfuscation,allowshrinking class org.chromium.content.browser.ViewEventSinkImpl

works around the issue for me. I believe there is some reflection going on as one part of the code that affects that bug is the presence of

    public static ViewEventSinkImpl from(WebContents webContents) {
        ViewEventSinkImpl ret =
                ((WebContentsImpl) webContents)
                        .getOrSetUserData(
                                ViewEventSinkImpl.class, UserDataFactoryLazyHolder.INSTANCE);
        return ret;
    }

I hope the advice to send the repro case directly is still valid, I should have it down to a manageable size soon.

Thanks, it would be great if you would be able to share a reproduction for this.

I have sent the repro over by email. Can you confirm if the mail has gotten thru spam filters, etc.?

Project: r8
Branch: main
Author: Christoffer Adamsen <christofferqa@google.com>
Link:      https://r8-review.googlesource.com/102400

Reproduce inadequate value propagation in presence of T::new expressions

Reproduce inadequate value propagation in presence of T::new expressions 
 
Bug: b/397737234 
Change-Id: Ia6cbb0ef3366125420afbdfcf3a8f0d228cc2004

Project: r8
Branch: main
Author: Christoffer Adamsen <christofferqa@google.com>
Link:      https://r8-review.googlesource.com/102421

Account for T::new expressions in default field value joiner

Account for T::new expressions in default field value joiner 
 
Bug: b/397737234 
Change-Id: Iea344f54fa5a8ac40739a51da5d7e6679d5964b8