Older kotlinc versions (1.1.5?) didn't generate the 'INNERCLASS' attribute for some anonymous classes, e.g. for 'crossinline' lambdas.
An example: 'Timer().schedule(1000) { foo () }'
Normally, stub loader checks if the class is 'ClassFileViewProvider.isInnerClass()', and ignores the class file.
Without the 'INNERCLASS' attribute this check fails. As the stub loaded isn't created to deal with anonymous classes nicely, it fails miserably.
This commit explicitly ignores classes with local visibility.
Ensure that breakpoints of each type can be placed only on lines where it makes sense to place a breakpoint.
Here is a quick summary of the rules:
1. Method breakpoints are available for functions, property accessors, constructors;
2. Line breakpoints are available on any line with an expression, excluding some cases like 'const' property initializers or annotations;
3. Line breakpoints should be available on a '}' in functions and lambdas;
4. Line breakpoints are not suggested for one-liners;
5. Lambda breakpoints should be shown for single-line lambdas.
Now it's possible to put a function breakpoint.
In JVM, function breakpoints behave as JVM method breakpoints. Normally, they're triggered twice – once on enter, and once on exit.
Under COMPOSITE mode we don't have a globally known way to create
built-ins, instead, we have to create them on per-module basis.
So, in this commit we:
1. Use builtInsProvider: (ModuleInfo) -> KotlinBuiltIns instead of
precomputed builtIns instance, in order to be able to calculate
builtIns on per-module basis
2. Introduce new entity, called BuiltInsCache, which, roughly
speaking, is a map of form ModuleInfo -> KotlinBuiltIns, to prevent
creation of multiple builtInsInstances
NB. Actually, it's of form BuiltInsCacheKey -> KotlinBuiltIns, because
we shouldn't create new builtIns for each module. Also, currently,
each platform has its own BuiltInsCacheKey implementation, because
parameters by which built-ins are created, are a bit different across
different platforms. Ideally, we should eliminate those differences
and they use one concrete implementation as a key.
Under COMPOSITE resolution mode (see ResolutionModeComponent) we have
no fixed and globally known SDK, instead, for each module we have to
find SDK it it's transitive dependencies.
Currently, this is necessary in order to create proper JvmBuiltIns,
which need dependency on SDK to be present in immediate dependencies.
Previously, each ProjectResolutionFacade was tied to the respective
platform, so there were no point in collection moduleInfos for all
possible platforms.
For composite resolution mode, we have to get all modules no matter
what their platform is (because all modules will be analyzed in one
facade), so this commit adds such an ability.
This commit introduces CompositeResolverForModuleFactory, which should
work under so-called "composite resolution mode", where sources of all
all modules are analyzed in one global facade.
This allows to:
- avoid re-analyzation of common sources
- avoid retaining memory for all platforms (which can be very bad as
soon as we'll start distinguishing various flavours of platforms,
especially "flavours" of common platform)
- support running platform-specific checks in common modules (e.g.,
report JVM_PLATFORM_DECLARATION_CLASH if common sources are going to have
it)
- support analysis of shared platform modules, like commonNative
This mode heavily depends on so-called "type refinement" support in the
compiler, which is introduced in other series of commits.
In this commit, CompositeResolver and related codepaths are left unused.
Also, this commit misses several important pieces of logic in
resolvers-setup code, which should be different for CompositeResolver
- computation of 'firstDependency'
- computation of built-ins
- computation of modules owned by facade
They will be covered in the following commits
Because we want to support both COMPOSITE and SEPARATE resolution modes
at once, we have to leave 'globalFacadesPerPlatformAndSdk'-map, but in
COMPOSITE mode it should use less parameters for that map, and, in
particular, we shouldn't use Platform and SDK for equality.
This commit introduces separate instance which should be used in
COMPOSITE mode.
COMPOSITE mode itself will be introduced in the following commits.
Introduce a component which tells which resolution mode should be used.
COMPOSITE mode will analyze all sources for all platforms in one facade,
and will use proper support in the frontend instead of
CombinedModuleInfo.
SEPARATE mode is essentially a "legacy" mode, where each platform is
analyzed in separate facade (leading, in particular, to multiple
re-analyzation of common sources)
Facilities for support of COMPOSITE mode will be introduced in the
following commits.
resolution component
As consequence, remove IdePlatformKindTooling.resolverForModule, because
it became more than just field, and it duplicates similar API in
IdePlatformKindResolution anyways
Before refinement, order of accessing compiler's entities (supertypes,
descriptors, memberscopes) was always the following:
sources -> libraries -> SDK (built-ins)
With refinement, it is sometimes possible to inverse this order, e.g.
access sources after libraries or SDK. This mainly happens in the following
scenario:
- we reference some library/SDK class, but do not acquire source-lock
This might seem a bit weird, but actually it is quite easy to achieve
as soon as we understand that analysis sources doesn't necessarily
acquires respective lock, only forcing lazy computations does so.
E.g., we can just traverse PSI tree and meet some refernce to "Any?" -
this doesn't involves acquiring source-lock
- we start resolving it, which usually involves acquiring library/SDK-lock
(e.g., in order to get it supertypes or memberScope)
- because we reference it from the source-module, we may like to refine
it, in which case we will have to acquire source-lock on refinement
cache
Obviously, that may lead to deadlocks, so, in this commit we disable
creating granular locks when we work with refinement.
Note that if refinement is disabled (which is the case for all non-MPP
projects), we still create separate locks.
There're exceptions from `isWritable` method in light classes caused by
accessing invalid elements.
Override KtLightMemberImpl implementation to avoid activating
decompiler during validity check.
Yan Zhulanow