This was added in ea54c3b, presumably inadvertently.

…ed while iterating

In `SourceLookupCache::lookupVisibleDecls`, copy the top level values before iterating them.

If we have 'addinitstotoplevel' enabled, calling 'addConstructorCallsForType' can cause macros to get expanded, which can then cause new members ot get added to 'TopLevelValues', invalidating the current iterator.

I have not been able to reduce this to a test case that doesn’t rely on the `Observation` module in the SDK but here is the test case with which I was able to reproduce the issue very reliably.

```swift
import Foundation
import Observation

@observable class MyObject {}

extension MyObject {}

// RUN: ~/sbin/sourcekitd-test \
// RUN:   -req=complete.open \
// RUN:   -req-opts=addinitstotoplevel=1 \
// RUN:   -pos=8:1 \
// RUN:   %s \
// RUN:   -- \
// RUN:   %s \
// RUN:   -Xfrontend \
// RUN:   -load-plugin-library \
// RUN:   -Xfrontend \
// RUN:   /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/host/plugins/libObservationMacros.dylib \
// RUN:   -sdk \
// RUN:   /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk
```

rdar://109202157

…omAttributeScope

so that it can represent the scope for any custom attribute and its arguments.

This commit is NFC, but CustomAttributeScope is now applicable to attached macros.

…s inside

a macro argument.

…APIs.

This source location will be used to determine whether to add a name lookup
option to exclude macro expansions when the name lookup request is constructed.
Currently, the source location argument is unused.

expansions.

Evaluator::hasActiveResolveMacroRequest is now unused.

checker while type checking a freestanding macro argument in the same scope.

…arbitrary

names at global scope.

Freestanding and peer macros applied at top-level scope cannot introduce
arbitrary names. Introducing arbitrary names means that any lookup
into this scope must expand the macro. This is a problem, because
resolving the macro can invoke type checking other declarations, e.g.
anything that the macro arguments depend on. If _anything_ the macro
depends on performs name unqualified name lookup, e.g. type resolution,
we'll get circularity errors. It's better to prevent this by banning
these macros at global scope if any of the macro candidates introduce
arbitrary names.

… of a

macro argument.

…lookup.

…ass.

IDE inspection can delay parsing of particular declarations, so expanding
ASTScopes during the first pass will miss those declarations. Clear any
expanded scopes to force re-expansion during the second pass.

…ookup

namespace.

This moves the `isInMacroArgument` predicate and `lookupMacros` into `namelookup`.
ASTScope still encapsulates the scope tree and contains the operation to lookup
the enclosing macro scope, which then invokes a callback to determine whether a
potential macro scope is indeed a macro, because answering this question requires
name lookup.

…ions

When emitting the underlying `switch` statement
for a `switch` expression, we emit an `unreachable`
if the subject is uninhabited. Statement emission
code can handle this, but expression emission expects
an RValue to handed back. To remedy this, emit
an unreachable block that we can emit the rest of
the expression emission code into. The SILOptimizer
will then drop this unreachable block.

Add the windows message queue status flags macros.  This should allow
the use of the macros when writing Windows code.

Previously we would skip over ExprPatterns, but
we need to ensure that we walk them, as they may
have interesting variable references that the
closure needs to be connected to the type
variables for.

rdar://110617471

Apply the same logic that we apply to other
conjunction elements, to make sure that e.g
property wrapper projected values work correctly.

rdar://110649179

These seem to be related to signal handling issues in threads that
have been started presumably by the C library or some other library.

Primarily this appears to affect Ubuntu 20.04 on aarch64, though I
have seen sporadic issues on 18.04 as well.

We address the problem by making the thread suspension mechanism
more robust in the face of threads with masked signals.

rdar://110653167

…#66366)

Teach swift dependency scanner to use CAS to capture the full dependencies for a build and construct build commands with immutable inputs from CAS.

This allows swift compilation caching using CAS.

…o-argument

[Macros] Use source locations to determine whether to suppress macro expansions.

apple#66497 and
apple#66482 succeeded separately, then
merged. But after 66497 the error now includes parentheses.

Resolves rdar://110655182.

[Test] Update expected macro error

…le dependencies

These are meant to capture paths to the PCH files that a given module was built with.

…tion

[CodeCompletion] Fix an issue that causes an iterator to be invalidated while iterating

… dependencies in output and provide libSwiftScan API to query it

When an `OpaqueTypeDecl` is constructed, the access level attributes of the
decl that names the opaque type were copied on to it. However, the
`@usableFromInline` attribute is not permitted on every decl, so it does not
get copied. This in turn causes access level computations for opaque types to
fail to take `@usableFromInline` into account and that results in the emitted
symbol getting the wrong linkage during IRGen. The fix is to make access level
computations take this quirk of opaque types into account directly (like they
already to for several other kinds of decls), instead of relying on copying of
attributes.

Resolves rdar://110544170

When a default constructor is declared, but does not have a body because it is defaulted (`= default;`), Swift did not emit the IR for it. This was causing linker error for types such as `std::map` in libstdc++ when someone tried to initialize such types from Swift.

rdar://110638499 / resolves apple#61412

…diagnostic mode

If generic parameter gets opened during regular solving it cannot
be bound to a hole, that can only happen in diagnostic mode, so
let's not even try. Doing so also makes sure that there are no
inference side-effects related to holes because bindings are ranked
based on their attributes.

…onstructor

[cxx-interop] Avoid linker errors when calling a defaulted constructor

rdar://109908383

…e-type-decl-linkage

AST: Inherit access level of an opaque type decl from its naming decl

rdar://109908383

…nicalize-ossa-lifetime-comments

[CanonicalizeOSSALifetime] Gardening: Tweaked comments.

type.subst in mapTypeIntoContext.

The outer context substitutions are already applied when invoking
QueryInterfaceTypeSubstitutions. Applying the context substitutions
before subst also causes problems because QueryInterfaceTypeSubstitutions
will return a null type if given an archetype, which manifested with
opened pack element environments.

…-diags

Improve noncopyable closure diags

…tions (apple#66577)

We want to re-use them for enum layout string instantiation, so best to pull them into separate functions.

So that it's consistent with C++ sources

rdar://110363377

cmake: correctly set NDEBUG for imported headers in SwiftCompilerSources

…pple#66582)

* Fix sign of fractional units in Duration initializers from Double.

When separating a double duration into integral and fractional parts, we got the sign wrong. This fixes that bug.

* Fixup variable name.

…Modules

[Dependency Scanning] Record header dependencies of binary Swift module dependencies

rdar://107909624

…tutions

[GenericEnvironment] Don't apply outer context substitutions before `type.subst` in `mapTypeIntoContext`.

Windows: add some defines from `WinUser.h`

[Backtracing][Linux] Fix Ubuntu 20.04-aarch64 CI failures.

[cxx-interop] Add `std::set` initializer that takes a Swift Sequence

[Test] Remove five second delay in swift-reflection-test startup.

…ode-only

[ConstraintSystem] Allow generic parameters to bind to holes only in …