Re-apply "Rename @transparent to @_transparent for now."

This re-applies 90fcbfe. I'll be committing
the corresponding change to Foundation momentarily.

docs/Modules.rst

@@ -98,7 +98,7 @@ Modules can also contain `autolinking` information, which the compiler passes
 on to the linker. This can be used to specify which library implements the
 declarations in the module.
 
-.. [#] Specifically, code marked with the ``[transparent]`` attribute is
+.. [#] Specifically, code marked with the ``@_transparent`` attribute is
    required to be "transparent" to the compiler: it *must* be inlined and
    will affect diagnostics.
 

docs/Serialization.rst

@@ -132,7 +132,7 @@ organizational purposes.
 - The **SIL block** contains SIL-level implementations that can be imported
   into a client's SILModule context. In most cases this is just a performance
   concern, but sometimes it affects language semantics as well, as in the case
-  of ``@transparent``. The SIL block precedes the AST block because it affects
+  of ``@_transparent``. The SIL block precedes the AST block because it affects
   which AST nodes get serialized.
 
 - The **SIL index black** contains tables for accessing various SIL entities by

docs/TransparentAttr.rst

@@ -1,35 +1,35 @@
 :orphan:
 
-``@transparent``
-================
+``@_transparent``
+=================
 
-Semantically, ``@transparent`` means something like "treat this operation as if
-it were a primitive operation". The name is meant to imply that both the
+Semantically, ``@_transparent`` means something like "treat this operation as
+if it were a primitive operation". The name is meant to imply that both the
 compiler and the compiled program will "see through" the operation to its
 implementation.
 
 This has several consequences:
 
-- Any calls to a function marked ``@transparent`` MUST be inlined prior to
+- Any calls to a function marked ``@_transparent`` MUST be inlined prior to
   doing dataflow-related diagnostics, even under ``-Onone``. This may be
   necessary to *catch* dataflow errors.
 
-- Because of this, a ``@transparent`` function is inherently "fragile", in that
-  changing its implementation most likely will not affect callers in existing
-  compiled binaries.
+- Because of this, a ``@_transparent`` function is inherently "fragile", in
+  that changing its implementation most likely will not affect callers in
+  existing compiled binaries.
 
-- Because of this, a ``@transparent`` function MUST only reference public
+- Because of this, a ``@_transparent`` function MUST only reference public
   symbols, and MUST not be optimized based on knowledge of the module it's in.
   [This is not currently implemented or enforced.]
 
 - Debug info SHOULD skip over the inlined operations when single-stepping
   through the calling function.
 
-This is all that ``@transparent`` means.
+This is all that ``@_transparent`` means.
 
 
-When should you use ``@transparent``?
--------------------------------------
+When should you use ``@_transparent``?
+--------------------------------------
 
 - Does the implementation of this function ever have to change? Then you can't
   allow it to be inlined.
@@ -42,19 +42,19 @@ When should you use ``@transparent``?
 
 - Is it okay if the function is *not* inlined? You'd just prefer that it were?
   Then you should use [the attribute we haven't designed yet], rather than
-  ``@transparent``. (If you really need this right now, try
+  ``@_transparent``. (If you really need this right now, try
   ``@inline(__always)``.)
 
 - Is it a problem if the function is inlined even under ``-Onone``? Then you're
   really in the previous case. Trust the compiler.
 
 - Is it a problem if you can't step through the function that's been inlined?
-  Then you don't want ``@transparent``; you just want ``@inline(__always)``.
+  Then you don't want ``@_transparent``; you just want ``@inline(__always)``.
 
 - Is it okay if the inlining happens after all the dataflow diagnostics? Then
-  you don't want ``@transparent``; you just want ``@inline(__always)``.
+  you don't want ``@_transparent``; you just want ``@inline(__always)``.
 
-If you made it this far, it sounds like ``@transparent`` is the right choice.
+If you made it this far, it sounds like ``@_transparent`` is the right choice.
 
 
 Current implementation limitations
@@ -79,5 +79,5 @@ Current implementation limitations
 
 - Similarly, when compiling in non-single-frontend mode, no SIL is generated for
   any functions but those in the primary file (for each frontend invocation),
-  including ``@inline(__always)`` and ``@transparent`` functions. This is
+  including ``@inline(__always)`` and ``@_transparent`` functions. This is
   semantically a bug. rdar://problem/15366167

docs/proposals/C Pointer Argument Interop.rst

@@ -259,7 +259,7 @@ An example of a conformance for ``CMutablePointer``::
 
     typealias InOutType = T
 
-    @transparent
+    @_transparent
     static func _convertFromInOutAddress(p: Builtin.RawPointer)
     -> CMutablePointer {
       return CMutablePointer(p)
@@ -315,23 +315,23 @@ An example of a conformance for ``ObjCInOut``::
     typealias InOutType = T!
     typealias WritebackType = Builtin.RawPointer
 
-    @transparent
+    @_transparent
     static func _createWriteback(inout ref: T!)
     -> Builtin.RawPointer {
       // The initial object reference is passed into the callee effectively
       // __unsafe_unretained, so pass it as a RawPointer.
       return unsafeBitCast(ref, Builtin.RawPointer.self)
     }
 
-    @transparent
+    @_transparent
     static func _commitWriteback(inout ref: T!,
                                  value: Builtin.RawPointer) {
       // The reference is autoreleased on return from the caller, so retain it
       // by loading it back as a T?.
       ref = unsafeBitCast(value, T!.self)
     }
 
-    @transparent
+    @_transparent
     static func _convertFromWritebackAddress(value: Builtin.RawPointer) {
       return ObjCInOut(value)
     }

include/swift/AST/Attr.def

@@ -148,7 +148,7 @@ SIMPLE_DECL_ATTR(infix  , Infix  , OnFunc | OnOperator | DeclModifier, 23)
 SIMPLE_DECL_ATTR(prefix , Prefix , OnFunc | OnOperator | DeclModifier, 24)
 SIMPLE_DECL_ATTR(postfix, Postfix, OnFunc | OnOperator | DeclModifier, 25)
 
-SIMPLE_DECL_ATTR(transparent, Transparent,
+SIMPLE_DECL_ATTR(_transparent, Transparent,
                  OnFunc|OnConstructor|OnVar|OnExtension|UserInaccessible, 26)
 SIMPLE_DECL_ATTR(requires_stored_property_inits, RequiresStoredPropertyInits,
                  OnClass, 27)

include/swift/AST/DiagnosticsSema.def

@@ -691,13 +691,13 @@ ERROR(static_functions_not_mutating,sema_tcd,none,
       "static functions may not be declared mutating", ())
 
 ERROR(transparent_stored_property,sema_tcd,none,
-      "@transparent cannot be applied to stored properties", ())
+      "@_transparent cannot be applied to stored properties", ())
 ERROR(transparent_on_invalid_extension,sema_tcd,none,
-      "@transparent is only supported on struct and enum extensions", ())
+      "@_transparent is only supported on struct and enum extensions", ())
 ERROR(transparent_in_protocols_not_supported,sema_tcd,none,
-      "@transparent is not supported on declarations within protocols", ())
+      "@_transparent is not supported on declarations within protocols", ())
 ERROR(transparent_in_classes_not_supported,sema_tcd,none,
-      "@transparent is not supported on declarations within classes", ())
+      "@_transparent is not supported on declarations within classes", ())
 
 ERROR(invalid_iboutlet,sema_tcd,none,
       "only instance properties can be declared @IBOutlet", ())