Skip to content
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

Rollup of 14 pull requests #81780

Closed
wants to merge 39 commits into from
Closed

Conversation

m-ou-se
Copy link
Member

@m-ou-se m-ou-se commented Feb 5, 2021

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

Amanieu d'Antras and others added 30 commits January 27, 2021 23:08
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`
@rustbot rustbot added the rollup A PR which is a rollup label Feb 5, 2021
@m-ou-se
Copy link
Member Author

m-ou-se commented Feb 5, 2021

@bors r+ p=14 rollup=never

@bors
Copy link
Contributor

bors commented Feb 5, 2021

📌 Commit 64f8920 has been approved by m-ou-se

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Feb 5, 2021
@m-ou-se
Copy link
Member Author

m-ou-se commented Feb 5, 2021

Closing in favor of #81784

@m-ou-se m-ou-se closed this Feb 5, 2021
@m-ou-se m-ou-se deleted the rollup-2gv4ou5 branch February 5, 2021 11:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.