Rollup of 5 pull requests #97476
Merged
Rollup of 5 pull requests #97476
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
With `ignore (rust)` rather than `ignore (pseudo-Rust)` my editor highlights the code in the block, which is nicer. Signed-off-by: David Wood <david.wood@huawei.com>
Adds a new `fluent_messages` macro which performs compile-time
validation of the compiler's Fluent resources (i.e. that the resources
parse and don't multiply define the same messages) and generates
constants that make using those messages in diagnostics more ergonomic.
For example, given the following invocation of the macro..
```ignore (rust)
fluent_messages! {
typeck => "./typeck.ftl",
}
```
..where `typeck.ftl` has the following contents..
```fluent
typeck-field-multiply-specified-in-initializer =
field `{$ident}` specified more than once
.label = used more than once
.label-previous-use = first use of `{$ident}`
```
...then the macro parse the Fluent resource, emitting a diagnostic if it
fails to do so, and will generate the following code:
```ignore (rust)
pub static DEFAULT_LOCALE_RESOURCES: &'static [&'static str] = &[
include_str!("./typeck.ftl"),
];
mod fluent_generated {
mod typeck {
pub const field_multiply_specified_in_initializer: DiagnosticMessage =
DiagnosticMessage::fluent("typeck-field-multiply-specified-in-initializer");
pub const field_multiply_specified_in_initializer_label_previous_use: DiagnosticMessage =
DiagnosticMessage::fluent_attr(
"typeck-field-multiply-specified-in-initializer",
"previous-use-label"
);
}
}
```
When emitting a diagnostic, the generated constants can be used as
follows:
```ignore (rust)
let mut err = sess.struct_span_err(
span,
fluent::typeck::field_multiply_specified_in_initializer
);
err.span_default_label(span);
err.span_label(
previous_use_span,
fluent::typeck::field_multiply_specified_in_initializer_label_previous_use
);
err.emit();
```
Signed-off-by: David Wood <david.wood@huawei.com>
Use new typed Fluent identifiers for the "missing type parameters" diagnostic in the typeck crate which was manually creating `DiagnosticMessage`s previously. Signed-off-by: David Wood <david.wood@huawei.com>
The methods in `OsStrExt` consume and return `&[u8]` and don't perform any UTF-8 checks.
This is the only place it's used, so there's no need for it to be public in another module. In general, `dist` shouldn't ever touch shell scripts.
…tabilization, r=yaahc Partially stabilize `(const_)slice_ptr_len` feature by stabilizing `NonNull::len` This PR partially stabilizes features `const_slice_ptr_len` and `slice_ptr_len` by only stabilizing `NonNull::len`. This partial stabilization is tracked under features `slice_ptr_len_nonnull` and `const_slice_ptr_len_nonnull`, for which this PR can serve as the tracking issue. To summarize the discussion from rust-lang#71146 leading up to this partial stabilization request: It's currently a bit footgunny to obtain the length of a raw slice pointer, stabilization of `NonNull:len` will help with removing these footguns. Some example footguns are: ```rust /// # Safety /// The caller must ensure that `ptr`: /// 1. does not point to memory that was previously allocated but is now deallocated; /// 2. is within the bounds of a single allocated object; /// 3. does not to point to a slice for which the length exceeds `isize::MAX` bytes; /// 4. points to a properly aligned address; /// 5. does not point to uninitialized memory; /// 6. does not point to a mutably borrowed memory location. pub unsafe fn ptr_len<T>(ptr: core::ptr::NonNull<[T]>) -> usize { (&*ptr.as_ptr()).len() } ``` A slightly less complicated version (but still more complicated than it needs to be): ```rust /// # Safety /// The caller must ensure that the start of `ptr`: /// 1. does not point to memory that was previously allocated but is now deallocated; /// 2. must be within the bounds of a single allocated object. pub unsafe fn ptr_len<T>(ptr: NonNull<[T]>) -> usize { (&*(ptr.as_ptr() as *const [()])).len() } ``` This PR does not stabilize `<*const [T]>::len` and `<*mut [T]>::len` because the tracking issue rust-lang#71146 list a potential blocker for these methods, but this blocker [does not apply](rust-lang#71146 (comment)) to `NonNull::len`. We should probably also ping the [Constant Evaluation WG](https://github.com/rust-lang/const-eval) since this PR includes a `#[rustc_allow_const_fn_unstable(const_slice_ptr_len)]`. My instinct here is that this will probably be okay because the pointer is not actually dereferenced and `len()` does not touch the address component of the pointer, but would be best to double check :) One potential down-side was raised that stabilizing `NonNull::len` could lead to encouragement of coding patterns like: ``` pub fn ptr_len<T>(ptr: *mut [T]) -> usize { NonNull::new(ptr).unwrap().len() } ``` which unnecessarily assert non-nullness. However, these are much less of a footgun than the above examples and this should be resolved when `slice_ptr_len` fully stabilizes eventually.
…olnay Implement `Hash` for `core::alloc::Layout` This was brought up on [reddit](https://www.reddit.com/r/rust/comments/uoypui/the_standard_library_types_are_good_except_when/), and I don't see why Layout shouldn't implement `Hash`. Feel free to comment if I am wrong though :)
…mpile-time-validation, r=oli-obk
macros: introduce `fluent_messages` macro
Adds a new `fluent_messages` macro which performs compile-time validation of the compiler's Fluent resources (i.e. that the resources parse and don't multiply define the same messages) and generates constants that make using those messages in diagnostics more ergonomic.
For example, given the following invocation of the macro..
```rust
fluent_messages! {
typeck => "./typeck.ftl",
}
```
..where `typeck.ftl` has the following contents..
```fluent
typeck-field-multiply-specified-in-initializer =
field `{$ident}` specified more than once
.label = used more than once
.label-previous-use = first use of `{$ident}`
```
...then the macro parse the Fluent resource, emitting a diagnostic if it fails to do so...
```text
error: could not parse Fluent resource
--> $DIR/test.rs:35:28
|
LL | missing_message => "./missing-message.ftl",
| ^^^^^^^^^^^^^^^^^^^^^^^
|
= help: see additional errors emitted
error: expected a message field for "missing-message"
--> ./missing-message.ftl:1:1
|
1 | missing-message =
| ^^^^^^^^^^^^^^^^^^
|
```
...or generating the following code if it succeeds:
```rust
pub static DEFAULT_LOCALE_RESOURCES: &'static [&'static str] = &[
include_str!("./typeck.ftl"),
];
mod fluent_generated {
mod typeck {
pub const field_multiply_specified_in_initializer: DiagnosticMessage =
DiagnosticMessage::fluent("typeck-field-multiply-specified-in-initializer");
pub const field_multiply_specified_in_initializer_label_previous_use: DiagnosticMessage =
DiagnosticMessage::fluent_attr(
"typeck-field-multiply-specified-in-initializer",
"previous-use-label"
);
}
}
```
When emitting a diagnostic, the generated constants can be used as follows:
```rust
let mut err = sess.struct_span_err(
span,
fluent::typeck::field_multiply_specified_in_initializer
);
err.span_label(
span,
fluent::typeck::field_multiply_specified_in_initializer_label
);
err.span_label(
previous_use_span,
fluent::typeck::field_multiply_specified_in_initializer_label_previous_use
);
err.emit();
```
I'd like to reduce the verbosity of referring to labels/notes/helps with this scheme (though it wasn't much better before), but I'll leave that for a follow-up.
r? `@oli-obk`
cc `@pvdrz` `@compiler-errors`
…lett docs: Don't imply that OsStr on Unix is always UTF-8 The methods in `OsStrExt` consume and return `&[u8]` and don't perform any UTF-8 checks.
…Simulacrum [bootstrap] Move `sanitize_sh` from `dist` to `install` This is the only place it's used, so there's no need for it to be public in another module. In general, `dist` shouldn't ever touch shell scripts.
rustbot
added
T-compiler
|
@bors r+ rollup=never p=5 |
|
📌 Commit 5badc29 has been approved by |
bors
added
the
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
This was referenced May 28, 2022
|
Finished benchmarking commit (19abca1): comparison url. Instruction count
Max RSS (memory usage)Results
CyclesResults
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression Footnotes |
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.
Successful merges:
(const_)slice_ptr_lenfeature by stabilizingNonNull::len#94640 (Partially stabilize(const_)slice_ptr_lenfeature by stabilizingNonNull::len)Hashforcore::alloc::Layout#97034 (ImplementHashforcore::alloc::Layout)fluent_messagesmacro #97327 (macros: introducefluent_messagesmacro )sanitize_shfromdisttoinstall#97466 ([bootstrap] Movesanitize_shfromdisttoinstall)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup