Summary: | [compiler][null] Update NullReferenceImplTests and friends | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Stephan Herrmann <stephan.herrmann> |
Component: | Core | Assignee: | JDT-Core-Inbox <jdt-core-inbox> |
Status: | CLOSED WONTFIX | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | manoj.palat |
Version: | 4.4 | Keywords: | test |
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Linux | ||
Whiteboard: | |||
Bug Depends on: | 453648 | ||
Bug Blocks: |
Description
Stephan Herrmann
2014-11-30 08:28:14 EST
Additionally, bug 453483 will introduce two more bits to be considered during addInitializationsFrom(). I'll check feasibility of including these bits in the tests. This is a problem both for defining the transformation as well as for printing the karnaugh maps. In both cases an increase in size by factor 4 stretches the limits of what can be manually handled. Minimally, tests must ensure a reasonable value (1,1) for these bits to provide for comparability with previous results. First test updates have been pushed: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=b077f1ec27f6f9c95317db4e5e225319a96f87d5 (A) generator changes to solve these issues: - comparison of generator output with previous test file was encumbered by different sorting orders. For each section of NullReferenceImplTransformations a well defined order is now used (selected as to require minimal changes in this file). - state 0x1C was not considered by the generator because it was not found to be reachable. Considering, however, that these tests don't represent all possible operations on flowInfos, and given that this state has been observed in real life, it should be included by the generator. This is ensured by included all named states ("isSymbolic"). - the generator created bogus "CHECK" marks because for three-dimensional transformations it could not retrieve the defined result. http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=9c5059700205577ee2d000823b77569787384ecb (B) re-order definitions of transformations to align with generator output. In addition to re-ordering lines, this also includes for the symmetric operation "mergedWith" that left & right operands were swapped for a number of late added transitions. http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=79774393baaba7f9e5f3461242a5b822bf662647 (C) accept output of the generator as improved in (A) into files prepared by (B). All newly added transitions were scanned, some are commented as bogus or not ideal. No transitions were changed, however. At this point we're close to a fix point, where the generator would create an exact copy of its input. Only remaining difference: comments on individual transitions (some old, some newly added). Note, that NullReferenceImplTests - which are not part of our regular test suite - show one failure. During addInitializationsFrom the start value 0000 creates different outcomes depending on the number of slots used (UFI.extra bits, happens only in combination with state 0x2C). I assume, the bug depends on whether or not the flow info is recognized as not having any (interesting) null info. While this is a definite bug, it's not a regression recently introduced - it just wasn't noticed before. I'm waiting with a fix until all dust in the related bugs has settled. Also, this bug remains open to accommodate more changes necessitated by bug 453483. let's see if bug 453648 will come to life... (not for M4, though)... Too much on my plate for 4.6. Bulk deferral to 4.7 bulk move out of 4.8 bulk move out of 4.8 |