Also recognize .h++ as a C++ header extension#9346
Merged
bnavetta merged 1 commit intowarpdotdev:masterfrom Apr 29, 2026
Merged
Also recognize .h++ as a C++ header extension#9346bnavetta merged 1 commit intowarpdotdev:masterfrom
bnavetta merged 1 commit intowarpdotdev:masterfrom
Conversation
Contributor
|
I'm starting a first review of this pull request. You can follow along in the session on Warp. I approved this pull request. No matching stakeholder was found for the changed files, so no human reviewers were requested. Comment I approved this pull request and requested human review from: @vorporeal, @alokedesai, @zachbai. Comment Powered by Oz |
![oz-for-oss[bot]](https://avatars.githubusercontent.com/in/3450139?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Overview
This PR maps .hpp, .hxx, and .h++ file extensions to the existing C++ language support and adds a unit test covering the new extensions.
Concerns
- No blocking correctness, security, error handling, or performance concerns found in the changed lines.
Verdict
Found: 0 critical, 0 important, 0 suggestions
Approve
Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).
Powered by Oz
Contributor
There was a problem hiding this comment.
Overview
This PR maps .hpp, .hxx, and .h++ filename extensions to the existing C++ language support and adds a unit test covering those new header extensions.
Concerns
- No blocking correctness, security, error-handling, or performance concerns found in the changed lines.
Verdict
Found: 0 critical, 0 important, 0 suggestions
Approve
Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).
Powered by Oz
IsaiahWitzke
approved these changes
Apr 29, 2026
Contributor
Author
|
Heads-up — issue #9387 was filed earlier today for this exact bug, and #9388 covers a partly-overlapping set: If this lands first it will close #9387 too (linked via the new "Fixes #9387" trailer once added). Pushed an updated body with the issue link. |
Contributor
|
Hi, I'd missed this one. Since #9388 merged, could you rebase on top of that with the unified set of extensions? I'll approve+merge once CI passes. Thanks! |
Rebased on top of warpdotdev#9388 (which added `hpp`, `hxx`, and the uppercase `H` form). This adds the rarer `h++` extension as well so the case list covers the full set of C++ header conventions, and extends the existing `cpp_header_extensions_resolve_to_cpp_language` test to include `header.h++`.
anshul-garg27
force-pushed
the
fix/cpp-header-extensions
branch
from
8155450 to
73e17fa
Compare
anshul-garg27
changed the title
Contributor
|
I'm checking this implementation PR for association with a likely matching ready issue. Powered by Oz |
Contributor
Author
vorporeal
requested review from
bnavetta
and removed request for
alokedesai,
vorporeal and
zachbai
captainsafia
added
the
external-contributor
Warp Dev Github Integration
zachbai
pushed a commit
that referenced
this pull request
May 1, 2026
## Description Follow-up to #9395 in a different file. While auditing image-extension lists across the repo I found a third copy in `is_supported_blocklist_image_source` (`app/src/ai/blocklist/block/view_impl/common.rs`) that suffers from the exact same drift: it only matches `jpg | jpeg | png | gif | webp | svg`, missing `.bmp`, `.tiff` / `.tif`, and `.ico`. So inline references to local `.bmp` / `.tiff` / `.ico` images in agent block output fail the support check and don't render as the inline image — they silently fall back to plain text — even though the same files do route to the system viewer once #9395 lands. ```diff - "jpg" | "jpeg" | "png" | "gif" | "webp" | "svg" + "jpg" | "jpeg" | "png" | "gif" | "bmp" | "tiff" | "tif" | "webp" | "ico" | "svg" ``` The full picture, for context: | Location | What it does | Pre-fix | |---|---|---| | `crates/warp_util/src/file_type.rs` (`is_binary_file`) | Canonical binary-file extension list | 9 image formats | | `app/src/util/openable_file_type.rs` (`is_supported_image_file`) | Routes click-to-open to `FileTarget::SystemGeneric` | 6 formats — fixed in #9395 | | **This PR** — `app/src/ai/blocklist/block/view_impl/common.rs` (`is_supported_blocklist_image_source`) | Gates inline rendering of agent block image references | 6 formats | | `crates/warpui_core/src/platform/file_picker.rs` (`FileType::Image`) | Theme-creator file-picker filter | 3 formats — left for a separate PR; the right "what should be selectable as a theme background" set is more subjective | ## Testing - Added `is_supported_blocklist_image_source_covers_common_local_formats` in `common_tests.rs`. Asserts every supported extension passes (10 cases), case-insensitivity (`PHOTO.PNG`, `scan.TIFF`), and that HTTP / HTTPS sources and non-image extensions still return false. Fails on master for the four new extensions, passes after the change. - `cargo fmt -p warp -- --check` passes locally. - Couldn't run `cargo nextest` locally because the Metal toolchain isn't installed (same caveat as #9277, #9345, #9346, #9395) — relying on CI for the full clippy / nextest pass. ## Related - #9395 — same fix for `is_supported_image_file` (file-open routing path). ## Changelog Entries for Stable CHANGELOG-BUG-FIX: Inline `.bmp`, `.tiff` / `.tif`, and `.ico` images in agent block output now render correctly instead of falling back to plain text. Co-authored-by: anshul-garg27 <anshul-garg27@users.noreply.github.com>
zerx-lab
pushed a commit
to zerx-lab/warp
that referenced
this pull request
May 3, 2026
## Description Follow-up to warpdotdev#9395 in a different file. While auditing image-extension lists across the repo I found a third copy in `is_supported_blocklist_image_source` (`app/src/ai/blocklist/block/view_impl/common.rs`) that suffers from the exact same drift: it only matches `jpg | jpeg | png | gif | webp | svg`, missing `.bmp`, `.tiff` / `.tif`, and `.ico`. So inline references to local `.bmp` / `.tiff` / `.ico` images in agent block output fail the support check and don't render as the inline image — they silently fall back to plain text — even though the same files do route to the system viewer once warpdotdev#9395 lands. ```diff - "jpg" | "jpeg" | "png" | "gif" | "webp" | "svg" + "jpg" | "jpeg" | "png" | "gif" | "bmp" | "tiff" | "tif" | "webp" | "ico" | "svg" ``` The full picture, for context: | Location | What it does | Pre-fix | |---|---|---| | `crates/warp_util/src/file_type.rs` (`is_binary_file`) | Canonical binary-file extension list | 9 image formats | | `app/src/util/openable_file_type.rs` (`is_supported_image_file`) | Routes click-to-open to `FileTarget::SystemGeneric` | 6 formats — fixed in warpdotdev#9395 | | **This PR** — `app/src/ai/blocklist/block/view_impl/common.rs` (`is_supported_blocklist_image_source`) | Gates inline rendering of agent block image references | 6 formats | | `crates/warpui_core/src/platform/file_picker.rs` (`FileType::Image`) | Theme-creator file-picker filter | 3 formats — left for a separate PR; the right "what should be selectable as a theme background" set is more subjective | ## Testing - Added `is_supported_blocklist_image_source_covers_common_local_formats` in `common_tests.rs`. Asserts every supported extension passes (10 cases), case-insensitivity (`PHOTO.PNG`, `scan.TIFF`), and that HTTP / HTTPS sources and non-image extensions still return false. Fails on master for the four new extensions, passes after the change. - `cargo fmt -p warp -- --check` passes locally. - Couldn't run `cargo nextest` locally because the Metal toolchain isn't installed (same caveat as warpdotdev#9277, warpdotdev#9345, warpdotdev#9346, warpdotdev#9395) — relying on CI for the full clippy / nextest pass. ## Related - warpdotdev#9395 — same fix for `is_supported_image_file` (file-open routing path). ## Changelog Entries for Stable CHANGELOG-BUG-FIX: Inline `.bmp`, `.tiff` / `.tif`, and `.ico` images in agent block output now render correctly instead of falling back to plain text. Co-authored-by: anshul-garg27 <anshul-garg27@users.noreply.github.com>
zerx-lab
pushed a commit
to zerx-lab/warp
that referenced
this pull request
May 3, 2026
Rebased on top of warpdotdev#9388 (which landed \`hpp\`, \`hxx\`, and the uppercase \`H\` form, per @bnavetta's request). This keeps just the one delta from the original PR: adding \`h++\` to the match arm so the case list covers the full set of C++ header conventions, and extending the existing \`cpp_header_extensions_resolve_to_cpp_language\` test to include \`header.h++\`. \`h++\` is the rarer of the C++ header conventions but it's part of the canonical set (used in some older codebases and called out in the GNU coding style guidance for C++). ### Testing - Existing \`cpp_header_extensions_resolve_to_cpp_language\` test extended to include \`header.h++\`. - \`cargo fmt -p languages -- --check\` passes. - \`cargo test -p languages\` doesn't run locally for me (Metal toolchain unavailable on this machine — same situation as warpdotdev#9277), but CI should cover it. ### Server API No server changes. ### Agent Mode Not applicable. ### Changelog Entries \`CHANGELOG-IMPROVEMENT\`: Recognize \`.h++\` files as C++ headers (in addition to \`.hpp\`, \`.hxx\`, and \`.H\` from warpdotdev#9388). Co-authored-by: anshul-garg27 <anshul-garg27@users.noreply.github.com>
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
4 participants
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.
Rebased on top of #9388 (which landed `hpp`, `hxx`, and the uppercase `H` form, per @bnavetta's request).
This keeps just the one delta from the original PR: adding `h++` to the match arm so the case list covers the full set of C++ header conventions, and extending the existing `cpp_header_extensions_resolve_to_cpp_language` test to include `header.h++`.
`h++` is the rarer of the C++ header conventions but it's part of the canonical set (used in some older codebases and called out in the GNU coding style guidance for C++).
Testing
~inwarp://action/new_tab?path=URLs #9277), but CI should cover it.Server API
No server changes.
Agent Mode
Not applicable.
Changelog Entries
`CHANGELOG-IMPROVEMENT`: Recognize `.h++` files as C++ headers (in addition to `.hpp`, `.hxx`, and `.H` from #9388).