Lift the limitation of a single active diagnostic, which was a pretty
easy-to-hit footgun. We now maintain an array of active in-flight
diagnostics, which gets flushed once all them have ended.
For a method key path use the locator for the apply itself rather
than the member, ensuring we handle invalid cases where the apply is
the first component, and providing more accurate location info.
The utility effectively determines whether a value leaks as part of its
work, a subset of the checking done by the ownership verifier. Disable
that checking when the flag that disables the ownership verifier is
passed.
Parameter type could be represented by an associated type which is
bound to a concrete type by an extension, `AbstractFunction::getType()`
should map it into context before returning because the construct is
that it always produces a function type.
Resolves: rdar://156955193
The invalid bit on PatternBindingDecl is very coarse grained, it
means any of the possible binding entries could be invalid.
Contextualization can handle invalid code anyway (e.g this is what we
do for `typeCheckBody`), so let's just avoid checking.
This new flag makes it easy to build Swift cross-compilation toolchains,
by disabling cross-compilation of all host tools, like the Swift
compiler and various macros, building on prior pulls #38441 and #82163.
Native compilation has more fine-grained flags like
`--build-swift-tools`, `--build-llvm`, and `--swift-testing-macros`, but
those will disable building them for _all_ platforms (with the exception
of `--build-swift-tools`, which I modified to only apply for the host,
since the initial introduction of this
`--cross-compile-build-swift-tools` flag a couple months ago), so
they're not suited for building a cross-compilation toolchain, where you
want all host tools built for the native host but not for any
cross-compilation SDKs.
Correct several behaviors of availability checking in unavailable contexts that
were inconsistent with the checking model:
- Avoid diagnosing unintroduced and obsolted declarations in contexts that are
unavailable in the same domain.
- Diagnose unavailability normally in type signature contexts.
This switches from using lit.cfg to attempt to recompute the module
triple to using the triple computed in CMake to ensure consistency.
This is a better source of truth than having many sources everywhere.
In case anyone sees this and is wondering, the "target triple" refers to
the triple that the compiler is built for, while the "variant triple"
refers to the platform that the tests and runtimes are built for.
FreeBSD isn't using toolchain files at the moment so this test is
failing. XFAIL'ing it on FreeBSD. If/when we do switch, the XFAIL should
fail, and we can re-enable it then.
Carefully overhaul our word breaking implementation to follow the recommendations of Unicode Annex #29. Start exposing the core primitives (as well as `String`-level interfaces), so that folks can prototype proper API for these concepts.
- Fix `_wordIndex(after:)` to always advance forward. It now requires its input index to be on a word boundary. Remove the `@_spi` attribute, exposing it as a (hidden, but) public entry point.
- The old SPIs `_wordIndex(before:)` and `_nearestWordIndex(atOrBelow:)` were irredemably broken; follow the Unicode recommendation for implementing random-access text segmentation and replace them both with a new public `_wordIndex(somewhereAtOrBefore:)` entry pont.
- Expose handcrafted low-level state machines for detecting word boundaries (_WordRecognizer`, `_RandomAccessWordRecognizer`), following the design of `_CharacterRecognizer`.
- Add tests to reliably validate that the two state machine flavors always produce consistent results.
rdar://155482680
`return` statement withot an expression automatically gets an
implicit `()` which is allowed to be converted to types like
`()?` and `Any` or `Any?`. Let's remove a too strict assertion
that expected a contextual type to always be `()?` even
through in reality any type that `()` is convertible to is valid.
Resolves: rdar://152553143
Set an upper bound on the number of chained lookups we attempt to
avoid spinning while trying to recursively apply the same dynamic
member lookup to itself.
rdar://157288911
