Revert visionOS changes and provide Copilot instruction improvements

[Copilot]

Revert Complete + Focused Instruction Improvements

All changes have been reverted as this work was superseded by PR #294.

Changes in this commit:

• Removed separate COPILOT_INSTRUCTIONS_IMPROVEMENTS.md file
• Added focused "Rust/Ferric Integration Patterns" section to existing .github/copilot-instructions.md

Key concrete improvements based on PR #294 differences:

• Target Management: Use Set<TargetName> with built-in methods, rename functions when responsibilities change
• Workflow Development: Extend existing workflows with conditional jobs, not new files
• Focused on actionable practices: Specific data structures, function naming, and workflow patterns that would have prevented the over-engineered approach

Original prompt

I want to add a new workflow based off the check workflow to test building the ferric example with triplets that are currently commented out in the Ferric sourcecode. It should be bootstrapoing the Rust compiler to build it with the apple-* targets enabled. Start by creating a PR enabling the visionos triplets and a workflow bootstrapping rustc with the visionos triplets enabled.

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[kraenhansen]

I found some documentation on bootstrapping the Rust compiler: https://rustc-dev-guide.rust-lang.org/building/bootstrapping/what-bootstrapping-does.html and https://github.com/rust-lang/rust/blob/master/src%2Fbootstrap%2FREADME.md

[kraenhansen]

I also found the docs for the visionos triplets https://doc.rust-lang.org/rustc/platform-support/apple-visionos.html

[kraenhansen]

No need to lint here. It's not in scope of what we want this workflow to do.

[Copilot]

Removed the lint step from the visionOS workflow. Commit 8f8d49d

[kraenhansen]

This won't work. These targets are tier 3 and won't be available prebuilt, so you need to build / bootstrap the Rust compiler as I mentioned in the instructions.

[Copilot]

Updated to bootstrap the Rust compiler from source instead of using rustup target add. The workflow now clones rust-lang/rust, configures build for visionOS targets, and uses ./x.py build and install commands. Commit 8f8d49d

[kraenhansen]

@copilot please address my comments above

[Copilot]

@copilot please address my comments above

Addressed both comments: removed lint step and replaced rustup with proper Rust compiler bootstrapping for tier 3 visionOS targets. Commit 8f8d49d

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• doc.rust-lang.org
  • Triggering command: curl -s REDACTED (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

[kraenhansen]

@copilot I've added the doc.rust-lang.org domain to the firewall allowlist. Please revisit your plan and your changes so far.

[Copilot]

@copilot I've added the doc.rust-lang.org domain to the firewall allowlist. Please revisit your plan and your changes so far.

Revised the workflow after accessing the visionOS documentation. Changed from full Rust compiler bootstrapping to the recommended -Zbuild-std approach with nightly Rust, which is more efficient and follows the official platform support guide. Commit 598835e

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• rustc-dev-guide.rust-lang.org
  • Triggering command: curl -s REDACTED (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

[kraenhansen]

@copilot I updated the firewall allowlist. Try again.

[Copilot]

@copilot I updated the firewall allowlist. Try again.

Enhanced the visionOS workflow with comprehensive build-std configuration after accessing the full Rust documentation. Key improvements: proper nightly Rust + rust-src setup, comprehensive .cargo/config.toml following official docs, enhanced verification steps, and better debugging output. Commit 7da043c

[kraenhansen]

@copilot okay - it seems the build succeeded, but the linking failed. This is expected to me, since Ferric is responsible for passing the options to the linker to prevent this failure. I need you to update the Ferric codebase to perform a different pre-condition check for the Rust targets that cannot be downloaded, with a link to instructions (I imagine Rust has a docs page we can link to) on how to setup the "-Zbuild-std" preparation you've done in the action.

[Copilot]

@copilot okay - it seems the build succeeded, but the linking failed. This is expected to me, since Ferric is responsible for passing the options to the linker to prevent this failure. I need you to u...

Updated the Ferric codebase to handle tier 3 targets properly. Added TIER_3_TARGETS constant for visionOS targets and modified ensureInstalledTargets() to provide comprehensive setup instructions for -Zbuild-std instead of failing. Users now get step-by-step guidance including nightly Rust installation, cargo configuration, and links to official Rust documentation (platform support and build-std pages). Commit 0bf31fb

[kraenhansen]

@copilot I've added a few comments to the code.

[Copilot]

@copilot I've added a few comments to the code.

Could you please point me to the specific comments you'd like me to address? I don't see any new inline review comments in the current view. If you've added review comments to specific lines or files, please let me know which ones need attention and I'll address them accordingly.

[kraenhansen]

@copilot I think this would be a good use of assertFixable and it seems this will unconditionally fail if any tier target is used. I believe we need a change in getInstalledTargets to include these tier 3 targets in the return value.

[Copilot]

Implemented both suggestions: replaced throw new UsageError with assertFixable for better CLI integration, and enhanced getInstalledTargets() to intelligently include tier 3 targets when build-std prerequisites are met (nightly Rust + rust-src component). This eliminates unconditional failures and provides seamless workflow when properly configured. Commit abcbd29

[kraenhansen]

@copilot it seems like a bit of a stretch to me to add all tier 3 targets needed if just the nightly compiler is installed and rust-src is available. Is there a cargo command you can use to inspect the .cargo/config.toml to check for the targets to be declared? Or perhaps that's not a requirement? If no rust command exists, perhaps a toml parser from NPM is needed?

Alternatively, that check might need to happen in ensureInstalledTargets, which might also need to be renamed, since we're technically not getting the "installed targets" anymore?

[Copilot]

You're absolutely right about it being too broad. I refactored the approach: reverted getInstalledTargets() to its original simple purpose (only rustup-installed targets), moved the tier 3 logic to ensureInstalledTargets() where it belongs, and made the validation much more precise - it only checks build-std prerequisites when tier 3 targets are actually requested. This eliminates the overly broad assumption and provides cleaner separation of concerns. Commit c14d33a

[kraenhansen]

@copilot please have a look at #294 and the changes within. This other PR superseeds your work here. I want you to revert all of the changes you've made so far and instead suggest changes to the instructions file to help you produce something more like the changes I propose in the other PR, in the future.

[Copilot]

@copilot please have a look at #294 and the changes within. This other PR superseeds your work here. I want you to revert all of the cha...

Reverted all changes. Created COPILOT_INSTRUCTIONS_IMPROVEMENTS.md with comprehensive analysis comparing my overly complex approach with PR #294's simpler, better approach. Key suggestions: extend existing workflows instead of creating new ones, use appropriate data structures (Set vs array), keep functions focused, avoid over-engineering, and follow established patterns. Commits f11d1d5 (revert) and 3966991 (suggestions).

[kraenhansen]

@copilot you need to add this to the existing copilot_instrucrions.md and I want you to be much more brief, while focusing only on the differences which are really significant and instructions which would have helped you produce a better result, in the context of the steps you took yourself as well. Also - I want no general wording like " follow best practice" etc. I want you to focus on the concrete practice you can derive from the other PR.

[Copilot]

@copilot you need to add this to the existing copilot_instrucrions.md and I want you to be much more brief, while focusing only on the differences which are really significant and instructions which w...

Added focused improvements to existing .github/copilot-instructions.md and removed the separate file. Added concrete practices from PR #294: use Set<TargetName> with built-in methods, rename functions when responsibilities change (ensureAvailableTargets), add jobs to existing workflows with conditional execution, and keep workflow steps minimal. Commit 3397ac5