-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Rustup #11929
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
Rustup #11929
Conversation
Stabilize C string literals RFC: https://rust-lang.github.io/rfcs/3348-c-str-literal.html Tracking issue: rust-lang/rust#105723 Documentation PR (reference manual): rust-lang/reference#1423 # Stabilization report Stabilizes C string and raw C string literals (`c"..."` and `cr#"..."#`), which are expressions of type [`&CStr`](https://doc.rust-lang.org/stable/core/ffi/struct.CStr.html). Both new literals require Rust edition 2021 or later. ```rust const HELLO: &core::ffi::CStr = c"Hello, world!"; ``` C strings may contain any byte other than `NUL` (`b'\x00'`), and their in-memory representation is guaranteed to end with `NUL`. ## Implementation Originally implemented by PR rust-lang/rust#108801, which was reverted due to unintentional changes to lexer behavior in Rust editions < 2021. The current implementation landed in PR rust-lang/rust#113476, which restricts C string literals to Rust edition >= 2021. ## Resolutions to open questions from the RFC * Adding C character literals (`c'.'`) of type `c_char` is not part of this feature. * Support for `c"..."` literals does not prevent `c'.'` literals from being added in the future. * C string literals should not be blocked on making `&CStr` a thin pointer. * It's possible to declare constant expressions of type `&'static CStr` in stable Rust (as of v1.59), so C string literals are not adding additional coupling on the internal representation of `CStr`. * The unstable `concat_bytes!` macro should not accept `c"..."` literals. * C strings have two equally valid `&[u8]` representations (with or without terminal `NUL`), so allowing them to be used in `concat_bytes!` would be ambiguous. * Adding a type to represent C strings containing valid UTF-8 is not part of this feature. * Support for a hypothetical `&Utf8CStr` may be explored in the future, should such a type be added to Rust.
Because the variant name in `Level` is `Note`, and the `without_error` suffix is omitted in similar cases like `struct_allow` and `struct_help`.
…bug`. Because the corresponding `Level` is `DelayedBug` and `span_delayed_bug` follows the pattern used everywhere else: `span_err`, `span_warning`, etc.
…r-errors Cleanup error handlers Mostly by making function naming more consistent. More to do after this, but this is enough for one PR. r? compiler-errors
Clippy subtree sync r? `@Manishearth`
@bors try |
@bors delegate=@matthiaskrgr |
✌️ @matthiaskrgr, you can now approve this pull request! If @flip1995 told you to " |
Rustup r? `@xFrednet` changelog: none out of cycle sync to fix integration test failure for the XFAIL integration test, as the `delayed_span_bug` attribute name was updated.
@matthiaskrgr Feel free to merge after you re-updated the |
If that test fails, running all other tests doesn't make sense. This test only takes a few seconds to run. So running it right away will make the pipeline fail faster.
@bors try |
Rustup r? `@xFrednet` changelog: none out of cycle sync to fix integration test failure for the XFAIL integration test, as the `delayed_span_bug` attribute name was updated.
@bors r+ |
☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test |
r? @xFrednet
changelog: none
out of cycle sync to fix integration test failure for the XFAIL integration test, as the
delayed_span_bug
attribute name was updated.