Welcome to lint-dev

[Tor Norbye]

This group will hopefully make it easier to get questions answered about how to write custom lint checks, improve lint itself, or make feature suggestions. 

In the past this information was spread in a number of places -- Google+ comment threads, twitter replies, and so on. My hope is that this group will make it easier to get questions answered and make the information more easily searchable.

[Lin Wang]

Thanks Tor!

Moved my question here now:

Recently I have been developing custom lint rules and one challenge I am facing is to set up the unit tests for the lint rules I am writing especially for JavaScanner and ClassScanner.

Basically I extend LintDetectorTest and use lintFiles() by providing the relative path of the file I want the test to pick up. I trace into the system and realized that the LintDriver can find my file (a class file for example), tracing down to the checkIndividualClassFiles() method in LintDriver class and because the project.getJavaClassFolders() always gives me an empty list, then my file couldn't be picked up in the following if block.

I am not sure if there are some real examples for lint rule unit tests and not sure if this could be solved by providing a better TestConfiguration. Please advice how to proceed because having the unit tests set up for lint rules will speed up development significantly and ensure the lint rule quality itself.

[Tor Norbye]

In the "old" days, lint unit tests would check in test source files as files, and then the lint unit test infrastructure would try to find them relative to the detector class.

That worked well for all the builtin checks, but it was not working well for third party lint checks.

There's a better way to do this now, and in the 2.2 timeframe I migrated *all* lint unit tests to the new scheme.

With the new scheme, you basically "inline" all the test sources right there in the unit test.

Basically, you construct your project by passing in a bunch of source file descriptions.

In the very general sense, you can just call the method 

   source(String path, String contents)

which lets you place arbitrary text in an arbitrary location.

But there are a lot of dedicated methods for constructing certain types of source files.

For example:

* You can create an XML file by calling xml(String path, String contents) and because the system now knows this is an XML file, when you look at your test in IntelliJ the contents (the second parameter) is syntax highlighted, and semantically checked, as XML:

Notice how the text code here is highlighted as XML so you can instantly see if there's a problem.

Notice also the line above the xml() call -- there's a "manifest()" method. That one not only lets you pass in a specific manifest file; there are also DSL methods to quickly configure default manifest files with various attributes, such as one with a given minSdkVersion as shown here.

There's also a DSL for constructing Java files -- and you normally don't have to type in the path to where the Java source file should be, since it's implied by the package statement and the class name:

So, the basic approach is to just inline your source files right into the test. It keeps all the data together, which makes it easier to see what's going on in your test anyway.

Second, note that in version 2.3 (of Studio, Gradle, etc) there is a brand new lint test DSL. This has a number of advantages:

(1) You don't have to extend AbstractCheckTest -- so you can now write your tests as JUnit4 instead of JUnit3.

(2) There is a new DSL which lets you configure a lot of stuff for each test -- so you no longer need to override method for the whole test case (which then affected all the tests).

    For example, you can configure, for each test, which specific issues to check (if your detector detects more than one issue), you can decide whether you'll allow compilation errors,

   you can override the SDK home location, etc, etc.

(3) There's a fluent API so it's easier to write the test. Basically you create a lint test context, then on that one configure your project's files (and it's much easier to create multi-project tests too), you configure the tests, and then you run the tests, and then you get to assert things about the test result.

(4) There's also support for mocking the Gradle model now, so it's much easier to write tests for detectors which are operating on builder model objects.

Here are some sample tests from the 2.3 unit tests:

    public void testNoGroupWarningWithPlugin15() throws Exception {

        lint().files(

                manifest().minSdk(14),

                xml("res/drawable/foo.xml", ""

                        + "<vector xmlns:android=\"http://schemas.android.com/apk/res/android\"\n"

                        + "        android:height=\"76dp\"\n"

                        + "        android:width=\"76dp\"\n"

                        + "        android:viewportHeight=\"48\"\n"

                        + "        android:viewportWidth=\"48\">\n"

                        + "\n"

                        + "    <group />"

                        + "\n"

                        + "</vector>"

                        + ""),

                gradle(""

                        + "buildscript {\n"

                        + "    dependencies {\n"

                        + "        classpath 'com.android.tools.build:gradle:1.5.0-alpha1'\n"

                        + "    }\n"

                        + "}\n"))

                .run()

                .expectClean();

    }

