Based off the PlaygroundTransform, this new ASTWalker leaves calls to __builtin_pc_before and __builtin_pc_after before and after a user would expect a program counter to enter a range of source code.
This is a /slightly/ more user-friendly option than
-debug-time-function-bodies; pass it a limit in milliseconds and
the compiler will warn whenever a function or multi-statement closure
takes longer than that to type-check.
Since it's a frontend option (and thus usually passed with -Xfrontend),
I went with the "joined" syntax as the common case. The usual "separate"
syntax of "-warn-long-function-bodies <N>" is also available.
As a frontend option, this is UNSUPPORTED and may be removed without
notice at any future date.
Additional caveats:
- Other parts of type-checking not measured by this may also be slow.
- May include first-use penalties (i.e. "this is slow because it's
the first function that references an imported type, which causes
many things to be imported")
- Does not report anything whatsoever about other phases of compilation
(SILGen, optimization, IRGen, assembly emission, whatever).
- Does not catch anything accidentally being type-checked multiple times
(a known issue for initial value expressions on properties).
When there is only one source file passed to the frontend, the primary
buffer id can be set to ~0, so this check would fail for some
-parse -verify invocations.
Don't emit warnings if specified at the command line or when working
on a non-primary input file.
https://bugs.swift.org/browse/SR-1012
rdar://problem/25282622
Invoking the following command to `-dump-parse` a file containing SIL
triggers an assertion from within the Swift compiler frontend:
```
swiftc -dump-parse foo.sil
```
The assertion is not coupled with a description of what went wrong.
It turns out the frontend doesn't support `-dump-parse` for SIL files,
although `swiftc -help` wouldn't inform users of that:
```
-dump-parse Parse input file(s) and dump AST(s)
```
As a result, a user may invoke `-dump-parse` on a SIL file and not know
what went wrong. Add an assertion message to inform the user that only
Swift code may be parsed. (`IFK_Swift_Library` here is for the case
where `swiftc -parse-as-library -dump-parse foo.swift` is invoked.)
We want to distinguish the special case of a library built with
-sil-serialize-all, from a SIL function that is [fragile] because
of an explicitly @_transparent or @inline(__always).
For now, NFC.
Now that WitnessChecker is separate from ConformanceChecker, implement
a DefaultWitnessChecker subclass which performs default witness
resolution.
This populates the recently-added ProtocolDecl::DefaultWitnesses map.
Unlike ConformanceChecker, the DefaultWitnessChecker looks up the witness
in any protocol extensions of the protocol, matching the context archetypes
of the requirement against the witness.
For now, we infer default witnesses for all protocols, but don't do
anything with that information. An upcoming SILGen patch will start to
emit thunks and add tests.
Pre-specializations were only used by Onone builds, but were kept inside the standard library dylyb anyways. This commit moves all the pre-specializations into a dedicated Swift module and a dynamic library, which are only used by Onone builds.
This reduces the code size of libswiftCore.dylib by 4%-5%.
Pre-specializations were only used by Onone builds, but were kept inside the standard library dylyb anyways. This commit moves all the pre-specializations into a dedicated Swift module and a dynamic library, which are only used by Onone builds.
This reduces the code size of libswiftCore.dylib by 5%.
Since resilience is a property of the module being compiled,
not decls being accessed, we need to record which types are
resilient as part of the module.
Previously we would only ever look at the @_fixed_layout
attribute on a type. If the flag was not specified, Sema
would slap this attribute on every type that gets validated.
This is wasteful for non-resilient builds, because there
all types get the attribute. It was also apparently wrong,
and I don't fully understand when Sema decides to validate
which decls.
It is much cleaner conceptually to just serialize this flag
with the module, and check for its presence if the
attribute was not found on a type.
Exposes the global warning suppression and treatment as errors
functionality to the Swift driver. Introduces the flags
"-suppress-warnings" and "-warnings-as-errors". Test case include.
Till now, a SIL module would be only verified if an optimization has changed it. But if there were no changes, then no verification would happen and some SIL module format errors would stay unnoticed. This was happening in certain cases when reading a textual SIL module representation, which turned out to be broken, but SIL verifier wouldn't catch it.
Swift SVN r31863
To invoke the front-end on a SIL with whole-module optimizations enabled, execute:
swiftc -frontend myfile.sil
To invoke the front-end on a SIL without whole-module optimizations enabled, add a -primary-file option:
swiftc -frontend -primary-file myfile.sil
To invoke a sil-opt with whole-module optimizations enabled, use the -wmo option:
sil-opt myfile.sil -wmo
This change was need to be able to write SIL unit tests which should be compiled in the WMO mode.
Swift SVN r31862
We normally report a warning when a #available() check will always be true
because of the minimum deployment target. These warnings are potentially
annoying when the developer either cannot change the minimum deployment target
from the default (as in playgrounds) or when doing so is burdensome (as for
interpreted command-line scripts, which would require passing a target triple)
-- so suppress them.
The is a updated version of the reverted r29582, which didn't check for
immediate mode properly.
rdar://problem/21324005
Swift SVN r29646
That's how everything behaved anyway. Might as well make it explicit and
stop special-casing it.
I've left in compatibility for modules built with older compilers so that
people using the OS toolchains aren't immediately unable to debug their apps.
As soon as we change the module format in a more significant way, I can take
this out.
Groundwork for rdar://problem/21254367; see next commit.
Swift SVN r29437
Modules occupy a weird space in the AST now: they can be treated like
types (Swift.Int), which is captured by ModuleType. They can be
treated like values for disambiguation (Swift.print), which is
captured by ModuleExpr. And we jump through hoops in various places to
store "either a module or a decl".
Start cleaning this up by transforming Module into ModuleDecl, a
TypeDecl that's implicitly created to describe a module. Subsequent
changes will start folding away the special cases (ModuleExpr ->
DeclRefExpr, name lookup results stop having a separate Module case,
etc.).
Note that the Module -> ModuleDecl typedef is there to limit the
changes needed. Much of this patch is actually dealing with the fact
that Module used to have Ctx and Name public members that now need to
be accessed via getASTContext() and getName(), respectively.
Swift SVN r28284
Instead of only honoring the last occurrence of -import-module, the frontend now
honors all occurrences of -import-module, making all of the modules specified on
the command line implicitly visible.
This fixes <rdar://problem/20422696>.
Swift SVN r27299
getImportedModules is the canonical way to get imports, whether private,
public, or both. This is especially true now that we have more flags
for SourceFile imports that really shouldn't be consumed by anyone
outside of SourceFile.
In this same vein, provide addImports instead of setImports, since imports
are always additive.
No visible functionality change.
Swift SVN r26634
This flag indicates that internal APIs within the module should be made
available to client code for testing purposes. Currently does nothing.
Not ready for developer consumption yet, ergo a hidden frontend-only flag.
Part of testability (rdar://problem/17732115)
Swift SVN r26292
Separate InputFileKind from SourceFileKind, FrontendOptions will now use
InputFileKind, while Module will use SourceFileKind.
This is in preparation for adding an input file kind for LLVM IR.
rdar://19048891
Swift SVN r25555
Also into a separate file.
Before (swift/Serialization/SerializedModuleLoader.h):
ModuleStatus
SerializedModuleLoader::ValidationInfo
SerializedModuleLoader::ExtendedValidationInfo
SerializedModuleLoader::isSerializedAST
SerializedModuleLoader::validateSerializedAST
After (swift/Serialization/Validation.h):
serialization::Status
serialization::ValidationInfo
serialization::ExtendedValidationInfo
serialization::isSerializedAST
serialization::validateSerializedAST
No functionality change, just a lot of renaming and a bit of reorganizing.
Swift SVN r25226
Until we get a proper fix for rdar://problem/19720334 to close the .pcm
files immediately after reading them, forcefully close all the .pcm file
descriptors at the end of performSema. This avoids file descriptor
leaks that eventually bring down SourceKit.
rdar://problem/19059478
Swift SVN r25038
This implicitly adds the named module as an import of every source file
in the module being compiled. This is not intended to be used generally,
but will be useful for playgrounds.
rdar://problem/19605934
Swift SVN r24905
Parser may stop at some erroneous constructions like stray #else or #endif, in some cases closing brace ‘}’, etc…
continue parsing until we are done.
Swift SVN r24822
This has been long in coming. We always had it in IRGenOpts (in string form).
We had the version number in LangOpts for availability purposes. We had to
pass IRGenOpts to the ClangImporter to actually create the right target.
Some of our semantic checks tested the current OS by looking at the "os"
target configuration! And we're about to need to serialize the target for
debugging purposes.
Swift SVN r24468
These are the same dependencies collected for .d files, including
headers and imported swiftmodules. These can also cause a file to be out
of date.
Part of rdar://problem/19270920
Swift SVN r24334
This is a hidden frontend-only option intended for debugging purposes,
mainly for identifying where in a file the type checker is spending most
of its time. Use with "sort -g" to get the top problem functions.
Swift SVN r23789
This should have been done a long time ago since SILOptions are options that
should be able to effect everything SIL related. In this case I just want to
pass in a flag on the SILModule to enable +0 self. By putting it on the
SILModule I can conveniently check it in SILFunctionType without exposing any
internal state from SILFunctionType.cpp.
Swift SVN r23647
Objective-C method unintended override checking is one such case where
properly checking unintended overrides requires us to essentially look
at the whole module, because one translation unit may declare
something that produces an Objective-C method "setFoo:" in a
superclass while another translation unit declares something with a
distinct name that produces an Objective-C method "setFoo:". So, when
we don't have a primary file (e.g., when we're doing the merge-module
step), delay such checks until after all the source files for the
module have been type-checked. When there is a primary file, we
perform the checking that we can based on type checking that primary
file (and whatever got touched along the way), so we get a subset of
the proper diagnostics.
Swift SVN r23179
This tracks top-level qualified and unqualified lookups in the primary
source file, meaning we see all top-level names used in the file. This
is part of the intra-module dependency tracking work that can enable
incremental rebuilds.
This doesn't quite cover all of a file's dependencies. In particular, it
misses cases involving extensions defined in terms of typealiases, and
it doesn't yet track operator lookups. The whole scheme is also very
dependent on being used to track file-level dependencies; if C is a subclass
of B and B is a subclass of A, C doesn't appear to depend on A. It only
works because changing A will mark B as dirty.
Part of rdar://problem/15353101
Swift SVN r22925
