Rollup of 14 pull requests #81780
Closed
Rollup of 14 pull requests #81780
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
Newly added targets aren't available on the stage0 toolchain.
This makes it clear that it's an implementation detail of `display_fn` and shouldn't be used elsewhere, and it enforces in the compiler that no one else can use it.
As described in rust-lang#68574, the currently exposed API for symlinks is, in fact, a thin wrapper around the corresponding syscall, and not suitable for public usage. The reason is that the 2nd param in the call is expected to be a handle of a "preopened directory" (a WASI concept for exposing dirs), and the only way to retrieve such handle right now is by tinkering with a private `__wasilibc_find_relpath` API, which is an implementation detail and definitely not something we want users to call directly. Making matters worse, the semantics of this param aren't obvious from its name (`fd`), and easy to misinterpret, resulting in people trying to pass a handle of the target file itself (as in vitiral/path_abs#50), which doesn't work as expected. I did a codesearch among open-source repos, and the usage above is so far the only usage of this API at all, but we should fix it before more people start using it incorrectly. While this is technically a breaking API change, I believe it's a justified one, as 1) it's OS-specific and 2) there was strictly no way to correctly use the previous form of the API, and if someone does use it, they're likely doing it wrong like in the example above. The new API does not lead to the same confusion, as it mirrors `std::os::unix::fs::symlink` and `std::os::windows::fs::symlink_{file,dir}` variants by accepting source/target paths. Fixes rust-lang#68574.
This comes up a lot when bootstrapping.
add test to ensure object-safety This allows for runtime polymorphic allocators
Also changed a couple of comments from "intra-doc-links" to "intra-doc links" (my understanding is that "intra-doc links" is the standard way to refer to them).
Previously, this was omitted because it could be misleading, but the functionality seems too useful not to include.
…-trait-paths, r=jackh726 Generic associated types in trait paths This is the second part of rust-lang#78978 This should fix: Fixes rust-lang#67510 Fixes rust-lang#68648 Fixes rust-lang#68649 Fixes rust-lang#68650 Fixes rust-lang#68652 Fixes rust-lang#74684 Fixes rust-lang#76535 Fixes rust-lang#79422 Fixes rust-lang#80433 and implement the remaining functionality needed for rust-lang#44265 r? `@matthewjasper`
relax adt unsizing requirements Changes unsizing of structs in case the last struct field shares generic params with other adt fields which do not change. This change is currently insta stable and changes the language, so it at least requires a lang fcp. I feel like the current state is fairly unintuitive. An example for what's now allowed would be https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6dd331d23f5c9ffc8c978175aae2e967 ```rust struct A<T, U: ?Sized>(T, B<T, U>); // previously ERR // struct A<T, U: ?Sized>(T, B<[u32; 1], U>); // ok struct B<T, U: ?Sized>(T, U); fn main() { let x = A([0; 1], B([0; 1], [0; 1])); let y: &A<[u32; 1], [u32]> = &x; assert_eq!(y.1.1.len(), 1); } ```
…etrochenkov Handle `Span`s for byte and raw strings and add more detail CC rust-lang#81208.
rustdoc-json: Fix has_body Previously, `has_body` was always true. Now propagate the type of the method to set it correctly. Relies on rust-lang#81287, that will need to be merged first.
Make remote-test-server easier to use with new targets While testing rust-lang#81455 I encountered 2 issues with `remote-test-server`: - It is built with the stage 0 toolchain, which does not support a newly added target. - It overwrites `LD_LIBRARY_PATH` instead of appending to it, which prevents the use of a custom sysroot for target libraries.
…ell, r=jyn514 rustdoc: Move `display_fn` struct inside `display_fn` This makes it clear that it's an implementation detail of `display_fn` and shouldn't be used elsewhere, and it enforces in the compiler that no one else can use it. r? ```@GuillaumeGomez```
Remove struct_type from union output Also bumps the format number and adds a test Rationale: It's illegal to have unions of the form `union Union(i32, f32);`, or `union Union;`. The struct_type field was recently removed from the rustdoc Union AST, at which time this field was changed to always just read "union". It makes sense to completely remove it, as it provides no information.
Expose correct symlink API on WASI As described in rust-lang#68574, the currently exposed API for symlinks is, in fact, a thin wrapper around the corresponding syscall, and not suitable for public usage. The reason is that the 2nd param in the call is expected to be a handle of a "preopened directory" (a WASI concept for exposing dirs), and the only way to retrieve such handle right now is by tinkering with a private `__wasilibc_find_relpath` API, which is an implementation detail and definitely not something we want users to call directly. Making matters worse, the semantics of this param aren't obvious from its name (`fd`), and easy to misinterpret, resulting in people trying to pass a handle of the target file itself (as in vitiral/path_abs#50), which doesn't work as expected. I did a [codesearch among open-source repos](https://sourcegraph.com/search?q=std%3A%3Aos%3A%3Awasi%3A%3Afs%3A%3Asymlink&patternType=literal), and the usage above is so far the only usage of this API at all, but we should fix it before more people start using it incorrectly. While this is technically a breaking API change, I believe it's a justified one, as 1) it's OS-specific and 2) there was strictly no way to correctly use the previous form of the API, and if someone does use it, they're likely doing it wrong like in the example above. The new API does not lead to the same confusion, as it mirrors `std::os::unix::fs::symlink` and `std::os::windows::fs::symlink_{file,dir}` variants by accepting source/target paths. Fixes rust-lang#68574. r? `@alexcrichton`
Add more information to the error code for 'crate not found' This comes up a lot when bootstrapping.
…, r=oli-obk Add additional bitset benchmarks Add additional benchmarks for operations in bitset, I realize that it was a bit lacking when I intended to optimize it earlier, so I was hoping to put some in so I can verify my work later.
…Amanieu Make `Allocator` object-safe This allows rust-lang/wg-allocators#83: polymorphic allocators
…uillaumeGomez Cleanup rustdoc pass descriptions a bit Also changed a couple of comments from "intra-doc-links" to "intra-doc links" (my understanding is that "intra-doc links" is the standard way to refer to them).
…rk-Simulacrum Update LayoutError/LayoutErr stability attributes `LayoutError` ended up not making it into 1.49.0, updating the stability attributes to reflect that. I also pushed `LayoutErr` deprecation back a release to allow 2 releases before the deprecation comes into effect. This change should be backported to beta.
… r=oli-obk Indicate change in RSS from start to end of pass in time-passes output Previously, this was omitted because it could be misleading, but the functionality seems too useful not to include. r? `@oli-obk`
|
@bors r+ p=14 rollup=never |
|
📌 Commit 64f8920 has been approved by |
bors
added
the
S-waiting-on-bors
|
Closing in favor of #81784 |
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:
Spans for byte and raw strings and add more detail #81307 (HandleSpans for byte and raw strings and add more detail )display_fnstruct insidedisplay_fn#81497 (rustdoc: Movedisplay_fnstruct insidedisplay_fn)Allocatorobject-safe #81730 (MakeAllocatorobject-safe)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup