Fixed for the difference of Cygwin with other Windows variants (MSVC,
Itanium, MinGW).
- The platform name is renamed to "cygwin" from "windows" which is used
for searching the standard libraries.
- The consideration for DLL storage class (DllExport/DllImport) is not
required for Cygwin and MinGW. There is no problem when linking in
these environment.
- Cygwin should use large memory model as default.(This may be changed
if someone ports to 32bit)
- Cygwin and MinGW should use the autolink feature in the sameway of
Linux due to the linker's limit.
The sentence in the comment trailed off even when it was added in
64a6a739, but the author may have meant putting arbitrary keys in the
Objective-C image info.
Changes:
* Terminate all namespaces with the correct closing comment.
* Make sure argument names in comments match the corresponding parameter name.
* Remove redundant get() calls on smart pointers.
* Prefer using "override" or "final" instead of "virtual". Remove "virtual" where appropriate.
The Darwin linker won't process the debug info if the source file name
is invalid so there is no point in having a fallback implemented there.
<rdar://problem/25130236>
Fixes IRGen test failures that only arise in non-asserts builds that
we've apparently been working around in less principled ways for
the last few months.
The force load symbol was not marked as DLL export. This would result in the
symbol not being emitted into the import library and consequently not being
available to the consumer. This ensures that the symbol is visible outside of
the module.
Add initial support for modelling DLL Storage semantics for global values. This
is needed to support the indirect addressing mechanism used on Windows.
Background
----------
Now that Swift AST type support in LLDB has matured, we can stop emitting DWARF
type information by default to reduce compile time and ibject file size.
A future commit will change -g to emit only AST type references.
The full set of debug options will be
-gnone
-gline-tables-only
-g // AST types (= everything that LLDB needs)
-gdwarf-types // AST types + DWARF types (for legacy debuggers)
Use the target specific directive generation. This addresses a TODO to use the
same logic as clang. Unfortunately, the logic in clang is not accessible
outside of it, so replicate the behaviour.
@convention(witness_method) values were changed to carry a pointer to their source witness table, but the type info wasn't changed to match. Fixing this fixes rdar://problem/26268544.
COFF supports the `.drectve` section for embedding linker directives. LLVM has
long supported emitting this section. With this move, ELF shall become the only
target needing the autolink-extract functionality.
Clang IR-generation can fail. When it does this, it destroys the
module. Previously, we were blithely assuming this couldn't happen,
and so we would crash on the deallocated module. Delay the
finalization of the Clang code generator until our own module
finalization, which is a more appropriate place for it anyway,
and then just bail out of the last few steps if Clang fails.
Now we can discern the types of values in heap boxes at runtime!
Closure reference captures are a common way of creating reference
cycles, so this provides some basic infrastructure for detecting those
someday.
A closure capture descriptor has the following:
- The number of captures.
- The number of sources of metadata reachable from the closure.
This is important for substituting generics at runtime since we
can't know precisely what will get captured until we observe a
closure.
- The number of types in the NecessaryBindings structure.
This is a holding tank in a closure for sources of metadata that
can't be gotten from the captured values themselves.
- The metadata source map, a list of pairs, for each
source of metadata for every generic argument needed to perform
substitution at runtime.
Key: The typeref for the generic parameter visible from the closure
in the Swift source.
Value: The metadata source, which describes how to crawl the heap from
the closure to get to the metadata for that generic argument.
- A list of typerefs for the captured values themselves.
Follow-up: IRGen tests for various capture scenarios, which will include
MetadataSource encoding tests.
rdar://problem/24989531
In order to perform layout, the remote mirrors library needs to know
about the size, alignment and extra inhabitants of builtin types.
Ideally we would emit a reflection info section in libswiftRuntime.o,
but in the meantime just duplicate builtin type metadata for all
builtin types referenced from the current module instead.
In practice only the stdlib and a handful of overlays like the SIMD
overlay use builtin types, and only a few at a time.
Tested manually by running swift-reflection-tool on the standard
library -- I'll add automated tests by using -parse-stdlib to
reference Builtin types in a subsequent patch that adds more layout
logic.
NFC if -enable-reflection-metadata is off.
The size of a protocol's metadata was not a multiple of 8 bytes, so
on 64-bit platforms, the runtime would copy default witnesses from
the wrong address, because IRGen metadata does not add alignment padding,
whereas the in-memory structure does.
Fix this by adding a 32-bit padding field at the end of the protocol
descriptor. Technically this is not necessary on 32-bit, but this keeps
things simpler for now.
The test case for this is a library evolution test exercising resilient
default protocol requirements, but it is not quite ready to go in yet.
In the rare cases where C style comments are needed sticking with the
one line form is preferred to allow for quick comment analysis by
simple methods such as:
$ git grep -E '(//|/\*.*\*/)'
When using the single line form the command above is guaranteed to
include all comment content (+ some non-comment content), which
greatly simplifies quick comment analysis.
"minimal" is defined as the set of requirements that would be
passed to a function with the type's generic signature that
takes the thick metadata of the parent type as its only argument.
This was a very subtle bug, which occurred only in interpreter mode under Linux.
The actual name of the symbol should be artificially prefixed by an underscore,
because this underscore is stripped during a symbol lookup in interpreter mode.
If this is not done, then a reference to variable "_x" is being resolved as a reference
to the function "x"!
Teach IRGen how to handle runtime functions definitions in RuntimeFunctions.def
depending on their calling convention and on their need for global symbols referring
to their internal implementations.
IRGen would now generate wrappers for runtime functions invocations if at least one
of the following conditions is met:
- The runtime function is defined using FUNCTION_WITH_GLOBAL_SYMBOL_AND_IMPL,
which explicitly states that it has a global symbol referring to its implementation. In this case,
the generated wrapper will perform an indirect call using the specified global symbol.
This results in some performance improvements, because doing so removes one level of
indirection during a call of the runtime function.
The invocation sequence before looked like:
Swift code -> dynamic linker stub -> runtime_function -> indirect call of runtime_function's implementation through a global function pointer
And using a wrapper it becomes:
Swift code -> wrapper -> indirect call of runtime_function's implementation through a global function pointer
- The runtime function is defined using the usual FUNCTION x-macro but it uses a calling convention
that requires that wrappers should be used instead of dynamic linker stubs to avoid the situations
where the dynamic linker would clobber some of the callee-saved registers when it performs a lazy
binding of the runtime function, which may lead to an undefined behaviour during the program execution.
In this case, the behaviour is similar to the first case, except that the name of the global symbol for
the runtime function f is assumed to be _f, i.e. it has an underscore as a prefix. This symbol
will be auto-generated and properly initialized by an x-macro based metaprogramming machinery
in the runtime library.
