Fix warning when libcore is compiled with no_fp_fmt_parse #105434

nbdd0121 · 2022-12-08T00:20:48Z

Discovered when trying to compile Rust-for-Linux with Rust 1.66 beta.

It'll be helpful if this is backported to beta (should be trivial enough for backporting), so Rust-for-Linux's rust version bump wouldn't need to do --cap-lints allow for libcore.

rustbot · 2022-12-08T00:20:54Z

r? @thomcc

(rustbot has picked a reviewer for you, use r? to override)

rustbot · 2022-12-08T00:20:56Z

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

Stabilizing library features
Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
Changing public documentation in ways that create new stability guarantees
Changing observable runtime behavior of library APIs

thomcc · 2022-12-08T04:16:10Z

@bors r+ rollup

bors · 2022-12-08T04:16:12Z

📌 Commit a3c4c2e has been approved by thomcc

It is now in the queue for this repository.

thomcc · 2022-12-08T04:19:19Z

It'll be helpful if this is backported to beta (should be trivial enough for backporting), so Rust-for-Linux's rust version bump wouldn't need to do --cap-lints allow for libcore.

I've marked it as nominated for beta backport, although I'm probably opposed -- I don't really like the thought that these configurations are considered so important that a beta-backport is justified for a warning (and if they are that important, we should check them in CI). But I don't feel that strongly.

Fix warning when libcore is compiled with no_fp_fmt_parse Discovered when trying to compile Rust-for-Linux with Rust 1.66 beta. It'll be helpful if this is backported to beta (should be trivial enough for backporting), so Rust-for-Linux's rust version bump wouldn't need to do `--cap-lints allow` for libcore.

nbdd0121 · 2022-12-08T17:34:21Z

if they are that important, we should check them in CI

There is indeed a test to verify that libcore can compile with this custom cfg (but it doesn't currently use -Dwarnings).

…iaskrgr Rollup of 10 pull requests Successful merges: - rust-lang#104922 (Detect long types in E0308 and write them to disk) - rust-lang#105120 (kmc-solid: `std::sys` code maintenance) - rust-lang#105255 (Make nested RPIT inherit the parent opaque's generics.) - rust-lang#105317 (make retagging work even with 'unstable' places) - rust-lang#105405 (Stop passing -export-dynamic to wasm-ld.) - rust-lang#105408 (Add help for `#![feature(impl_trait_in_fn_trait_return)]`) - rust-lang#105423 (Use `Symbol` for the crate name instead of `String`/`str`) - rust-lang#105433 (CI: add missing line continuation marker) - rust-lang#105434 (Fix warning when libcore is compiled with no_fp_fmt_parse) - rust-lang#105441 (Remove `UnsafetyState`) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup

Fix warning when libcore is compiled with no_fp_fmt_parse Discovered when trying to compile Rust-for-Linux with Rust 1.66 beta. It'll be helpful if this is backported to beta (should be trivial enough for backporting), so Rust-for-Linux's rust version bump wouldn't need to do `--cap-lints allow` for libcore.

…iaskrgr Rollup of 10 pull requests Successful merges: - rust-lang#104922 (Detect long types in E0308 and write them to disk) - rust-lang#105120 (kmc-solid: `std::sys` code maintenance) - rust-lang#105255 (Make nested RPIT inherit the parent opaque's generics.) - rust-lang#105317 (make retagging work even with 'unstable' places) - rust-lang#105405 (Stop passing -export-dynamic to wasm-ld.) - rust-lang#105408 (Add help for `#![feature(impl_trait_in_fn_trait_return)]`) - rust-lang#105423 (Use `Symbol` for the crate name instead of `String`/`str`) - rust-lang#105433 (CI: add missing line continuation marker) - rust-lang#105434 (Fix warning when libcore is compiled with no_fp_fmt_parse) - rust-lang#105441 (Remove `UnsafetyState`) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup

Upgrade the Rust version from 1.62.0 to 1.66.0. The overwhelming majority of the commit is about upgrading our `alloc` fork to the new version from upstream [1]. License has not changed [2][3] (there were changes in the `COPYRIGHT` file, but unrelated to `alloc`). As in the previous version upgrades (done out of tree so far), upgrading `alloc` requires checking that our small additions (`try_*`) still match their original (non`-try_*`) versions. With this version upgrade, the following unstable Rust features were stabilized: `bench_black_box` (1.66.0), `const_ptr_offset_from` (1.65.0), `core_ffi_c` (1.64.0) and `generic_associated_types` (1.65.0). Thus remove them. This also implies that only two unstable features remain allowed for non-`rust/` code: `allocator_api` and `const_refs_to_cell`. There are some new Clippy warnings that we are triggering (i.e. introduced since 1.62.0), as well as a few others that were not triggered before, thus allow them in this commit and clean up or remove them as needed later on: - `borrow_deref_ref` (new in 1.63.0). - `explicit_auto_deref` (new in 1.64.0). - `bool_to_int_with_if` (new in 1.65.0). - `needless_borrow`. - `type_complexity`. - `unnecessary_cast` (allowed only on `CONFIG_ARM`). Furthermore, `rustdoc` lint `broken_intra_doc_links` is triggering on links pointing to `macro_export` `macro_rules` defined in the same module (i.e. appearing in the crate root). However, even if the warning appears, the link still gets generated like in previous versions, thus it is a bit confusing. An issue has been opened upstream [4], and it appears that the link still being generated was a compatibility measure, thus we will need to adapt to the new behavior (done in the next patch). In addition, there is an added `#[const_trait]` attribute in `RawDeviceId`, due to 1.66.0's PR "Require `#[const_trait]` on `Trait` for `impl const Trait`") [5]. Finally, the `-Aunused-imports` was added for compiling `core`. This was fixed upstream for 1.67.0 in PR "Fix warning when libcore is compiled with no_fp_fmt_parse" [6], and prevented for the future for that `cfg` in PR "core: ensure `no_fp_fmt_parse builds` are warning-free" [7]. Reviewed-by: Björn Roy Baron <[email protected]> Reviewed-by: Martin Rodriguez Reboredo <[email protected]> Tested-by: Martin Rodriguez Reboredo <[email protected]> Reviewed-by: Gary Guo <[email protected]> Reviewed-by: Vincenzo Palazzo <[email protected]> Reviewed-by: Alice Ferrazzi <[email protected]> Tested-by: Alice Ferrazzi <[email protected]> Reviewed-by: Neal Gompa <[email protected]> Tested-by: Neal Gompa <[email protected]> Link: Rust-for-Linux#947 Link: https://github.com/rust-lang/rust/tree/1.66.0/library/alloc/src [1] Link: https://github.com/rust-lang/rust/blob/1.66.0/library/alloc/Cargo.toml#L4 [2] Link: https://github.com/rust-lang/rust/blob/1.66.0/COPYRIGHT [3] Link: rust-lang/rust#106142 [4] Link: rust-lang/rust#100982 [5] Link: rust-lang/rust#105434 [6] Link: rust-lang/rust#105811 [7] Signed-off-by: Miguel Ojeda <[email protected]>

Upgrade the Rust version from 1.62.0 to 1.66.0. The overwhelming majority of the commit is about upgrading our `alloc` fork to the new version from upstream [1]. License has not changed [2][3] (there were changes in the `COPYRIGHT` file, but unrelated to `alloc`). As in the previous version upgrades (done out of tree so far), upgrading `alloc` requires checking that our small additions (`try_*`) still match their original (non`-try_*`) versions. With this version upgrade, the following unstable Rust features were stabilized: `bench_black_box` (1.66.0), `const_ptr_offset_from` (1.65.0), `core_ffi_c` (1.64.0) and `generic_associated_types` (1.65.0). Thus remove them. This also implies that only two unstable features remain allowed for non-`rust/` code: `allocator_api` and `const_refs_to_cell`. There are some new Clippy warnings that we are triggering (i.e. introduced since 1.62.0), as well as a few others that were not triggered before, thus allow them in this commit and clean up or remove them as needed later on: - `borrow_deref_ref` (new in 1.63.0). - `explicit_auto_deref` (new in 1.64.0). - `bool_to_int_with_if` (new in 1.65.0). - `needless_borrow`. - `type_complexity`. - `unnecessary_cast` (allowed only on `CONFIG_ARM`). Furthermore, `rustdoc` lint `broken_intra_doc_links` is triggering on links pointing to `macro_export` `macro_rules` defined in the same module (i.e. appearing in the crate root). However, even if the warning appears, the link still gets generated like in previous versions, thus it is a bit confusing. An issue has been opened upstream [4], and it appears that the link still being generated was a compatibility measure, thus we will need to adapt to the new behavior (done in the next patch). In addition, there is an added `#[const_trait]` attribute in `RawDeviceId`, due to 1.66.0's PR "Require `#[const_trait]` on `Trait` for `impl const Trait`") [5]. Finally, the `-Aunused-imports` was added for compiling `core`. This was fixed upstream for 1.67.0 in PR "Fix warning when libcore is compiled with no_fp_fmt_parse" [6], and prevented for the future for that `cfg` in PR "core: ensure `no_fp_fmt_parse builds` are warning-free" [7]. Reviewed-by: Björn Roy Baron <[email protected]> Reviewed-by: Martin Rodriguez Reboredo <[email protected]> Tested-by: Martin Rodriguez Reboredo <[email protected]> Reviewed-by: Gary Guo <[email protected]> Reviewed-by: Vincenzo Palazzo <[email protected]> Reviewed-by: Alice Ferrazzi <[email protected]> Tested-by: Alice Ferrazzi <[email protected]> Reviewed-by: Neal Gompa <[email protected]> Tested-by: Neal Gompa <[email protected]> Link: Rust-for-Linux/linux#947 Link: https://github.com/rust-lang/rust/tree/1.66.0/library/alloc/src [1] Link: https://github.com/rust-lang/rust/blob/1.66.0/library/alloc/Cargo.toml#L4 [2] Link: https://github.com/rust-lang/rust/blob/1.66.0/COPYRIGHT [3] Link: rust-lang/rust#106142 [4] Link: rust-lang/rust#100982 [5] Link: rust-lang/rust#105434 [6] Link: rust-lang/rust#105811 [7] Signed-off-by: Miguel Ojeda <[email protected]>

Upgrade the Rust version from 1.62.0 to 1.66.0. The overwhelming majority of the commit is about upgrading our `alloc` fork to the new version from upstream [1]. License has not changed [2][3] (there were changes in the `COPYRIGHT` file, but unrelated to `alloc`). As in the previous version upgrades (done out of tree so far), upgrading `alloc` requires checking that our small additions (`try_*`) still match their original (non`-try_*`) versions. With this version upgrade, the following unstable Rust features were stabilized: `bench_black_box` (1.66.0), `const_ptr_offset_from` (1.65.0), `core_ffi_c` (1.64.0) and `generic_associated_types` (1.65.0). Thus remove them. This also implies that only two unstable features remain allowed for non-`rust/` code: `allocator_api` and `const_refs_to_cell`. There are some new Clippy warnings that we are triggering (i.e. introduced since 1.62.0), as well as a few others that were not triggered before, thus allow them in this commit and clean up or remove them as needed later on: - `borrow_deref_ref` (new in 1.63.0). - `explicit_auto_deref` (new in 1.64.0). - `bool_to_int_with_if` (new in 1.65.0). - `needless_borrow`. - `type_complexity`. - `unnecessary_cast` (allowed only on `CONFIG_ARM`). Furthermore, `rustdoc` lint `broken_intra_doc_links` is triggering on links pointing to `macro_export` `macro_rules` defined in the same module (i.e. appearing in the crate root). However, even if the warning appears, the link still gets generated like in previous versions, thus it is a bit confusing. An issue has been opened upstream [4], and it appears that the link still being generated was a compatibility measure, thus we will need to adapt to the new behavior (done in the next patch). In addition, there is an added `#[const_trait]` attribute in `RawDeviceId`, due to 1.66.0's PR "Require `#[const_trait]` on `Trait` for `impl const Trait`") [5]. Finally, the `-Aunused-imports` was added for compiling `core`. This was fixed upstream for 1.67.0 in PR "Fix warning when libcore is compiled with no_fp_fmt_parse" [6], and prevented for the future for that `cfg` in PR "core: ensure `no_fp_fmt_parse builds` are warning-free" [7]. Reviewed-by: Björn Roy Baron <[email protected]> Reviewed-by: Martin Rodriguez Reboredo <[email protected]> Tested-by: Martin Rodriguez Reboredo <[email protected]> Reviewed-by: Gary Guo <[email protected]> Reviewed-by: Vincenzo Palazzo <[email protected]> Reviewed-by: Alice Ferrazzi <[email protected]> Tested-by: Alice Ferrazzi <[email protected]> Reviewed-by: Neal Gompa <[email protected]> Tested-by: Neal Gompa <[email protected]> Link: Rust-for-Linux#947 Link: https://github.com/rust-lang/rust/tree/1.66.0/library/alloc/src [1] Link: https://github.com/rust-lang/rust/blob/1.66.0/library/alloc/Cargo.toml#L4 [2] Link: https://github.com/rust-lang/rust/blob/1.66.0/COPYRIGHT [3] Link: rust-lang/rust#106142 [4] Link: rust-lang/rust#100982 [5] Link: rust-lang/rust#105434 [6] Link: rust-lang/rust#105811 [7] Signed-off-by: Miguel Ojeda <[email protected]>

Upgrade the Rust version from 1.62.0 to 1.66.0. The overwhelming majority of the commit is about upgrading our `alloc` fork to the new version from upstream [1]. License has not changed [2][3] (there were changes in the `COPYRIGHT` file, but unrelated to `alloc`). As in the previous version upgrades (done out of tree so far), upgrading `alloc` requires checking that our small additions (`try_*`) still match their original (non`-try_*`) versions. With this version upgrade, the following unstable Rust features were stabilized: `bench_black_box` (1.66.0), `const_ptr_offset_from` (1.65.0), `core_ffi_c` (1.64.0) and `generic_associated_types` (1.65.0). Thus remove them. This also implies that only two unstable features remain allowed for non-`rust/` code: `allocator_api` and `const_refs_to_cell`. There are some new Clippy warnings that we are triggering (i.e. introduced since 1.62.0), as well as a few others that were not triggered before, thus allow them in this commit and clean up or remove them as needed later on: - `borrow_deref_ref` (new in 1.63.0). - `explicit_auto_deref` (new in 1.64.0). - `bool_to_int_with_if` (new in 1.65.0). - `needless_borrow`. - `type_complexity`. - `unnecessary_cast` (allowed only on `CONFIG_ARM`). Furthermore, `rustdoc` lint `broken_intra_doc_links` is triggering on links pointing to `macro_export` `macro_rules` defined in the same module (i.e. appearing in the crate root). However, even if the warning appears, the link still gets generated like in previous versions, thus it is a bit confusing. An issue has been opened upstream [4], and it appears that the link still being generated was a compatibility measure, thus we will need to adapt to the new behavior (done in the next patch). In addition, there is an added `#[const_trait]` attribute in `RawDeviceId`, due to 1.66.0's PR "Require `#[const_trait]` on `Trait` for `impl const Trait`") [5]. Finally, the `-Aunused-imports` was added for compiling `core`. This was fixed upstream for 1.67.0 in PR "Fix warning when libcore is compiled with no_fp_fmt_parse" [6], and prevented for the future for that `cfg` in PR "core: ensure `no_fp_fmt_parse builds` are warning-free" [7]. Reviewed-by: Björn Roy Baron <[email protected]> Reviewed-by: Martin Rodriguez Reboredo <[email protected]> Tested-by: Martin Rodriguez Reboredo <[email protected]> Reviewed-by: Gary Guo <[email protected]> Reviewed-by: Vincenzo Palazzo <[email protected]> Reviewed-by: Alice Ferrazzi <[email protected]> Tested-by: Alice Ferrazzi <[email protected]> Reviewed-by: Neal Gompa <[email protected]> Tested-by: Neal Gompa <[email protected]> Link: Rust-for-Linux/linux#947 Link: https://github.com/rust-lang/rust/tree/1.66.0/library/alloc/src [1] Link: https://github.com/rust-lang/rust/blob/1.66.0/library/alloc/Cargo.toml#L4 [2] Link: https://github.com/rust-lang/rust/blob/1.66.0/COPYRIGHT [3] Link: rust-lang/rust#106142 [4] Link: rust-lang/rust#100982 [5] Link: rust-lang/rust#105434 [6] Link: rust-lang/rust#105811 [7] Signed-off-by: Miguel Ojeda <[email protected]>

Fix warning when libcore is compiled with no_fp_fmt_parse

a3c4c2e

rustbot assigned thomcc Dec 8, 2022

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Dec 8, 2022

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 8, 2022

thomcc added the beta-nominated Nominated for backporting to the compiler in the beta channel. label Dec 8, 2022

matthiaskrgr mentioned this pull request Dec 8, 2022

Rollup of 9 pull requests #105444

Closed

matthiaskrgr mentioned this pull request Dec 8, 2022

Rollup of 8 pull requests #105448

Closed

matthiaskrgr mentioned this pull request Dec 8, 2022

Rollup of 10 pull requests #105456

Merged

bors merged commit 433189b into rust-lang:master Dec 9, 2022

rustbot added this to the 1.67.0 milestone Dec 9, 2022

pietroalbini removed the beta-nominated Nominated for backporting to the compiler in the beta channel. label Dec 12, 2022

ojeda mentioned this pull request Dec 16, 2022

core wanted features & bugfixes Rust-for-Linux/linux#514

Open

13 tasks

albertlarsan68 mentioned this pull request Jan 9, 2023

Regression in Beta/Nightly: implementation of Trait is not general enough #106630

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix warning when libcore is compiled with no_fp_fmt_parse #105434

Fix warning when libcore is compiled with no_fp_fmt_parse #105434

nbdd0121 commented Dec 8, 2022

rustbot commented Dec 8, 2022

rustbot commented Dec 8, 2022

thomcc commented Dec 8, 2022

bors commented Dec 8, 2022

thomcc commented Dec 8, 2022

nbdd0121 commented Dec 8, 2022

Fix warning when libcore is compiled with no_fp_fmt_parse #105434

Fix warning when libcore is compiled with no_fp_fmt_parse #105434

Conversation

nbdd0121 commented Dec 8, 2022

rustbot commented Dec 8, 2022

rustbot commented Dec 8, 2022

thomcc commented Dec 8, 2022

bors commented Dec 8, 2022

thomcc commented Dec 8, 2022

nbdd0121 commented Dec 8, 2022