Bcc32 compatibility #1079

starkmapper · 2019-03-15T14:18:29Z

I did some work to get fmt working on the "classic" Embarcadero compiler.

vitaut · 2019-03-15T15:22:45Z

Hi @starkmapper, thanks for the PR!

Since this is your first contribution to {fmt}, please review CONTRIBUTING.md, particularly the part about licensing, and comment here whether you agree with it being applied to your contributions including this PR.

starkmapper · 2019-03-15T16:05:09Z

I have read contributing.md and agree that my contribution will be licensed under the fmt license.

vitaut

Left some comments in the first commit. Also instead of fixing issues in the follow-up commits, please amend the ones earlier in the stack for easier review and sensible revision history.

fmt/format.cc

fmt/format.h

starkmapper · 2019-03-18T14:46:40Z

I didn't want to rebase+squash just yet, but let me know if that would help you.

starkmapper · 2019-03-18T14:55:03Z

I'm also a little worried about the CI failing, is there anything I can do about that?

vitaut · 2019-03-19T01:10:27Z

I didn't want to rebase+squash just yet, but let me know if that would help you.

That would help.

I'm also a little worried about the CI failing, is there anything I can do about that?

Please check the error at https://travis-ci.org/fmtlib/fmt/jobs/507890085. Looks like they are mostly namespace-related.

starkmapper · 2019-03-19T10:13:13Z

Squashed and fixed non-windows builds. I'm not sure what's going on with the appveyor build. Did I break that or is something else going on?

starkmapper · 2019-03-19T13:42:57Z

I'm not sure what's going on with the appveyor build. Did I break that or is something else going on?
Tried the appveyor script locally and that seems to work.

vitaut

I think the Appveyor build is failing because the cmake command in https://github.com/fmtlib/fmt/blob/4.x/support/appveyor-build.py#L11 is missing ".." at the end for some reason. Could you add it by any chance while at it? Also a few comments inline.

fmt/format.h

vitaut · 2019-03-20T14:37:13Z

fmt/format.h

@@ -2593,11 +2687,8 @@ class SystemError : public internal::RuntimeError {
       throw fmt::SystemError(errno, "cannot open file '{}'", filename);
   \endrst
  */
-  SystemError(int error_code, CStringRef message) {
-    init(error_code, message, ArgList());
-  }


Please keep this ctor.

It is generated by the FMT_VARIADIC_ macro.

It's here for documentation purposes (note the apidoc above). If it is causing problems for bcc, I suggest conditionally compiling instead of removing.

It's not a bcc issue, it's because all FMT_VARIADIC_* macros now use the FMT_VARIADIC_ macro, this normalizing variadic template handing, and less macro magic to maintain. The FMT_VARIADIC_ macro generates functions with 0..15 templated arguments to mimic variadic templates, where the 0 argument one has the exact same signature as this manually defined one.
I propose to make it consistent with functions printf, format etc and add an overload with an extra ArgList parameter:

SystemError(int error_code, CStringRef message, ArgList args) { init(error_code, message, args); }

This would be the best of both worlds: singe FMT_VARIADIC_ macro and documentation (and more consistency as a bonus :-) ).

If this is not bcc issue, could you remove the macro changes from the current PR?

The need for the macro changes is because of a bcc issue. If you feel very strongly about not changing the constructor signature in the documentation I can change the FMT_VARIADIC_CTOR macro not to generate the conflicting overload.

Background

The original macro did c-style array initialization:

ArgArray<2>::Type array = { MakeValue<BasicFormatter<char>>(v0), MakeValue<BasicFormatter<char>>(v1)};

Where ArgArray<2>::Type is an array of Value.
Somehow bcc tried to assign the results of MakeValue<BasicFormatter<char>>(vN) to the first member of Value (int int_value in the anonymous union) causing a "Cannot convert `MakeValue<BasicFormatter>(vN) to int" error.

When I started fixing this issue I found the FMT_VARIADIC_ function and started using that. This had already solved this issue by generating the individual assignment statements for the array:

ArgArray<2>::Type arr; arr[0] = MakeValue<BasicFormatter<char>>(v0), arr[1] = MakeValue<BasicFormatter<char>>(v1);

note: I left out namespaces for clarity

I see. The macro logic is fairly complicated and version 4.x is in maintenance mode, so I'd like the changes in this PR to be minimal, just enough for bcc32 compatibility. Right now it's hard to see what actually changed because the macros have been moved around. Could you return them to their original places and make changes there?

I started doing that, but found that the solution would depend on the (newer and more versatile) macros defined later on in the file. That is why I moved the large macros block up. To verify that I only moved them I used kdiff3 with manual alignment. I'll post those diffs so you can get a better idea of the changes I made.

Here you can see what I changed to get this working for bcc with the existing macros. Not only achieving bcc compatibility, but also removing the second set of macro's, resulting in less "magic" to maintain:

And the diff for the FMT_MAKE_REF macro's:

The alignment of the diff is shown below. I marked the manual alignment markers with red.

I hope this makes it clear that I only made minor changes, apart from moving the macros.

fmt/format.h

starkmapper · 2019-03-20T19:24:26Z

I'll make the proposed changes. Would you like me to squash again, or just push updates? Also, should I check the documentation using doxygen, or apidoc like you mentioned?

