Fix rebuild issue: disable dep file check for now!#1
Draft
wavewave wants to merge 1 commit into
Draft
Conversation
wavewave
pushed a commit
that referenced
this pull request
Apr 12, 2025
Summary: # Context App targets that contain app extension targets need to set up explicit target dependencies on the app extension targets. This is similar to D60223003, where we set up target dependencies for UI tests, so we can reuse much of the infrastructure from there. Here's a diff of our Xcode project before and after manually adding the target dependency in the f2-with-extensions project spec: https://www.internalfb.com/phabricator/paste/view/P1724920080?view=diff --- So we need to add 2 things for each app extension target in the project: ## 1. A PBXContainerItemProxy ``` /* Begin PBXContainerItemProxy section */ 8F4F81192D51C2DF00E9EC84 /* PBXContainerItemProxy */ = { isa = PBXContainerItemProxy; containerPortal = 2D699AA517DD0EA4E6F454A2 /* Project object */; proxyType = 1; remoteGlobalIDString = FF2546F571E94DE085D0A99B; remoteInfo = FocusPlaygroundShareExtension; }; /* End PBXContainerItemProxy section */ ``` Needs: 1. PBXProject's reference 2. App extension target's PBXNativeTarget's name and reference ## 2. PBXTargetDependency ``` /* Begin PBXTargetDependency section */ 8F4F811A2D51C2DF00E9EC84 /* PBXTargetDependency */ = { isa = PBXTargetDependency; target = FF2546F571E94DE085D0A99B /* FocusPlaygroundShareExtension */; targetProxy = 8F4F81192D51C2DF00E9EC84 /* PBXContainerItemProxy */; }; /* End PBXTargetDependency section */ ``` Needs: 1. PBXContainerItemProxy's reference (Get from #1) 2. App extension target's reference --- ## Add all of the app extension PBXTargetDependency identifiers to the containing app's dependency list: ``` 738F5F018A4B4BF20629BF02 /* FocusPlayground */ = { isa = PBXNativeTarget; buildConfigurationList = 6A55E7FA57E7AAB88FF7C0E1 /* Build configuration list for PBXNativeTarget "FocusPlayground" */; buildPhases = ( D243AE6F52E0F92791974A8D /* Buck Prebuild */, 0579C1CFF2E1E6055656AEAB /* Buck Build */, ); buildRules = ( ); dependencies = ( + 8F4F811A2D51C2DF00E9EC84 /* PBXTargetDependency */, ); name = FocusPlayground; productName = FocusPlayground; productReference = 7A5EBA4A826A7828EEA9F8C3 /* FocusPlayground.app */; productType = "com.apple.product-type.application"; }; ``` Needs: 1. All app extension PBXTargetDependency references (Get from #2) --- Much like in D60223003, we'll need to generate the PBXContainerItemProxy and PBXTargetDependency objects in the aggregate stage, because only then will we know all the different targets being generated and be able to understand the relationships between them. For generating the list of dependencies, we'll need to pass through a list of app extension dependencies from the app bundle and generate the references in the partial target generation. This does mean at some stage we'll need to filter the list of app extension to only those targets *currently being focused*. # This Diff In xcode-data, get the full set of app extension dependencies and add them to the [xcode-data] output. We explicitly want the `raw_target()` of the configured dependency because inter-target dependencies are a per-target concern, not a per configured_target concern. Differential Revision: D69201882 fbshipit-source-id: 467138d970d3727d4831bc5d8c623d93f8e442d1
wavewave
pushed a commit
that referenced
this pull request
Apr 12, 2025
…ependency generation Summary: # Context App targets that contain app extension targets need to set up explicit target dependencies on the app extension targets. This is similar to D60223003, where we set up target dependencies for UI tests, so we can reuse much of the infrastructure from there. Here's a diff of our Xcode project before and after manually adding the target dependency in the f2-with-extensions project spec: https://www.internalfb.com/phabricator/paste/view/P1724920080?view=diff --- So we need to add 2 things for each app extension target in the project: ## 1. A PBXContainerItemProxy ``` /* Begin PBXContainerItemProxy section */ 8F4F81192D51C2DF00E9EC84 /* PBXContainerItemProxy */ = { isa = PBXContainerItemProxy; containerPortal = 2D699AA517DD0EA4E6F454A2 /* Project object */; proxyType = 1; remoteGlobalIDString = FF2546F571E94DE085D0A99B; remoteInfo = FocusPlaygroundShareExtension; }; /* End PBXContainerItemProxy section */ ``` Needs: 1. PBXProject's reference 2. App extension target's PBXNativeTarget's name and reference ## 2. PBXTargetDependency ``` /* Begin PBXTargetDependency section */ 8F4F811A2D51C2DF00E9EC84 /* PBXTargetDependency */ = { isa = PBXTargetDependency; target = FF2546F571E94DE085D0A99B /* FocusPlaygroundShareExtension */; targetProxy = 8F4F81192D51C2DF00E9EC84 /* PBXContainerItemProxy */; }; /* End PBXTargetDependency section */ ``` Needs: 1. PBXContainerItemProxy's reference (Get from #1) 2. App extension target's reference --- ## Add all of the app extension PBXTargetDependency identifiers to the containing app's dependency list: ``` 738F5F018A4B4BF20629BF02 /* FocusPlayground */ = { isa = PBXNativeTarget; buildConfigurationList = 6A55E7FA57E7AAB88FF7C0E1 /* Build configuration list for PBXNativeTarget "FocusPlayground" */; buildPhases = ( D243AE6F52E0F92791974A8D /* Buck Prebuild */, 0579C1CFF2E1E6055656AEAB /* Buck Build */, ); buildRules = ( ); dependencies = ( + 8F4F811A2D51C2DF00E9EC84 /* PBXTargetDependency */, ); name = FocusPlayground; productName = FocusPlayground; productReference = 7A5EBA4A826A7828EEA9F8C3 /* FocusPlayground.app */; productType = "com.apple.product-type.application"; }; ``` Needs: 1. All app extension PBXTargetDependency references (Get from #2) --- Much like in D60223003, we'll need to generate the PBXContainerItemProxy and PBXTargetDependency objects in the aggregate stage, because only then will we know all the different targets being generated and be able to understand the relationships between them. For generating the list of dependencies, we'll need to pass through a list of app extension dependencies from the app bundle and generate the references in the partial target generation. This does mean at some stage we'll need to filter the list of app extension to only those targets *currently being focused*. # This Diff Not all app extension dependencies are necessarily going to be focused, so we don't want to generate an app extension dependency reference to an app extension that isn't going to actually be a target in the Xcode project (and therefore won't generate a PBXTargetDependency/PBXContainerItemProxy in the project file to resolve the reference). Differential Revision: D69339302 fbshipit-source-id: 4b1859f4a524b0fca4b0d489aa48db9532ece22d
9999years
pushed a commit
that referenced
this pull request
Apr 28, 2025
Summary: This will inject a specific list test command (when the configs are present) for generating the list test comand for android robolectric tests. The next diff will fully test this e2e. Notable configs: `-c testinfra.build_codesense` If true we will build the codesense binary (for development) if not true we will use the dotslash version --- `-c testinfra.codesense_static_listing` If true we will inject the above RunInfo and use it in the robolectric.bzl If not true we will not have this injected and the existing path will be used ## Rollout plan For phase #1 we will create shadow runs for the robolectric continuous runs and inject the config `-c testinfra.codesense_static_listing` for those shadow runs. We can then compare between both runs and ensure the same tests were discovered. After we have parity and all of the targets that won't support this (e.g., Parametrized tests) we can move to a label based opt-out. Reviewed By: jselbo Differential Revision: D73158309 fbshipit-source-id: 179d6a8866c05123a29be0aaf32804afcb305a08
9999years
pushed a commit
that referenced
this pull request
May 1, 2025
Summary: As part of Buck2 Error Customization Authors, we are doing two things: 1. better-categorizing errors that pop-up in Apple so that we can better lever the new `.message` property on `ActionSubError` which enables you to inline things like links to wikis. 2. Add help so that engineers can get wikis at their desk. Looking at buck2's error categorization dashboard: https://fburl.com/unidash/symtoxim `apple_compilation_failure` is the #1 at Meta, and that's because it's just an amalgamation of any errors. I chatted offline with williamtwilson + mzlee and I think it makes more sense to declare bankruptcy on this... - it's too vague to inject a helpful message. - it causing over-aggregation on the dashboards. - I'm not sure anyone is looking at it. Reviewed By: benb Differential Revision: D73878564 fbshipit-source-id: 02fc29d9a661bd33747981d03dcae96096c54b73
9999years
pushed a commit
that referenced
this pull request
Sep 9, 2025
…ut to disable llvm-dwp --continue-on-cu-index-overflow (try 2)
Summary:
Unicorn uses `folly::symbolizer` at runtime to print stack traces or log stack traces to scuba.
`folly::symbolizer` may crash on corrupt DWARF/DWP leading to incidents or time wasted investigating pre-release crashes.
I tried to remove `--continue-on-cu-index-overflow` with the plan that broken builds can be onboarded to link groups, but there still are projects that can't use link groups (and don't mind corrupt debug info).
- {D63291887}
Add a per-directory rollout (onboard `unicorn`, `search`, `nlp_tools` which I know use `folly::symbolizer` at runtime) and remove `--continue-on-cu-index-overflow` for those directories and ensure `llvm-dwp` either builds correct DWP files or exits with an error.
---
For future reference and aid for others that hit DWP corruption issues, fixes involved turning on link groups:
- {D63277289}
- {D81615968}
---
Attempt #1 removed the default `--continue-on-cu-index-overflow` from `dwp_wrapper.py` and then tried to add it back explicitly, but it was done in a manner that missed some cases that end up calling into `dwp`.
This attempt keeps the default in `dwp_wrapper.py` (so should not cause other build issues) and adds an override for the codepaths that matter to `unicorn` & co. but keeps the default `--continue-on-cu-index-overflow`.
#forcetdhashing
Reviewed By: mzlee
Differential Revision: D81839152
fbshipit-source-id: 92dcdd76b2cd0e255eeabf3d76648c39dade1a36
lf-
pushed a commit
that referenced
this pull request
Apr 1, 2026
Summary: `collect::<FreezeResult<_>>()` takes a trip though rust's "GenericShunt", which always returns a lower bound of zero (because we may always exit early on a failure). As a result, the map/vector/whatever that we're collecting into tends to `::with_capacity(lower=0)` on itself, and we get geometric growth of the container when we're trying to freeze it with minimum size. We could: 1. Forgo `collect` and use an explicit loop (what this does) 1. Change the collected-into types to prefer the upper bound (if given), or some mix of (lower != 0 or upper != MAX) or something. Hard to know if the underlying implementations will change, and we get ridiculous numbers for lower/upper in the future. It's safer to do #1. 1. implement our own `try_collect_exact` or something that does not do the behavior we're trying to avoid, and provides an exact size hint (lower == upper == len of input iterator). Reviewed By: JakobDegen Differential Revision: D98960692 fbshipit-source-id: ff18aa92fac6acf09264b874b5485dad675b0c96
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.