Tr/patch extra lines before and after

[mrT23]

PR Type

Enhancement, Tests

---

Description

• Implemented granular control over patch extension by introducing separate patch_extra_lines_before and patch_extra_lines_after parameters.
• Updated core functions in git_patch_processing.py and pr_processing.py to utilize the new patch extension parameters.
• Modified configuration to set patch_extra_lines_before to 4 and patch_extra_lines_after to 2.
• Increased max_context_tokens from 10000 to 16000 for code suggestions.
• Added support for the 'claude-3-5-sonnet' model with a 100000 token limit.
• Updated and added tests to verify the new patch extension functionality.
• Revised documentation to reflect the new configuration options for patch extension.
• Enabled extra lines for code suggestions by default.

---

Changes walkthrough 📝

	Relevant files
Configuration changes	__init__.py Add Claude 3.5 Sonnet model                                                            pr_agent/algo/init.py Added 'claude-3-5-sonnet' to the model token limit dictionary with a limit of 100000 tokens. +1/-0      configuration.toml Update configuration for new patch extension settings        pr_agent/settings/configuration.toml Changed patch_extra_lines to separate patch_extra_lines_before and patch_extra_lines_after. Updated patch_extra_lines_before to 4 and patch_extra_lines_after to 2. Increased max_context_tokens from 10000 to 16000. +3/-2
Enhancement	git_patch_processing.py Refactor patch extension for granular context control        pr_agent/algo/git_patch_processing.py Modified extend_patch function to accept separate patch_extra_lines_before and patch_extra_lines_after parameters. Updated patch extension logic to use these new parameters for more granular control over context lines. +8/-19    pr_processing.py Update PR processing for new patch extension parameters    pr_agent/algo/pr_processing.py Updated get_pr_diff and pr_generate_extended_diff functions to use separate before and after extra lines parameters. Modified patch extension calls to use the new configuration settings. +15/-17  pr_code_suggestions.py Enable extra lines for code suggestions                                    pr_agent/tools/pr_code_suggestions.py Changed disable_extra_lines parameter from True to False in the get_pr_diff call within _prepare_prediction method. +1/-1
Tests	test_extend_patch.py Update and add tests for new patch extension functionality tests/unittest/test_extend_patch.py Updated existing tests to use new patch_extra_lines_before and patch_extra_lines_after parameters. Added new test class PRProcessingTest with tests for extended patch functionality. +65/-45
Documentation	additional_configurations.md Update documentation for new patch extension settings        docs/docs/usage-guide/additional_configurations.md Updated documentation to reflect new patch_extra_lines_before and patch_extra_lines_after configuration options. +2/-1

---

💡 PR-Agent usage:
Comment /help on the PR to get a list of all available PR-Agent tools and their descriptions

[qodo-merge-pro]

PR Reviewer Guide 🔍

⏱️ Estimated effort to review: 3 🔵🔵🔵⚪⚪

🏅 Score: 85

🧪 PR contains tests

🔒 No security concerns identified

🔀 Multiple PR themes Sub-PR theme: Implement granular control over patch extension Relevant files: pr_agent/algo/git_patch_processing.py pr_agent/algo/pr_processing.py Sub-PR theme: Update configuration and documentation for new patch extension parameters Relevant files: pr_agent/settings/configuration.toml docs/docs/usage-guide/additional_configurations.md Sub-PR theme: Add and update tests for new patch extension functionality Relevant files: tests/unittest/test_extend_patch.py

⚡ Key issues to review Code Refactoring The extend_patch function has been significantly modified to handle separate patch_extra_lines_before and patch_extra_lines_after parameters. This change might require careful review to ensure it doesn't introduce any bugs. Configuration Update The PR introduces new configuration parameters patch_extra_lines_before and patch_extra_lines_after. Ensure these are properly documented and used consistently throughout the codebase.

[qodo-merge-pro]

PR Code Suggestions ✨

