Add (back) unsupported_calling_conventions lint to reject more invalid calling conventions
#141435
+1,510
−358
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
These commits modify compiler targets. |
rustbot
added
S-waiting-on-review
RalfJung
force-pushed
the
unsupported_calling_conventions
branch
3 times, most recently
from
f4146aa to
b8f4367
Compare
|
@rust-lang/lang following positive vibes expressed here, I'd like to land this PR as a first step to implement the plan from that issue. Can we get this FCPd? :) The one potential open question here is whether this should be a regular FCW first or whether it can immediately become an FCW that shows up in dependencies. I assume stdcall and fastcall are sufficiently rare that we can go for report-in-deps immediately (since they already get rejected on non-x86-32 non-Windows targets). "cdecl" might be more widely used though so it may be worth ramping up the lint more slowly. |
RalfJung
added
the
I-lang-nominated
traviscross
added
P-lang-drag-1
|
Searching across GitHub, there are 506 Rust file hits on Regarding whether to fire the FCW in deps immediately, I lean toward it probably being OK. Given that this may show up in |
|
Oh that's the syntax for doing such a search... I tried and failed to get a similar result out of github search.^^ |
traviscross
changed the title
unsupported_calling_conventions lint to reject more invalid calling conventions
|
Let's propose to do it. @rfcbot fcp merge |
|
Team member @traviscross has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns. |
rfcbot
added
proposed-final-comment-period
|
@rfcbot reviewed |
|
@rfcbot reviewed I think, in the case of
|
rfcbot
added
final-comment-period
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
traviscross
added
I-lang-radar
|
Try build cancelled. Cancelled workflows: |
|
❗ A try build is currently in progress. You can cancel it using |
|
@bors2 try |
rust-bors bot
added a commit
that referenced
this pull request
Jun 8, 2025
…try> Add (back) `unsupported_calling_conventions` lint to reject more invalid calling conventions This adds back the `unsupported_calling_conventions` lint that was removed in #129935, in order to start the process of dealing with #137018. Specifically, we are going for the plan laid out [here](#137018 (comment)): - thiscall, stdcall, fastcall, cdecl should only be accepted on x86-32 - vectorcall should only be accepted on x86-32 and x86-64 The difference to the status quo is that: - We stop accepting stdcall, fastcall on targets that are windows && non-x86-32 (we already don't accept these on targets that are non-windows && non-x86-32) - We stop accepting cdecl on targets that are non-x86-32 - (There is no difference for thiscall, this was already a hard error on non-x86-32) - We stop accepting vectorcall on targets that are windows && non-x86-* Vectorcall is an unstable ABI so we can just make this a hard error immediately. The others are stable, so we emit the `unsupported_calling_conventions` forward-compat lint. I set up the lint to show up in dependencies via cargo's future-compat report immediately, but we could also make it show up just for the local crate first if that is preferred. try-job: i686-msvc-1 try-job: x86_64-msvc-1 try-job: test-various
|
🙏 @bors r+ |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
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 334ba81 (parent) -> b6685d7 (this PR) Test differencesShow 170 test diffsStage 1
Stage 2
Additionally, 81 doctest diffs were found. These are ignored, as they are noisy. Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard b6685d748fe4668571c05ba338f61520db6dacc9 --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
This was referenced Jun 9, 2025
|
Finished benchmarking commit (b6685d7): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.
Max RSS (memory usage)Results (primary -2.0%, secondary 3.3%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResults (secondary -6.7%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 755.214s -> 753.257s (-0.26%) |
workingjubilee
added a commit
to workingjubilee/rustc
that referenced
this pull request
Jun 12, 2025
…cl-and-other-abis, r=RalfJung compiler: Ease off the accelerator on `unsupported_calling_conventions` This is to give us more time to discuss rust-lang#142330 without the ecosystem having an anxiety attack. I have withdrawn `unsupported_calling_conventions` from report-in-deps I believe we should consider this a simple suspension of the decision in rust-lang#141435 to start this process, rather than a reversal. That is, we may continue with linting again. But I believe we are about to get a... reasonable amount of feedback just from currently available information and should allow ourselves time to process it.
workingjubilee
added a commit
to workingjubilee/rustc
that referenced
this pull request
Jun 12, 2025
…cl-and-other-abis, r=RalfJung compiler: Ease off the accelerator on `unsupported_calling_conventions` This is to give us more time to discuss rust-lang#142330 without the ecosystem having an anxiety attack. I have withdrawn `unsupported_calling_conventions` from report-in-deps I believe we should consider this a simple suspension of the decision in rust-lang#141435 to start this process, rather than a reversal. That is, we may continue with linting again. But I believe we are about to get a... reasonable amount of feedback just from currently available information and should allow ourselves time to process it.
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Jun 12, 2025
…cl-and-other-abis, r=RalfJung compiler: Ease off the accelerator on `unsupported_calling_conventions` This is to give us more time to discuss rust-lang#142330 without the ecosystem having an anxiety attack. I have withdrawn `unsupported_calling_conventions` from report-in-deps I believe we should consider this a simple suspension of the decision in rust-lang#141435 to start this process, rather than a reversal. That is, we may continue with linting again. But I believe we are about to get a... reasonable amount of feedback just from currently available information and should allow ourselves time to process it.
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Jun 12, 2025
…cl-and-other-abis, r=RalfJung compiler: Ease off the accelerator on `unsupported_calling_conventions` This is to give us more time to discuss rust-lang#142330 without the ecosystem having an anxiety attack. I have withdrawn `unsupported_calling_conventions` from report-in-deps I believe we should consider this a simple suspension of the decision in rust-lang#141435 to start this process, rather than a reversal. That is, we may continue with linting again. But I believe we are about to get a... reasonable amount of feedback just from currently available information and should allow ourselves time to process it.
bors
added a commit
that referenced
this pull request
Jun 12, 2025
…r-abis, r=RalfJung compiler: Ease off the accelerator on `unsupported_calling_conventions` This is to give us more time to discuss #142330 without the ecosystem having an anxiety attack. I have withdrawn `unsupported_calling_conventions` from report-in-deps I believe we should consider this a simple suspension of the decision in #141435 to start this process, rather than a reversal. That is, we may continue with linting again. But I believe we are about to get a... reasonable amount of feedback just from currently available information and should allow ourselves time to process it.
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Jun 12, 2025
…cl-and-other-abis, r=RalfJung compiler: Ease off the accelerator on `unsupported_calling_conventions` This is to give us more time to discuss rust-lang#142330 without the ecosystem having an anxiety attack. I have withdrawn `unsupported_calling_conventions` from report-in-deps I believe we should consider this a simple suspension of the decision in rust-lang#141435 to start this process, rather than a reversal. That is, we may continue with linting again. But I believe we are about to get a... reasonable amount of feedback just from currently available information and should allow ourselves time to process it.
bors
added a commit
that referenced
this pull request
Jun 13, 2025
…r-abis, r=ChrisDenton,RalfJung compiler: Ease off the accelerator on `unsupported_calling_conventions` This is to give us more time to discuss #142330 without the ecosystem having an anxiety attack. I have withdrawn `unsupported_calling_conventions` from report-in-deps I believe we should consider this a simple suspension of the decision in #141435 to start this process, rather than a reversal. That is, we may continue with linting again. But I believe we are about to get a... reasonable amount of feedback just from currently available information and should allow ourselves time to process it.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds back the
unsupported_calling_conventionslint that was removed in #129935, in order to start the process of dealing with #137018. Specifically, we are going for the plan laid out here:The difference to the status quo is that:
Vectorcall is an unstable ABI so we can just make this a hard error immediately. The others are stable, so we emit the
unsupported_calling_conventionsforward-compat lint. I set up the lint to show up in dependencies via cargo's future-compat report immediately, but we could also make it show up just for the local crate first if that is preferred.try-job: i686-msvc-1
try-job: x86_64-msvc-1
try-job: test-various