Deferred resolution of JAR-to-AAR mapping, since the Android Gradle
plugin now resolves dependencies at execution phase.
Dropped the code related to the Jack toolchain compatibility.
Throwing a build error when Jack is enabled.
Changed warning about Jack into a build error.
BasicCompletionWeigherTestGenerated$ExpectedInfo.testPreferMatchingThis
Looks like IDEA now rearranges elements with same weight by length and
then alphabetically
Previously we could differentiate between callables with the same name
when relevant type declaration were in the same file only
Problem manifested most severely when several copies of sources were attached
to the same library
Rename to getNonConfiguredModulesWithKotlinFiles() to match what it
actually does, remove duplicate configurator status check, extract code
for collecting all configurators
Report CAN_BE_CONFIGURED from Gradle configurator only if we didn't
find any file containing valid configuration (normally the top-level
project file in an Android project doesn't have any Kotlin
configuration, so we report CAN_BE_CONFIGURED even though the module
file contains valid configuration)
Don't show notification after every sync; trigger it from
rootsChanged handler because the root model is not yet updated at
syncDone point
#KT-16590 Fixed
Filter out duplicate reference targets.
Fix test data as directory references are available
inside of string literals.
Fix test data as Spring @Autowired inspection
no more reports parameterless methods.
Fix gutter checking as configuration bean references now resolve
to @ComponentScan annotation
CompletionContributor should not store offsets inside
replacement zone(part of file which are replaced with
dummy identifier) in offsetMap
#KT-16848 fixed
Otherwise, when we check the highlighting on one of the files, the text
of the other still contains the <lineMarker> annotation and can't be
indexed as valid Kotlin code.
- Use FULL_JDK instead of mock JDK in some tests because mock JDK is
created from JDK 6 and full JDK is now JDK 8, so there are differences
in the behavior in the compiler and at runtime
- Remove some '*.runtime.txt' files which were workarounds to JDK 6
reflection issues regarding generic inner classes; code in these tests
is now loaded exactly the same in the compiler and at runtime
- Change supertype in SupertypesAndBounds.kt: the class in the supertype
is not relevant to that test, it checks that annotations can be loaded
on types
- Use another API to get file name out of a javac diagnostic
(.getSource().getName()'s behavior changed in JDK 8)
- Delete .txt files for those tests which check that javac reported a
compilation error; the order and content of declarations in those
files is undefined
Sergey Igushkin