A vestigial remnant of it was left behind after
06921cfe84 in order to avoid a reverse
condfail when building old swiftinterfaces that define
```swift
func _copy<T>(_ value: T) -> T {
#if $BuiltinCopy
Builtin.copy(value)
#else
value
#endif
}
```
If the language feature is removed, though, such interfaces should again
be buildable because the branch where the language feature isn't defined
should be expanded.
rdar://127516085
The copy operator has been implemented and doesn't use it. Remove
`Builtin.copy` and `_copy` as much as currently possible.
Source compatibility requires that `_copy` remain in the stdlib. It is
deprecated here and just uses the copy operator.
Handling old swiftinterfaces requires that `Builtin.copy` be defined.
Redefine it here as a passthrough--SILGen machinery will produce the
necessary copy_addr.
rdar://127502242
Originally move when it was in the stdlib as _move was behind a keyword but we
moved it in front to allow for some testing. Now that we are going with a
keyword (which we can't leave in/deprecate) move it behind the move only
experimental flag until this gets through evolution.
I also updated the move function tests to show that this is working. As a nice
bonus, I was able to enable all of the tests also in a non-optimized stdlib.
The error diagnostic tells the user that the compiler can't check the value. It
then instructs the user to make a feature request and provide the test case if
they think it is reasonable. I also provided an option to disable the diagnostic
to unblock people.
The reason why I think this is the right thing to do is we want people to know
that _move means they do not need to worry about the given binding being used
later in the program in some way without having to reason. For now I am doing
this by banning _move on non-lets, non-params. This is implemented by noting
that:
1. _move inserts move_value [allows_diagnostics].
2. The checker always removes [allows_diagnostics] after checking a _move.
Thus we know after we check, any move_value that is still marked with
[allows_diagnostic], it was a _move that we never used in any checking.
I added some test cases where this known triggers. I am either going to
implement some sort of support for performing _move on them or give a more
specific diagnostic. This is just an initial incremental step.
The key thing is that the move checker will not consider the explicit copy value
to be a copy_value that can be rewritten, ensuring that any uses of the result
of the explicit copy_value (consuming or other wise) are not checked.
Similar to the _move operator I recently introduced, this is a transparent
function so we can perform one level of specialization and thus at least be
generic over all concrete types.
