Rollup of 10 pull requests #93009
Merged
Rollup of 10 pull requests #93009
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
Several times, people have seemed unclear on how to respond to some of the policy requirements, particularly those that just state things the target developers must *not* do (e.g. not posting to PRs that break the target). Add a note that such requirements just need acknowledgement, nothing more. Make quoting and responding a "must" rather than an "is encouraged to", since it's easier to review the requirements that way.
The requirement on dependencies was phrased in terms of "host tools", but it was also intended to apply equally to targets that only support cross-compilation. Only the exception (for libraries commonly needed for binaries on the target) was intended to apply to host tools. Reword the requirement to talk about the dependencies required for "compiling, linking,and emitting functional binaries, libraries, or other code for the target", rather than generically in terms of dependencies for rustc/cargo. This doesn't change the net effect of the requirements, since other requirements already stated that the target can't make the Rust toolchain depend on proprietary libraries. However, this should make the requirements clearer.
The requirement for target documentation talks about "running tests", but tier 3 targets often don't support running the full testsuite, and in practice the documentation for how to run an individual binary may be more useful. Change "running tests" to "running binaries, or running tests".
Explain that target-specific documentation should appear in a subdirectory of platform-support, with a link from the target's entry on the platform-support page.
Use "(associated) function" terminology instead of "method". Co-authored-by: Daniel Henry-Mantilla <daniel.henry.mantilla@gmail.com>
This adds the old, pre 90639 `is_implemented` that previously only was true if the implementation of the item was from the given impl block and not from the trait default.
This test checks that `#[rustc_must_implement_one_of]` is gated behind `#![feature(rustc_attrs)]`.
This was originally introduced in rust-lang#10916 as a way to remove all landing pads when performing LTO. However this is no longer necessary today since rustc properly marks all functions and call-sites as nounwind where appropriate. In fact this is incorrect in the presence of `extern "C-unwind"` which must create a landing pad when compiled with `-C panic=abort` so that foreign exceptions are caught and properly turned into aborts.
Faced with a very long word, browsers will let it overflow its box horizontally rather than break it in the middle. We essentially never want that behavior. We would rather break the word and keep it inside its horizontal limits. So we apply a default overflow-wrap: break-word/anywhere to the document as a while. In some contexts we would rather add a horizontal scrollbar (code blocks), or elide the excess text with an ellipsis (sidebar). Those still work as expected.
This version is nice in that it doesn't need to worry about zeros, and thus doesn't have any error cases.
Now that we have (unstable) methods for this, we don't need the bespoke trait methods for it in the `bignum` implementation.
…unctions in metadata.rs.
…ft-updates, r=Mark-Simulacrum Clarifications in the target tier policy We've added several targets since the introduction of the target tier policy. Based on experiences of those adding such targets, and discussions around such additions, clarify the target tier policy to make it easier to follow and work with. None of these changes substantively change the requirements on targets. (In some cases the changes do direct target submitters to follow specific process requirements for the addition of a target, such as how to respond to requirements, where to put target-specific documentation, or what should appear in that documentation. Those changes are procedural in nature and document the procedures we already direct people to follow.) - Clarify how to quote and respond to the target tier policy requirements. Several times, people have seemed unclear on how to respond to some of the policy requirements, particularly those that just state things the target developers must *not* do (e.g. not posting to PRs that break the target). Add a note that such requirements just need acknowledgement, nothing more. - Clarify dependency requirements in the face of cross-compilation. I previously phrased this confusingly in terms of "host tools", since that is the case where an exception applies (allowing proprietary target libraries commonly used by binaries for the target). Rephrase it to apply equally to cross-compilation. This doesn't change the net effect of the requirements, since other requirements already cover the dependencies of the Rust toolchain. - Clarify documentation about running binaries. The requirement for target documentation talks about "running tests", but tier 3 targets often don't support running the full testsuite, and in practice the documentation for how to run an individual binary may be more useful. Change "running tests" to "running binaries, or running tests". - Explain where to place target-specific documentation (a subdirectory of platform-support, with a link from the platform-support entry for the target). - Add a template for target-specific documentation.
…ne_of_attr, r=Aaron1011
Implement `#[rustc_must_implement_one_of]` attribute
This PR adds a new attribute — `#[rustc_must_implement_one_of]` that allows changing the "minimal complete definition" of a trait. It's similar to GHC's minimal `{-# MINIMAL #-}` pragma, though `#[rustc_must_implement_one_of]` is weaker atm.
Such attribute was long wanted. It can be, for example, used in `Read` trait to make transitions to recently added `read_buf` easier:
```rust
#[rustc_must_implement_one_of(read, read_buf)]
pub trait Read {
fn read(&mut self, buf: &mut [u8]) -> Result<usize> {
let mut buf = ReadBuf::new(buf);
self.read_buf(&mut buf)?;
Ok(buf.filled_len())
}
fn read_buf(&mut self, buf: &mut ReadBuf<'_>) -> Result<()> {
default_read_buf(|b| self.read(b), buf)
}
}
impl Read for Ty0 {}
//^ This will fail to compile even though all `Read` methods have default implementations
// Both of these will compile just fine
impl Read for Ty1 {
fn read(&mut self, buf: &mut [u8]) -> Result<usize> { /* ... */ }
}
impl Read for Ty2 {
fn read_buf(&mut self, buf: &mut ReadBuf<'_>) -> Result<()> { /* ... */ }
}
```
For now, this is implemented as an internal attribute to start experimenting on the design of this feature. In the future we may want to extend it:
- Allow arbitrary requirements like `a | (b & c)`
- Allow multiple requirements like
- ```rust
#[rustc_must_implement_one_of(a, b)]
#[rustc_must_implement_one_of(c, d)]
```
- Make it appear in rustdoc documentation
- Change the syntax?
- Etc
Eventually, we should make an RFC and make this (or rather similar) attribute public.
---
I'm fairly new to compiler development and not at all sure if the implementation makes sense, but at least it passes tests :)
…-debuginfo, r=petrochenkov
rustc_codegen_llvm: Remove (almost) unused span parameter from many functions in metadata.rs
Many functions and intermediate data structures in `rustc_codegen_llvm/src/debuginfo/metadata.rs` take a span parameter that is only used for providing a span to a `span_bug!()` invocation, in case the debuginfo typemap gets corrupted. However, this span does not really convey useful information as it just points to the first point a type is used -- and half of the time is initialized to `DUMMY_SP`.
This PR removes this span parameter from the module.
It also removes the following unused parameters from `composite_type_metadata()` together with an outdated comment:
```rust
// Ignore source location information as long as it
// can't be reconstructed for non-local crates.
_file_metadata: &'ll DIFile,
_definition_span: Span,
```
…gisa Correct minor typos in some long error code explanations Just a little nitpick to improve the long explanations of the error codes. 😊
Enable wrapping words by default Faced with a very long word, browsers will let it overflow its box horizontally rather than break it in the middle. We essentially never want that behavior. We would rather break the word and keep it inside its horizontal limits. So we apply a default overflow-wrap: break-word/anywhere to the document as a while. In some contexts we would rather add a horizontal scrollbar (code blocks), or elide the excess text with an ellipsis (sidebar). Those still work as expected. Fixes rust-lang#92771 [Some related discussion](https://rust-lang.zulipchat.com/#narrow/stream/266220-rustdoc/topic/wrap.20.2F.20overflow.20.2F.20scroll) and a related issue: rust-lang#92421. Demo: https://rustdoc.crud.net/jsha/overflow-wrap/std/iter/trait.Iterator.html#method.try_find r? ``@GuillaumeGomez``
…, r=Mark-Simulacrum Rename environment variable for overriding rustc version
…k-Simulacrum Remove LLVMRustMarkAllFunctionsNounwind This was originally introduced in rust-lang#10916 as a way to remove all landing pads when performing LTO. However this is no longer necessary today since rustc properly marks all functions and call-sites as nounwind where appropriate. In fact this is incorrect in the presence of `extern "C-unwind"` which must create a landing pad when compiled with `-C panic=abort` so that foreign exceptions are caught and properly turned into aborts.
…aumeGomez rustdoc: Remove `collect` in `html::markdown::parse`
Add `log2` and `log10` to `NonZeroU*` This version is nice in that it doesn't need to worry about zeros, and thus doesn't have any error cases. cc `int_log` tracking issue rust-lang#70887 (I didn't add them to `NonZeroI*` despite it being on `i*` since allowing negatives bring back the error cases again.)
…mulacrum
Use `carrying_{mul|add}` in `num::bignum`
Now that we have (unstable) methods for this, we don't need the bespoke trait methods for it in the `bignum` implementation.
cc rust-lang#85532
rustbot
added
T-compiler
|
@bors r+ rollup=never p=10 |
|
📌 Commit 68d47de has been approved by |
bors
added
the
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
This was referenced Jan 18, 2022
|
Finished benchmarking commit (86b1581): comparison url. Summary: This benchmark run did not return any relevant changes. If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression |
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:
#[rustc_must_implement_one_of]attribute #92164 (Implement#[rustc_must_implement_one_of]attribute)collectinhtml::markdown::parse#92936 (rustdoc: Removecollectinhtml::markdown::parse)log2andlog10toNonZeroU*#92956 (Addlog2andlog10toNonZeroU*)carrying_{mul|add}innum::bignum#92960 (Usecarrying_{mul|add}innum::bignum)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup