Enables Chris's auto-apply-fixes mode for -verify: if an expected-*
annotation has the wrong message, or if the expected fix-its are
incorrect, this option will **edit the original file** to update them.
This is a tool for compiler developers only; it doesn't affect
normal diagnostic printing or normal fix-its.
Given a source location, we can find the innermost enclosing scope
that describes that source location. Introduce this operation into the
scope map, then add a testing mode where we probe the scope map at
specifi locations to see what we find. Test for:
1) Finding the right innermost enclosing scope, and
2) That we're only expanding the part of the scope map that is needed
to identify that scope.
The scope map models all of the name lookup scopes within a source
file. It can be queried by source location to find the innermost scope
that contains that source location. Then, one can follow the parent
pointers in the scope to enumerate the enclosing scopes.
The scope map itself is lazily constructed, only creating scope map
nodes when required implicitly (e.g, when searching for a particular
innermost scope) or forced for debugging purposes.
using a lazily-constructed tree that can be searched by source
location. A search within a particular source location will
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).
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.
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.
This times each phase of compilation, so you can see where time is being
spent. This doesn't cover all of compilation, but does get all the major
work being done.
Note that these times are non-overlapping, and should stay that way.
If we add more timers, they should go in a different timer group, so we
don't end up double-counting.
Based on a patch by @cwillmor---thanks, Chris!
Example output, from an -Onone build using a debug compiler:
===-------------------------------------------------------------------------===
Swift compilation
===-------------------------------------------------------------------------===
Total Execution Time: 8.7215 seconds (8.7779 wall clock)
---User Time--- --System Time-- --User+System-- ---Wall Time--- --- Name ---
2.6670 ( 30.8%) 0.0180 ( 25.3%) 2.6850 ( 30.8%) 2.7064 ( 30.8%) Type checking / Semantic analysis
1.9381 ( 22.4%) 0.0034 ( 4.8%) 1.9415 ( 22.3%) 1.9422 ( 22.1%) AST verification
1.0746 ( 12.4%) 0.0089 ( 12.5%) 1.0834 ( 12.4%) 1.0837 ( 12.3%) SILGen
0.8468 ( 9.8%) 0.0171 ( 24.0%) 0.8638 ( 9.9%) 0.8885 ( 10.1%) IRGen
0.6595 ( 7.6%) 0.0142 ( 20.0%) 0.6737 ( 7.7%) 0.6739 ( 7.7%) LLVM output
0.6449 ( 7.5%) 0.0019 ( 2.6%) 0.6468 ( 7.4%) 0.6469 ( 7.4%) SIL verification (pre-optimization)
0.3505 ( 4.1%) 0.0023 ( 3.2%) 0.3528 ( 4.0%) 0.3530 ( 4.0%) SIL optimization
0.2632 ( 3.0%) 0.0005 ( 0.7%) 0.2637 ( 3.0%) 0.2639 ( 3.0%) SIL verification (post-optimization)
0.0718 ( 0.8%) 0.0021 ( 3.0%) 0.0739 ( 0.8%) 0.0804 ( 0.9%) Parsing
0.0618 ( 0.7%) 0.0010 ( 1.4%) 0.0628 ( 0.7%) 0.0628 ( 0.7%) LLVM optimization
0.0484 ( 0.6%) 0.0011 ( 1.5%) 0.0495 ( 0.6%) 0.0495 ( 0.6%) Serialization (swiftmodule)
0.0240 ( 0.3%) 0.0006 ( 0.9%) 0.0246 ( 0.3%) 0.0267 ( 0.3%) Serialization (swiftdoc)
0.0000 ( 0.0%) 0.0000 ( 0.0%) 0.0000 ( 0.0%) 0.0000 ( 0.0%) Name binding
8.6505 (100.0%) 0.0710 (100.0%) 8.7215 (100.0%) 8.7779 (100.0%) Total
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
...and always serialize -working-directory for Clang. (But allow it to be
overridden by a later -Xcc -working-directory.)
Not having this has caused plenty of headaches for the debugger, which is the
primary client of this information. We can still get into bad situations with
search paths that don't exist at all (say, when a built framework is transferred
to another computer), but at least we won't fall over in multi-project workspaces.
This isn't an actual command-line option for a few reasons:
- SourceKit is still using frontend options directly, and they'll need something
like this to fix rdar://problem/21912068.
- We might want to be more formal about passing this to Clang.
- I don't actually like the existence of such an option for users.
We can revisit this later if the scales tip. Fixing the debugging issue is the
priority.
rdar://problem/21857902
Swift SVN r30500
Compute the hash of all interface tokens when parsing; write the
interface hash to the swiftdeps file, or if the -dump-interface-hash
option is passed to the frontend. This hash will be used in incremental
mode to determine whether a file's interface has changed, and therefore
whether dependent files need to be rebuilt in response to the change.
Committed on ChrisW's behalf while he gets his setup unborked.
rdar://problem/15352929
Swift SVN r30477
This works around a big performance regression in code completion
performance that was introduced with r25741. This hack does not work
completely correctly with multiple file builds, but a) this should be a
minor issue for enum code completions, and b) this simply returns to the
pre-25741 behaviour. This hack should disappear when we fix
rdar://problem/20047340.
For rdar://problem/20445407.
Swift SVN r27320
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
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
This will be needed for split-llvm code generation.
If multiple -o options are specified and only a single output file is needed
(currently always), the last one wins. This is NFC.
Swift SVN r25884
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
This is mainly for the debugger's use, to set up CompilerInvocations that
match how a particular app was compiled in certain important ways. Today
that's the target (which is also in the binary), the SDK path (which in
the long run should probably be an SDK name), and any random -Xcc options
we need to pass (which we should probably attempt to minimize).
Because there's only one target and SDK per context, and because -Xcc
options can easily conflict, this is only intended to be used once per
CompilerInvocation.
Note that search paths are not covered by this; they are already being
added at the time the module is loaded. See r24545.
Completes rdar://problem/17670778.
Swift SVN r25227
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
There's also a testing option, -serialize-debugging-options, to force this
extra info to be serialized even for library targets. In the long run we'll
probably write out this information for all targets, but strip it out of
the "public module" when a framework is built. (That way it ends up in the
debug info's copy of the module.)
Incidentally, this commit includes the ability to add search paths to the
Clang importer on the fly, which is most of rdar://problem/16347147.
Unfortunately there's no centralized way to add search paths to both Clang
/and/ Swift at the moment.
Part of rdar://problem/17670778
Swift SVN r24545
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
This refactoring is groundwork for saving the cross-module dependencies
in the swiftdeps files as well, so that we know to rebuild files if an
outside file changes (such as a bridging header, another framework's
headers, or another framework's swiftmodule).
Part of rdar://problem/19270920
Swift SVN r24258
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
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
llvm::Optional lives in "llvm/ADT/Optional.h". Like Clang, we can get
Optional in the 'swift' namespace by including "swift/Basic/LLVM.h".
We're now fully switched over to llvm::Optional!
Swift SVN r22477
This may be something to refactor in the future, but for now the two sets
of options need the module name for entirely different reasons.
rdar://problem/17918172, again.
Swift SVN r22150
