fN::BITS constants for feature float_bits_const#151109
fN::BITS constants for feature float_bits_const#151109rust-bors[bot] merged 1 commit intorust-lang:mainfrom
Conversation
|
cc @tgross35 |
This comment has been minimized.
This comment has been minimized.
9a456a5 to
10e2d54
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
The Miri subtree was changed cc @rust-lang/miri |
|
Reminder, once the PR becomes ready for a review, use |
Either of these things are unfortunately definitely a problem; we can't expect working crates to enable a nightly feature to keep building correctly, nor do we want them to stop building if the types don't line up. Not exactly sure what our options are here but let's start a crater run to have an idea of impact. @bors try |
This comment has been minimized.
This comment has been minimized.
fN::BITS constants for feature float_bits_const
| } | ||
|
|
||
| let fbits = <$fty>::BITS; | ||
| let fbits = <$fty as Float>::BITS; |
There was a problem hiding this comment.
This makes the BITS constant in the Float trait in this file dead, doesn't it?
There was a problem hiding this comment.
The diff here I think is intentionally using BITS from the Float trait. It could go the other way and drop BITS from Flaot, just means Miri has to depend on this feature.
There was a problem hiding this comment.
That's right - However when I tried to add the feature flag to the miri tests it said the feature was not allowed - I think it might be building these tests with a stable compiler that doesn't allow such features.
Regularly it would just be a warning but warnings are treated as errors, so I had to change this to get it to pass.
There was a problem hiding this comment.
Miri uses the in-tree standard library built with the in-tree compiler. So it looks like something went wrong in your testing.
But anyway we still need the const in the trait since we have code generic over the trait, so it doesn't really matter.
bb1183b to
a4662d0
Compare
|
Some changes occurred in compiler/rustc_codegen_gcc Some changes occurred in compiler/rustc_attr_parsing cc @jdonszelmann, @JonathanBrouwer Some changes occurred in check-cfg diagnostics cc @Urgau Some changes occurred to constck cc @fee1-dead Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt Some changes occurred in src/tools/opt-dist cc @Kobzol HIR ty lowering was modified cc @fmease Some changes occurred in GUI tests. Some changes occurred to the CTFE machinery |
|
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
|
🎉 Experiment
Footnotes
|
|
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
|
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
|
🎉 Experiment
Footnotes
|
|
For context, the warning looks like this: I guess crater might not actually show warnings? In any case, there isn't a problem adding them but we may need to revisit at stabilization. @bors r+ |
fN::BITS constants for feature float_bits_const Also enables the feature for compiler_builtins as otherwise this causes a warning and conflicts with the Float extension trait. --- Implementation for rust-lang#151073 Feature flag: `#![feature(float_bits_const)]` Note that this is likely to conflict with some extension traits, as it has with compiler builtins. However, assuming correct values for the constants, they are either `u32`, the same type, which should not cause a problem (as shown by enabling the feature for compiler_builtins), or a different type (e.g. `usize`), which should cause a compiler error. Either way this should never change behaviour unless the extension trait implemented an incorrect value. Also note that it doesn't seem to be possible to put multiple unstable attributes on an item, so `f128::BITS` and `f16::BITS` are gated behind the feature flags for those primitives, rather than `#![feature(float_bits_const)]`
Rollup of 6 pull requests Successful merges: - #152008 (`rust-analyzer` subtree update) - #151109 (fN::BITS constants for feature float_bits_const) - #151976 (Rename `collect_active_jobs` to several distinct names) - #151691 (compiletest: Don't assume `aux-crate` becomes a `*.so` with `no-prefer-dynamic`) - #151919 (fix: Make `--color always` always print color with `--explain`) - #152028 (Convert to inline diagnostics in `rustc_driver_impl`)
Rollup of 7 pull requests Successful merges: - #152008 (`rust-analyzer` subtree update) - #151109 (fN::BITS constants for feature float_bits_const) - #151976 (Rename `collect_active_jobs` to several distinct names) - #151691 (compiletest: Don't assume `aux-crate` becomes a `*.so` with `no-prefer-dynamic`) - #151919 (fix: Make `--color always` always print color with `--explain`) - #152017 (Remove `with_no_trimmed_paths` use in query macro) - #152028 (Convert to inline diagnostics in `rustc_driver_impl`)
Rollup merge of #151109 - tyhdefu:float_bits_const, r=tgross35 fN::BITS constants for feature float_bits_const Also enables the feature for compiler_builtins as otherwise this causes a warning and conflicts with the Float extension trait. --- Implementation for #151073 Feature flag: `#![feature(float_bits_const)]` Note that this is likely to conflict with some extension traits, as it has with compiler builtins. However, assuming correct values for the constants, they are either `u32`, the same type, which should not cause a problem (as shown by enabling the feature for compiler_builtins), or a different type (e.g. `usize`), which should cause a compiler error. Either way this should never change behaviour unless the extension trait implemented an incorrect value. Also note that it doesn't seem to be possible to put multiple unstable attributes on an item, so `f128::BITS` and `f16::BITS` are gated behind the feature flags for those primitives, rather than `#![feature(float_bits_const)]`
Rollup of 7 pull requests Successful merges: - rust-lang/rust#152008 (`rust-analyzer` subtree update) - rust-lang/rust#151109 (fN::BITS constants for feature float_bits_const) - rust-lang/rust#151976 (Rename `collect_active_jobs` to several distinct names) - rust-lang/rust#151691 (compiletest: Don't assume `aux-crate` becomes a `*.so` with `no-prefer-dynamic`) - rust-lang/rust#151919 (fix: Make `--color always` always print color with `--explain`) - rust-lang/rust#152017 (Remove `with_no_trimmed_paths` use in query macro) - rust-lang/rust#152028 (Convert to inline diagnostics in `rustc_driver_impl`)
Rollup of 7 pull requests Successful merges: - rust-lang/rust#152008 (`rust-analyzer` subtree update) - rust-lang/rust#151109 (fN::BITS constants for feature float_bits_const) - rust-lang/rust#151976 (Rename `collect_active_jobs` to several distinct names) - rust-lang/rust#151691 (compiletest: Don't assume `aux-crate` becomes a `*.so` with `no-prefer-dynamic`) - rust-lang/rust#151919 (fix: Make `--color always` always print color with `--explain`) - rust-lang/rust#152017 (Remove `with_no_trimmed_paths` use in query macro) - rust-lang/rust#152028 (Convert to inline diagnostics in `rustc_driver_impl`)
Rollup of 7 pull requests Successful merges: - rust-lang/rust#152008 (`rust-analyzer` subtree update) - rust-lang/rust#151109 (fN::BITS constants for feature float_bits_const) - rust-lang/rust#151976 (Rename `collect_active_jobs` to several distinct names) - rust-lang/rust#151691 (compiletest: Don't assume `aux-crate` becomes a `*.so` with `no-prefer-dynamic`) - rust-lang/rust#151919 (fix: Make `--color always` always print color with `--explain`) - rust-lang/rust#152017 (Remove `with_no_trimmed_paths` use in query macro) - rust-lang/rust#152028 (Convert to inline diagnostics in `rustc_driver_impl`)
Also enables the feature for compiler_builtins as otherwise this causes a warning and conflicts with the Float extension trait.
Implementation for #151073
Feature flag:
#![feature(float_bits_const)]Note that this is likely to conflict with some extension traits, as it has with compiler builtins. However, assuming correct values for the constants, they are either
u32, the same type, which should not cause a problem (as shown by enabling the feature for compiler_builtins), or a different type (e.g.usize), which should cause a compiler error. Either way this should never change behaviour unless the extension trait implemented an incorrect value.Also note that it doesn't seem to be possible to put multiple unstable attributes on an item, so
f128::BITSandf16::BITSare gated behind the feature flags for those primitives, rather than#![feature(float_bits_const)]