{"id":1397,"date":"2013-05-01T08:52:48","date_gmt":"2013-04-30T20:52:48","guid":{"rendered":"https:\/\/www.deltics.co.nz\/blog\/?p=1397"},"modified":"2013-05-01T08:56:22","modified_gmt":"2013-04-30T20:56:22","slug":"qualified-enum-reference-that-fails-to-compile-in-xe4-and-rightly-so","status":"publish","type":"post","link":"https:\/\/www.deltics.co.nz\/blog\/posts\/1397\/","title":{"rendered":"Qualified Enum Reference That Fails to Compile in XE4 (and rightly so)"},"content":{"rendered":"[Estimated Reading Time: <\/span> 3<\/span> minutes]<\/span><\/span>

Running through some of my code last night, putting them through the new XE4 compiler, threw up a real oddity: Some code that used to compile just fine, which no longer compiles in XE4 and which should not<\/strong> have compiled before<\/em>!
\n
\nIt’s an odd one, because the code previously compiled – and worked – as intended, and the old “bug” that seems to have now been fixed could well have instead been embraced as a feature (although I can understand why it was not and am not suggesting it should have, just observing).<\/p>\n

I have to point out at this juncture that there is nothing much to learn from this post I’m afraid. It is a bit of a compiler curiosity, that is all. But even so, I found it interesting and thought others might as well. And who knows, someone else might have the same problem lurking in their older library code, unbeknownst to them, in which case this might save a bit of head scratching for them.<\/p>\n

It involves the referencing of an enum in a unit that is not referenced in the uses clause, where the reference is qualified by the unit name in which the enum is declared and where the unit containing the reference uses some other unit that in turn does<\/em> use the unit that contains the enum.<\/p>\n

Got all that ? Clear as mud ? \ud83d\ude42<\/p>\n

Ok, here’s the simplest possible test case that will show what I mean. 3 files – a DPR and 2 units. Obviously in the real project the DPR and the units involved were a sight more complex (I suspect that the “error” crept in during a refactoring where the unit containing the enum was decomposed into 3 smaller units).<\/p>\n

In any event, here’s the sample DPR. The code doesn’t do anything, as such, it just exercises the necessary parts of the compiler:<\/p>\n

\r\nprogram unused;\r\n\r\nuses\r\n  Foo.Foo in 'Foo.Foo.pas';\r\n\r\nvar\r\n  c: Integer;\r\nbegin\r\n  c := Ord(Foo.enumBAR);\r\nend.\r\n<\/pre>\n
Here we can see that the DPR uses the unit Foo.Foo<\/strong>, but references an enum member – enumBAR<\/strong> – qualified with a different<\/em> unit name, Foo<\/strong>, which is not being “used” at all.<\/p>\n
Here is the Foo.Foo<\/strong> unit:<\/p>\n
\r\nunit Foo.Foo;\r\n\r\ninterface\r\n\r\n  uses\r\n    Foo;\r\n\r\nimplementation\r\n\r\nend.\r\n<\/pre>\n
And finally the Foo<\/strong> unit containing the enum declaration with the enumBAR<\/strong> member:<\/p>\n
\r\nunit Foo;\r\n\r\ninterface\r\n\r\n  type\r\n    TEnum = (enumBAR);\r\n\r\nimplementation\r\n\r\nend.\r\n<\/pre>\n
This project compiles just fine in Delphi 2010, but fails in XE4 with the compiler complaining about the undeclared “Foo” identifier on the line:<\/p>\n
\r\n  c:= Ord(Foo.enumBAR);\r\n<\/pre>\n
Again, in the actual case in my actual project, the reference was not in the DPR but in another unit in the project.  All units involved were in the DPR uses list, but other than that, the scenario was the same as illustrated by the sample.<\/p>\n
The solution is obviously to simply add the required unit to the uses<\/strong> list, so no great shakes.<\/p>\n
I haven’t tried the sample specifically in other versions of Delphi, but this project has previously been tested in Delphi versions 7 thru XE2, though I cannot honestly recall if it has been tested in those versions since the refactoring that might have led to this situation.  The point being that I think if I were to do that testing, I would find that the behaviour in this area might have changed as a result of the introduction of SCOPEDENUMS<\/strong> (since this case involves a qualified enum reference, albeit unit qualified rather than type-name qualified).<\/p>\n
Obviously whether it existed in any other version of Delphi besides 2010 or not, the previous behaviour was technically wrong.  It should not have been possible to reference members of units that are not being “used”.  But then again, given than “using” a unit is a formal declaration that brings the contents of that unit into scope, it is arguable that you could conceivably extend the syntax to allow formal qualification of specific members in a unit without<\/em> requiring that unit to be used to bring all<\/em> it’s members into scope for un<\/strong>qualified use.<\/p>\n
I don’t think you should<\/em>.  The declaration of which units are being used is useful self-documentation imho.  As I said at the outset, it is interesting to think that it might not (and apparently did not always used to be :)) necessary.<\/p>\n
In any event, this code now compiles correctly.  Or, more accurately, correctly fails to compile.  \ud83d\ude42<\/p>\n","protected":false},"excerpt":{"rendered":"
[Estimated Reading Time: <\/span>  3<\/span> minutes]<\/span><\/span>Running through some of my code last night, putting them through the new XE4 compiler, threw up a real oddity: Some code that used to compile just fine, which no longer compiles in XE4 and which should not have compiled before!<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"jetpack_post_was_ever_published":false},"categories":[4,201],"tags":[71,88,203,202],"class_list":["post-1397","post","type-post","status-publish","format-standard","hentry","category-delphi","category-xe4","tag-compiler","tag-enums","tag-scopedenums","tag-xe4-2"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/p1TKYv-mx","jetpack_sharing_enabled":true,"jetpack-related-posts":[],"_links":{"self":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/1397","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/comments?post=1397"}],"version-history":[{"count":5,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/1397\/revisions"}],"predecessor-version":[{"id":1401,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/1397\/revisions\/1401"}],"wp:attachment":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/media?parent=1397"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/categories?post=1397"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/tags?post=1397"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}