...

    public void testPlayServiceConsistencyNonIncremental() throws Exception {

        String expected = ""

                + "build.gradle: Error: All com.google.android.gms libraries must use the exact same version specification (mixing versions can lead to runtime crashes). Found versions 7.5.0, 7.3.0. Examples include com.google.android.gms:play-services-wearable:7.5.0 and com.google.android.gms:play-services-location:7.3.0 [GradleCompatible]\n"

                + "1 errors, 0 warnings\n";

        lint().files(

                gradle(""

                        + "apply plugin: 'android'\n"

                        + "\n"

                        + "dependencies {\n"

                        + "    compile 'com.google.android.gms:play-services-wearable:7.5.0'\n"

                        + "    compile 'com.google.android.gms:play-services-location:7.3.0'\n"

                        + "}\n"))

                .issues(COMPATIBILITY)

                .sdkHome(getMockSupportLibraryInstallation())

                .run()

                .expect(expected);

    }

Let me know if you have any questions.

[Lin Wang]

Thanks a lot Tor, this is really helpful!!!

One additional question I have is how to pass in a class file for the ClassScanner in the same fashion? Will those inline java files get compiled into class files when we run the tests? 

[Tor Norbye]

On Wednesday, February 22, 2017 at 3:40:33 PM UTC-8, Lin Wang wrote:

One additional question I have is how to pass in a class file for the ClassScanner in the same fashion? Will those inline java files get compiled into class files when we run the tests? 

No, there's no automatic compilation during test runs, though that's a reasonable enhancement request.

You can pack arbitrary binary data into files using the "base64gzip" test file method. That one takes a string which represents the base64 encoded version of a binary file that has also been gzip'ed.

Here's how a test like this looks:

 

Now you may wonder how I generated that string to begin with. There are builtin methods for this too.

What I typically do is this. Let's say I happen to have stored the .class file I want to use in this path: /tmp/MyClass.class.

I then add an assertion like this to the unit test as the first line:

        assertEquals("", toBase64gzip(new File("/tmp/MyClass.class")));

The "toBase64gzip" method here will generate the base64 string of the gzipped contents of the bytes found in the given file and return it. The test will obviously fail -- but then I click on IntelliJ's output which shows the diff -- and I copy the actual value. That will be the string which I copy into the second parameter above -- the actual base64gzip call which returns a test file. Then I delete this assertion. Obviously you can use a different workflow to get the string out of the file but the toBase64gzip method should be helpful.

-- Tor

[Lin Wang]

I didn't happen to find this base64gzip() function, which leads me to wonder if I am using the latest APIs. I tried to search for latest versions of the lint APIs but didn't find. I am sharing my gradle file here, could you please take a look? Thanks!

dependencies {
    compile 'com.android.tools.lint:lint-api:24.3.1'
    compile 'com.android.tools.lint:lint-checks:24.3.1'
    testCompile 'junit:junit:4.11'
    testCompile 'com.android.tools.lint:lint:24.3.1'
    testCompile 'com.android.tools.lint:lint-tests:24.3.1'
    testCompile 'com.android.tools:testutils:24.3.1'
}

jar {
    manifest {
        attributes("Lint-Registry": "com.pinterest.lint.PinterestIssueRegistry")
    }
}

[Tor Norbye]

The current dev version of lint is 2.3.0-rc1 (Studio, Gradle). The actual maven artifact version number for these libraries is 25.3.0-rc1 (for historical reasons, the tools/base libraries = gradle version + 23.0.0.)   If you want to only use 2.2 (since 2.3 hasn't quite been released yet) use 25.2.0 -- but for the new DSL stuff you'll need 25.3.

--
You received this message because you are subscribed to the Google Groups "lint-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lint-dev+u...@googlegroups.com.
To post to this group, send email to lint...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lint-dev/1baf13a1-e613-49bd-8275-12412865aa00%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tor Norbye]

Btw I recommend 2.3.0-rc1 over 2.2.0 at this point; the remaining bugs in 2.3 aren't lint related, and there were a *large* number of bug fixes in lint 2.3 (along with several new features such as the new HTML Reports, lint baseline support, etc.)

[Lin Wang]

