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 11 pull requests #81733

Closed
wants to merge 31 commits into from

Conversation

Dylan-DPC-zz
Copy link

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.
Change filesearch::get_or_default_sysroot() to check if sysroot is found
using env::args().next() if rustc in argv[0] is a symlink; otherwise, or
if it is not found, use env::current_exe() to imply sysroot. This makes
the rustc binary able to locate Rust libraries in systems using
content-addressable storage (CAS).
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.
We used to ignore `forbid(group)` scenarios completely. This changed
in rust-lang#78864, but that led to a number of regressions (rust-lang#80988, rust-lang#81218).

This PR introduces a future compatibility warning for the case where
a group is forbidden but then an individual lint within that group
is allowed. We now issue a FCW when we see the "allow", but permit
it to take effect.
Per a comment on rust-lang#70516 this changes `eq_ignore_ascii_case` to take the generic parameter `S: AsRef<OsStr>` by value instead of by reference.

This is technically a breaking change to an unstable method. I think the only way it would break is if you called this method with an explicit type parameter, ie `my_os_str.eq_ignore_ascii_case::<str>("foo")` becomes `my_os_str.eq_ignore_ascii_case::<&str>("foo")`.

Besides that, I believe it is overall more flexible since it can now take an owned `OsString` for example.

If this change should be made in some other PR (like rust-lang#80193) then please just close this.
This comes up a lot when bootstrapping.
This extends the `panic_fmt` lint to warn for all cases where the first
argument cannot be interpreted as a format string, as will happen in
Rust 2021.

It suggests to add `"{}", ` to format the message as a string. In the
case of `std::panic!()`, it also suggests the recently stabilized
`std::panic::panic_any()` function as an alternative.

It renames the lint to `non_fmt_panic` to match the lint naming
guidelines.
…gisa

Fix rustc sysroot in systems using CAS

Change filesearch::get_or_default_sysroot() to check if sysroot is found using env::args().next() if rustc in argv[0] is a symlink; otherwise, or if it is not found, use env::current_exe() to imply sysroot. This makes the rustc binary able to locate Rust libraries in systems using content-addressable storage (CAS).
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.
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`
…lint, r=pnkfelix

introduce future-compatibility warning for forbidden lint groups

We used to ignore `forbid(group)` scenarios completely. This changed in rust-lang#78864, but that led to a number of regressions (rust-lang#80988, rust-lang#81218).

This PR introduces a future compatibility warning for the case where a group is forbidden but then an individual lint within that group is allowed. We now issue a FCW when we see the "allow", but permit it to take effect.

r? ``@Mark-Simulacrum``
…1995

Add lint for `panic!(123)` which is not accepted in Rust 2021.

This extends the `panic_fmt` lint to warn for all cases where the first argument cannot be interpreted as a format string, as will happen in Rust 2021.

It suggests to add `"{}",` to format the message as a string. In the case of `std::panic!()`, it also suggests the recently stabilized
`std::panic::panic_any()` function as an alternative.

It renames the lint to `non_fmt_panic` to match the lint naming guidelines.

![image](https://user-images.githubusercontent.com/783247/106520928-675ea680-64d5-11eb-81f7-d8fa48b93a0b.png)

This is part of rust-lang#80162.

r? `@estebank`
Add more information to the error code for 'crate not found'

This comes up a lot when bootstrapping.
Refactor `PrimitiveTypeTable` for Clippy

I removed `PrimitiveTypeTable` and added `PrimTy::ALL` and `PrimTy::from_name` in its place. This allows Clippy to use `PrimTy::from_name` for the `builtin_type_shadow` lint, and a `const` list of primitive types is deleted from Clippy code (the goal). All changes should be a little faster, if anything.
…, 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.
OsStr eq_ignore_ascii_case takes arg by value

Per a comment on rust-lang#70516 this changes `eq_ignore_ascii_case` to take the generic parameter `S: AsRef<OsStr>` by value instead of by reference.

This is technically a breaking change to an unstable method. I think the only way it would break is if you called this method with an explicit type parameter, ie `my_os_str.eq_ignore_ascii_case::<str>("foo")` becomes `my_os_str.eq_ignore_ascii_case::<&str>("foo")`.

Besides that, I believe it is overall more flexible since it can now take an owned `OsString` for example.

If this change should be made in some other PR (like rust-lang#80193) then please just close this.
Move test to be with the others

No functional changes. I just created this test in the wrong place in a past PR. All of the other or-pattern tests are in the `or-patterns` directory.
…mulacrum

Revert stabilizing integer::BITS.

We agreed in the libs meeting just now to revert stablization, since the [breakage](rust-lang#81654) is significant throughout the ecosystem, through `lexical-core`.

cc rust-lang#76904

Fixes rust-lang#81654
@rustbot rustbot added the rollup A PR which is a rollup label Feb 3, 2021
@Dylan-DPC-zz
Copy link
Author

@bors r+ rollup=never p=5

@bors
Copy link
Contributor

bors commented Feb 4, 2021

📌 Commit 6876aba has been approved by Dylan-DPC

@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 4, 2021
@bors
Copy link
Contributor

bors commented Feb 4, 2021

⌛ Testing commit 6876aba with merge b68c730cbe2c5b3343bd4db6445f7bdd1ed48c3e...

@bors
Copy link
Contributor

bors commented Feb 4, 2021

💥 Test timed out

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Feb 4, 2021
@m-ou-se m-ou-se closed this Feb 4, 2021
@rust-log-analyzer
Copy link
Collaborator

A job failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

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-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.