Add a case sensitive variant of IContentType.isAssociatedWith #673

[jantje]

As discussed in #673
Would something like this be acceptable?
I could not test the change so I do not know this will work yet so please do not yet accept this.
What is the advised way to add tests?

[github-actions]

Test Results

  424 files   -   212    424 suites   - 212   29m 14s ⏱️ - 10m 46s
3 945 tests ±    0  3 904 ✅  -    18   41 💤 +18  0 ❌ ±0 
8 294 runs   - 4 147  8 179 ✅  - 4 098  115 💤  - 49  0 ❌ ±0 

Results for commit 9b1f3c0. ± Comparison against base commit 31e1ef4.

This pull request skips 18 tests.

org.eclipse.core.tests.resources.regression.Bug_026294 ‑ testDeleteClosedProjectLinux
org.eclipse.core.tests.resources.regression.Bug_026294 ‑ testDeleteFolderLinux
org.eclipse.core.tests.resources.regression.Bug_026294 ‑ testDeleteOpenProjectLinux
org.eclipse.core.tests.resources.regression.Bug_044106 ‑ testDeleteLinkedFile
org.eclipse.core.tests.resources.regression.Bug_044106 ‑ testDeleteLinkedFileKeepHistory
org.eclipse.core.tests.resources.regression.Bug_044106 ‑ testDeleteLinkedFolder
org.eclipse.core.tests.resources.regression.Bug_044106 ‑ testDeleteLinkedFolderKeepHistory
org.eclipse.core.tests.resources.regression.Bug_044106 ‑ testDeleteLinkedFolderParentKeepHistory
org.eclipse.core.tests.resources.regression.Bug_044106 ‑ testDeleteLinkedResourceInProject
org.eclipse.core.tests.resources.regression.Bug_044106 ‑ testDeleteLinkedResourceInProjectKeepHistory
…

[jukzi]

As discussed in #673
Would something like this be acceptable?

maybe @jonahgraham can review as he was involved in the discussion?

What is the advised way to add tests?

Copy and paste existing tests and adapt them. I typically find related tests in the call hierarchy.

[merks]

I'm not sure the deprecations in the API are necessary or helpful. They're certainly not properly documented.

[merks]

If you deprecate it, there should be javadoc explaining what to use instead.

I wonder though, why deprecate it instead of having a default method that calls the new method with true, which has been the behavior of the past? But then, you've deprecated two methods and replaced them with a single method, so if I have a string but not a scope context, what will I do to fix the deprecation warning?

[merks]

If you deprecate it, there should be javadoc explaining what to use instead.

[mickaelistria]

What would be responsible of defining whether we want caseStrict or not? Some global preference? A flag in the extension point?

[merks]

What would be responsible of defining whether we want caseStrict or not? Some global preference? A flag in the extension point?

That's also a very good question! I see these callers:

But that's mostly in the type hierarchy. It's not at all clear how the following usage would decide true versus false and in fact there isn't good non-deprecated method for it to call:

I would have expect the flag to be defined by the content type provider/definition such that this decision is not even something you see in the API. I.e., just because CDT wants .c and .C to be the same, doesn't mean JDT should also .Java, .JaVa, and all variations there of...

[laeubi]

As we already have a typeMask, why not having a new flag controlling the behavior?