Skip to content

Conversation

folkertdev
Copy link
Contributor

tracking issue: #44930

The parts of #143546 that don't require any particular knowledge about c-variadic functions.

This prepares the way for rejecting c-variadic functions that are also coroutines, safe functions, or associated functions.

@rustbot
Copy link
Collaborator

rustbot commented Sep 3, 2025

r? @lcnr

rustbot has assigned @lcnr.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Sep 3, 2025
@rust-log-analyzer

This comment has been minimized.

@folkertdev folkertdev force-pushed the c-variadic-errors-take-2 branch from 9eaecd8 to 8d11719 Compare September 3, 2025 16:35
@lcnr
Copy link
Contributor

lcnr commented Sep 8, 2025

@bors r+ rollup

@bors
Copy link
Collaborator

bors commented Sep 8, 2025

📌 Commit 8d11719 has been approved by lcnr

It is now in the queue for this repository.

@bors 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 Sep 8, 2025
@bors
Copy link
Collaborator

bors commented Sep 8, 2025

⌛ Testing commit 8d11719 with merge 68baa87...

@bors
Copy link
Collaborator

bors commented Sep 8, 2025

☀️ Test successful - checks-actions
Approved by: lcnr
Pushing 68baa87 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Sep 8, 2025
@bors bors merged commit 68baa87 into rust-lang:master Sep 8, 2025
11 checks passed
@rustbot rustbot added this to the 1.91.0 milestone Sep 8, 2025
Copy link
Contributor

github-actions bot commented Sep 8, 2025

What is this? This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing beeb8e3 (parent) -> 68baa87 (this PR)

Test differences

Show 7 test diffs

Stage 1

  • [ui] tests/ui/c-variadic/no-closure.rs: [missing] -> pass (J1)
  • [ui] tests/ui/c-variadic/valid.rs: [missing] -> pass (J1)

Stage 2

  • [ui] tests/ui/c-variadic/no-closure.rs: [missing] -> pass (J0)
  • [ui] tests/ui/c-variadic/valid.rs: [missing] -> pass (J0)

Additionally, 3 doctest diffs were found. These are ignored, as they are noisy.

Job group index

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 68baa87ba6f03f8b6af2a368690161f1601e4040 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

  1. dist-x86_64-apple: 6734.4s -> 9954.8s (47.8%)
  2. dist-aarch64-apple: 6139.4s -> 7880.6s (28.4%)
  3. x86_64-gnu-llvm-20-3: 7055.4s -> 6329.0s (-10.3%)
  4. dist-various-1: 3689.4s -> 4011.2s (8.7%)
  5. dist-apple-various: 4138.6s -> 4453.4s (7.6%)
  6. dist-aarch64-msvc: 5493.4s -> 5855.5s (6.6%)
  7. x86_64-mingw-1: 10322.7s -> 9644.5s (-6.6%)
  8. dist-i686-linux: 6224.9s -> 6620.4s (6.4%)
  9. x86_64-mingw-2: 7539.3s -> 7998.2s (6.1%)
  10. dist-powerpc64le-linux-musl: 5185.5s -> 5473.8s (5.6%)
How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (68baa87): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-1.2% [-1.2%, -1.2%] 1
Improvements ✅
(secondary)
-0.1% [-0.1%, -0.1%] 1
All ❌✅ (primary) -1.2% [-1.2%, -1.2%] 1

Max RSS (memory usage)

Results (primary 3.3%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
3.3% [3.2%, 3.3%] 2
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 3.3% [3.2%, 3.3%] 2

Cycles

Results (secondary -2.7%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-2.7% [-3.1%, -2.1%] 3
All ❌✅ (primary) - - 0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 466.876s -> 468.245s (0.29%)
Artifact size: 387.41 MiB -> 387.41 MiB (0.00%)

GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this pull request Sep 9, 2025
…3, r=workingjubilee

Improve C-variadic error messages: part 2

tracking issue: rust-lang#44930

a reimplementation of rust-lang#143546 that builds on rust-lang#146165.

This PR

- disallows coroutines (e.g. `async fn`) from having a `...` argument
- disallows associated functions (both in traits and standard impl blocks) from having a `...` argument
- splits up a generic "ill-formed C-variadic function" into specific errors about using an incorrect ABI, not specifying an ABI, or missing the unsafe keyword

C-variadic coroutines probably don't make sense? C-variadic functions are for FFI purposes, combining that with async functions seems weird.

For associated functions, we're just cutting scope. It's probably fine, but it's probably better to explicitly allow it. So for now, at least give a more targeted error message.

Made to be reviewed commit-by-commit.

cc `@workingjubilee`
r? compiler
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this pull request Sep 9, 2025
…3, r=workingjubilee

Improve C-variadic error messages: part 2

tracking issue: rust-lang#44930

a reimplementation of rust-lang#143546 that builds on rust-lang#146165.

This PR

- disallows coroutines (e.g. `async fn`) from having a `...` argument
- disallows associated functions (both in traits and standard impl blocks) from having a `...` argument
- splits up a generic "ill-formed C-variadic function" into specific errors about using an incorrect ABI, not specifying an ABI, or missing the unsafe keyword

C-variadic coroutines probably don't make sense? C-variadic functions are for FFI purposes, combining that with async functions seems weird.

For associated functions, we're just cutting scope. It's probably fine, but it's probably better to explicitly allow it. So for now, at least give a more targeted error message.

Made to be reviewed commit-by-commit.

cc ``@workingjubilee``
r? compiler
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Sep 10, 2025
…3, r=workingjubilee

Improve C-variadic error messages: part 2

tracking issue: rust-lang#44930

a reimplementation of rust-lang#143546 that builds on rust-lang#146165.

This PR

- disallows coroutines (e.g. `async fn`) from having a `...` argument
- disallows associated functions (both in traits and standard impl blocks) from having a `...` argument
- splits up a generic "ill-formed C-variadic function" into specific errors about using an incorrect ABI, not specifying an ABI, or missing the unsafe keyword

C-variadic coroutines probably don't make sense? C-variadic functions are for FFI purposes, combining that with async functions seems weird.

For associated functions, we're just cutting scope. It's probably fine, but it's probably better to explicitly allow it. So for now, at least give a more targeted error message.

Made to be reviewed commit-by-commit.

cc `@workingjubilee`
r? compiler
rust-timer added a commit that referenced this pull request Sep 11, 2025
Rollup merge of #146342 - folkertdev:c-variadic-errors-take-3, r=workingjubilee

Improve C-variadic error messages: part 2

tracking issue: #44930

a reimplementation of #143546 that builds on #146165.

This PR

- disallows coroutines (e.g. `async fn`) from having a `...` argument
- disallows associated functions (both in traits and standard impl blocks) from having a `...` argument
- splits up a generic "ill-formed C-variadic function" into specific errors about using an incorrect ABI, not specifying an ABI, or missing the unsafe keyword

C-variadic coroutines probably don't make sense? C-variadic functions are for FFI purposes, combining that with async functions seems weird.

For associated functions, we're just cutting scope. It's probably fine, but it's probably better to explicitly allow it. So for now, at least give a more targeted error message.

Made to be reviewed commit-by-commit.

cc `@workingjubilee`
r? compiler
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
F-c_variadic `#![feature(c_variadic)]` merged-by-bors This PR was explicitly merged by bors. 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.

7 participants