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 unsupported_fn_ptr_calling_conventions #130260

Open
tdittr opened this issue Sep 12, 2024 · 2 comments
Labels
A-ABI Area: Concerning the application binary interface (ABI) 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

@tdittr
Copy link
Contributor

tdittr commented Sep 12, 2024

This is the summary issue for the unsupported_fn_ptr_calling_conventions future-compatibility warning. 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 unsupported_fn_ptr_calling_conventions lint is output whenever there is a use of a target dependent calling convention on a target that does not support this calling convention on a function pointer.

For example stdcall does not make much sense for a x86_64 or, more apparently, powerpc code, because this calling convention was never specified for those targets.

Example

fn stdcall_ptr(f: extern "stdcall" fn ()) {
    f()
}

This will produce:

warning: use of calling convention not supported on this target on function pointer
  --> $DIR/unsupported.rs:34:15
   |
LL | fn stdcall_ptr(f: extern "stdcall" fn()) {
   |               ^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
   = note: for more information, see issue #130260 <https://github.com/rust-lang/rust/issues/130260>
   = note: `#[warn(unsupported_fn_ptr_calling_conventions)]` on by default

Explanation

On most of the targets the behavior of stdcall and similar calling conventions is not defined at all, but was previously accepted due to a bug in the implementation of the compiler.

Recommendations

Use #[cfg(…)] annotations to ensure that the ABI identifiers are only used in combination with targets for which the requested ABI is well specified.

When will this warning become a hard error?

At the beginning of each 6-week release cycle, the Rust compiler team will review the set of outstanding future compatibility warnings and nominate some of them for Final Comment Period. Toward the end of the cycle, we will review any comments and make a final determination whether to convert the warning into a hard error or remove it entirely.

Implemented in #128784

See also #87678 for the similar unsupported_calling_conventions lint.

@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Sep 12, 2024
@tdittr

This comment was marked as resolved.

@rustbot rustbot added C-future-incompatibility Category: Future-incompatibility lints C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. labels Sep 12, 2024
@compiler-errors compiler-errors removed needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. labels Sep 12, 2024
@fmease fmease added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. A-ABI Area: Concerning the application binary interface (ABI) labels Sep 14, 2024
@fmease fmease changed the title Tracking issue for UNSUPPORTED_FN_PTR_CALLING_CONVENTIONS future compatibility lint Tracking issue for UNSUPPORTED_FN_PTR_CALLING_CONVENTIONS future-incompatibility lint Sep 14, 2024
@fmease fmease changed the title Tracking issue for UNSUPPORTED_FN_PTR_CALLING_CONVENTIONS future-incompatibility lint Tracking issue for future-incompatibility lint unsupported_fn_ptr_calling_conventions Sep 14, 2024
@fmease fmease added the A-lint Area: Lints (warnings about flaws in source code) such as unused_mut. label Sep 14, 2024
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Oct 12, 2024
…iler-errors

Check ABI target compatibility for function pointers

Tracking issue: rust-lang#130260
Related tracking issue: rust-lang#87678

Compatibility of an ABI for a target was previously only performed on function definitions and `extern` blocks. This PR adds it also to function pointers to be consistent.

This might have broken some of the `tests/ui/` depending on the platform, so a try run seems like a good idea.

Also this might break existing code, because we now emit extra errors. Does this require a crater run?

# Example
```rust
// build with: --target=x86_64-unknown-linux-gnu

// These raise E0570
extern "thiscall" fn foo() {}
extern "thiscall" { fn bar() }

// This did not raise any error
fn baz(f: extern "thiscall" fn()) { f() }
```

# Open Questions
* [x] Should this report a future incompatibility warning like rust-lang#87678 ?
* [ ] Is this the best place to perform the check?
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Oct 12, 2024
…iler-errors

Check ABI target compatibility for function pointers

Tracking issue: rust-lang#130260
Related tracking issue: rust-lang#87678

Compatibility of an ABI for a target was previously only performed on function definitions and `extern` blocks. This PR adds it also to function pointers to be consistent.

This might have broken some of the `tests/ui/` depending on the platform, so a try run seems like a good idea.

Also this might break existing code, because we now emit extra errors. Does this require a crater run?

# Example
```rust
// build with: --target=x86_64-unknown-linux-gnu

// These raise E0570
extern "thiscall" fn foo() {}
extern "thiscall" { fn bar() }

// This did not raise any error
fn baz(f: extern "thiscall" fn()) { f() }
```

# Open Questions
* [x] Should this report a future incompatibility warning like rust-lang#87678 ?
* [ ] Is this the best place to perform the check?
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Oct 13, 2024
Rollup merge of rust-lang#128784 - tdittr:check-abi-on-fn-ptr, r=compiler-errors

Check ABI target compatibility for function pointers

Tracking issue: rust-lang#130260
Related tracking issue: rust-lang#87678

Compatibility of an ABI for a target was previously only performed on function definitions and `extern` blocks. This PR adds it also to function pointers to be consistent.

This might have broken some of the `tests/ui/` depending on the platform, so a try run seems like a good idea.

Also this might break existing code, because we now emit extra errors. Does this require a crater run?

# Example
```rust
// build with: --target=x86_64-unknown-linux-gnu

// These raise E0570
extern "thiscall" fn foo() {}
extern "thiscall" { fn bar() }

// This did not raise any error
fn baz(f: extern "thiscall" fn()) { f() }
```

# Open Questions
* [x] Should this report a future incompatibility warning like rust-lang#87678 ?
* [ ] Is this the best place to perform the check?
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Oct 14, 2024
…age, r=compiler-errors

Update lint message for ABI not supported

Tracking issue: rust-lang#130260

As requested in rust-lang#128784 (review) I updated the error message.

I could also change it to be the same message as if it was a hard error on a normal function:

> "`{abi}` is not a supported ABI for the current target"

Or would that get confusing when people try to google the error message?

r? compiler-errors
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Oct 14, 2024
…age, r=compiler-errors

Update lint message for ABI not supported

Tracking issue: rust-lang#130260

As requested in rust-lang#128784 (review) I updated the error message.

I could also change it to be the same message as if it was a hard error on a normal function:

> "`{abi}` is not a supported ABI for the current target"

Or would that get confusing when people try to google the error message?

r? compiler-errors
compiler-errors added a commit to compiler-errors/rust that referenced this issue Oct 15, 2024
…age, r=compiler-errors

Update lint message for ABI not supported

Tracking issue: rust-lang#130260

As requested in rust-lang#128784 (review) I updated the error message.

I could also change it to be the same message as if it was a hard error on a normal function:

> "`{abi}` is not a supported ABI for the current target"

Or would that get confusing when people try to google the error message?

r? compiler-errors
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Oct 15, 2024
…age, r=compiler-errors

Update lint message for ABI not supported

Tracking issue: rust-lang#130260

As requested in rust-lang#128784 (review) I updated the error message.

I could also change it to be the same message as if it was a hard error on a normal function:

> "`{abi}` is not a supported ABI for the current target"

Or would that get confusing when people try to google the error message?

r? compiler-errors
@Freax13

This comment has been minimized.

rust-timer added a commit to rust-lang-ci/rust that referenced this issue Oct 15, 2024
Rollup merge of rust-lang#131675 - tdittr:update-unsupported-abi-message, r=compiler-errors

Update lint message for ABI not supported

Tracking issue: rust-lang#130260

As requested in rust-lang#128784 (review) I updated the error message.

I could also change it to be the same message as if it was a hard error on a normal function:

> "`{abi}` is not a supported ABI for the current target"

Or would that get confusing when people try to google the error message?

r? compiler-errors
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-ABI Area: Concerning the application binary interface (ABI) 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
None yet
Development

No branches or pull requests

5 participants