A recent PR (#77204) started to import C++ source locations into Swift.
This PR flips a switch so these locations are actually used more widely.
Now some of the diagnostic locations are changed, but they generally
improved the quality of the diagnostics, pointing out conformances
imported from Obj-C code right when they are declared.
This applies the same changes from Clang CFE r349065 to the Swift
frontend to unify how filenames, cmpilation directories and absolute
paths in filenames and path remappings are handled.
The loading of additional modules by Sema may trigger an out-of-date
PCM rebuild in the Clang module dependencies of the additional
module. A PCM rebuild causes the ModuleManager to unload previously
loaded ASTFiles. For this reason we must use the cached ASTFile
information here instead of the potentially dangling pointer to the
ASTFile that is stored in the clang::Module object.
This fixes a crash in IRGenDebugInfo when generation DIModule context
chains.
rdar://problem/47600180
conversions that reverse an implicit conversion done to align
foreign declarations with their imported types.
For example, consider an Objective-C method that returns an NSString*:
- (nonnull NSString*) foo;
This will be imported into Swift as a method returning a String:
func foo() -> String
A call to this method will implicitly convert the result to String
behind the scenes. If the user then casts the result back to NSString*,
that would normally be compiled as an additional conversion. The
compiler cannot simply eliminate the conversion because that is not
necessarily semantically equivalent.
This peephole recognizes as-casts that immediately reverse a bridging
conversion as a special case and gives them special power to eliminate
both conversions. For example, 'foo() as NSString' will simply return
the original return value. In addition to call results, this also
applies to call arguments, property accesses, and subscript accesses.
All refutable patterns and function parameters marked with 'var'
is now an error.
- Using explicit 'let' keyword on function parameters causes a warning.
- Don't suggest making function parameters mutable
- Remove uses in the standard library
- Update tests
rdar://problem/23378003
And include some supplementary mangling changes:
- Give the first generic param (depth=0, index=0) a single character mangling. Even after removing the self type from method declaration types, 'Self' still shows up very frequently in protocol requirement signatures.
- Fix the mangling of generic parameter counts to elide the count when there's only one parameter at the starting depth of the mangling.
Together these carve another 154KB out of a debug standard library. There's some awkwardness in demangled strings that I'll clean up in subsequent commits; since decl types now only mangle the number of generic params at their own depth, it's context-dependent what depths those represent, which we get wrong now. Currying markers are also wrong, but since free function currying is going away, we can mangle the partial application thunks in different ways.
Swift SVN r32896
prologue is handled in the line table.
We now mark the first instruction after the stack setup as end_prologue and
any further initilizations (which may include function calls to metadata
accessors) with line 0 which lldb will skip. This allows swiftc to emit
debug info for compiler-generated functions such as metadata accessors.
Mixing debug and non-debug functions is not very well supported by LLVM
and the resulting line table makes it impossible for LLDB to determine
where a function with debug info ends and a nondebug function starts.
rdar://problem/23042642
Swift SVN r32816
MDModule was a bitcode-incompatible internal-only extension that has
since been replaced with a blessed IR node on trunk.
<rdar://problem/20965932> Upstream DIModule and support it in clang-700, swiftlang-700, and lldb-700
Swift SVN r29832
The Clang importer introduces a number of synthesized conformances for
imported enums (normal, NS_ENUMS, or NS_OPTIONS-based all have the
same issue) that aren't used in most translation units. Rather than go
through the effort of fully checking these conformances and generating
SIL for them always, rely on semantic analysis to force them to be
fully checked when the conformance is required. This cuts down on the
amount of work we need to do for imported enumeration types
considerably. For a simple program consisting of only:
import Foundation
var str = NSString()
My not-entirely-scientific measurements show that:
* Time to parse + type-check is reduced by 34%
* Time to generate SIL is reduced by 50%
* Time to generate IR is reduced by 47%
* SIL output size is reduced by 66%
Fixes rdar://problem/20047340.
Swift SVN r27946
