<rdar://problem/19104060>
LLVM's PointerIntPair always picks the highest bits of the available low
order free bits but NumLowBitsAvailable is the number of *lowest* bits
available from the LSB. This could cause problems with overwriting when
putting a FlaggedPointer inside a PointerIntPair. Just don't allow it.
Add a static assert to make sure there are enough bits to support the
number of nested FlaggedPointers.
Add a helper constexpr min function which isn't available until C++14.
Swift SVN r23597
References to functions that take inout parameters crash the compiler
because InOutType isn't a "real" type in itself and has no special type
metadata to emit. It merely further qualifies the function's input
types.
For example, we would like to have a unique entry in the cache for:
var f: (T, T) -> ()
and
var f2: (inout T, T) -> ()
For each argument type metadata pointer in the function's input, take
advantage of pointer alignment and mark the lowest bit if it is inout.
Since the metadata cache uses pointers to create the key, this creates a
unique entry while still being able to extract the actual pointer.
This fixes <rdar://problem/17655125>, and a couple of other similar
crashes.
Swift SVN r23557
Also handles mangling, demangling, printing and parsing.
This is the first patch to use global getter for "let" globals.
rdar://16614767
Swift SVN r23106
Whenever we add a requirement, we now know
(1) Why we added the requirement, e.g., whether it was explicitly written, inferred from a signature, or introduced by an outer scope.
(2) Where in the source code that requirement originated.
Also add a debugging flag for dumping the archetype builder information, so we can write tests against it.
This is effectively NFC, but it's infrastructure to help a number of requirements-related tasks.
Swift SVN r22638
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 lets us reliably print and parse opened archetypes across different compiler invocations. Using a source-related locator would be ideal, but that's complicated by the need to manufacture, print, and parse these things during SIL passes, so cop out and burn a UUID for now.
Swift SVN r22385
Note that the demangling for 'a' accessors changes from
'addressor' to 'mutableAddressor'. This is correct for
the existing use-case of global variables, which permit
modification through the result.
Swift SVN r22254
This patch adds the ability (-enable-experimental-unavailable-as-optional) to
treat potentially unavailable declarations as if they had optional types. For
the moment, this is only implemented for global variables.
The high-level approach is to (1) record the potential unavailability of a
declaration reference in the overload choice during constraint generation; (2)
treat the declaration as if it had an optional type during overload resolution
(this is similar to how optional protocol members are treated); and (3) add an
implicit conversion (UnavailableToOptionalExpr) during constraint application
to represent the run-time availability check and optional injection.
This patch does not implement SILGen for UnavailableToOptionalExpr.
Swift SVN r22245
FixNum.h and BCRecordLayout.h will move down into LLVM, APINotes
will move into Clang. Get the namespaces right before we start to move
files around.
Swift SVN r22218
for testing purposes.
When enabled, if the typechecker tries to typecheck a decl or unresolved identifier with the provided
prefix, then an llvm fatal_error will get triggered.
This approach has the advantage that it is very easy to write tests for unnecessary typechecking for a wide range of functionality,
for the compiler or SourceKit, for code-completion, indexing, etc.
Swift SVN r22003
Some of the buffers are owned by the ClangImporter, so after the
ClangImporter's been deallocated, the SourceManager isn't going to be fully
valid any more.
Should fix issues from r21958.
Swift SVN r21989
This rare crash happens when
1. A diagnostic is reported when building a Clang module.
2. The diagnostic is mapped to a Swift diagnostic by mirroring the Clang
source buffer as a Swift source buffer (via non-owning reference).
3. The Clang CompilerInstance used specifically to build the module is
destroyed.
4. Some /new/ buffer is allocated in the same memory spot as the old buffer.
5. Some new Clang diagnostic occurs in the new buffer.
6. The Swift source manager asserts when trying to set up a virtual name
for the diagnostic in the second imported buffer, because there's already
a name for that region.
The fix, because we don't expect diagnostics from modules to appear very
often, is to keep any clang::SourceManagers alive if diagnostics are emitted
in their buffers. We can revisit this if/when Swift's source manager
(currently built on llvm::SourceMgr) has the ability to remove buffers.
Many thanks to Greg for noticing the problem, tracking it down, and providing
a diff to make it fail reproducibly under GuardMalloc. I've tried to preserve
the spirit of that diff in the new logic in ~SourceManager, which will also
fail reliably with GuardMalloc (and probably ASan).
rdar://problem/18285805
Swift SVN r21958
...thus supporting "private var x: Int" in two different source files in the
same module.
This marks the completion of the bulk of the work for rdar://problem/17632175.
Remaining work is to make sure debugging does the right thing when processing
expressions in a particular source context.
Swift SVN r21851
We currently mangle private declarations exactly like public declarations,
which means that private entities with the same name and same type will
have the same symbol even if defined in separate files.
This commit introduces a new mangling production, private-decl-name, which
includes a discriminator string to identify the file a decl came from.
Actually producing a unique string has not yet been implemented, nor
serialization, nor lookup using such a discriminator.
Part of rdar://problem/17632175.
Swift SVN r21598
If a method is defined within an extension of a class or struct that is
defined in a different module, we mangle the module where the extension is
defined.
If we define function f in module A, and redefine it again in an extension in
module B, we use different mangling to prevent linking in the wrong
SILFunction.
rdar://18057875
Swift SVN r21488
Also, use 'Playground' to control the behavior of ignored expressions
(which are not an error because they are displayed in the playground log).
This is preparation for LLDB no longer passing 'DebuggerSupport' for a
playground <rdar://problem/18090611>. 'DebuggerSupport' now only applies
to REPL-like contexts and enables identifiers beginning with $, special
rules for parsing top-level code, ignored expressions (like playgrounds),
and the @LLDBDebuggerSupport attribute.
Besides ignored expressions, 'Playground' enables the playground transformation
and provides an entry point for debugger initialization.
Note that this is a bit insincere---many of the options controlled by both
'Playground' and 'DebuggerSupport' really only apply to the main source file
or main module. If/when we add back support for source file imports, we'll
need to revisit all of LangOptions and see which of them should /really/
apply to /everything/ in the ASTContext.
Swift SVN r21384
This is enabled by default because SILGen can crash when @objc is used without importing Foundation, but
it gets disabled when compiling the Swift stdlib.
Addresses rdar://17931250.
Related test case on the SourceKit side.
Swift SVN r21319
This allows UnicodeScalars to be constructed from an integer, rather
then from a string. Not only this avoids an unnecessary memory
allocation (!) when creating a UnicodeScalar, this also allows the
compiler to statically check that the string contains a single scalar
value (in the same way the compiler checks that Character contains only
a single extended grapheme cluster).
rdar://17966622
Swift SVN r21198
