Produce special stdlib artifact with annotations for dist.
Put js outputs to dist, they're required for JS backend tests.
Use kotlin-compiler for maven, which has all required dependencies bundled.
Clean local directory repository on clean.
Change paths in tests to compiled artifacts.
PathUtil.getJdkClassesRoots() takes the path to the JRE. On macOS, this
is the same as the path to the JDK (for Java 6), so the test worked
there. However for OpenJDK on Linux, there's a separate directory named
"jre" in the JDK root. See JavaSdkUtil.getJdkClassesRoots for more
information on how the JDK roots are found
The directive was only used in this test and it had no effect on the
behavior of the test. The test is removed because it's equivalent to
simple.kt in the same directory
Forbid underscore-only (_, __, ___, ...) names as callees and as types.
If CHECK_TYPE directive is on, filter out UNDERSCORE_USAGE_WITHOUT_BACKTICKS messages.
After update of the project to JDK 8, the default JDK at java.home is
now JDK 8. However, this test relied on the fact that the default is JDK
6. Pass the path to the JDK 6 explicitly
- 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
Pass it in the CompilerConfiguration instead of LanguageVersionSettings.
This is better because LanguageVersionSettings is accessible everywhere
in front-end and back-end, and this flag should not be used there
Previously there were three LanguageFeature instances -- Coroutines,
DoNotWarnOnCoroutines and ErrorOnCoroutines -- which were handled very
awkwardly in the compiler and in the IDE to basically support a language
feature with a more complex state: not just enabled/disabled, but also
enabled with warning and enabled with error. Introduce a new enum
LanguageFeature.State for this and allow LanguageVersionSettings to get
the state of any language feature with 'getFeatureSupport'.
One noticeable drawback of this approach is that looking at the API, one
may assume that any language feature can be in one of the four states
(enabled, warning, error, disabled). This is not true however; there's
only one language feature at the moment (coroutines) for which these
intermediate states (warning, error) are handled in any way. This may be
refactored further by abstracting the logic that checks the language
feature availability so that it would work exactly the same for any
feature.
Another issue is that the difference among ENABLED_WITH_ERROR and
DISABLED is not clear. They are left as separate states because at the
moment, different diagnostics are reported in these two cases and
quick-fixes in IDE rely on that
Inject LanguageVersionSettings instead; all information relevant to the
analysis should be now passed via an instance of LanguageVersionSettings
(which should be renamed to a more general name in the future).
This is partially a revert of d499998 and related commits
This makes it possible to avoid the CompilerConfiguration instance in
injectors, because CompilerDeserializationConfiguration was the only
left component that required it.
LanguageVersionSettings is not a good name for this entity anymore, it
should be renamed in the future
This makes it possible to drop CompilerConfiguration from
CallCheckerContext, which in turn helps to avoid passing the entire
CompilerConfiguration instance through front-end
To prevent tests from altering outcomes of the subsequent tests.
Also expose the clearCaches method (in the internal class
ReflectionFactoryImpl) so that it can be used in other places in similar
circumstances
The problem was that LanguageVersionSettingsImpl.DEFAULT did not have
"WarnOnCoroutines" as a feature and so it was manually added to the settings,
but only in two places: in the compiler and in the IDE
LanguageVersionSettings can be read from the configuration. Also, the
configuration may be used for other stuff, not related to language version
settings, soon
Pass the LanguageVersionSettings instance inside the CompilerConfiguration,
since it's needed anyway. In compiler and tests, the configuration comes from
KotlinCoreEnvironment; in IDE, we're constructing it in JvmAnalyzerFacade
Ilya Gorbunov