Currently still on AS 2.2.1 and will try out 2.3.0-rc1, it might take time for the entire team to migrate to the new AS version since traditionally we struggle with some 3rd party libraries' compatibility issues including kotlin.

I will give "25.2.0 for lint and 2.2.1 for AS" a stub.

[Lin Wang]

Got the 25.2.0 from mavenCentral() eventually and saw the base64() method.

Now that with this short test, I am expecting some error messages but didn't get any. Dive deeper into it and realized the BrioXmlDetector's visitElement() doesn't get invoked either. Sharing this test here, any advices?

public class XmlDetectorTest extends LintDetectorTest {
    @Override
    protected Detector getDetector() {
        return new BrioXmlDetector();
    }

    @Override
    protected List<Issue> getIssues() {
        List<Issue> issuesList = new ArrayList<Issue>();
        issuesList.add(BrioXmlDetector.ISSUE_SYNTAX);
        issuesList.add(BrioXmlDetector.ISSUE_UNIQUE);
        issuesList.add(BrioXmlDetector.ISSUE_STR_REF);
        return issuesList;
    }

    public void testTest() throws Exception {
        String msg = lintProject(manifest().minSdk(10), xml("res/layout/sample.xml", ""
                + "<TextView xmlns:android=\"http://schemas.android.com/apk/res/android\">\n"
                + "    brio:layout_width=\"hello\"\n"
                + "    brio:layout_marginTop=\"4bt\">\n"
                + "</TextView>\n")
        );
        System.out.print("test msg : " + msg);
    }
}

[Tor Norbye]

Not sure -- hard to say more without seeing your detector implementation. Make sure that the implementation scope includes RESOURCE_SCOPE. And check the getApplicableElements()  method to make sure that it returns the elements you're interested in, or ALL, not null.

[Lin Wang]

ok, It worked and my detector has been picked up and I see expected error messages eventually!!! it was due to an extra ">" in my xml file which returned early in my detector logic and somehow I also put the break point in a wrong place.

I am all set for xml detector now, trying java and class detectors .... Thanks a lot, Tor!!!

[Tor Norbye]

Yes, turns out XML is pretty flexible and that extra > still makes a valid XML document (your "attributes" on the next line are now just treated as text).

But I'm surprised you're not getting full XML syntax highlighting the way I see it in my tests -- see my earlier screenshot where tags are yellow etc.

Maybe you need to add this dependency explicitly:

  compile 'com.intellij:annotations:12.0'

?

On Thu, Feb 23, 2017 at 4:38 PM 'Lin Wang' via lint-dev <lint...@googlegroups.com> wrote:

ok, It worked and my detector has been picked up and I see expected error messages eventually!!! it was due to an extra ">" in my xml file which returned early in my detector logic and somehow I also put the break point in a wrong place.

I am all set for xml detector now, trying java and class detectors .... Thanks a lot, Tor!!!

--

You received this message because you are subscribed to the Google Groups "lint-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lint-dev+u...@googlegroups.com.
To post to this group, send email to lint...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lint-dev/44f9c916-2675-4524-9ddb-7270a91b1198%40googlegroups.com.

[Lin Wang]

Yeah, the flexible xml part makes sense.

Actually I do see xml syntax, in my earlier email I think it's just because I copy-paste the text directly from AS and the highlight is not carried over. If I just paste the image, it will show. In this group chat interface, it requires more steps to paste an image, so I did the text copy earlier. It would be more convenient to support copy-paste image directly by short-cuts here, just like in gmail.

Test Copy

public void testXml() throws Exception {

    lintProject(manifest().minSdk(10),
            xml("res/layout/sample.xml", ""
                    + "<TextView xmlns:android=\"http://schemas.android.com/apk/res/android\"\n"
                    + "    brio:layout_width=\"hello\"\n"
                    + "    brio:layout_marginTop=\"4bt\">\n"
                    + "</TextView>\n"));
}

Image Capture:

[Lin Wang]

Now that the Java file scanner unit test works for me as well, had to implement the JavaPsiScanner since the JavaScanner is deprecated. Also worth to note is that the source file folder has an assumption about its top level folder, which has to be "src/", otherwise the detector wouldn't be picked up, although the detector scope is set to JAVA_FILE_SCOPE. Not sure if that's a real assumption in 25.2.0 or I missed something.

