Bug 118823 - [model] Secondary types cache not reset while removing _all_ secondary types from CU
Summary: [model] Secondary types cache not reset while removing _all_ secondary types ...
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.2   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.2 M5   Edit
Assignee: Frederic Fusier CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-12-01 10:24 EST by Frederic Fusier CLA
Modified: 2020-10-01 09:36 EDT (History)
0 users

See Also:


Attachments
Patch to fix this issue (24.95 KB, patch)
2005-12-07 12:56 EST, Frederic Fusier CLA
no flags Details | Diff
New patch to fix this issue (45.43 KB, patch)
2006-01-05 13:37 EST, Frederic Fusier CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Frederic Fusier CLA 2005-12-01 10:24:48 EST
Using build I20051129-1200.

While talking about bug 118789, we discover another problem with fix for bug 36032.

Let's take following example:
P
  A.java
    public class A {}
    class S {}
  B.java
    public class B {
      S s;
    }

Here's the scenario:
0) Start a wksp with "org.eclipse.jdt.core/debug/resolution" trace activated
1) Open B, there's of course no compiler error
2) Now modify A.java contents outside eclipse to remove secondary type
   declaration
3) Refresh project => get an error in B: OK
4) Clear console
5) Select S and hit F3 => current text selection does not resolve to a Java
   element: OK
6) Lookt at trace in console: it shows that a secondary type 'S' has been found
   although it should not!
Comment 1 Frederic Fusier CLA 2005-12-07 12:56:33 EST
Created attachment 31320 [details]
Patch to fix this issue

This is a specific eclipse patch format including 2 projects:
  - org.eclipse.jdt.core
  - org.eclipse.jdt.core.tests.model
Comment 2 Frederic Fusier CLA 2005-12-09 11:44:50 EST
Too late for M4, defer to M5...
Comment 3 Frederic Fusier CLA 2006-01-03 10:48:52 EST
Note that with 3.2 M4, trace in Console looks like:
Thread[main,6,main]  BUILDING NameLoopkup
Thread[main,6,main]  -> pkg roots size: 10
Thread[main,6,main]  -> pkgs size: 443
Thread[main,6,main]  -> working copy size: 2
Thread[main,6,main]  -> spent: 0ms
Thread[main,6,main] NameLookup FIND SECONDARY TYPES:
Thread[main,6,main]  -> pkg name: 
Thread[main,6,main]  -> type name: S
Thread[main,6,main]  -> projects: b118823
Thread[main,6,main]  -> type: S
Thread[main,6,main] NameLookup FIND SECONDARY TYPES:
Thread[main,6,main]  -> pkg name: java.lang
Thread[main,6,main]  -> type name: S
Thread[main,6,main]  -> projects: b118823
Thread[main,6,main] TIME SPENT in NameLoopkup#seekTypesInSourcePackage: 0ms
Thread[main,6,main] TIME SPENT in NameLoopkup#seekTypesInBinaryPackage: 0ms

The line :
Thread[main,6,main]  -> type: S
shows that NameLookup finds a secondary type 'S'
Comment 4 Frederic Fusier CLA 2006-01-05 13:37:10 EST
Created attachment 32533 [details]
New patch to fix this issue

Specific eclipse patch format including changes on following projects:
  - org.eclipse.jdt.core
  - org.eclipse.jdt.core.model.tests
Comment 5 Frederic Fusier CLA 2006-01-05 13:37:32 EST
Patch released in HEAD.

Note that with this version, search request for secondary types is only done once. Secondary types cache is updated after using delta processor events and indexing...

Performance tests have been run and no regression have been noticed.

Test cases have been added to ReconcilerTests.
Comment 6 David Audel CLA 2006-02-15 04:05:48 EST
Verified for 3.2 M5 using build I20060214-0010