Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 334922

Summary: CharOperation#match does not work as expected when isCaseSensitive is passed as false
Product: [WebTools] JSDT Reporter: Ian Tewksbury <itewksbu>
Component: GeneralAssignee: Ian Tewksbury <itewksbu>
Status: RESOLVED FIXED QA Contact: Nitin Dahyabhai <thatnitind>
Severity: normal    
Priority: P3 CC: david_williams
Version: 3.2.3Flags: david_williams: pmc_approved+
thatnitind: pmc_approved? (raghunathan.srinivasan)
thatnitind: pmc_approved? (naci.dai)
thatnitind: pmc_approved? (deboer)
thatnitind: pmc_approved? (neil.hauge)
thatnitind: pmc_approved? (kaloyan)
thatnitind: review+
Target Milestone: 3.2.3   
Hardware: All   
OS: All   
Whiteboard: PMC_approved
Bug Depends on:    
Bug Blocks: 333901, 333903    
Attachments:
Description Flags
fix patch
none
unit tests none

Description Ian Tewksbury CLA 2011-01-20 11:35:09 EST 
When using the CharOperation#match method and isCaseSensitive the results are not always what you expect.  If you pass the same string for both the pattern and the path and thouse identical strings contain one capital letter match will return FALSE when TRUE would be epxected.

This is because in #match there is a bit of logic that says if isCaseSensitive is false then lowercase the character from the path but NOT the character from the pattern.

This needs to be updated so that if isCaseSensitive is set to false then both characters are lower cased.
Comment 1 Ian Tewksbury CLA 2011-01-20 11:39:01 EST 
Created attachment 187210 [details]
fix patch

Needed fix.
Comment 2 Nitin Dahyabhai CLA 2011-01-26 21:13:58 EST 
Created attachment 187706 [details]
unit tests
Comment 3 Nitin Dahyabhai CLA 2011-01-26 21:15:39 EST 
* Explain why you believe this is a stop-ship defect. Or, if it is a "hotbug" (requested by an adopter) please document it as such. 

This utility matching method doesn't correctly handle case insensitivity. As it is used when applying inclusion/exclusion filters to our project Include Path, it can cause us to index and process files not as intended.

* Is there a work-around? If so, why do you believe the work-around is insufficient? 

No workaround.  Exclusion patterns and file paths could fail the match test incorrectly, affecting search results and indexing operations.

* How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added?

JUnit attached.

* Give a brief technical overview. Who has reviewed this fix?

Corrects the logic in the test so that case insensitivity actually does what it should.

* What is the risk associated with this fix? 

Far-reaching, but low.
Comment 4 David Williams CLA 2011-01-27 00:26:42 EST 
I'm fine with this fix, sounds better than it was. But ... I will remind you of all the nice ICU case checking methods that will automatically handle locale sensitive case differences for you (you know, like that lower/uppercase Turkish "i" problem :) Not sure if this is locale sensitive data (or, if already does call icu deep in the scanner code?) ... just reminding you. 

And, thanks for including a test case!
Comment 5 Nitin Dahyabhai CLA 2011-01-27 00:59:24 EST 
Released.