Also found it's so cool that I can put multiple files and they will all get compiled and I even got compilation errors if there are.

public class TestJavaDetector extends Detector implements Detector.JavaPsiScanner {
    private static final String IS_ADDED_METHOD = "isAdded";

    public static final Issue ISSUE_IS_ADDED = Issue.create(
            "UnsupportedMethodInFragment",
            "Fragment contains unsupported method calls",
            "Fragment should not call isAdded()",
            Category.CORRECTNESS, 6, Severity.ERROR,
            new Implementation(TestJavaDetector.class, Scope.JAVA_FILE_SCOPE));

    public TestJavaDetector() {
    }

    // ---- Implements JavaPsiScanner ----

    @Override
    public List<String> getApplicableMethodNames() {
        return Arrays.asList(IS_ADDED_METHOD);
    }

    @Override
    public void visitMethod(
            @NonNull JavaContext context,
            @Nullable JavaElementVisitor visitor,
            @NonNull PsiMethodCallExpression call,
            @NonNull PsiMethod method) {
        context.report(ISSUE_IS_ADDED, method, context.getLocation(method), "report error");
    }
}

public void testJava() throws Exception {
    String msg = lintProject(manifest().minSdk(10),
            java("src/test/java/test/pkg/RequestParams.java", ""
                    + "package test.pkg;\n"
                    + "public interface RequestParams {}\n"),
            java("src/test/java/test/pkg/SampleRequestParams.java", ""
                    + "package test.pkg;\n"
                    + "\n"
                    + "public class SampleRequestParams implements RequestParams {\n"
                    + "    public SampleRequestParams() {\n"
                    + "        isAdded();"
                    + "    }\n"
                    + "\n"
                    + "    public int hashCode() {\n"
                    + "        return 1;\n"
                    + "    }\n"

                    + "\n"
                    + "    public void isAdded() {}\n"
                    + "}\n"));

    System.out.print("test msg : " + msg);
}

test msg : src/test/java/test/pkg/SampleRequestParams.java:10: Error: report error [UnsupportedMethodInFragment]
      public void isAdded() {}
      ~~~~~~~~~~~~~~~~~~~~~~~~
1 errors, 0 warnings

Process finished with exit code 0

[Tor Norbye]

Yes, for default projects it will default to adding "src" as the Java source folder, "res" as the resource folder etc.

