- Added missing translations for diagnostics settings in all locales
- Fixed DiagnosticsSettings component tests to handle conditional rendering
- Updated test mocks to properly handle VSCodeCheckbox onChange events
- Introduced new settings for diagnostics in multiple languages, including:
- Include Diagnostics: Option to enable code diagnostics in API requests.
- Max Diagnostics: Maximum number of diagnostics to include in API requests.
- Diagnostics Filter: Filter diagnostics by code or source.
- Updated localization files for languages: Catalan, German, English, Spanish, French, Hindi, Indonesian, Italian, Japanese, Korean, Dutch, Polish, Portuguese (Brazil), Russian, Turkish, Vietnamese, Chinese (Simplified), and Chinese (Traditional).
- Added DiagnosticsSettings component to SettingsView with proper integration
- Added missing localization keys for diagnostics section
- Standardized includeDiagnostics default value to false across all files
- Fixed double configuration reading in diagnosticsToProblemsString
- Updated filter logic to use exact matching for diagnostic codes
- Replaced any types with proper React event types
- Added UI validation for max diagnostics count (0-200 range)
- Added comprehensive test coverage for new functionality
- Bumped version to 3.20.4
- Add includeDiagnostics, maxDiagnosticsCount, and diagnosticsFilter to global settings
- Create DiagnosticsSettings component for UI configuration
- Update ClineProvider to handle diagnostics settings messages
- Modify diagnosticsToProblemsString to accept options parameter
- Update ExtensionState type and related components
- Add proper defaults: includeDiagnostics=false, maxDiagnosticsCount=5, diagnosticsFilter=['error','warning']
This allows users to configure diagnostics settings that persist across sessions
instead of being reset to defaults on each restart.
Add support for the save/discard flow for support prompt setting page
Normally when you edit things on the settings pages, the save button lights up,
allowing you to discard your changes. Currently the prompts page doesn't support this flow-
the prompts are immediately saved when they change.
With this change, we use the normal cachedState system in the SettingView, allowing users to dicard changes to their prompts like any other setting.
This removed the need for the resetSupportPrompt event since we send the entire state of the support prompts (same as before).
Test plan:
* Manually verified prompts can be saved/discarded for different types of support prompts.
* Add reasoning budget support to Bedrock models and update related components
- Introduced `supportsReasoningBudget` property in Bedrock models.
- Enhanced `AwsBedrockHandler` to handle reasoning budget in payloads.
- Updated `ThinkingBudget` component to dynamically set max tokens based on reasoning support.
- Modified `ApiOptions` and `Bedrock` components to conditionally render `ThinkingBudget`.
- Added tests for extended thinking functionality in `bedrock-reasoning.test.ts`.
* Add BedrockThinkingConfig interface and update payload structure
* fix: address PR review feedback (#4481)
- Simplify ThinkingBudget ternary logic since component only renders when reasoning budget supported
- Break down complex thinking enabled condition with clear documentation
- Replace 'as any' usage with proper TypeScript interfaces for AWS SDK events
- Add comprehensive documentation for multiple stream structures explaining AWS SDK compatibility
* feat: show ThinkingBudget component unconditionally
Remove selectedProviderModels.length check to display ThinkingBudget
for all providers, not just those with available models
---------
Co-authored-by: hannesrudolph <hrudolph@gmail.com>