Category	Suggestion	Score
Best practice	Use parameterized tests to reduce code duplication and improve test maintainability Consider using parameterized tests to reduce code duplication and make it easier to add new test cases. This will make the test suite more maintainable and easier to extend. tests/unittest/test_extend_patch.py [6-25] -def test_happy_path(self): - original_file_str = 'line1\nline2\nline3\nline4\nline5' - patch_str = '@@ -2,2 +2,2 @@ init()\n-line2\n+new_line2\nline3' - num_lines = 1 - expected_output = '@@ -1,4 +1,4 @@ init()\nline1\n-line2\n+new_line2\nline3\nline4' +import pytest + +@pytest.mark.parametrize("original_file_str, patch_str, num_lines, expected_output", [ + ('line1\nline2\nline3\nline4\nline5', + '@@ -2,2 +2,2 @@ init()\n-line2\n+new_line2\nline3', + 1, + '@@ -1,4 +1,4 @@ init()\nline1\n-line2\n+new_line2\nline3\nline4'), + ('line1\nline2\nline3\nline4\nline5', + '', + 1, + ''), +]) +def test_extend_patch(self, original_file_str, patch_str, num_lines, expected_output): actual_output = extend_patch(original_file_str, patch_str, patch_extra_lines_before=num_lines, patch_extra_lines_after=num_lines) assert actual_output == expected_output -# Tests that the function returns an empty string when patch_str is empty -def test_empty_patch(self): - original_file_str = 'line1\nline2\nline3\nline4\nline5' - patch_str = '' - num_lines = 1 - expected_output = '' - assert extend_patch(original_file_str, patch_str, - patch_extra_lines_before=num_lines, patch_extra_lines_after=num_lines) == expected_output - Apply this suggestion Suggestion importance[1-10]: 8 Why: Parameterized tests significantly improve test maintainability and make it easier to add new test cases, which is a valuable best practice in testing.	8
Maintainability	Extract patch extension logic into a separate function for better modularity Consider extracting the patch extension logic into a separate function to improve code modularity and reusability. This will make the code easier to maintain and test. pr_agent/algo/pr_processing.py [404-407] +def get_patch_extension_params(): + settings = get_settings() + return { + 'patch_extra_lines_before': settings.config.patch_extra_lines_before, + 'patch_extra_lines_after': settings.config.patch_extra_lines_after + } + +patch_params = get_patch_extension_params() patches_extended, total_tokens, patches_extended_tokens = pr_generate_extended_diff( - pr_languages, token_handler, add_line_numbers_to_hunks=True, - patch_extra_lines_before=get_settings().config.patch_extra_lines_before, - patch_extra_lines_after=get_settings().config.patch_extra_lines_after) + pr_languages, token_handler, add_line_numbers_to_hunks=True, **patch_params) Apply this suggestion Suggestion importance[1-10]: 7 Why: This suggestion improves code modularity and reusability, which can lead to better maintainability and easier testing.	7
	Use a more descriptive variable name to improve code readability Consider using a more descriptive variable name instead of res to improve code readability. For example, you could use hunk_info or patch_details to better reflect the content of the list. pr_agent/algo/git_patch_processing.py [37-46] -res = list(match.groups()) -for i in range(len(res)): - if res[i] is not None: - res[i] = res[i].decode('utf-8') -start1, size1, size2 = map(int, res[:3]) +hunk_info = list(match.groups()) +for i in range(len(hunk_info)): + if hunk_info[i] is not None: + hunk_info[i] = hunk_info[i].decode('utf-8') +start1, size1, size2 = map(int, hunk_info[:3]) start2 = 0 -section_header = res[4] +section_header = hunk_info[4] Apply this suggestion Suggestion importance[1-10]: 5 Why: The suggestion improves code readability by using a more descriptive variable name, but it's a minor change that doesn't significantly impact functionality.	5
Enhancement	Use f-strings for more concise and readable string formatting Consider using f-strings for string formatting instead of the older .format() method. F-strings are more readable and generally faster. pr_agent/algo/git_patch_processing.py [51-53] extended_patch_lines.append( - f'@@ -{extended_start1},{extended_size1} ' - f'+{extended_start2},{extended_size2} @@ {section_header}') + f'@@ -{extended_start1},{extended_size1} +{extended_start2},{extended_size2} @@ {section_header}') Apply this suggestion Suggestion importance[1-10]: 4 Why: While f-strings can improve readability, the existing code is already using f-strings. The suggestion only combines two f-strings into one, which is a minor optimization.	4