But note that for Java test files you don't need to specify the source file. Just do something like

                        java(""

                            + "package test.pkg;\n"

                            + "public class GravityTest extends Activity {\n"

                            + ...

There are two versions of the java() call -- one where you specify the path (this is the one you used), and one where it infers it based on (a) where the java source folder is, (b) the package statement in the class and (c) the class name.  

This is particularly useful if you create a Gradle project, since in that case the source folder won't be src/, it will be src/main/java/ (and src/main/res for resources). (How do you make it a Gradle project you ask? By adding a gradle() source file as well.)

--

You received this message because you are subscribed to the Google Groups "lint-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lint-dev+u...@googlegroups.com.
To post to this group, send email to lint...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lint-dev/98bb6315-9586-494e-a8ee-9d8fe85adeec%40googlegroups.com.

[Tor Norbye]

And actually, re: the JavaScanner vs JavaPsiScanner comment -- there are some more changes coming in that area. But I'm going to start a new topic for that discussion -- this whole thread is hidden behind "Welcome to lint-dev" in the web interface on the group...

[Lin Wang]

Cool, thanks, using the java() method without a path fits the need for me.

Now I am trying to make my class detector work, tried a few things and still couldn't let the system pick up my class detector.

public class SimpleClassDetector extends Detector implements Detector.ClassScanner {

    public static final Issue ISSUE_SIMPLE_CLASS_CHECK = Issue.create(
            "SimpleIssueClassCheck",
            "A sample issue for class check",
            "This class has errors",
            Category.CORRECTNESS,
            6,
            Severity.ERROR,
            new Implementation(SimpleClassDetector.class, Scope.CLASS_FILE_SCOPE));

    @Override
    public void checkClass(@NonNull ClassContext context, @NonNull ClassNode classNode) {
        context.report(ISSUE_SIMPLE_CLASS_CHECK, context.getLocation(classNode), "report error");
    }
}

public void testClass() throws Exception {
    final String msg = lintProject(manifest().minSdk(10),
            base64("classes/RequestParams.class",
                    "yv66vgAAADQABwcABQcABgEAClNvdXJjZUZpbGUBABJSZXF1ZXN0UGFyYW1z"
                    + "LmphdmEBAA1SZXF1ZXN0UGFyYW1zAQAQamF2YS9sYW5nL09iamVjdAYBAAEA"
                    + "AgAAAAAAAAABAAMAAAACAAQ="),
            base64("classes/SampleRequestParams.class",
                    "yv66vgAAADQAEQoAAwANBwAOBwAPBwAQAQAGPGluaXQ+AQADKClWAQAEQ29k"
                    + "ZQEAD0xpbmVOdW1iZXJUYWJsZQEACGhhc2hDb2RlAQADKClJAQAKU291cmNl"
                    + "RmlsZQEAGFNhbXBsZVJlcXVlc3RQYXJhbXMuamF2YQwABQAGAQATU2FtcGxl"
                    + "UmVxdWVzdFBhcmFtcwEAEGphdmEvbGFuZy9PYmplY3QBAA1SZXF1ZXN0UGFy"
                    + "YW1zACEAAgADAAEABAAAAAIAAQAFAAYAAQAHAAAAHQABAAEAAAAFKrcAAbEA"
                    + "AAABAAgAAAAGAAEAAAABAAEACQAKAAEABwAAABoAAQABAAAAAgSsAAAAAQAI"
                    + "AAAABgABAAAAAwABAAsAAAACAAw="));

[Tor Norbye]

"classes" isn't on the classpath by default.

If you add a classpath() test file, that will add a project file registration which points to bin/classes/ where .class files are normally found.

(Note by the way that bytecode based checks aren't run on the fly inside the IDE and have various other disadvantages, so I've ported nearly all of the built in lint checks that once used to be implemented as bytecode based checks over to be AST based checks.)

Also, note that there are both base64 and base64gzip methods (and construction methods toBase64 and toBase64gzip methods). The gzip versions create more compact binary versions, which is particularly important when you create larger test files (for example for whole .jar files). (Note that there's also a jar() file test file construction syntax which lets you make .jar files on the fly, from nested descriptions of other test files including base64 :-) 

-- Tor

To view this discussion on the web visit https://groups.google.com/d/msgid/lint-dev/e4c74a31-686e-41b3-8433-dff57f5afa2a%40googlegroups.com.

[Lin Wang]

Ok, I will move towards AST test.

By AST test, I think you refer to JavaPsiScanner and I need to override getApplicableReferenceNames() to provide a list of full qualified class names, and implement the checkClass() method to inspect the class.

And the base64gzip() method is not in the 25.2.0 version yet, but I might not need it anymore since I am moving to use AST tests.

Thanks,

Lin

[Tor Norbye]

Yes -- take a look at the javadoc for JavaPsiScanner; it should give a lot of useful tips. And be aware of the JavaEvaluator class -- which is basically a utility class with lots of handy helpers, e.g. if you have a PsiMethod you can ask the evaluator if this method is a member of a class which is extends a given class/interface, and so on.

P.S. I posted a different thread called "UAST" where I describe the fact that in 2.4 the AST API will change. So fair warning -- if you rewrite your check now you'll need to do it again at some point (I'll keep PSI compatibility for a while, just like I kept Lombok compatibility), but on the other hand, the jump from bytecode to AST analysis is a big jump -- the jump from PSI to UAST should be pretty straightforward. I've already ported all the builtin checks.

-- Tor

To view this discussion on the web visit https://groups.google.com/d/msgid/lint-dev/ae090189-188e-4f67-a5a0-00730dbe7ed6%40googlegroups.com.

[Lin Wang]

Finally had it work and thanks for all the suggestions. Btw, are the builtin checks open source? It would be great to study some as examples.

Thanks,
Lin

To unsubscribe from this group and stop receiving emails from it, send an email to lint-dev+unsubscribe@googlegroups.com.

[Tor Norbye]

Yeah they're all open source (http://tools.android.com/build/ - the source code is in tools/base/lint/.) However, the current source drop is based on 2.2; as soon as 2.3 is done we'll push the 2.3 source code to AOSP.

I have however uploaded some big CLs to AOSP for the ongoing UAST work to share with JetBrains which also includes a CL which brings the AOSP lint code up to 2.3 (well 2.4 master as of a few weeks ago actually). It's not final - but it gives you access to all the 2.3 conventions. I haven't ported all the tests over to the new scheme yet but all new tests are written that way and I plan to go back and retrofit them all.

https://android-review.googlesource.com/#/q/topic:lint-uast

This is the CL which replaces the 2.2 version of lint with the 2.3 version:

https://android-review.googlesource.com/#/c/318070/

As you can see it deletes all the data files and switches exclusively to the embedded-source-within-test format. What it doesn't do globally yet is switch to the new lint test driver (lint().).

To view this discussion on the web visit https://groups.google.com/d/msgid/lint-dev/ae090189-188e-4f67-a5a0-00730dbe7ed6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "lint-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lint-dev+u...@googlegroups.com.
To post to this group, send email to lint...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lint-dev/CAB5eP36y1EwRY%2B1bswd2eMLRD9rj%2BR-VBc5434ojbvGu5XxSHw%40mail.gmail.com.

[Lin Wang]

Hi Tor,

Found a new problem here, while everything works well on my machine, when my co-worker tries to run one test case and she encountered a test case compilation error like this:

junit.framework.AssertionFailedError: Found compilation problems in lint test not overriding allowCompilationErrors():

SampleRequestParams.java:Error: 4: Implicit super constructor Object() is undefined. Must explicitly invoke another constructor

RequestParams.java:Error: 1: The type java.lang.Object cannot be resolved. It is indirectly referenced from required .class files

The test case and detector are the following:

public void testJavaClass() throws Exception {
    String errorMsg = lintProjectWithDefaultManifest(

            java(""
                    + "package test.pkg;\n"

                    + "public interface RequestParams {}\n"),
            java(""

                    + "package test.pkg;\n"
                    + "\n"
                    + "public class SampleRequestParams implements RequestParams {\n"
                    + "    public SampleRequestParams() {\n"

                    + "    }\n"
                    + "\n"
                    + "    public int hashCode() {\n"
                    + "        return 1;\n"
                    + "    }\n"

                    + "}\n"));

    Assert.assertEquals(errorMsg, ""
            + "src/test/pkg/SampleRequestParams.java:3: Error: sample error "
            + "[IssueDummyClassCheck]\n"

            + "public class SampleRequestParams implements RequestParams {\n"

            + "^\n"
            + "1 errors, 0 warnings\n");
}

public class DummyJavaClassDetector extends Detector implements Detector.JavaPsiScanner {

    public static final Issue ISSUE_DUMMY_CLASS_CHECK = Issue.create(
            "IssueDummyClassCheck",

            "A sample issue for class check",
            "This class has errors",
            Category.CORRECTNESS,
            6,
            Severity.ERROR,

            new Implementation(DummyJavaClassDetector.class, Scope.JAVA_FILE_SCOPE));

    /**
     * Provide the classes this detector cares about by listing its super classes or implemented
     * interfaces.
     */
    @Override
    public List<String> applicableSuperClasses() {
        return Arrays.asList("java.lang.Object", "test.pkg.SampleRequestParams");
    }

    /**
     * Investigate a class node with the given {@code context}
     */
    public void checkClass(@NonNull JavaContext context, @NonNull PsiClass declaration) {
        context.report(ISSUE_DUMMY_CLASS_CHECK, context.getLocation(declaration), "sample error");
    }
}

Looks like the lintProject() call could not find java.lang.Object in its class path, we tried adding JAVA_HOME, ANDROID_HOME to the .bash_profile but either helps.

Any hints?

To unsubscribe from this group and stop receiving emails from it, send an email to lint-dev+unsubscribe@googlegroups.com.

To post to this group, send email to lint...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lint-dev/ae090189-188e-4f67-a5a0-00730dbe7ed6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "lint-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to lint-dev+unsubscribe@googlegroups.com.

To post to this group, send email to lint...@googlegroups.com.

[Tor Norbye]

Can you start a new topic for this?

To view this discussion on the web visit https://groups.google.com/d/msgid/lint-dev/ae090189-188e-4f67-a5a0-00730dbe7ed6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "lint-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to lint-dev+u...@googlegroups.com.
To post to this group, send email to lint...@googlegroups.com.