Check if dependencies are modified since the last checking.
Dependencies:
- Other source files in the current module
- Dependent files collected by the dependency tracker
When:
- If the last dependency check was over N (defaults to 5) seconds ago
Invalidate if:
- The dependency file is missing
- The modification time of the dependecy is greater than the last check
- If the modification time is zero, compare the content using the file
system from the previous completion and the current completion
rdar://problem/62336432
This change makes us treat it exactly as we do 'init'. We don't allow renaming the base name,
and don't fail if the basename doesn't match for calls.
Also:
- explicit init calls/references like `MyType.init(42)` are now reported with
'init' as a keywordBase range, rather than nothing.
- cursor info no longer reports rename as available on init/callAsFunction
calls without arguments, as there's nothing to rename in that case.
- Improved detection of when a referenced function is a call (rather than
reference) across syntactic rename, cursor-info, and indexing.
Resolves rdar://problem/60340429
A request is intended to be a pure function of its inputs. That function could, in theory, fail. In practice, there were basically no requests taking advantage of this ability - the few that were using it to explicitly detect cycles can just return reasonable defaults instead of forwarding the error on up the stack.
This is because cycles are checked by *the Evaluator*, and are unwound by the Evaluator.
Therefore, restore the idea that the evaluate functions are themselves pure, but keep the idea that *evaluation* of those requests may fail. This model enables the best of both worlds: we not only keep the evaluator flexible enough to handle future use cases like cancellation and diagnostic invalidation, but also request-based dependencies using the values computed at the evaluation points. These aforementioned use cases would use the llvm::Expected interface and the regular evaluation-point interface respectively.
* Reference is marked "explicit", which may be unexpected - the reason
is that the *call* is explicit, so we want to find it with e.g. rename,
or looking up callers, even though the identifier callAsFunction is
implicit. This matches the behaviour of initializers.
* The source location is the same as the base name (e.g. in `add3(5)`,
it would be at `add3`), which matches the behaviour of initializers.
rdar://problem/60327632
* Update DAK_Available name to match @available keyword
Update expected errors for @available attribute tests
* Update available attribute keyword name in DeclAttrKeyword documentation comment
Now
* NotApplicable: The result is not relevant for type relation (e.g.
keywords, and overloads)
* Unknown: the relation was not calculated (e.g. cached results), or the
context type is unknown.
* Invalid: The result type is invalid for this context (i.e. 'Void' for
non-'Void' context)
* Unrelated: The result type has no relation to the context type
* Convertible: The result type is convertible to the context type
* Identical: The result type is identical to the context type
Because we won’t be serializing this attribute, add custom diagnostics for the cases where:
- We add @_hasMissingDesignatedInits to an open class, which means subclasses won’t be able to inherit its inits
- We remove @_inheritsConvenienceInitializers, which means APIs are removed
if fast-completion is enabled. So they have higher chance to use the cached
completion instance.
If it's disabled, don't block, use an ephemeral instance so we can peform
multiple completions simultaneously.
To controls the lifetime of CompilerInstance within CompletionIntance.
- Prevent from using the same CompilerInstance from multiple completion
requests
- Separate the stacktrace between "fast" and "normal" completions
- Further code consolidation between various completion-like requests
- Introduce ide::CompletionInstance to manage CompilerInstance
- `CompletionInstance` vends the cached CompilerInstance when:
-- The compiler arguments (i.e. CompilerInvocation) has has not changed
-- The primary file is the same
-- The completion happens inside function bodies in both previous and
current completion
-- The interface hash of the primary file has not changed
- Otherwise, it vends a fresh CompilerInstance and cache it for the next
completion
rdar://problem/20787086
By convention, most structs and classes in the Swift compiler include a `dump()` method which prints debugging information. This method is meant to be called only from the debugger, but this means they’re often unused and may be eliminated from optimized binaries. On the other hand, some parts of the compiler call `dump()` methods directly despite them being intended as a pure debugging aid. clang supports attributes which can be used to avoid these problems, but they’re used very inconsistently across the compiler.
This commit adds `SWIFT_DEBUG_DUMP` and `SWIFT_DEBUG_DUMPER(<name>(<params>))` macros to declare `dump()` methods with the appropriate set of attributes and adopts this macro throughout the frontend. It does not pervasively adopt this macro in SILGen, SILOptimizer, or IRGen; these components use `dump()` methods in a different way where they’re frequently called from debugging code. Nor does it adopt it in runtime components like swiftRuntime and swiftReflection, because I’m a bit worried about size.
Despite the large number of files and lines affected, this change is NFC.
- No need to hash input values first
- Pass many values to a single hash_combine to save on intermediates
- Use hash_combine_range instead of a loop of hash_combines
No functionality change.
This simplifies the code and prevents an assertion failure this code was
hitting computing the type relations between the result types and what it
determined as the expected type.
Resolves rdar://problem/53958454
Like the last commit, SourceFile is used a lot by Parse and Sema, but
less so by the ClangImporter and (de)Serialization. Split it out to
cut down on recompilation times when something changes.
This commit does /not/ split the implementation of SourceFile out of
Module.cpp, which is where most of it lives. That might also be a
reasonable change, but the reason I was reluctant to is because a
number of SourceFile members correspond to the entry points in
ModuleDecl. Someone else can pick this up later if they decide it's a
good idea.
No functionality change.
Most of AST, Parse, and Sema deal with FileUnits regularly, but SIL
and IRGen certainly don't. Split FileUnit out into its own header to
cut down on recompilation times when something changes.
No functionality change.
If client's subclass provides an implementation of all of its superclass designated
initializers, it automatically inherits all of the superclass convenience initializers.
This means if a new designated init is added to the base class, the inherited
convenience init may be missing and cause breakage.
SR-11454
