Type-checking an operator requires look up of all of its decls regardless of
which access modifier is used before filtering. If one of them is a package
decl in an imported module that was built with package-name, but the use site
of the operator decl is in a module that is not built with package-name, it
currently crashes as it tries to access package context of the use site, which
is null. This PR checks if both decl site and use site have package contexts
before accessing the package name property, otherwise return false to be filtered
out.
Resolves rdar://108961906
Calling `getInnermostDeclContext()->getParentSourceFile()` on a macro-produced decl does not seem to be a reliable way to obtain the macro expansion source file, because `PatternBindingDecl` is not a `DeclContext` and `getInnermostDeclContext()` falls back outside the macro expansion file. This patch switches to using `getSourceFileContainingLocation` when possible.
Resolves rdar://109376568.
We need to teach code completion how to invoke the type checker for attached macro attributes. After that, everything started working.
rdar://105232015
Attached macro mangles for accessors were using a fallback case that
triggers an assertion in +Asserts builds, and conflicting manglings is
non-Asserts builds. Provide a custom mangling for these cases that's
embedded in the identifier.
This is a narrow hack to eliminate an assertion. We are considering a
different approach for the long term that uses entity manglings with a
placeholder type, which will be more flexible long-term.
We were not type checking the default argument initializer because `MacroDecl` is not an `AbstractFucntionDecl`. Add `MacroDecl` to the list of nodes we know how to get parameters from.
rdar://108163564
When completing after `names:`, completion should offer the different ways you can specify the names, i.e. `arbitrary`, `named`, etc.
```
@freestanding(declaration, names: #^COMPLETE^#)
```
rdar://108535077
When an accessor macro adds a non-observing accessor to a property, it
subsumes the initializer. We had previously modeled this as removing
the initializer, but doing so means that the initializer could not be
used for type inference and was lost in the AST.
Explicitly mark the initializer as "subsumed" here, and be more
careful when querying the initializer to distinguish between "the
initializer that was written" and "the initializer that will execute"
in more places. This distinction already existed at the
pattern-binding level, but not at the variable-declaration level.
This is the proper fix for the circular reference issue described in
rdar://108565923 (test case in the prior commit).
Eliminate another circular reference through macro expansion mangling
by adjusting the starting declaration context to ensure that it is from
a suitable "outer" context.
Fixes rdar://108511666.
My recent change to parse initializer names in the macro role
introduced names now correctly distinguishes between the two forms, but
this breaks any existing macros written with the back-ticked form.
Treat the former as the latter to provide a grace period for such
macros.
Fixes rdar://108571834.
The macro-resolution request for an attached macro was expressed in
terms of the custom attribute and the declaration context enclosing the
attribute. While the declaration context is the correct one for
resolving the types and arguments of the custom attribute, the
declaration provides a better anchor for cases where the same
attribute applies to multiple declarations, e.g., with
member-attribute macros, leading to false cyclic references.
This cycle break means that some attributes introduced by
member-attribute macros aren't getting processed. I'm still reducing a
test case while I look for a fix, but for now I'm reverting this
change to address a regression for macros.
Fixes rdar://108456284.
If a parameter is marked consuming and its type is Copyable, that
parameter has eager-move semantics. Apply that attribute to the
SILFunctionArgument corresponding to the parameter.
rdar://108385761
Parse compound and special names in the macro role attributes
(`@freestanding` and `@attached`). This allows both compound names and
initializers, e.g., `init(coding:)`.
Fixes rdar://107967344.
This method was misleading. The majority of callers (all but one!) don't want
to unconditionally treat all locations in any macro expansion buffer the
same way, because the code also must handle nested macro expansions. There
is one part of SourceKit (and possibly others) that really do want to ignore
all macro expansions, but those can be handled within SourceKit / IDE code,
because I don't believe this utility is useful in the frontend.
inside closures while type checking a macro expansion.
PreCheckExpr, ConstraintGenerator, and other walkers do not walk into macro
expansions. However, the implementation of this macro walking behavior in
ASTWalker would skip any declaration that appears inside any macro expansion
buffer. This is incorrect for cases where the parent is in the same macro
expansion buffer, because the local declaration is not inside a new macro
expansion. This caused bogus errors when type checking expanded macro expressions
containing closures with local declarations, because pre-check and constraint
generation mistakenly skipped local pattern bindings.
When populating the name lookup tables for a nominal type, we were only
visiting declarations with peer macros within the nominal type
declaration itself. Also visit the members of extensions of the
nominal type.
Without this change, peer-macro-defined members of extensions are not
visible.
Add a private discriminator to the mangling of an outermost-private `MacroExpansionDecl` so that declaration macros in different files won't have colliding macro expansion buffer names.
rdar://107462515
How did we go this long without having the right context? Who knows.
The fix is trivial and obvious.
The failure mode here is that we wouldn't get an appropriate generic
context in the result type of a macro, so we would complain about
generic parameters not meeting their own generic requirements.
Sometimes we build a `MacroExpansionDecl` from a `MacroExpansionExpr`.
Sometimes we do it the other way. In both cases, we risk the two
copies of must-by-shared data (macro arguments, resolved macro
reference, etc.) getting out-of-sync.
Instead, share the storage between the two representations when we
create one from the other, so that they cannot get out-of-sync. This
allows us to eliminate the extremely-dodgy `cacheOutput` call earlier.
