Skip to content

Fix std.format FP printing for soft-float targets - #7377

Merged
wilzbach merged 1 commit into
dlang:masterfrom
kinke:format
Feb 5, 2020
Merged

wilzbach merged 1 commit into
dlang:masterfrom
kinke:format

Conversation

@kinke

@kinke kinke commented Jan 27, 2020

Copy link
Copy Markdown
Contributor

After #7362.

@kinke
kinke requested a review from andralex as a code owner January 27, 2020 23:27
@dlang-bot

Copy link
Copy Markdown

Thanks for your pull request and interest in making D better, @kinke! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

  • My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
  • My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
  • I have provided a detailed rationale explaining my changes
  • New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.


If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub fetch digger
dub run digger -- build "master + phobos#7377"

@ghost

ghost commented Jan 28, 2020

Copy link
Copy Markdown

Instead of importing std.math completely, wouldn't it be better to have something like enum hasFloatingPointControlSupport in std.math import this and in case of it being true doing import std.math : FloatingPointControl?

@kinke

kinke commented Jan 28, 2020

Copy link
Copy Markdown
Contributor Author

The local import only affects the little then branch of the if...

@ghost

ghost commented Jan 28, 2020

Copy link
Copy Markdown

That "little then branch" will grow with PRs #7264 and #7318 and the followups and eventually end in being the whole template. Anyway, it's still local of course and I personally would not mind. But as far as I know, we are currently trying to reduce the imports as much as possible, don't we? I think, some modules are even checked for whole imports by the style checker and would be rejected...

@kinke

kinke commented Jan 28, 2020

Copy link
Copy Markdown
Contributor Author

AFAIK, the only difference for a whole import here is the namespace pollution, but as long as that's restricted to a little then (or in the future, possibly its own little getRoundingMode()), I see no problem with it, and would find a

import std.math : isFloatingPointControlAvailable;
static if (isFloatingPointControlAvailable)
{
    import std.math : FloatingPointControl;
    ...
}

much uglier.

@ghost

ghost commented Jan 28, 2020

Copy link
Copy Markdown

For me both is fine.

Comment thread std/format.d Outdated
@n8sh

n8sh commented Jan 31, 2020

Copy link
Copy Markdown
Member

std/format.d(2661:20)[warn]: Local imports should specify the symbols being imported to avoid hiding local symbols.

Yeah maybe this wasn't a good rule since it defeats this kind of compile time introspection.

@wilzbach

Copy link
Copy Markdown
Contributor

Yeah maybe this wasn't a good rule since it defeats this kind of compile time introspection.

The rules can be selectively disabled in .dscanner.ini

@kinke
kinke requested a review from wilzbach as a code owner February 1, 2020 01:26
@n8sh n8sh added the Merge:72h no objection -> merge The PR will be merged if there are no objections raised. label Feb 2, 2020
@kinke

kinke commented Feb 5, 2020

Copy link
Copy Markdown
Contributor Author

Does the bot ignore the 72h... label?

@wilzbach

wilzbach commented Feb 5, 2020

Copy link
Copy Markdown
Contributor

Yes, the label is just for humans.

@wilzbach
wilzbach merged commit f314024 into dlang:master Feb 5, 2020
@kinke
kinke deleted the format branch February 5, 2020 21:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Merge:72h no objection -> merge The PR will be merged if there are no objections raised.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants