Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Clarify method's purpose with clearer name

  1. … 2 more files in changeset.
Improve incremental compilation for Java

This patch splits the collected dependencies found in a .class file into "accessible" and "private" dependencies.

* "Accessbile" dependencies are classes that belong to non-private fields, non-private method signatures, class signature ("extends", "implements") etc

* "Private" dependencies are classes that belong to private fields, private methods and classes used in method bodies (i.e. just in "the code")

The TL;DR of the approach is to change the algorithm in `ClassSetAnalysis.getRelevantDependents` to only recurse for "accessible" dependencies.

Goal by example:

Consider classes like

```

class A {

private B b

}

class B {

private C c

}

class C {

}

```

The previous algorithm in `ClassSetAnalysis.getRelevantDependents` would recompile all classes, if `C` was changed. The new algorithm recompiles

just `B` and `C`, because `C` has been changed and `B` uses `C`. But it doesn't recompile `A`, because `A` is not affected by the change. The same

is true, if `C` would have been only used in a method body of `B` or in the signature of a `private` function in `B`.

The algorithm properly handles changes to classes used in the following example:

```

public class SomeClass {

List<Integer> field = new LinkedList<Integer>();

private AccessedFromPrivateField accessedFromPrivateField;

AccessedFromPackagePrivateField someField;

private AccessedFromPrivateMethod accessedFromPrivateMethod() {

return null;

}

public String accessedFromPrivateMethodBody() {

return new AccessedFromPrivateMethodBody().toString();

}

private Set<String> stuff(HashMap<String, String> map) {

System.out.println(new Foo());

return new HashSet<String>();

}

private class Foo {

// Hint: this field won't appear in the ClassAnalysis for SomeClass

public AccessedFromPrivateClassPublicField anotherField;

public String toString() {

return "" + new AccessedFromPrivateClass();

}

}

}

```

Changes the serialization format of `ClassAnalysis` + `DependentsSet`

Signed-off-by: Robert Stupp <snazy@snazy.de>

  1. … 14 more files in changeset.
Use normalized path for inferring class names

Instead of relativizing the path to source roots. The information of

the relative path is already available, so why bother inferring it

again.

  1. … 6 more files in changeset.
Move compiler parameters into compiler implementation classes

  1. … 5 more files in changeset.
