Enable checking for uses of potentially unavailable APIs. There is
a frontend option to disable it: -disable-availability-checking.
This commit updates the SDK overlays with @availability() annotations for the
declarations where the overlay refers to potentially unavailable APIs. It also changes
several tests that refer to potentially unavailable APIs to use either #available()
or @availability annotations.
Swift SVN r27272
Remove the suppression of deprecation and potential unavailability diagnostics in
synthesized functions. We still suppress some explicit unavailability diagnostics -- those
in synthesized functions in synthesized functions that are lexically contained in
declarations that are themselves annotated as unavailable. For these cases, the right
solution <rdar://problem/20491640> is to not synthesize the bodies of these functions in
the first place.
rdar://problem/20024980
Swift SVN r27203
We're not going to require the type parameters to be redeclared on
extensions of generic types, so take away the staging option and
diagnostic.
Swift SVN r26854
In particular, this is problematic when libraries are loaded dynamically, and
may have newer deployment targets than the main executable.
Swift SVN r26786
...which allows "@testable import" to work with modules not compiled for
testing. This isn't generally safe, but should be fine for clients like
SourceKit which just need to have the API available and might not be able
to properly rebuild the original target for testing.
We may revisit this in the future.
Swift SVN r26629
This flag enables checking of availability (deprecation, explicit unavailability,
and potential unavailability) in synthesized functions. The flag will go away once this
checking is fully staged in.
Swift SVN r26624
Up to now we've been assuming that we have only one 32-bit target and
one 64-bit target per platform. There is a need to be able to build
armv7s for iOS, but assumptions abound in the organization of files per
architecture - tests, cmake targets, and installation.
- Build armv7s when building for iOS
- Use the actual architecture name, not blank or "/32" in all paths
related to architecture.
Testing: Clean buildbot incremental RA tests pass (requires a test
update in SourceKit as well).
rdar://problem/20206215
Swift SVN r26600
This warning is temporarily going being a flag so that, once it is safe to place generic parameters on extensions of generic types, we can opt-in to update our code when it is convenient.
Swift SVN r26416
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
Make this diagnostic a little nicer in other ways, too:
- Highlight the whole attribute (including the at-sign).
- Don't hardcode the string "objc".
Swift SVN r25999
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
As per discussion on the mailing list we don't want different behavior for
programmer errors at Ounchecked than at O for errors that are not diagnosable.
Neither O nor Ounchecked will now emit LLVM's NoAlias attribute for inout
parameters.
rdar://20041458
Swift SVN r25784
We have to guarantee memory safety in the presence of the user violating the
inout assumption. Claiming NoAlias for parameters that might alias is not
memory safe because LLVM will optimize based on that assumption.
Unfortunately, this means that llvm can't optimize arrays as aggressively. For
example, the load of array->buffer won't get hoisted out of loops (this is the
Sim2DArray regression below).
-O numbers (before/after):
CaptureProp 0.888365
Chars 1.09143
ImageProc 0.917197
InsertionSort 0.895204
JSONHelperDeserialize 0.909717
NSDictionaryCastToSwift 0.923466
Sim2DArray 0.76296
SwiftStructuresBubbleSort 0.897483
Continue emitting noalias for inout when compiling Ounchecked.
rdar://20041458
Swift SVN r25770
Move helper function EmbedBitcode() from frontend_main.cpp to IRGen.cpp so we
can call it from performIRGeneration when the input file is Swift.
Add testing case to make sure that -embed-bitcode-marker option adds an
empty LLVM bitcode section.
rdar://19048891
Swift SVN r25577
With -embed-bitcode, save a copy of the llvm IR as data in the __LLVM,__bitcode
section and save the command-line options in the __LLVM,__cmdline section.
rdar://19048891
Swift SVN r25560
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
Since a function pointer doesn't carry any context, we can only form a C function pointer from a static reference to a global function or a context-free local function or closure. (Or maybe a static function applied to its metatype, but that's not handled here yet.) As a placeholder for a to-be-bikeshedded surface syntax, let the existing @cc(cdecl) attribute appear in source text when the -enable-c-function-pointers frontend flag is passed.
Swift SVN r25308
This adds the -profile-coverage-mapping option to swift, and teaches
SILGenProfiling to generate mappings from source ranges to counters.
Swift SVN r25266
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 adds the -profile-generate flag, which enables LLVM's
instrumentation based profiling. It implements the instrumentation
for basic control flow, such as if statements, loops, and closures.
Swift SVN r25155
We've had a rash of bugs due to inconsistencies between how IRGen and the runtime think types are laid out. Add a '-verify-type-layout' mode to the frontend that causes IRGen to emit a bunch of code that compares its static assumptions against what the runtime value witness does.
Swift SVN r24918
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
If a subclass overrides methods with variance in the optionality of non-class-type members, emit a thunk to handle wrapping more optional parameters or results and force-unwrapping any IUO parameters made non-optional in the derived. For this to be useful, we need IRGen to finally pay attention to SILVTables, but this is a step on the way to fixing rdar://problem/19321484.
Swift SVN r24705
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 flag enables one to specify a json file that expresses a specific
pipeline in the following format:
[
[
"$PASS_MANAGER_ID",
"run_n_times"|"run_to_fixed_point",
$NUM_ITERATIONS,
"$PASS1", "$PASS2", ...
],
...
]
This will make it easier to experiment with different pass pipelines by
allowing:
1. Automatic generation of pass pipelines without needing to recompile
the compiler itself.
2. Simple scripting of pass pipelines via the json meta language.
3. Enabling the easy expression and reproducability of a specific
pipeline ordering via radar.
In the next commit I will provide a python library for the generation of these
json files with a few types of pipeline generators already created.
Swift SVN r24055
...and then honor them.
While here, make -l a little more flexible (see interpret_with_options test).
rdar://problem/17830826, which unblocks the LLDB feature for the same.
Swift SVN r24033
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 does not have any tests since I am going to start going through SILGen
tests and updating them for guaranteed self as the appropriate tests.
*NOTE* There is more work to be done in terms of thunks, but the basic
functionality is done.
rdar://15729033
Swift SVN r23653
