Community
Participate
Working Groups
Build Identifier: Eclipse 3.5.1 - JavaScript Developer Tools 1.1.2.v200908101420-77-FGCCcNBC-BhLcE_Pm - Build id: 20090917225226 Code completion does not populate parameters for constructor. Animal.prototype=new Object(); function Animal(name){}; // when code completion is invoked, user has no idea the Animal constructor takes any param Animal.prototype.property=""; Animal.prototype.eat=function(food){}; Reproducible: Always Steps to Reproduce: 1. Define the above in your JavaScript. 2. Enter "var deer = new Ani" then Ctrl+Space. "Ani" is expanded to "Animal", but there is no bracket and param displayed. 3. Now complete the declaration so that it looks like: var deer = new Animal('Sam'); 4. Now type "deer.e" then Ctrl+Space, see that it's expanded to "deer.eat(food)". Can code completion for constructors works like a regular function?
JSDoc is not shown for constructor as well.
I think the problem here is that the constructor function is not actually shown in content assist. It is only showing the name of class.
The AssistParser has been modified to just show type names, but without that modification we get all of the visible variable and function names instead (even if that includes constructors).
Adding information as per the WTP Hotbug policy (http://wiki.eclipse.org/WTP/Hotbug_Policy): 1. Affiliation: RIM 2. Targeted Release: The fix needs to go into the final release of WTP 3.2 so it's fixed in Eclipse 3.6. 3. Reason why this is a hotbug: This bug blocks our adoption of WTP because the JavaScript code completion is a critical feature of our product. Fixing this bug would make code completion much more usable if the user knows what parameters the constructor(s) would accept.
Deferring. Not enough time left.
Created attachment 177568 [details] Fix Patch This patch seems to work to get constructor content assist working. But I have 102 failing existing JUnits I need to look into and write some new JUnits.
Created attachment 177649 [details] Fix Patch - Update 1 These are the scenarios that Chris and I have identified that should work: ---- file1.js: function Awesome(param1, param2) { this.param1 = param1; this.param2 = param2; }; bar.Class1 = function(a, b) {}; bar.Class1.prototype = new Object(); ---- With this setup the following should work in "file1.js" or a separate "file2.js" with "file1.js" being open or closed (in memory model or index model). new Aw| new b| new bar.| new bar.Cl| new Cla| With this new patch the only scenario that does not work is "new Cla|" in a separate "file2.js" with "file1.js" open or closed. I know why this. I just haven't figured out how to get around the problem. With this patch all existing JUnits also pass. Well 2 didn't but that was a case where the JUnit was now wrong so had to be updated. ---- Things to do: * Write new JUnits to test new functionality * get the one broken scenario working
Good work Ian.
Created attachment 178055 [details] Fix Patch with JUnits - Update 2 Same fix now plus 20 new junits. Still one more scenario to fix which is the one new junit that fails. all existing junits pass.
Created attachment 178355 [details] Fix Patch with JUnits - Update 3 Cleaned up patch. Disabled JUnit for Bug 324690. Bug 324960 will cover fixing the one case this patch does not deal with. Patch ready for review.
Created attachment 178356 [details] Testing ZIP This Zip file needs to be placed in "org.eclipse.wst.jsdt.ui.tests/testresources/ContentAssist.zip" for the JUnits to work.
* 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. Hotbug requested by an adopter * Is there a work-around? If so, why do you believe the work-around is insufficient? No there is not. Without this fix there is no content assist for constructors in JSDT * How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? I have added 19 JUnits to cover every possibility I can think of. I have also smoke tested the new and existing functionality. All existing tests pass. * Give a brief technical overview. Who has reviewed this fix? JSDT Core had to be tweaked in many places to get content assist for constructors to show up. The fix spans everything form the content assist code, the search engine code, the compiler, and the infer engine. There is no one major fix in any one place just a lot of 1-10 line fixes here and there to get the story working. The idea of constructors already existed it just wasn't fully flushed out for the content assist story. Things are extra complicated by constructors for classes in packages. No one part of this patch fixes anything on its own, only with all of the parts together does the full constructor content assist story work (except for the one case mentioned in Bug 324690) * What is the risk associated with this fix? Mitigated Medium. It is Medium because there are changes here in the basic classes of JSDT when it comes to the search engine and the infer engine (again minor tweaks, but changes none-the-less). But it is mitigated because of the extensive testing done on existing functionality and new functionality.
*** Bug 324690 has been marked as a duplicate of this bug. ***
Created attachment 178862 [details] Fix Patch with JUnits - Update 4 This patch fixes the one scenario that was not working, represented by the following example: File1.js ----- bar.Class1 = function(a, b) {}; bar.Class1.prototype = new Object(); ----- File2.js ----- new Cla| ----- JUnit has been enabled to test this case (test zip does NOT need to be updated). All existing JUnits pass. Smoke test of content assist passes.
Created attachment 179784 [details] inappropriate proposals shown with "new |" Current patch (attachment 178862 [details]) seems to include all of the properties of Object and Global as potential constructors as well as the types that were shown pre-patch. It should also patch the new test folder into that bundle's build.properties file.
Another problem... function Class1() { this.a = 3; } var a = new Class1(); var Class2 = function() {}; Class2.prototype.meth = function() {}; new Clas* When I attempt content assist I do not get the constructor for Class2.
Created attachment 179871 [details] Fix Patch with JUnits - Update 5 Patch updated to deal with issues brought up in comment 15 and comment 16. Also added more JUnits.
Created attachment 179872 [details] Testing ZIP - Update 1 An updated testing zip for fix patch update 5. Still needs to go in "org.eclipse.wst.jsdt.ui.tests/testresources/ContentAssist.zip"
Created attachment 179972 [details] Fix Patch with JUnits - Update 6 Last patch accidentally included a testing println statement.
Created attachment 179983 [details] Fix Patch with JUnits - Update 6 Found a couple more testing lines that snuck through.
var o = { a: new * } Content assist at * returns all methods.
(In reply to comment #21) > var o = { > a: new * > } > > Content assist at * returns all methods. Because that is also the current behavior and you have been worried about the size and scope of this patch already, my suggestion would be to put it in as is and open a separate report for that issue. Unless you want me to grow the size and scope of this patch to include this issue as well.
(In reply to comment #22) > (In reply to comment #21) > > var o = { > > a: new * > > } > > > > Content assist at * returns all methods. > > Because that is also the current behavior and you have been worried about the > size and scope of this patch already, my suggestion would be to put it in as is > and open a separate report for that issue. Unless you want me to grow the size > and scope of this patch to include this issue as well. I take that back. When responding to comment 15 i thought I had fixed this. And I sort of did for the case new | it would seem your case var o = { a: new | } is somehow different. Looking into why and see if I can fix it.
Created attachment 183390 [details] Fix Patch with JUnits - Update 7 Fixed issue mentioned in comment 21. Fix was needed in CompletionEngine#isAllocationExpression to deal with allocation expressions nested inside of other expressions. Now using an ASTVisitor to determine if the completion expression is part of an allocation expression. Added new junits to test for the scenario in comment 21. Removed unnecessary changes to SearchPattern. After further investigation must have been left over from some earlier attempt I made.
Created attachment 183391 [details] Testing ZIP - Update 2 An updated testing zip for fix patch update 7. Still needs to go in "org.eclipse.wst.jsdt.ui.tests/testresources/ContentAssist.zip"
I opened Bug 330614 to track using working copies when available for content assist.
(In reply to comment #26) > I opened Bug 330614 to track using working copies when available for content > assist. Ignore this, with this patch the working copies are used.
Created attachment 184171 [details] Testing ZIP - Update 3 Updated testing zip for: "org.eclipse.wst.jsdt.ui.tests/testresources/ContentAssist.zip"
Created attachment 184172 [details] Fix Patch with JUnits - Update 8 More JUnits added.
Created attachment 184812 [details] Fix Patch with JUnits - Update 9 Update the patch that gets rid of some unnecessary changes that suck their way in while developing. Also fixes issue with <init>() being proposed in the case of new | For that case only constructors in the current document are suggested and <init>() was coming up because of an issue in MethodScope#createMethod. Now for the blank document case doing new | will give the suggestions: Global(), Object(), Window() which are the parent types of any given JS document. I also fixed it so that in the allocation expression content assist case (aka: new *|) only constructors are now recommended. There was an issue that when searching the namespace all bindings would be returned not just constructors.
Created attachment 186212 [details] Fix Patch with JUnits - Update 10 Updated patch to apply cleanly with latest code in 3.2.x stream but there seem to be some errors in the existing JUnits. Problem seems to be around the fix for comment #30. I will update when I figure out whats going on.
Created attachment 186287 [details] Fix Patch with JUnits - Update 11 This patch updates Scope#getConstructor to work correctly with the rest of the patch, most notably not searching for "<init>" and not validating parameters. This method is what was causing the JUnit fails after implementing comment 30. This patch also updates all of the copyright years to 2011
Created attachment 186670 [details] Fix Patch with JUnits - Update 12 Resolved conflicts with latest 3.2.3 code and patch.
Created attachment 187057 [details] Fix Patch with JUnits - Update 13 Updated patch to update SourceTypeBinding to ensure that the scope for a method gets bound correctly. Also updated JUnits that started to fail because of this, but it turns out that they were hard coded with a broken solution and the new solution is actually correct. Testing ZIP does not need to change.
Created attachment 187315 [details] New Patch with Junits This patch is different from the previous because it changes the type of completion node that is used. Because of this and currently limitations on the parser this patch does not allow constructor content assist to work for the following case new foo.bar.MyCo| If this is the patch used then a new bug will have to be open to track fixes needed to the parser to support this case.
We found some more issues ad-hoc testing today. Trying to apply a completion for the constructor for "com.foo" did nothing--it may have even removed what Chris was typing to filter his list down. Far less important, the proposal icon's also still the Class image, not the function/method image.
(In reply to comment #36) > We found some more issues ad-hoc testing today. Trying to apply a completion > for the constructor for "com.foo" did nothing--it may have even removed what > Chris was typing to filter his list down. > See comment #35. That case is not going to work with the updated patch you asked for. If you want to go back to my original patch that scenario works as expected. > Far less important, the proposal icon's also still the Class image, not the > function/method image. That should not be to hard to fix.
(In reply to comment #36) > We found some more issues ad-hoc testing today. Trying to apply a completion > for the constructor for "com.foo" did nothing--it may have even removed what > Chris was typing to filter his list down. > > Far less important, the proposal icon's also still the Class image, not the > function/method image. The image is not really an issue. It was just showing the type proposal. The most important issue was the ArrayIndexOutOfBounds exception I was seeing.
(In reply to comment #38) > (In reply to comment #36) > > We found some more issues ad-hoc testing today. Trying to apply a completion > > for the constructor for "com.foo" did nothing--it may have even removed what > > Chris was typing to filter his list down. > > > > Far less important, the proposal icon's also still the Class image, not the > > function/method image. > > The image is not really an issue. It was just showing the type proposal. > > The most important issue was the ArrayIndexOutOfBounds exception I was seeing. I see no comment here about an ArrayIndexOutOfBounds. Whats the stack?
Created attachment 197744 [details] New Patch with JUnits - Update 1 Updates the patch to apply against latest 3.2m stream. Tested and works.
Some high level info: * index version updated because now constructors that were not in the index will now be in the index and thus projects need re-indexing * add a new proposal type for constructors, idea taken from JDT * completionengine updated so it can do searches looking only for constructors which are METHOD bindings that have isConstructor set to true * updated a couple classes to stop ignoring working copies, ignoring working copies meant that no constructors from open files would be included in results * updated enviorment and search of index to use regular expression so when matching on "Test|" will match on Test TestBar foo.Test foo.TestBar test.foo.Bar I did performance testing, no difference using or not using regex * made it so the inferred name of a function will be used if the method declarion did not have a name, this helps with cases like foo = function() {}, also some other changes to support that * updated some cases to fix up argument binding to the constructors, specifically getting the name and type of the arguments * wrote a TON of JUnits that tests both general function content assist and constructor content assist. There are also extra tests in there that are turned off for when comment 35 is addressed
Created attachment 197928 [details] New Patch with JUnits - Update 2 Same as the last patch except for now cases like "new foo.bar.Aw|" now work. CompletionParser#createAssistTypeForAllocation * updated to take a CompletionOnMemberAccess and turn it into a CompletionOnSingleTypeReference * this only happens when the COmpletionOnMememberAccess is in an AllocationExpression CompletionOnMembmerAccess#isSpecial *now overrides parent to return true because it is a special node because it is a completion node ContentAssistTests * added back all of the tests having to do with cases like "new foo.bar.Aw|"
The following junits are failing after applying this patch..... InferTypesTest - test068 - test069 Please investigate before we review the patch.
Created attachment 198031 [details] New Patch with JUnits - Update 3 To address comment 43, not even sure how this test passed before my fix, there is a line in InferEngine that was commented out at some point that sets the type for a constructor, I added to my patch to add that line back. All new and existing JUnits now pass. I also updated Scope#getConstructor, I ran into an edge case that could cause some NPEing, that is now protected against.
Created attachment 198043 [details] New Patch with JUnits - Update 4 Updated InferedType#addConstructorMethod to perform some actions that were being taken by every implementer, such as setting the new InferredMethod as a constructor and setting the return type. Then updated all the callers to stop doing this on their own. Basically duplicate code clean up.
Created attachment 198131 [details] New Patch with JUnits - Update 5 Same as previous patch except I have updated SourceTypeBinding#buildMethods to correctly bind the arguments to the methods. All new and existing JUnits pass.
Created attachment 198132 [details] New Patch with JUnits - Update 6 Attached wrong file during the last patch. This is the correct one.
Content assist for the short name is not working..... For example....org.eclipse.MyClass if I attempt content assist on MyClass I get no proposals. I also had several time outs.
Created attachment 198290 [details] patch with JUnits - Update 7 Chris found a small bug that if after invoking content assist the user starts typing, if the case of the user prefix does not match that of the suggested proposals they will be filtered out. EX: new comb| suggestion is "foo.ComboBox", but if the user then types "o" the suggestion "foo.ComboBox" goes away because "combo" does match case of "ComboBox". patch now updated so this works ignoring case.
Type: var d = new D and attempt content assist.....it hangs for about 20 seconds and then I get: on var d = new D 4:20:11 PM: Me: takes about 20 seconds and then.... 4:20:12 PM: Me: !MESSAGE Exception when processing proposal for: dojox.grid.enhanced.plugins.filter._DataExpr() !STACK 0 java.lang.IllegalArgumentException at org.eclipse.wst.jsdt.internal.core.util.Util.scanTypeSignature(Util.java:2240) at org.eclipse.wst.jsdt.core.Signature.getParameterCount(Signature.java:564) at org.eclipse.wst.jsdt.ui.text.java.CompletionProposalCollector.createMethodReferenceProposal(CompletionProposalCollector.java:724) at org.eclipse.wst.jsdt.ui.text.java.CompletionProposalCollector.createJavaCompletionProposal(CompletionProposalCollector.java:401) at org.eclipse.wst.jsdt.ui.text.java.CompletionProposalCollector.accept(CompletionProposalCollector.java:214) at org.eclipse.wst.jsdt.internal.codeassist.CompletionEngine.acceptBindings(CompletionEngine.java:854) at org.eclipse.wst.jsdt.internal.codeassist.CompletionEngine.findTypesAndPackages(CompletionEngine.java:5451) at org.eclipse.wst.jsdt.internal.codeassist.CompletionEngine.complete(CompletionEngine.java:1286) at org.eclipse.wst.jsdt.internal.codeassist.CompletionEngine.complete(CompletionEngine.java:2291) at org.eclipse.wst.jsdt.internal.core.Openable.codeComplete(Openable.java:135) at org.eclipse.wst.jsdt.internal.core.CompilationUnit.codeComplete(CompilationUnit.java:305) at org.eclipse.wst.jsdt.internal.core.CompilationUnit.codeComplete(CompilationUnit.java:298) at org.eclipse.wst.jsdt.internal.ui.text.java.JavaCompletionProposalComputer.internalComputeCompletionProposals(JavaCompletionProposalComputer.java:176) at org.eclipse.wst.jsdt.internal.ui.text.java.JavaCompletionProposalComputer.computeCompletionProposals(JavaCompletionProposalComputer.java:142) at org.eclipse.wst.jsdt.internal.ui.text.java.CompletionProposalComputerDescriptor.computeCompletionProposals(CompletionProposalComputerDescriptor.java:298) at org.eclipse.wst.jsdt.internal.ui.text.java.CompletionProposalCategory.computeCompletionProposals(CompletionProposalCategory.java:258) at org.eclipse.wst.jsdt.internal.ui.text.java.ContentAssistProcessor.collectProposals(ContentAssistProcessor.java:244) at org.eclipse.wst.jsdt.internal.ui.text.java.ContentAssistProcessor.computeCompletionProposals(ContentAssistProcessor.java:213) at org.eclipse.jface.text.contentassist.ContentAssistant.computeCompletionProposals(ContentAssistant.java:1834) at org.eclipse.jface.text.contentassist.CompletionProposalPopup.computeProposals(CompletionProposalPopup.java:556) at org.eclipse.jface.text.contentassist.CompletionProposalPopup.access$16(CompletionProposalPopup.java:553) at org.eclipse.jface.text.contentassist.CompletionProposalPopup$2.run(CompletionProposalPopup.java:488) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70) at org.eclipse.jface.text.contentassist.CompletionProposalPopup.showProposals(CompletionProposalPopup.java:482) at org.eclipse.jface.text.contentassist.ContentAssistant.showPossibleCompletions(ContentAssistant.java:1660) at org.eclipse.wst.jsdt.internal.ui.javaeditor.CompilationUnitEditor$AdaptedSourceViewer.doOperation(CompilationUnitEditor.java:168) at org.eclipse.ui.texteditor.ContentAssistAction$1.run(ContentAssistAction.java:82) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70) at org.eclipse.ui.texteditor.ContentAssistAction.run(ContentAssistAction.java:80) at org.eclipse.jface.action.Action.runWithEvent(Action.java:498) at org.eclipse.ui.commands.ActionHandler.execute(ActionHandler.java:185) at org.eclipse.ui.internal.handlers.LegacyHandlerWrapper.execute(LegacyHandlerWrapper.java:109) at org.eclipse.core.commands.Command.executeWithChecks(Command.java:476) at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:508) at org.eclipse.ui.internal.handlers.HandlerService.executeCommand(HandlerService.java:169) at org.eclipse.ui.internal.keys.WorkbenchKeyboard.executeCommand(WorkbenchKeyboard.java:468) at org.eclipse.ui.internal.keys.WorkbenchKeyboard.press(WorkbenchKeyboard.java:786) at org.eclipse.ui.internal.keys.WorkbenchKeyboard.processKeyEvent(WorkbenchKeyboard.java:885) at org.eclipse.ui.internal.keys.WorkbenchKeyboard.filterKeySequenceBindings(WorkbenchKeyboard.java:567) at org.eclipse.ui.internal.keys.WorkbenchKeyboard.access$3(WorkbenchKeyboard.java:508) at org.eclipse.ui.internal.keys.WorkbenchKeyboard$KeyDownFilter.handleEvent(WorkbenchKeyboard.java:123) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Display.filterEvent(Display.java:1253) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1052) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1077) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java) at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1103) at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1099) at org.eclipse.swt.widgets.Widget.wmChar(Widget.java:1508) at org.eclipse.swt.widgets.Control.WM_CHAR(Control.java:4270) at org.eclipse.swt.widgets.Canvas.WM_CHAR(Canvas.java:345) at org.eclipse.swt.widgets.Control.windowProc(Control.java:4162) at org.eclipse.swt.widgets.Canvas.windowProc(Canvas.java:341) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4873) at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method) at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:2459) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3655) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2640) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2604) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2438) at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:671) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:664) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:115) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at java.lang.reflect.Method.invoke(Method.java:600) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:620) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:575) at org.eclipse.equinox.launcher.Main.run(Main.java:1408) at org.eclipse.equinox.launcher.Main.main(Main.java:1384)
Created attachment 198364 [details] patch with JUnits - Update 8 Same as previous patch except updates JavaMethodCompletionProposal#computeTriggerCharacters to use METHOD_NAME_TRIGGERS when the proposal type is either a METHDO_NAME_REFERENCE or a METHDO_REF. The side affect of not doing this was that period was being included as a trigger character when invoking content assist like "foo.bar|" and thus then typing another period was causing the first suggestion to be inserted rather then continuing to filter the list.
I opened and supplied a patch to bug 350047 which deals with comment 50.
Created attachment 198853 [details] Testing ZIP - Update 4 Updated test zip with files for new tests added in the forthcoming new patch. Still goes in "org.eclipse.wst.jsdt.ui.tests/testresources/ContentAssist.zip"
Created attachment 198854 [details] patch with JUnits - Update 9 This patch is fundamentally different then the last patches because now constructors are stored in the index as constructors and then during content assist searched for in the index as constructors. This is rather then saving them in the index as methods and searching all of the methods for constructors. This approach makes content assist much much faster because the set of things to search is much small, and mor importantly no parsing/inferring/etc has to be done to find all of the constructor matches now. All existing JUnits pass. All new JUnits pass. Added a couple new junits since the last patch, be sure to get the new test project zip. Chris tested a slightly older version of this patch and much preferred the performance over the old patch. All code in the patch is well documented both in line and with javadoc. I have gone over every single line of changed code, we need it all.
Comment on attachment 198854 [details] patch with JUnits - Update 9 Apparently I can not store the parameter arguments just like "String", it has to be stored as a signature like "QString;"
(In reply to comment #55) > Comment on attachment 198854 [details] > patch with JUnits - Update 9 > > Apparently I can not store the parameter arguments just like "String", it has > to be stored as a signature like "QString;" Yes, content assist proposals are quite dependent on signatures.
(In reply to comment #56) > (In reply to comment #55) > > Comment on attachment 198854 [details] [details] > > patch with JUnits - Update 9 > > > > Apparently I can not store the parameter arguments just like "String", it has > > to be stored as a signature like "QString;" > > Yes, content assist proposals are quite dependent on signatures. The constructor ones are not. It seemed very much a convoluted system that gave no benefit. So I am still looking if there is some way to enhance this code path so it can deal with the types as not a signature.
Created attachment 198935 [details] Fix patch - Update 10 Same as last patch except I removed some unnecessary logging and fixed the constructor parameter type signature issue.
Created attachment 198972 [details] fix patch - update 12 Somehow my last patch was missing a couple of my fixes.
Created attachment 198973 [details] fix patch - update 13 merged patch with recent changes to maintenance stream.
Approved with caveats in bug 350975; committed to maintenance, opened bug 350976 for application to HEAD (attachment 198853 [details] will not apply cleanly).
(In reply to comment #61) > Approved with caveats in bug 350975; committed to maintenance, opened bug > 350976 for application to HEAD (patch will not apply cleanly). That should instead refer to attachment 198973 [details].
I created Bug 351448 to put this fix as well as the bug 350975 into HEAD.
