Community
Participate
Working Groups
Build ID: I20090522-1710 Steps To Reproduce: 1. Eclipse: 3.5 RC2, CDT: I200905220803 (RC2) 2. Create a managed build C++ project 3. Add an assembler file test.s with the lower case ending .s to the project 4. "Build selected files" from the context menu of test.s is disabled More information: Managed build works fine for *.S assembler files (upper case ending .S). The entry "*.S = Assembly source file" is locked on the preference page "C/C++ File Types". It isn't possible to add a second entry "*.s = Assembly source file".
I see the same behavior in Ganymede as well. But the difference is, in Ganymede it accepts *.s and doesnot recognise *.S assembly file. *.s is in preference page and it is not possible to add *.S entry. --fizul (In reply to comment #0) > Build ID: I20090522-1710 > > Steps To Reproduce: > 1. Eclipse: 3.5 RC2, CDT: I200905220803 (RC2) > 2. Create a managed build C++ project > 3. Add an assembler file test.s with the lower case ending .s to the project > 4. "Build selected files" from the context menu of test.s is disabled > > More information: > Managed build works fine for *.S assembler files (upper case ending .S). The > entry "*.S = Assembly source file" is locked on the preference page "C/C++ File > Types". It isn't possible to add a second entry "*.s = Assembly source file".
In the meantime I found a workaround for the problem: Project Properties -> C/C++ General -> File Types -> Use project settings -> New -> Pattern: *.s, Type: Assembly Source File -> OK alex
(In reply to comment #1) > I see the same behavior in Ganymede as well. But the difference is, in Ganymede > it accepts *.s and doesnot recognise *.S assembly file. *.s is in preference > page and it is not possible to add *.S entry. > > --fizul In my CDT 6.0 (Galileo on MS Windows) it switches over to accepts not *.s and recognise *.S assembly files. Not good. But I think it's an plattform fault, since in org.eclipse.cdt.core (5.1.1.200909110608) the content-type contribution looks fine: base-type = org.eclipse.core.runtime.text file-extensions = S,s,asm,ASM id = asmSource name = Assembly Source File priority = high Can someone assign this bug to the plattform? --Harald
org.eclipse.core.internal.content.FileSpec: public boolean equals(final String text, final int otherType, final boolean strict) { return ((!strict && getBasicType(type) == getBasicType(otherType)) || type == otherType) && this.text.equalsIgnoreCase(text); } This is used by org.eclipse.core.internal.content.ContentType.hasFileSpec() for matching to avoid duplicates when org.eclipse.core.internal.content.ContentType.internalAddFileSpec() is adding file extensions, and that means that, when all the extension specs are being added to the content type at startup time, as from the list you mentioned: > file-extensions = S,s,asm,ASM the first "S" is accepted, the second "s" discarded as a duplicate; likewise for the "asm", and "ASM" probably doesn't work for you either. The result is that the asmSource ContentType only ends up with two file extensions. The underlying bug then is that FileSpec.equals is case insensitive, but the rest of the world expects file extensions (as represented by FileSpecs) to be case-sensitive. Here's a traceback of the stack at the time when it decides that "s" and "S" are duplicates and not to add the second one: Thread [Thread-2] (Suspended) ContentType.hasFileSpec(String, int, boolean) line: 388 ContentType.internalAddFileSpec(String, int) line: 406 ContentType.createContentType(ContentTypeCatalog, String, String, byte, String[], String[], String, String, Map, IConfigurationElement) line: 96 ContentTypeBuilder.createContentType(IConfigurationElement) line: 170 ContentTypeBuilder.registerContentType(IConfigurationElement) line: 211 ContentTypeBuilder.buildCatalog() line: 90 ContentTypeManager.getCatalog() line: 123 ContentTypeManager.getContentType(String) line: 134 EditorRegistry.addEditorFromPlugin(EditorDescriptor, List, List, List, boolean) line: 251 EditorRegistryReader.readElement(IConfigurationElement) line: 108 EditorRegistryReader(RegistryReader).readElements(IConfigurationElement[]) line: 144 EditorRegistryReader(RegistryReader).readExtension(IExtension) line: 155 EditorRegistryReader(RegistryReader).readRegistry(IExtensionRegistry, String, String) line: 176 EditorRegistryReader.addEditors(EditorRegistry) line: 42 EditorRegistry.initializeFromStorage() line: 565 EditorRegistry.<init>() line: 164 WorkbenchPlugin.getEditorRegistry() line: 454 EditorReference.getDescriptor(String) line: 225 EditorReference.<init>(EditorManager, IMemento) line: 190 EditorManager.restoreEditorState(IMemento, ArrayList, IEditorReference[], MultiStatus) line: 1486 EditorManager.restoreState(IMemento) line: 928 WorkbenchPage.restoreState(IMemento, IPerspectiveDescriptor) line: 3174 WorkbenchWindow.restoreState(IMemento, IPerspectiveDescriptor) line: 2219 Workbench.doRestoreState(IMemento, MultiStatus) line: 3399 Workbench.access$30(Workbench, IMemento, MultiStatus) line: 3341 Workbench$54.run() line: 2117 Workbench.runStartupWithProgress(int, Runnable) line: 1831 Workbench.restoreState(IMemento) line: 2115 Workbench.access$28(Workbench, IMemento) line: 2086 Workbench$49.run() line: 1949 SafeRunner.run(ISafeRunnable) line: 42 Workbench.restoreState() line: 1893 WorkbenchConfigurer.restoreState() line: 183 WorkbenchAdvisor$1.run() line: 781 I'm gonna try making that comparison in FileSpec.equals case-sensitive and see how much of the world breaks.
Created attachment 164154 [details] Simple fix Works for me. Haven't spotted any side-effects so far.
This appears to be a platform issue and actualy a duplicate of bug 105022. Could be worth to attach the patch there. Thanks for looking at it. *** This bug has been marked as a duplicate of bug 105022 ***
*** Bug 313350 has been marked as a duplicate of this bug. ***
