syntax: Remove AbiSet, use one Abi #13263
Closed
Conversation
This file contains 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
|
Glad to see this complexity gone. |
bors
added a commit
that referenced
this pull request
Apr 3, 2014
This change removes the AbiSet from the AST, converting all usage to have just one Abi value. The current scheme selects a relevant ABI given a list of ABIs based on the target architecture and how relevant each ABI is to that architecture. Instead of this mildly complicated scheme, only one ABI will be allowed in abi strings, and pseudo-abis will be created for special cases as necessary. For example the "system" abi exists for stdcall on win32 and C on win64. Closes #10049
This change removes the AbiSet from the AST, converting all usage to have just one Abi value. The current scheme selects a relevant ABI given a list of ABIs based on the target architecture and how relevant each ABI is to that architecture. Instead of this mildly complicated scheme, only one ABI will be allowed in abi strings, and pseudo-abis will be created for special cases as necessary. For example the "system" abi exists for stdcall on win32 and C on win64. Closes rust-lang#10049
flip1995
pushed a commit
to flip1995/rust
that referenced
this pull request
Sep 5, 2024
…tri3 move `manual_c_str_literals` to complexity IMO the suggestion to use `c""` literals over a hardcoded `\0` byte string literal has some fairly strong upsides (no need to manually null-terminate it and the compiler checks for intermediary null bytes) that this should just be enabled by default. It's also written slightly conservatively to only emit a warning when we can be reasonably confident that the lint is *actually* applicable (that is, lint on e.g. `b"foo\0".as_ptr()` but not `b"foo\0"`. The latter looks like a c-string but its type is `&[u8; _]`, and if it's used in a context where a byte slice is needed then you have no nice way to convert to it from a `c"foo"` literal of type `&CStr`). changelog: move [`manual_c_str_literals`] to complexity (now warn-by-default)
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 change removes the AbiSet from the AST, converting all usage to have just
one Abi value. The current scheme selects a relevant ABI given a list of ABIs
based on the target architecture and how relevant each ABI is to that
architecture.
Instead of this mildly complicated scheme, only one ABI will be allowed in abi
strings, and pseudo-abis will be created for special cases as necessary. For
example the "system" abi exists for stdcall on win32 and C on win64.
Closes #10049