starkmapper · 2019-03-20T19:57:54Z

Adding the .. didn't fix the appveyor build unfortunately. (https://ci.appveyor.com/project/vitaut/fmt/builds/23233738)

starkmapper · 2019-03-20T20:05:36Z

Adding the .. didn't fix the appveyor build unfortunately. (https://ci.appveyor.com/project/vitaut/fmt/builds/23233738)

But adding . did, seems that adding the source path to the commandline became required in v3.13.

vitaut · 2019-03-21T00:17:34Z

But adding . did, seems that adding the source path to the commandline became required in v3.13.

Thanks for fixing this.

Would you like me to squash again, or just push updates?

Yes, please squash and remove the macro changes as discussed above.

Also, should I check the documentation using doxygen, or apidoc like you mentioned?

I don't think it's necessary.

Resolve namespace issues Add workaround for compile error on bool template argument of ArgArray struct Squelch bcc32 warning on accessing the digits array Squelch bcc32 warning on unused values Use FMT_VARIADIC_ for FMT_VARIADIC_VOID and FMT_VARIADIC_CTOR Fix warnings about redefinig macros and conditions always true Disable "LConv" block for bcc32 compiler Remove macro test for deprecated macro Fix appveyor-build for cmake v3.13+

starkmapper · 2019-03-21T06:39:01Z

I changed the macros so the WindowsError and SystemError constructors can remain unchanged. Please let me know if there is anything else.

vitaut · 2019-03-27T18:05:57Z

Merged everything except the macro changes in d2744bc. The macros need a bit more work because they are in their present location for a reason: to make the system_header pragma apply to them and not to the other parts of the code. Also it's not entirely clear to me how FMT_VARIADIC_VAR_ARG fixes anything.

starkmapper · 2019-03-27T20:42:31Z

I'll try to find a less invasive way to make the macros work.

vitaut requested changes Mar 16, 2019

View reviewed changes

fmt/format.cc Outdated Show resolved Hide resolved

fmt/format.h Outdated Show resolved Hide resolved

fmt/format.h Outdated Show resolved Hide resolved

fmt/format.h Outdated Show resolved Hide resolved

starkmapper force-pushed the bcc32-compat branch from 8915b27 to 70aacd4 Compare March 19, 2019 10:11

starkmapper force-pushed the bcc32-compat branch from 70aacd4 to b272608 Compare March 19, 2019 12:09

vitaut requested changes Mar 20, 2019

View reviewed changes

starkmapper force-pushed the bcc32-compat branch from 1758351 to b78b305 Compare March 20, 2019 20:00

starkmapper closed this Mar 20, 2019

starkmapper reopened this Mar 20, 2019

starkmapper force-pushed the bcc32-compat branch from 6ef7a21 to 57a94f7 Compare March 21, 2019 06:35

starkmapper force-pushed the bcc32-compat branch from 57a94f7 to 159e12c Compare March 21, 2019 06:37

vitaut closed this Mar 27, 2019

vitaut mentioned this pull request Mar 31, 2019

Relicense {fmt} to make it more friendly for standard library vendors #1073

Closed

43 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Bcc32 compatibility #1079

Bcc32 compatibility #1079

starkmapper commented Mar 15, 2019

vitaut commented Mar 15, 2019

starkmapper commented Mar 15, 2019

vitaut left a comment

starkmapper commented Mar 18, 2019

starkmapper commented Mar 18, 2019

vitaut commented Mar 19, 2019

starkmapper commented Mar 19, 2019 •

edited

Loading

starkmapper commented Mar 19, 2019

vitaut left a comment

vitaut Mar 20, 2019

starkmapper Mar 20, 2019

vitaut Mar 20, 2019

starkmapper Mar 20, 2019

vitaut Mar 21, 2019

starkmapper Mar 21, 2019

vitaut Mar 22, 2019

starkmapper Mar 25, 2019

starkmapper Mar 25, 2019

starkmapper commented Mar 20, 2019

starkmapper commented Mar 20, 2019 •

edited

Loading

starkmapper commented Mar 20, 2019

vitaut commented Mar 21, 2019

starkmapper commented Mar 21, 2019

vitaut commented Mar 27, 2019

starkmapper commented Mar 27, 2019

Bcc32 compatibility #1079

Bcc32 compatibility #1079

Conversation

starkmapper commented Mar 15, 2019

vitaut commented Mar 15, 2019

starkmapper commented Mar 15, 2019

vitaut left a comment

Choose a reason for hiding this comment

starkmapper commented Mar 18, 2019

starkmapper commented Mar 18, 2019

vitaut commented Mar 19, 2019

starkmapper commented Mar 19, 2019 • edited Loading

starkmapper commented Mar 19, 2019

vitaut left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Background

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

starkmapper commented Mar 20, 2019

starkmapper commented Mar 20, 2019 • edited Loading

starkmapper commented Mar 20, 2019

vitaut commented Mar 21, 2019

starkmapper commented Mar 21, 2019

vitaut commented Mar 27, 2019

starkmapper commented Mar 27, 2019

starkmapper commented Mar 19, 2019 •

edited

Loading

starkmapper commented Mar 20, 2019 •

edited

Loading