Adding Contributing file by facebook-github-bot · Pull Request #1 · facebook/buck2-prelude

facebook-github-bot · 2022-09-25T19:31:55Z

This is pull request was created automatically because we noticed your project was missing a Contributing file.

CONTRIBUTING files explain how a developer can contribute to the project - which you should actively encourage.

This PR was crafted with love by Facebook's Open Source Team.

fbshipit-source-id: 653a22b831d1ed9f0496f75b86ee762cfe95146c

Summary: This reverts the Rust parts from D41714656 (fad0244) and implements it better a different way. Advantages of the new approach: 1. No more "falsiness". The default value kicks in only if a value was not passed by the code that instantiated the toolchain, or if `None` was passed. (As far as I can tell there is no way to tell these cases apart, but that seems fine.) Previously we had been doing e.g. `toolchain_info.rustc_flags or []`, which will silently accept a toolchain constructed with inappropriate falsey values like `rustc_flags = False` or `rustc_flags = ""`. 2. A consistent central place for the default values. No more needing to scatter `or []` to every location that a particular attribute is referenced. 3. A central place to observe which attributes have not yet been given a default value, and discuss what those default values should be. Other than #1 above, this diff does not intentionally change any behavior. Reviewed By: zertosh Differential Revision: D41752388 fbshipit-source-id: 47e8b290cc596528a7a3c5b3a68195083725f8bd

Summary: ## This stack This stack is what I have so far for the native `haskell_ghci` buck2 rule implementation. On D44449945 I published an initial RFC with what I had so far, but there were still a lot of things I didn't know. Now, I think I'm much closer to getting to finishing, but there are still a few things I don't know that could be causing the errors that I'm getting... I'll try to aggregate everything in an Help section... My goal now is to 1. Generate scripts that are equivalent (e.g. only differences are in directory paths) 2. Generate all the necessary artifacts (e.g. SOs, scripts), which I'll compare using `tree -lv BUCK_OUT` of buck1 and buck2 output. 3. Run haxlsh and successfully load and run an endpoint. I'm very close to #1. The only thing that's different is that I'm not creating an omnibus SO and I'm passing all the dependencies explicitly. ## This diff As title. Reviewed By: pepeiborra Differential Revision: D46476480 fbshipit-source-id: aa9eea0bd0ed9b65b94156f27adda16fd69afe7e

Summary: The existing `_get_argsfile_output` does two things: 1. creates the argsfile subtarget DefaultInfo provider 2. sets the `by_ext` attribute for use in xcode_data Up the stack, #2 is replaced by the `CompileArgsfiles` record which contains a map of extension to `CompileArgsfile`. Extracting out #1 allows us to restructure the code (later on) to 1. define the argsfile subtarget, DefaultInfo and action only for targets that want it 2. extract it out of compilation so that compilation code is simpler Reviewed By: milend Differential Revision: D46743454 fbshipit-source-id: 31a108410e49fb85851d91334ed598a10731e7d9

…cross all host platforms Summary: ### Motivation My team has a concrete need for buck to generate 100% matching zip files for the same sets of inputs on all host platforms (macOS, Linux, Windows). Current limitations: 1. File order can be different on file system with different case sensitivity. 2. Windows can't write correct posix mode (i.e. permissions) for any entries. Although the entries themselves might fully match, those discrepancies result in different metadata, which results in a different zip file. See D67149264 for an in-depth explanation of the use case that requires this level of determinism. ### Tentative solution #1 In D66386385, I made it so the asset generation rule was only executable from Linux. Paired with buck cross builds, it made so that outputs from macOS and Linux matched, but did not work on Windows [due to some lower level buck problem](https://fb.workplace.com/groups/930797200910874/posts/1548299102494011) (still unresolved). ### Tentative solution #2 In D66404381, I wrote my own Python script to create zip files. I got all the files and metadata to match everywhere, but I could not get around differences in the compression results. Decided not to pursue because compression is important for file size. ### Tentative solution #3 In D67149264, I duplicated and tweaked buck's zip binary. It did work, but IanChilds rightfully pointed out that I'd be making maintenance on those libraries more difficult and that the team is even planning on deleting those, at some point. ### Tentative solution #4 (this diff!) IanChilds advised me to try to fix buck itself to produce consistent results, so this is me giving it a try. Because the root problem could not have been done in a backwards compatible way (the file permissions, specifically; see inlined comment), I decided to use an argument to control whether the zip tool should strive to produce a deterministic output or not, at the expense of some loss of metadata. The changes are simple and backwards compatible, but any feedback on the root problem, idea and execution are welcome. Reviewed By: christolliday Differential Revision: D67301945 fbshipit-source-id: c42ef7a52efd235b43509337913d905bcbaf3782

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

…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

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

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

…-repo Update prelude to latest from the-culture-repo

…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

facebook-github-bot added 2 commits September 25, 2022 02:57

Initial commit

4c93eb6

fbshipit-source-id: 653a22b831d1ed9f0496f75b86ee762cfe95146c

OSS Automated Fix: Addition of Contributing

004c5b7

facebook-github-bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Sep 25, 2022

facebook-github-bot closed this Sep 30, 2022

facebook-github-bot force-pushed the main branch from 5365f34 to d07d7c1 Compare September 30, 2022 21:06

avdv pushed a commit to avdv/buck2-prelude that referenced this pull request Aug 25, 2025

Merge pull request facebook#1 from MercuryTechnologies/cb/the-culture…

2b31485

…-repo Update prelude to latest from the-culture-repo

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Adding Contributing file#1

Adding Contributing file#1
facebook-github-bot wants to merge 2 commits intomainfrom
automated_fixup_contributing_file_exists

facebook-github-bot commented Sep 25, 2022

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

facebook-github-bot commented Sep 25, 2022

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant