Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking issue for future-incompatibility lint conflicting_repr_hints #68585

Open
Centril opened this issue Jan 27, 2020 · 4 comments
Open

Tracking issue for future-incompatibility lint conflicting_repr_hints #68585

Centril opened this issue Jan 27, 2020 · 4 comments
Labels
A-attributes Area: Attributes (`#[…]`, `#![…]`) A-lint Area: Lints (warnings about flaws in source code) such as unused_mut. C-future-incompatibility Category: Future-incompatibility lints C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@Centril
Copy link
Contributor

Centril commented Jan 27, 2020

This is the summary issue for a bug fix related to repr(...) hints. The goal of this page is describe why this change was made and how you can fix code that is affected by it. It also provides a place to ask questions or register a complaint if you feel the change should not be made. For more information on the policy around future-compatibility warnings, see our breaking change policy guidelines.

What is the warning for?

The compiler incorrectly accepts #[repr(...)] hints on data types where the hints are incompatible and have conflicts. Examples of this includes:

// from `src/test/ui/conflicting-repr-hints.rs

#[repr(u32, u64)] //~ ERROR conflicting representation hints
enum D {
    D,
}

We are presently issuing a deny-by-default lint when conflicting representation hints are used together but we expect to transition the lint to hard errors in the future.

How can you fix your code?

Generally speaking, the conflict should be fixed by more clearly expressing your intent so that the conflict is resolved.

@Centril Centril added A-lint Area: Lints (warnings about flaws in source code) such as unused_mut. C-future-incompatibility Category: Future-incompatibility lints labels Jan 27, 2020
JohnTitor added a commit to JohnTitor/rust that referenced this issue Jan 29, 2020
Make conflicting_repr_hints a deny-by-default c-future-compat lint

Closes rust-lang#68428.
cc rust-lang#68585.

r? @petrochenkov @pnkfelix
@Manishearth
Copy link
Member

As discussed a bit in #68428 perhaps we should remove the warning and add semantics for #[repr(C, Int)] (namely, "fold into repr(C)").

C++ supports enum class Foo: uint16_t, and we heavily recommend you only pass repr(C) types across FFI boundaries, so it makes sense that the correct thing to write for this is #[repr(C, u16)]. Furthermore, for dataful enums, #[repr(C, u16)] actually does work, and it's weird for this not to be consistent.

@Centril
Copy link
Contributor Author

Centril commented Feb 24, 2020

Beta crater results in #68586 (comment):

error[E0566]: conflicting representation hints

Number of crates regressed: 2

* [`enum-utils v0.1.2`](https://crater-reports.s3.amazonaws.com/beta-1.42-1/beta-2020-02-05/reg/enum-utils-0.1.2/log.txt)

* [`ovr-mobile-sys v0.4.0`](https://crater-reports.s3.amazonaws.com/beta-1.42-rustdoc-1/beta-2020-02-05/reg/ovr-mobile-sys-0.4.0/log.txt)
  • enum-utils has 0 rev deps, (btw, cc @ecstatic-morse)
  • ovr-mobile-sys was the servo dependency and it seems to have been fixed already.

Based on these very limited results I don't think it's justified to retcon this into the specification, and making it an error again in the near future should be possible.

@ecstatic-morse
Copy link
Contributor

ecstatic-morse commented Feb 24, 2020

enum-utils has a test that ensures #[repr(C, u16)] works. You shouldn't consider it when determining fallout.

@marmeladema
Copy link
Contributor

marmeladema commented Feb 18, 2021

Just encountered this error.
I wonder how does it relate to

Will that make both those RFC obsolete?
Also, will it be turned into a hard error in edition 2021?

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Aug 21, 2024
…ncompat, r=lcnr

bump conflicting_repr_hints lint to be shown in dependencies

This has been a future compatibility lint for years, let's bump it up to be shown in dependencies (so that hopefully we can then make it a hard error fairly soon).

Cc rust-lang#68585
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Aug 21, 2024
Rollup merge of rust-lang#128727 - RalfJung:conflicting-repr-future-incompat, r=lcnr

bump conflicting_repr_hints lint to be shown in dependencies

This has been a future compatibility lint for years, let's bump it up to be shown in dependencies (so that hopefully we can then make it a hard error fairly soon).

Cc rust-lang#68585
@fmease fmease added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. A-attributes Area: Attributes (`#[…]`, `#![…]`) labels Sep 14, 2024
@fmease fmease changed the title Tracking issue for conflicting repr(...) hints future compatibility Tracking issue for future-incompatibility lint conflicting_repr_hints Sep 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-attributes Area: Attributes (`#[…]`, `#![…]`) A-lint Area: Lints (warnings about flaws in source code) such as unused_mut. C-future-incompatibility Category: Future-incompatibility lints C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
Archived in project
Development

No branches or pull requests

5 participants