Adding Code of Conduct file by facebook-github-bot · Pull Request #2 · facebook/buck2-prelude

facebook-github-bot · 2022-09-25T19:35:08Z

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

Code of Conduct files facilitate respectful and constructive communities by establishing expected behaviors for project contributors.

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

fbshipit-source-id: 653a22b831d1ed9f0496f75b86ee762cfe95146c

…ingle file when the archive has no bitcode object. Summary: Current opt step would check if each object in an archive is bitcode. then: 1. If it is, run an actual opt to generate ELF. 2. If it's not bitcode (already an ELF), trigger a copy action to copy the file to the destination. In the case of prebuilt library since all the objects are ELF already, it's more efficient to just copy the folder than #2. This change bring down the total number of actions from 186.5k -> 144k (22.7%) for unicorn:index_server {F780561315} Reviewed By: christycylee Differential Revision: D40319823 fbshipit-source-id: 4650cf8f6ef5170d2c6fb4d456e7042de77a4f2f

Summary: **Context** Supporting fat and non-fat toolchains becomes problematic because a fat toolchain usually combines tools using `command_alias()`. So if we set the platform constraints for the individual tools (which we need, so that the thin toolchain gets the correct platform), we end up producing conflicting constraints. ``` ┌─────────────────┐ ┌───────────────┐ │ linux-toolchain │ │ fat-toolchain │ └─────────────────┘ └───────────────┘ │ │ │ │ │ │ │ │ "tool" = attrs.exec_dep() "tool" = attrs.exec_dep() │ │ │ │ │ │ │ │ │ │ │ │ │ ▼ │ ┌────────────────────────────────┐ │ │command_alias(name = "fat-tool")│ │ └────────────────────────────────┘ │ │ │ platform_exe │ │ │ │ │ ┌─────────────────┴─────────────────────┐ │ │ │ │ │ │ │ │ │ │ │ │ ▼ ▼ ▼ ┌─────────────────────────────────┐ ┌───────────────────────────────────┐ │sh_binary(name="linux-only-tool")│ │sh_binary(name="windows-only-tool")│ └─────────────────────────────────┘ └───────────────────────────────────┘ ``` If we were to set the `target_compatible_with` constraints on `linux-only-tool` and `windows-only-tool`, then `fat-tool` is not resolved to any exec platform, as no exec platform satisfies *both* Windows and Linux. **Solution/Workaround** There are two solutions to the problem: 1. Set up mirrored aliases of all underlying tools 2. Set up an placeholder tool on `(apple|cxx|swift)_toolchain()` for the purposes of setting exec platform constraints We opt for solution #2 as it's much simpler and does not require extensive changes to existing toolchain setup. Since the tools are optional, they can be unused without any downsides. Reviewed By: rmaz Differential Revision: D44090642 fbshipit-source-id: 399cfbfdf4dcbb4b334e22545cfea5e86e31c837

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

Summary: This is another version of D47988498, which the minor change that fixes the bug the broke a few of our tests. The problem was that in the `haskell_ghci` rule, we were generating directory names using the suffix based on the profiling attribute of the `haskell_ghci` target, instead of the one considered when building the actual library. This meant that the interface files were not found for some packages and their modules couldn't be imported. --------- # Summary from D47988498 ## This stack See D47987891. ## This diff Change the names of generated artifacts (e.g. package directories, lib names) to consider the status of profiling. This is needed to (a) make it clear for every artifact if it was build with or without profiling and (b) to fix buck2 errors from declaring outputs with the same name of running the actions with the same category name (e.g. "haskell_link_..."). Reviewed By: helfper Differential Revision: D48110784 fbshipit-source-id: e12ec14aacb406d2334bfcd22e5ba81b82c847eb

Summary: This makes lives easier by not needing to passthrough it. Original diff D62916369 Landed the wrong version, :( Reviewed By: IanChilds Differential Revision: D62984484 fbshipit-source-id: 0805c94e694a722edd13e9b91cc73bad8c11e2b7

…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: Grepping the codebase told me those are all unused Reviewed By: IanChilds Differential Revision: D71549892 fbshipit-source-id: 434a0e2b48d195e2b3e2f77a29ba4ec49e5aeb9d

Summary: The 1st attempt D68205412 ``` VERSION=2.1.0 arc artificer download \ :kotlin:$VERSION --kotlin-bump \ :ksp:$VERSION-1.0.29 \ dev.zacsweers.kctfork:core:0.7.0 \ dev.zacsweers.kctfork:ksp:0.7.0 ``` run_all_fbandroid_tests run_all_fbandroid_tests_at_diff_time allow-large-files Reviewed By: thezhangwei, hick209 Differential Revision: D73063977 fbshipit-source-id: f8829b95081eade0736999195b56d5854c2c0079

…r-errors Improve error messages for GHC compilation failures

Summary: In our last attempt (D82469229), it was reverted because the failure unit tests. what's change since last one, we have fixed the unit test mentioned in the task T238489438 Reviewed By: NavidQar Differential Revision: D82642080 fbshipit-source-id: 247430d7b2bc7bc515e01413b0297c8cb60efa65

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

Initial commit

4c93eb6

fbshipit-source-id: 653a22b831d1ed9f0496f75b86ee762cfe95146c

OSS Automated Fix: Addition of Code of Conduct

b46f3ff

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#2 from MercuryTechnologies/rebeccat/bette…

30d9f0f

…r-errors Improve error messages for GHC compilation failures

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Adding Code of Conduct file#2

Adding Code of Conduct file#2
facebook-github-bot wants to merge 2 commits intomainfrom
automated_fixup_code_of_conduct_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