- Why we bother? Because this test tries to read @Metadata via
reflection, and in 1.3 @Metadata has @Since("1.3") annotation. Thus,
with version fixed to 1.2, this test fails with UNRESOLVED_REFERENCE
- Why it is correct? Because initially this directive was used to enable
'LanguageFeature.JvmPackageName' (we didn't have infrastructure for
enabling particulare feature at that moment). So, now we could change it
to the '!LANGUAGE:+JvmPackageName', but it is actually redundant,
because master is already >= 1.2
Rationaly is that facet importer knows better about which language
versions should be used, so we shouldn't interfere.
Otherwise, Gradle or Maven projects which have upgraded corresponding
plugin to 1.3 will be imported with 1.2 levels, which is undesirable
* First, it overrides `addCommonSourceSetToPlatformSourceSet` with an
old signature that was drop during migration to 'KotlinSourceSet's
* Second, it uses an extension SourceSet.kotlin that got dropped during
the aforementioned migration
Now, for the old MPP K/N plugin, `addCommonSourceSetToPlatformSourceSet`
is called twice, one time with the new signature and another with the
old one, which it overrides.
Version for IDEA 182 does not work properly here (returns null),
so we have to use `DataManager.getDataContext(focusedComponent)` directly
#KT-26399 Fixed
The extraction itself is needed due to different behaviour of related
IDEA functions in different platforms.
Check on null is needed because `createFromAnAction` last argument
cannot be null, otherwise we will get an exception.
Partial fix of KT-26399
When 'languageVersion' isn't passed explicitly, compiler will choose
'LATEST_STABLE'.
This may lead to spurious migration of a project to the next major
version after plugin update (e.g. when user had project of major
version X and then installed plugin of version X+1 -- in such case,
meaning of "no language version" suddenly changes).
So, we set it to RELEASED_VERSION, which is exactly the version
that is safe to use as the fallback.
There are few more such places. Better fix would be to avoid
situation, when we need to fallback. So in every project these
settings are defined. It means "Latest stable" setting is not good.
#KT-26364 Fixed
Make it the same type as in case of an empty collection, so that
`emptyRange.random()` throws the same exception as `emptyRange.toList().random()`.
#KT-15539
Given there's a Random API in the stdlib, that generates all random primitives, this commit adds the possibility to generate random unsigned integers.
It uses the same implementation from Random.nextInt, nextLong and nextBytes, but uses the appropriate conversions from a signed type to an unsigned type.
The use of the same API guarantees that the distribution is uniform, but this commit adds some unit test to enforce that necessity.
Fixes #KT-25570
Before, we've assumed that if call has no expression arguments, then
it's a 'returns()' call.
Now we check that we've resolved to overload of 'returns' from
ContractsDsl with zero parameters.
- Introduce ContractParsingDiagnosticsCollector
It allows us to make sure that we return 'null'-contract iff there's
some error. Note that it differs from previous behavior in two major
points:
a) if contract was unparsed, but no error were reported for
some reason, then generic error will be reported (previously we were
swallowing incorrect contract silently)
b) if there were some errors during parsing, return only 'null'
(previously, we could return some contract. It was unusable due to
errors in code, but we want to be extra-safe here)
- Introduce ContractCallContext to not pass a bunch of random arguments
around
- Make message of Error.CONTRACT_NOT_ALLOWED more flexible
'parseContract' is called only from
'ContractParsingServices.checkContractAndRecordIfPresent', and here we
already have checked that this call is indeed a contract call.
- Mark @ContractsDsl as @Experimental
- Move Contracts DSL out from 'internal' package
- Change visibility of ContractsDsl from 'internal' to 'public'
^KT-25274 Fixed
^KT-25495 Fixed
Anton Bannykh