Skip to content
New issue

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

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

Already on GitHub? # to your account

Split out the extern_system_varargs feature #136948

Merged

Conversation

workingjubilee
Copy link
Member

@workingjubilee workingjubilee commented Feb 12, 2025

After the stabilization PR was opened, extern "system" functions were added to extended_varargs_abi_support. This has a number of questions regarding it that were not discussed and were somewhat surprising. It deserves to be considered as its own feature, separate from extended_varargs_abi_support.

Tracking issue:

// User enabled additional ABI support for varargs and function ABI matches those ones.
(true, true) => return,
ExternAbi::System { .. } if extern_system_varargs => return,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you merge these guarded arms and the unguarded arms? I think:

ExternAbi::System { .. } if extern_system_varargs => return,
ExternAbi::System { .. } => {
    feature_err(&tcx.sess, sym::extern_system_varargs, span, UNSTABLE_EXPLAIN).emit();
}

Is much harder to read than:

ExternAbi::System { .. } => {
    if extern_system_varargs {
        return;
    } else {
        feature_err(&tcx.sess, sym::extern_system_varargs, span, UNSTABLE_EXPLAIN).emit();
}

Also, looking at the cotrol flow here... I think it's a bit strange here that we're issuing both a feature error and another error below. Maybe that could be consolidated/deduplicated too. Thoughts?

Copy link
Member Author

@workingjubilee workingjubilee Feb 12, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hm, is c9c1ab4 more readable to you?

it's pretty strange control flow, yes. I had been thinking about altering the entire way the error is computed, but it will work better after #136901 lands (and I'm fine with delaying this until it does) now that I can refactor it as the relevant PR landed

Copy link
Member Author

@workingjubilee workingjubilee Feb 12, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

my initial thought in the way I (re)wrote it was to put all "escape paths" next to each other and then have all "error paths" next to each other.

Copy link
Member Author

@workingjubilee workingjubilee Feb 13, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried to rewrite some things to hopefully make the thought process clearer, if this is legible to you I can iterate it a bit more to polish it out.

@rustbot rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Feb 12, 2025
Comment on lines 139 to 161
feature_err(&tcx.sess, sym::extern_system_varargs, span, UNSTABLE_EXPLAIN).emit();
}
}
abi => {
if abi.supports_varargs() {
// User enabled additional ABI support for varargs and function ABI matches those ones.
if extended_abi_support {
return;
} else {
// Using this ABI would be ok, if the feature for additional ABI support was enabled.
feature_err(
&tcx.sess,
sym::extended_varargs_abi_support,
span,
UNSTABLE_EXPLAIN,
)
.emit();
};
}
}

(false, false) => CONVENTIONS_STABLE,
(true, false) => CONVENTIONS_UNSTABLE,
};

tcx.dcx().emit_err(errors::VariadicFunctionCompatibleConvention { span, conventions });
Copy link
Member Author

@workingjubilee workingjubilee Feb 12, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally we'd

  • check if this is an actual error path (else bail)
  • then compute the error we want to emit
  • then emit one error

But also, ideally we'd not have to hardcode anything about the error we emit here: we should just filter ExternAbi::ALL_VARIANTS to "everything that actually can support varargs", then format and emit the list.

@workingjubilee workingjubilee force-pushed the split-off-extern-system-varargs branch 2 times, most recently from f242874 to 154eb95 Compare February 13, 2025 00:23
@rust-log-analyzer

This comment has been minimized.

@compiler-errors
Copy link
Member

LGTM, thanks for cleaning it up a bit

@bors r+

@bors
Copy link
Contributor

bors commented Feb 13, 2025

📌 Commit fa02c12 has been approved by compiler-errors

It is now in the queue for this repository.

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Feb 13, 2025
After the stabilization PR was opened, `extern "system"` functions were
added to `extended_varargs_abi_support`. This has a number of questions
regarding it that were not discussed and were somewhat surprising.
It deserves to be considered as its own feature, separate from
`extended_varargs_abi_support`.
@workingjubilee workingjubilee force-pushed the split-off-extern-system-varargs branch from fa02c12 to 4bb0c3d Compare February 13, 2025 04:03
@workingjubilee
Copy link
Member Author

squashed
@bors r=compiler-errors

@bors
Copy link
Contributor

bors commented Feb 13, 2025

📌 Commit 4bb0c3d has been approved by compiler-errors

It is now in the queue for this repository.

jhpratt added a commit to jhpratt/rust that referenced this pull request Feb 13, 2025
…stem-varargs, r=compiler-errors

Split out the `extern_system_varargs` feature

After the stabilization PR was opened, `extern "system"` functions were added to `extended_varargs_abi_support`. This has a number of questions regarding it that were not discussed and were somewhat surprising. It deserves to be considered as its own feature, separate from `extended_varargs_abi_support`.

Tracking issue:
- rust-lang#136946
bors added a commit to rust-lang-ci/rust that referenced this pull request Feb 13, 2025
Rollup of 9 pull requests

Successful merges:

 - rust-lang#134999 (Add cygwin target.)
 - rust-lang#136324 (Implement `f{16,32,64,128}::{erf,erfc}` (`#![feature(float_erf)]`))
 - rust-lang#136559 (Resolve named regions when reporting type test failures in NLL)
 - rust-lang#136660 (Use a trait to enforce field validity for union fields + `unsafe` fields + `unsafe<>` binder types)
 - rust-lang#136858 (Parallel-compiler-related cleanup)
 - rust-lang#136881 (cg_llvm: Reduce visibility of all functions in the llvm module)
 - rust-lang#136888 (Always perform discr read for never pattern in EUV)
 - rust-lang#136948 (Split out the `extern_system_varargs` feature)
 - rust-lang#136949 (Fix import in bench for wasm)

r? `@ghost`
`@rustbot` modify labels: rollup
bors added a commit to rust-lang-ci/rust that referenced this pull request Feb 13, 2025
Rollup of 8 pull requests

Successful merges:

 - rust-lang#134999 (Add cygwin target.)
 - rust-lang#136559 (Resolve named regions when reporting type test failures in NLL)
 - rust-lang#136660 (Use a trait to enforce field validity for union fields + `unsafe` fields + `unsafe<>` binder types)
 - rust-lang#136858 (Parallel-compiler-related cleanup)
 - rust-lang#136881 (cg_llvm: Reduce visibility of all functions in the llvm module)
 - rust-lang#136888 (Always perform discr read for never pattern in EUV)
 - rust-lang#136948 (Split out the `extern_system_varargs` feature)
 - rust-lang#136949 (Fix import in bench for wasm)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 36d3796 into rust-lang:master Feb 13, 2025
6 checks passed
@rustbot rustbot added this to the 1.86.0 milestone Feb 13, 2025
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Feb 13, 2025
Rollup merge of rust-lang#136948 - workingjubilee:split-off-extern-system-varargs, r=compiler-errors

Split out the `extern_system_varargs` feature

After the stabilization PR was opened, `extern "system"` functions were added to `extended_varargs_abi_support`. This has a number of questions regarding it that were not discussed and were somewhat surprising. It deserves to be considered as its own feature, separate from `extended_varargs_abi_support`.

Tracking issue:
- rust-lang#136946
@workingjubilee workingjubilee deleted the split-off-extern-system-varargs branch February 13, 2025 22:40
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants