tree a02e9ecf3df08b99e5caf19857624345acc8d1bd
parent 0cbe341c1a28037ee32d21b589030a7df0b9fdab
author David 'Digit' Turner <digit@google.com> 1649852512 +0200
committer Commit Bot <commit-bot@chromium.org> 1649866004 +0000

Add Target::builds_swift_module() method.

The SwiftValues::builds_module() method would always return false before
SwiftValues::OnResolvedTarget() is called, and this masked a subtle bug
when performing target resolution (see below).

This CL fixes the issue by adding a new method to the Target class
(Target::builds_swift_module()). This is necessary since giving the
correct answer requires knowing which Target instance the SwiftValue
class is associated with. Call sites are updated to use the new method.

Regarding the bug itself:

- During a Target::OnResolved() call, the PullRecursiveHardDeps()
  method is called before SwiftValues::OnTargetResolved().

- The PullRecursiveHardDeps() calls the `hard_dep()`  method on the
  current target, and its dependencies as in:

```
  for (const auto& pair : GetDeps(DEPS_LINKED)) {
    // Direct hard dependencies.
    if (hard_dep() || pair.ptr->hard_dep()) {
      recursive_hard_deps_.insert(pair.ptr);
      continue;
    }
    ...
```

  If the current target generates a Swift module, the first `hard_dep()`
  call would always mistakenly return false (because
  SwiftValues::OnTargetResolved() has not been called yet).

  Note that the `pair.ptr->hard_dep()` would always return the correct
  value since all dependencies of the current target are fully resolved
  when this code runs (and hence their own
  SwiftValues::OnTargetResolved() call had been performed).

The CL ensures that the first `hard_dep()` call always returns the
correct value. This also fixes a unit-test that was expecting the
previous behaviour.

Bug: None
Change-Id: I6ce8f2f182e22666282d0f7b889fa8df94c45c48
Reviewed-on: https://gn-review.googlesource.com/c/gn/+/13600
Reviewed-by: Sylvain Defresne <sdefresne@chromium.org>
Commit-Queue: David Turner <digit@google.com>