| 5e290ab6060c3204be3a3eb6084db6f92c88adee |
|
19-Jun-2012 |
Tor Norbye <tnorbye@google.com> |
Add typo detector
This changeset adds a new typo detector. There
are also some lint infrastructure fixes to better
handle positions within text nodes, and to allow
Eclipse lint quickfixes to supply multiple fixes
for a single issue (such as multiple misspelling
alternative replacements.)
Change-Id: Ie26f0bafc571e02ae09ff27a7f4b221fe0c2ea5b
|
| 968bf020570f1131206af33a79c4c90359ec1b6b |
|
26-Mar-2012 |
Tor Norbye <tnorbye@google.com> |
27471: Lint check for match_parent vs fill_parent on older APIs
Change-Id: I2ff5e88fce13f9016b27878ece2c45ea1b58ad7a
|
| fd9fe37e806b8f14b2944d29f307cd050ecb419c |
|
28-Feb-2012 |
Tor Norbye <tnorbye@google.com> |
Fix configuration information for library projects
This changeset fixes one more bug related to lint configurations and
library projects (see issue 26029).
Some lint checks, such as the MergeRootFrameLayoutDetector, computes
the warnings at the end of processing all files. At that point, the
context points to the master project, so any errors which were
actually found in a library project will instead be using the master
project's configuration. That means that any suppress rules applies to
the lint.xml in the library project will be ignored.
This changeset fixes this by moving the logic which looks up the
severity for a warning out of the lint clients and into the
context. Now it checks the current projects being scanned and looks up
the corresponding project for each file (based on the file prefix),
and retrieves the configuration that way.
This changeset also makes one more fix: It now consults *both* the
library project *and* the master project to see if a rule should be
ignored. This means that if you turn off a given check in your master
project, you will no longer see those warnings from library projects
either, which seems desirable.
Change-Id: Icb5cdf7696b4908b0553f86896793515cb06f29c
|
| a241a4dd5605b0986d63a973cd367e22c3083507 |
|
18-Feb-2012 |
Tor Norbye <tnorbye@google.com> |
Make API detector in XML files consider folder version
Take the folder version into account when checking the API level in
XML files. For example, even if minSdkVersion=5, it's okay to have a
<GridLayout> element in a layout if that layout is in a layout-v14 (or
higher) folder.
Change-Id: Idbd3647c1145e4b3d03f90626339ef7e6b10c827
|
| dc2b52530fa7c88e42a34020f4a170dc4e5d52fc |
|
16-Feb-2012 |
Tor Norbye <tnorbye@google.com> |
Add @android resource version checking to the lint API detector
This changeset makes the API lint detector look at XML attribute
values and XML value text nodes and check any references to @android
resources to ensure that they are available in all supported versions.
Change-Id: Iab0d23423c30381e06b32f54aa902a31cc1f9a1c
|
| 69067f399231dc28f4ff0aa02b60153ffd2d5831 |
|
06-Feb-2012 |
Tor Norbye <tnorbye@google.com> |
Add support for suppressing lint via XML attributes
This changeset adds support for suppressing in XML files:
(1) Lint will ignore errors found in attributes and elements if the
element (or any surrounding parent elements) specifies a
tools:ignore="id-list" attribute where the id-list matches the id
of the reported issue (or "all"). The "tools" prefix can be any
prefix bound to the namespace "http://schemas.android.com/tools"
(2) There's a new quickfix shown for XML lint warnings which offers to
add a lint suppress attribute for a given lint warning (setting
the id to the id of the warning, and adding the tools namespace
binding if necessary).
(3) The XML formatter now handles namespaces a bit better: after the
preferred attributes (id, name, style, layout params, etc) have
been handled, attributes are sorted by namespace prefix before
they are sorted by local name -- which effectively will sort any
new tools:ignore attributes to the end.
Change-Id: Id7474cde5665d9bd29bdd4e0d0cc89ed4d422aea
|
| d6124a176326169bc87cb29823ca2dc906689680 |
|
03-Feb-2012 |
Tor Norbye <tnorbye@google.com> |
A few simple name changes
This changeset contains no semantic changes, just a couple of simple
refactorings:
(1) Rename the "Lint" class to "LintDriver". "Lint" is a bit generic
(there's already LintClient for example), and this object was
already referred to as a driver from various other API's, such as
Context.getDriver().
(2) Rename LintRunner in Eclipse to EclipseLintRunner, similar to the
other EclipseLintClient in the same package - and to avoid
confusion with LintDriver.
(3) Move all the lint fix inner classes inside the LintFix class out
as top level classes. The class was getting really large and
there's really no good reason to keep all the individual fixes as
inner classes; there's already a separate lint package for them.
Change-Id: Ifc0004bfb38f8e11e33e9ddc477b6cf07ca319f2
|
| 380bdf7838171c02e29853027354c58ab9376beb |
|
25-Jan-2012 |
Tor Norbye <tnorbye@google.com> |
Add support for multi-pass lint checks, and chained locations
This changeset adds support for multi-pass lint checking. A detector
can indicate that it is interested in a second pass through the source
code.
A good example of where this is needed is the Unused Resource
detector. In the first pass, it tracks declarations and references,
and at the end of the first pass it knows which resources are
unused. However, at this point it's too late to compute detailed
location information about each unused resource. Without multi-pass
checks, it would have to track detailed location information for *all*
resources, and computing locations can be costly.
With multi-pass support, it just computes the unused resource names in
the first pass, and then in the second pass it computes details about
the locations of those resources found to be unused.
This now includes *chained locations*. For example, for an unused
string, all the different translations of the unused string are
marked. These do not generate separate unused messages, it simply adds
to the location chain for the original unused warning.
This changeset also updates all the error reporters (text, HTML and
XML) to include all the locations, not just the ones with messages.
This changeset also cleans up the API a little: context classes now
track the lint runner instead of the lint client (which can point to
the lint client), and the SDK info lives with the project rather than
with the context.
Change-Id: I14ca3310bd1165b7dff655486157d770a36c4eff
|
| b1283f2cc2dd403fa9f92407d4dfac37eddd520d |
|
10-Jan-2012 |
Tor Norbye <tnorbye@google.com> |
Add annotations to the Lint API
Change-Id: I6222f3ef2909174d9111dcfc037a2e74ad093acd
|
| 4c68f3dc9f10b76f1a32ff9c86587adca385a6d7 |
|
14-Dec-2011 |
Tor Norbye <tnorbye@google.com> |
Lint Library Support
This changeset adds support for library projects to lint. Lint now
checks all the library projects for errors as well, and projects that
depend on global analysis (such as the unused resource detector) will
properly handle resource declarations and references across projects.
This changeset also cleans up the multi-project handling for the Lint
window in Eclipse. The "Run Lint" toolbar action, in addition to
operating on multiple selection, now has a dropdown menu for choosing
which projects to check (and there are also actions for checking all
projects, the current file, and clearing markers). Running lint on a
project will also automatically include dependent library projects.
Finally, some misc UI improvements: The Lint preference dialog
includes buttons for quickly enabling and disabling all the checks;
the Lint View includes a Project column which is shown when more than
one project is checked, and the file and linenumber columns are now
blank when the location does not correspond to a specific file.
Change-Id: I733f5258102dfb0aebbc2b75cb02b9ba6ef974e8
|
| 3db9393ba06bbf70fa7b4a6db1ef60396979a1d4 |
|
06-Dec-2011 |
Tor Norbye <tnorbye@google.com> |
Add the Guava library to the tools
This changeset adds the Guava library to ADT and lint. (It is also a
prerequisite for the Lombok AST library which is added by a later CL.)
This changeset also uses the library in a few simple ways: It replaces
some custom I/O and collections code with calls into the equivalent
Guava methods, and it also adds the @Beta annotation on the various
"API" classes which are not yet stable.
Change-Id: I2f50febfa075c32818404e888578a2e1e447d408
|
| 3ce45b249f898697ae82e8c6dd045966227f3438 |
|
02-Dec-2011 |
Tor Norbye <tnorbye@google.com> |
Lint infrastructure improvements
This changeset fixes a bunch of issues in the infrastructure:
(1) It cleans up the Context class quite a bit. It had some hardcoded
XML stuff in it, which is now in a separate XmlContext class (and
there will be a JavaContext class in the Java support CL).
It also hides a bunch of public fields, cleans up some unused
stuff, and introduces a couple of wrapper methods to make detector
code cleaner; in particular, rather than calling
context.client.report(context, ...
you can now just call
context.report(...
and similarly there are wrappers for logging and checking for
disabled issues.
(2) The IParser interface is renamed to IDomParser since in the next
CL there will also be an IJavaParser. Some other related cleanup.
(3) There is now a "Location.Handle" interface. This allows detectors
to create light-weight location holders, and later on call
handle.resolve() to create a full-fledged Location. This is useful
when detectors don't yet know whether they'll need a location for
a node, but want to store it for later in case they do. As an
example, the unused resource detector creates location handles for
declaration and only resolves full locations for those that are
found to be unused.
Locations can now carry custom messages. For example, for a
duplicate id error, the secondary location now contains a
"original declaration here" message. And the CLI and HTML reports
now include alternate locations in the output.
Some other location cleanup too; using factory methods to make the
code cleaner, some default implementations that can be shared,
etc.
(4) There's a new SDK info class intended to provide SDK information
from a tool client (such as resource resolution). It currently
just contains parent-view information, used for the
ObsoleteLayoutParams detector and an upcoming CL for a
ViewTypeDetector.
(5) The Detector class now provides dummy implementations for the
inner-interfaces, so we no longer need the adapter classes. This
makes it easy to implement the XmlScanner or JavaScanner
interfaces without needing to also stub out a bunch of methods.
Change-Id: I4b3aaabe51febb25b000f9086703653bea6cf7c9
|