inline x^literal only for hardware-based number types x #20782
Conversation
|
Since it seems on #20768 that everyone prefers this behavior, hopefully this can be merged soon? |
|
Is there a simple way for user-defined types to opt into this behavior? (Separate issue.) |
|
Since this passes tests and is strictly more conservative that the current state, seems like we should just go ahead and merge this. Let's leave it open for a bit in case there are any objections. |
|
Okay, will merge once tests are green again (now that the conflict is resolved). For user-defined types to opt-in, I suppose we could define some kind of trait. But I'm not sure how many types will actually want to opt-in, so it may not be worth it. (That's one of the reasons why in #20637 I separated the inlining code into a function, so that other types could call this code-generation routine easily.) |
stevengj
force-pushed
the
inlinepow_hwonly
branch
from
8962f19
to
830212a
Compare
|
Darn it, messed up the rebase ... okay, should be fixed now. |
stevengj
force-pushed
the
inlinepow_hwonly
branch
from
830212a
to
a6b5e27
Compare
|
So packages can still make good use of |
|
@andyferris, yes, although there's no reason for packages to not just directly override |
* run NEWS-update.jl #20648 was partially reverted by #20782 * Fix doctest line numbers * Upgrade Documenter, add linkcheck exception bugs.kde.org fails to load from nanosoldier for some reason, gives a CURLE_RECV_ERROR (56) Failure with receiving network data fix alloc.c dead link in devdocs/init.md * fix timeit_init macro in test/perf/perfutil.jl needed to escape its arguments
Closes #20768.