Follow-ups of incremental Groovy compilation (#9848)

This PR:

- Closes https://github.com/gradle/gradle/issues/9785 and https://github.com/gradle/gradle/issues/9380

- Adds tests for

- Multiple classes in a same source Groovy file.

- Moving files between source set roots

Previously, removing a source directory from a source set would break the Java (and Groovy) incremental compiler (https://github.com/gradle/gradle/issues/9380). This PR detects this case and runs a full recompilation.

It also records relative path instead of absolute path in Groovy incremental compilation to make it build-cache-friendly.

  1. … 25 more files in changeset.
Groovy incremental compilation support (#9616)

Inspired by https://github.com/gradle/gradle/pull/9388 , this PR implements Groovy compilation avoidance. Unlike Java, things are a little more complex in Groovy compilation - a compilation unit can generate multiple classes. Thus, we introduced a `sourceClassMappingFile`, which records the source to classes mappings during the compilation process. Later, we can use this information in incremental compiler: only the affected groovy source files get recompiled in next compilation.

  1. … 71 more files in changeset.
Use isolated parameters for all worker isolation modes

  1. … 44 more files in changeset.
Publish all projects

  1. … 2 more files in changeset.
Move API classes back to :base-serivces

  1. … 32 more files in changeset.
Inline org.gradle.testing.internal.util.Specification

  1. … 53 more files in changeset.
Simplify worker daemon classloader hierarchy

  1. … 18 more files in changeset.
Pass compiler classes and instantiate them in the worker

  1. … 25 more files in changeset.
Fix non-classdir tests

  1. … 3 more files in changeset.
Handle removals of classes transitively

After further cleaning up our class change detection logic,

I noticed that we were handling additions and removals very

differently. This has been corrected and we now detect transitive

removals too. This doesn't happen often in practice, as one needs

to deliberately exclude a task to trigger the bug that was fixed.

Nevertheless, it's good to have symmetric logic.

  1. … 6 more files in changeset.
Detect changes to transitive dependencies on incremental compilation

The incremental compiler was completely ignoring changes in transitive

dependencies, except for changes to supertypes, which seems like a really

weird decision. It has been fixed to instead take all possible transitive

references into account. As a result the code is also simpler.

  1. … 8 more files in changeset.
Remove synchronization around all system property getters

  1. … 5 more files in changeset.
Support resource creation in incremental annotation processors

Allow resources to be created by incremental annotation processors using

`Filer#createResource`. Allow resources to be created in the three currently

existing output locations on `StandardLocation`: `SOURCE_OUTPUT`,

`CLASS_OUTPUT`, and `NATIVE_HEADER_OUTPUT`.

A generated resource is uniquely identified by its `Location` and its path

relative to that `Location`. A new type `GeneratedResource` is created to that

effect. Data of that type is then plumbed through the existing annotation

processing infrastructure, ultimately reaching

`IncrementalCompilationInitializer` so that cleaning may be done.

Resolves #4702.

Signed-off-by: Ian Kerins <ianskerins@gmail.com>

  1. … 32 more files in changeset.
Use notimestamp for JavaDoc and noversionstamp for GroovyDoc

Timestamps in the generated documentation have very limited practical use,

however they mark all the files as "modified" even in case of a small changes.

Having notimestamp by default enables repeatable documentation build, and

it simplifies storage of the documentation (e.g. reduces git traffic, etc)

Signed-off-by: Vladimir Sitnikov <sitnikov.vladimir@gmail.com>

  1. … 2 more files in changeset.
Introduce an internal factory to create `JavaForkOptions`, to encapsulate the service(s) needed to create instances of this type and decouple clients from this detail. This could/should move to `ObjectFactory` or some other public factory type.

  1. … 42 more files in changeset.
Hold a lock on System Properties while reading them in DefaultSslContextFactory

  1. … 3 more files in changeset.
Disallow '-J' flags in `CompilerOptions.compilerArgs`

`javac` already fails if -J flags (i.e. those affecting the JVM that is running

the compiler) appear in command-line argument files as opposed to directly on

the command line, but does so with a particularly useless error message.

This validation thus mainly serves to improve the error messaging, offering the

right alternative API for supplying such flags.

Signed-off-by: Ian Kerins <ianskerins@gmail.com>

  1. … 2 more files in changeset.
Move `TreeFormatter` out of core and decouple from `TreeVisitor` by introducing an interface to represent something that can receive diagnostic information.

  1. … 69 more files in changeset.
Only pass -s to javac if annotation processing is supported

Signed-off-by: Thomas Broyer <t.broyer@ltgt.net>

  1. … 1 more file in changeset.
Use only AnnotationProcessorResult in decorated processors

`AnnotationProcessorResult` now delegates to the overall

`AnnotationProcessingResult`.

  1. … 11 more files in changeset.
Resolve package cycle

  1. … 20 more files in changeset.
Add unit test for setting processor type

Track execution time in nanoseconds

This commit changes `TimeTrackingProcessor` to internally use Guava's

`Stopwatch` for keeping track of execution time. The lossy conversion to

millis is performed after each operation, but rounding errors do no

longer accumulate.

  1. … 4 more files in changeset.
Report whether annotation processor is incremental

This commit adds an `incremental` property to the result of the build

operation and checks that it’s reported correctly for the different

annotation processor types.

  1. … 20 more files in changeset.
Report annotation processor execution time

In order to track time spent by annotation processors, invocations of

compilers in `JavaCompile` and `GroovyCompile` are now wrapped in build

operations that report the execution time per fully-qualified annotation

processor class name in their result.

  1. … 22 more files in changeset.
Re-enable ignored tests