bors [Tue, 25 Oct 2022 04:57:51 +0000 (04:57 +0000)]
Auto merge of #102988 - dpaoliello:inlinerawdylib, r=dpaoliello
Support raw-dylib functions being used inside inlined functions
Fixes #102714
Issue Details:
When generating the import library for `raw-dylib` symbols, we currently only use the functions and variables declared within the current crate. This works fine if all crates are static libraries or `rlib`s as the generated import library will be contained in the static library or `rlib` itself, but if a dependency is a dynamic library AND the use of a `raw-dylib` function or variable is inlined or part of a generic instantiation then the current crate won't see its dependency's import library and so linking will fail.
Fix Details:
Instead, when we generate the import library for a `dylib` or `bin` crate, we will now generate it for the symbols both for the current crate and all upstream crates. We do this in two steps so that the import library for the current crate is passed into the linker first, thus it is preferred if there are any ambiguous symbols.
bors [Tue, 25 Oct 2022 02:16:57 +0000 (02:16 +0000)]
Auto merge of #103502 - JohnTitor:rollup-o6mhyzq, r=JohnTitor
Rollup of 11 pull requests
Successful merges:
- #103333 (Fix assertion failed for break_last_token and trailing token)
- #103350 (Change terminology for assoc method suggestions when they are not called)
- #103382 (Don't ICE when reporting borrowck errors involving regions from `anonymous_lifetime_in_impl_trait`)
- #103409 (Delay span bug when we can't map lifetimes back in `collect_trait_impl_trait_tys`)
- #103410 (-Z docs: Add link to unstable book)
- #103462 (rustdoc: remove no-op CSS `.source pre.rust { white-space: pre }`)
- #103465 (E0210 explanation: remove redundant sentence)
- #103486 (Use functions in highlight-colors rustdoc GUI test)
- #103493 (rustdoc: remove unused `.sidebar-logo` DOM on source pages)
- #103494 (rustdoc: remove redundant CSS `a.test-arrow:hover`)
- #103495 (rustdoc: Use `unix_sigpipe` instead of `rustc_driver::set_sigpipe_handler`)
In 4b402dbe690dd00f567542ca9e41042826a168b5, when this rule was added, it was overriding a rule that made all links in docblock get an underline when hovered. This became redundant when, after reordering the rules, 7585632052298f9c84cc12ac5afcb23786ae1d3d changed the pro-underline rule to exclude the test-arrow link anyway.
Yuki Okushi [Mon, 24 Oct 2022 23:01:28 +0000 (08:01 +0900)]
Rollup merge of #103409 - compiler-errors:rpitit-signature-mismatch, r=lcnr
Delay span bug when we can't map lifetimes back in `collect_trait_impl_trait_tys`
When a lifetime is late-bound in a trait signature, but early-bound in an impl signature, we already emit an error -- however, we also ICE in `collect_trait_impl_trait_tys`, so just delay a bug here.
Yuki Okushi [Mon, 24 Oct 2022 23:01:28 +0000 (08:01 +0900)]
Rollup merge of #103382 - compiler-errors:anon-apit-lt-region-ice, r=cjgillot
Don't ICE when reporting borrowck errors involving regions from `anonymous_lifetime_in_impl_trait`
The issue here is that when we have:
```
trait Trait<'a> { .. }
fn foo(arg: impl Trait) { .. }
```
The anonymous lifetime `'_` that we generate for `arg: impl Trait` doesn't end up in the argument type (which is a param) but in a where-clause of the function, in a predicate whose self type is that param ty.
In 4b402dbe690dd00f567542ca9e41042826a168b5, when this rule was added, it
was overriding a rule that made all links in docblock get an underline when
hovered. This became redundant when, after reordering the rules, 7585632052298f9c84cc12ac5afcb23786ae1d3d changed the pro-underline rule to
exclude the test-arrow link anyway.
bors [Mon, 24 Oct 2022 13:35:48 +0000 (13:35 +0000)]
Auto merge of #94063 - Aaron1011:pretty-print-rental, r=lcnr
Only apply `ProceduralMasquerade` hack to older versions of `rental`
The latest version of `rental` (v0.5.6) contains a fix that allows it to
compile without relying on the pretty-print back-compat hack.
Hopefully, there are no longer any crates relying on the affected
versions of the (much less popular) `procedural-masquerade` crate. This
should allow us to target the pretty-print back-compat hack specifically
to older versions of `rental`, and specifically mention upgrading to
`rental` v0.5.6 in the lint message.
bors [Mon, 24 Oct 2022 10:54:40 +0000 (10:54 +0000)]
Auto merge of #103471 - JohnTitor:rollup-tfmy6ab, r=JohnTitor
Rollup of 7 pull requests
Successful merges:
- #99578 (Remove redundant lifetime bound from `impl Borrow for Cow`)
- #99939 (Sort tests at compile time, not at startup)
- #102271 (Stabilize `duration_checked_float`)
- #102766 (Don't link to `libresolv` in libstd on Darwin)
- #103277 (Update libstd's libc to 0.2.135 (to make `libstd` no longer pull in `libiconv.dylib` on Darwin))
- #103437 (Sync rustc_codegen_cranelift)
- #103466 (Fix grammar in docs for std::io::Read)
Yuki Okushi [Mon, 24 Oct 2022 10:32:29 +0000 (19:32 +0900)]
Rollup merge of #103466 - jruderman:patch-2, r=Dylan-DPC
Fix grammar in docs for std::io::Read
Two independent clauses were incorrectly joined by a bare comma. The simplest fix would be to switch to a semicolon, but I think it's slightly better to keep the comma and use the coordinating conjunction "so".
Yuki Okushi [Mon, 24 Oct 2022 10:32:27 +0000 (19:32 +0900)]
Rollup merge of #103277 - thomcc:bump-libc-135, r=Mark-Simulacrum
Update libstd's libc to 0.2.135 (to make `libstd` no longer pull in `libiconv.dylib` on Darwin)
This is to pull in https://github.com/rust-lang/libc/pull/2944.
It's related to https://github.com/rust-lang/rust/pull/102766, in that they both remove unused dylibs from libstd on Darwin platforms. As a result, I'm marking this as relnotes since everybody agreed it was good to add it to the other as well. (The note should be about no longer linking against libiconv -- the libc update is irrelevant).
Yuki Okushi [Mon, 24 Oct 2022 10:32:27 +0000 (19:32 +0900)]
Rollup merge of #102766 - thomcc:remove-resolv, r=Mark-Simulacrum
Don't link to `libresolv` in libstd on Darwin
Currently we link `libresolv` into every Rust program on apple targets despite never using it (as of https://github.com/rust-lang/rust/pull/44965). I had thought we needed this for `getaddrinfo` or something, but we do not / cannot safely use it.
I'd like to fix this for `libiconv` too (the other library we pull in. that's harder since it's coming in through `libc`, which is https://github.com/rust-lang/libc/pull/2944)).
---
This may warrant release notes. I'm not sure but I've added the flag regardless -- It's a change to the list of dylibs every Rust program pulls in, so it's worth mentioning.
It's pretty unlikely anybody was relying on this being pulled in, and `std` does not guarantee that it will link (and thus transitively provide access to) any particular system library -- anybody relying on that behavior would already be broken when dynamically linking std. That is, there's an outside chance something will fail to link on macOS and iOS because it was accidentally relying on our unnecessary dependency.
(If that *does* happen, that project could be easily fixed by linking libresolv explicitly on those platforms, probably via `#[link(name = "resolv")] extern {}`,` -Crustc-link-lib=resolv`, `println!("cargo:rustc-link-lib=resolv")`, or one of several places in `.config/cargo.toml`)
---
I'm also going to preemptively add the nomination for discussing this in the libs meeting. Basically: Do we care about programs that assume we will bring libraries in that we do not use. `libresolv` and `libiconv` on macOS/iOS are in this camp (`libresolv` because we used to use it, and `libiconv` because the `libc` crate was unintentionally(?) pulling it in to every Rust program).
I'd like to remove them both, but this may cause link issues programs that are relying on `std` to depend on them transitively. (Relying on std for this does not work in all build configurations, so this seems very fragile, and like a use case we should not support).
More generally, IMO we should not guarantee the specific set of system-provided libraries we use (beyond what is implied by an OS version requirement), which means we'd be free to remove this cruft.
Yuki Okushi [Mon, 24 Oct 2022 10:32:26 +0000 (19:32 +0900)]
Rollup merge of #102271 - lopopolo:lopopolo/stabilize-duration-try-from-secs-float, r=dtolnay
Stabilize `duration_checked_float`
## Stabilization Report
This stabilization report is for a stabilization of `duration_checked_float`, tracking issue: https://github.com/rust-lang/rust/issues/83400.
### Implementation History
- https://github.com/rust-lang/rust/pull/82179
- https://github.com/rust-lang/rust/pull/90247
- https://github.com/rust-lang/rust/pull/96051
- Changed error type to `FromFloatSecsError` in https://github.com/rust-lang/rust/pull/90247
- https://github.com/rust-lang/rust/pull/96051 changes the rounding mode to round-to-nearest instead of truncate.
## API Summary
This stabilization report proposes the following API to be stabilized in `core`, along with their re-exports in `std`:
impl core::fmt::Display for TryFromFloatSecsError { ... }
impl core::error::Error for TryFromFloatSecsError { ... }
```
These functions are made const unstable under `duration_consts_float`, tracking issue #72440.
There is an open question in the tracking issue around what the error type should be called which I was hoping to resolve in the context of an FCP.
In this stabilization PR, I have altered the name of the error type to `TryFromFloatSecsError`. In my opinion, the error type shares the name of the method (adjusted to accommodate both types of floats), which is consistent with other error types in `core`, `alloc` and `std` like `TryReserveError` and `TryFromIntError`.
## Experience Report
Code such as this is ready to be converted to a checked API to ensure it is panic free:
```rust
impl Time {
pub fn checked_add_f64(&self, seconds: f64) -> Result<Self, TimeError> {
// Fail safely during `f64` conversion to duration
if seconds.is_nan() || seconds.is_infinite() {
return Err(TzOutOfRangeError::new().into());
}
Yuki Okushi [Mon, 24 Oct 2022 10:32:25 +0000 (19:32 +0900)]
Rollup merge of #99939 - saethlin:pre-sort-tests, r=thomcc,jackh726
Sort tests at compile time, not at startup
Recently, another Miri user was trying to run `cargo miri test` on the crate `iced-x86` with `--features=code_asm,mvex`. This configuration has a startup time of ~18 minutes. That's ~18 minutes before any tests even start to run. The fact that this crate has over 26,000 tests and Miri is slow makes a lot of code which is otherwise a bit sloppy but fine into a huge runtime issue.
Sorting the tests when the test harness is created instead of at startup time knocks just under 4 minutes out of those ~18 minutes. I have ways to remove most of the rest of the startup time, but this change requires coordinating changes of both the compiler and libtest, so I'm sending it separately.
(except for doctests, because there is no compile-time harness)
Yuki Okushi [Mon, 24 Oct 2022 10:32:24 +0000 (19:32 +0900)]
Rollup merge of #99578 - steffahn:remove_redundant_bound, r=thomcc
Remove redundant lifetime bound from `impl Borrow for Cow`
The lifetime bound `B::Owned: 'a` is redundant and doesn't make a difference,
because `Cow<'a, B>` comes with an implicit `B: 'a`, and associated types
will outlive lifetimes outlived by the `Self` type (and all the trait's
generic parameters, of which there are none in this case), so the implicit `B: 'a`
implies `B::Owned: 'a` anyway.
The explicit lifetime bound here does however [end up in documentation](https://doc.rust-lang.org/std/borrow/enum.Cow.html#impl-Borrow%3CB%3E),
and that's confusing in my opinion, so let's remove it ^^
_(Documentation right now, compare to `AsRef`, too:)_
bors [Mon, 24 Oct 2022 04:14:46 +0000 (04:14 +0000)]
Auto merge of #100848 - xfix:use-metadata-for-slice-len, r=thomcc
Use ptr::metadata in <[T]>::len implementation
This avoids duplication of ptr::metadata code.
I believe this is acceptable as the previous approach essentially duplicated `ptr::metadata` because back then `rustc_allow_const_fn_unstable` annotation did not exist.
I would like somebody to ping `@rust-lang/wg-const-eval` as the documentation says:
> Always ping `@rust-lang/wg-const-eval` if you are adding more rustc_allow_const_fn_unstable attributes to any const fn.
bors [Mon, 24 Oct 2022 00:29:51 +0000 (00:29 +0000)]
Auto merge of #103452 - notriddle:rollup-peewevm, r=notriddle
Rollup of 11 pull requests
Successful merges:
- #100462 (Clarify `array::from_fn` documentation)
- #101644 (Document surprising and dangerous fs::Permissions behaviour on Unix)
- #103005 (kmc-solid: Handle errors returned by `SOLID_FS_ReadDir`)
- #103140 (Add diagnostic for calling a function with the same name with unresolved Macro)
- #103254 (rustdoc: do not filter out cross-crate `Self: Sized` bounds)
- #103347 (bootstrap: also create rustc-src component in sysroot)
- #103402 (Fix wrapped valid-range handling in ty_find_init_error)
- #103414 (Pretty print lifetimes captured by RPIT)
- #103424 (rustdoc: remove no-op CSS `.code-header { border-bottom: none }`)
- #103434 (Use functions for jump-to-def-background rustdoc GUI test)
- #103447 (`MaybeUninit`: use `assume_init_drop()` in the partially initialized array example)
Michael Howell [Sun, 23 Oct 2022 21:48:17 +0000 (14:48 -0700)]
Rollup merge of #103402 - joshtriplett:niche-wrap-fix, r=oli-obk
Fix wrapped valid-range handling in ty_find_init_error
Rust's niche handling allows for wrapping valid ranges with end < start;
for instance, a valid range with start=43 and end=41 means a niche of
42. Most places in the compiler handle this correctly, but
`ty_find_init_error` assumed that `lo > 0` means the type cannot contain a
zero.
Michael Howell [Sun, 23 Oct 2022 21:48:16 +0000 (14:48 -0700)]
Rollup merge of #103254 - fmease:fix-24183, r=GuillaumeGomez
rustdoc: do not filter out cross-crate `Self: Sized` bounds
All type parameters **except `Self`** are implicitly `Sized` ([via](https://doc.rust-lang.org/nightly/std/marker/trait.Sized.html)). Previously, we disregarded the exception of `Self` and omitted cross-crate `Sized` bounds of *any* type parameter *including* `Self` when rendering.
From now on, we *do* render cross-crate `Self: Sized` bounds.
Most notably, in `std` we now finally properly render the `Sized` bound of the `Clone` trait as well as the `Self: Sized` bound on `Iterator::map`.
Michael Howell [Sun, 23 Oct 2022 21:48:15 +0000 (14:48 -0700)]
Rollup merge of #103005 - solid-rs:patch/kmc-solid/readdir-terminator, r=m-ou-se
kmc-solid: Handle errors returned by `SOLID_FS_ReadDir`
Fixes the issue where the `std::fs::ReadDir` implementaton of the [`*-kmc-solid_*`](https://doc.rust-lang.org/nightly/rustc/platform-support/kmc-solid.html) Tier 3 targets silently suppressed errors returned by the underlying `SOLID_FS_ReadDir` system function. The new implementation correctly handles all cases:
- `SOLID_ERR_NOTFOUND` indicates the end of directory stream.
- `SOLID_ERR_OK` + non-empty `d_name` indicates success.
- Some old filesystem drivers may return `SOLID_ERR_OK` + empty `d_name` to indicate the end of directory stream.
- Any other negative values (per ITRON convention) represent an error.
Michael Howell [Sun, 23 Oct 2022 21:48:14 +0000 (14:48 -0700)]
Rollup merge of #101644 - Timmmm:file_permissions_docs, r=thomcc
Document surprising and dangerous fs::Permissions behaviour on Unix
This documents the very surprising behaviour that `set_readonly(false)` will make a file *world writable* on Unix. I would go so far as to say that this function should be deprecated on Unix, or maybe even entirely. But documenting the bad behaviour is a good first step.
bors [Sun, 23 Oct 2022 21:38:43 +0000 (21:38 +0000)]
Auto merge of #103062 - cuviper:dist-mips, r=Mark-Simulacrum
Upgrade dist-mips*-linux to ubuntu:22.04 + crosstool-ng
These have no change in compatibility, still Linux 4.4 and glibc 2.23.
The main motivation for upgrading is that LLVM 16 will require at least GCC 7.1. Using crosstool-ng lets us choose our own toolchain versions, and then the Ubuntu version doesn't matter so much, just for the host compilation while we cross-compile.
It turns out `libc::dirent64` is quite big—https://docs.rs/libc/0.2.135/libc/struct.dirent64.html. In #103135 this memset accounted for 0.9% of the runtime of iterating a big directory.
Almost none of the big zeroed value is ever used. We memcpy a tiny prefix (19 bytes) into it, and then read just 9 bytes (`d_ino` and `d_type`) back out. We can read exactly those 9 bytes we need directly from the original entry_ptr instead.
## History
This code got added in #93459 and tweaked in #94272 and #94750.
Prior to #93459, there was no memset but a full 280 bytes were being copied from the entry_ptr.
<table><tr><td>copy 280 bytes</td></tr></table>
This was not legal because not all of those bytes might be initialized, or even allocated, depending on the length of the directory entry's name, leading to a segfault. That PR fixed the segfault by creating a new zeroed dirent64 and copying just the guaranteed initialized prefix into it.
However this was still buggy because it used `addr_of!((*entry_ptr).d_name)`, which is considered UB by Miri in the case that the full extent of entry_ptr is not in bounds of the same allocation. (Arguably this shouldn't be a requirement, but here we are.)
The UB got fixed by #94272 by replacing `addr_of` with some pointer manipulation based on `offset_from`, but still fundamentally the same operation.
After my PR we just grab the 9 needed bytes directly from entry_ptr.
<table><tr><td>copy 9 bytes</td></tr></table>
The resulting code is more complex but I believe still worthwhile to land for the following reason. This is an extremely straightforward thing to accomplish in C and clearly libc assumes that; literally just `entry_ptr->d_name`. The extra work in comparison to accomplish it in Rust is not an example of any actual safety being provided by Rust. I believe it's useful to have uncovered that and think about what could be done in the standard library or language to support this obvious operation better.
bors [Sun, 23 Oct 2022 11:33:18 +0000 (11:33 +0000)]
Auto merge of #103431 - Dylan-DPC:rollup-oozfo89, r=Dylan-DPC
Rollup of 6 pull requests
Successful merges:
- #101293 (Recover when unclosed char literal is parsed as a lifetime in some positions)
- #101908 (Suggest let for assignment, and some code refactor)
- #103192 (rustdoc: Eliminate uses of `EarlyDocLinkResolver::all_traits`)
- #103226 (Check `needs_infer` before `needs_drop` during HIR generator analysis)
- #103249 (resolve: Revert "Set effective visibilities for imports more precisely")
- #103305 (Move some tests to more reasonable places)
Dylan DPC [Sun, 23 Oct 2022 09:50:18 +0000 (15:20 +0530)]
Rollup merge of #103249 - petrochenkov:revaddids, r=oli-obk
resolve: Revert "Set effective visibilities for imports more precisely"
In theory the change was correct, but in practice the use of import items in HIR is limited and hacky, and it expects that (effective) visibilities for all (up to) 3 IDs of the import are set to the value reflecting (effective) visibility of the whole syntactic `use` item rather than its individual components.
Dylan DPC [Sun, 23 Oct 2022 09:50:17 +0000 (15:20 +0530)]
Rollup merge of #103226 - compiler-errors:delay-if-need-infer, r=lcnr
Check `needs_infer` before `needs_drop` during HIR generator analysis
This is kinda a revival of #103036, but with the understanding that after fallback, a generator-interior type will only have `needs_infer` true if there's an error that prevented int or float variable fallback to occur (modulo region variables, which are erased).
Therefore the best choice here is to delay a bug and skip the `needs_drop` call altogether.
bors [Sun, 23 Oct 2022 09:06:39 +0000 (09:06 +0000)]
Auto merge of #103345 - Nilstrieb:diag-flat, r=compiler-errors
Flatten diagnostic slug modules
This makes it easier to grep for the slugs in the code.
See https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Localization.20infra.20interferes.20with.20grepping.20for.20error for more discussion about it.
This was mostly done with a few regexes and a bunch of manual work. This also exposes a pretty annoying inconsistency for the extra labels. Some of the extra labels are defined as additional properties in the fluent message (which makes them not prefixed with the crate name) and some of them are new fluent messages themselves (which makes them prefixed with the crate name). I don't know whether we want to clean this up at some point but it's useful to know.
Matthias Krüger [Sun, 23 Oct 2022 06:14:33 +0000 (08:14 +0200)]
Rollup merge of #103399 - smoelius:unknown-lint-maybe-incorrect, r=fee1-dead
Change `unknown_lint` applicability to `MaybeIncorrect`
This small PR changes the applicability of `unknown_lint` to `MaybeIncorrect`, because the suggested lint might not be the correct one.
Here is one example where the current applicability causes a problem. Clippy has a set of internal lints guarded by a feature called `internal`. If the feature is not enabled, then the internal lints are "unknown." In that case, running `cargo clippy --fix ...` on `clippy_utils` causes lines such as the followig
https://github.com/rust-lang/rust/blob/26c96e341639102afacbbcad0dc18ad0ac71ab18/src/tools/clippy/clippy_utils/src/paths.rs#L51-L52
to be changed to
```rust
#[expect(clippy::invalid_regex)] // internal lints do not know about all external crates
pub const FUTURES_IO_ASYNCREADEXT: [&str; 3] = ["futures_util", "io", "AsyncReadExt"];
```
which is not correct.
Matthias Krüger [Sun, 23 Oct 2022 06:14:32 +0000 (08:14 +0200)]
Rollup merge of #103368 - compiler-errors:normalization-ambiguity-bug, r=oli-obk
Delay ambiguity span bug in normalize query iff not rustdoc
Oli and I decided that the compiler debt of adding another usage of `tcx.sess.opts.actually_rustdoc` is fine, because we don't really want to add more complexity to the normalize query, and moving rustdoc to use fulfill normalization (`fully_normalize`, i.e. not use the normalize query) is unnecessary overhead given that it's skipping binders and stuff.
Matthias Krüger [Sun, 23 Oct 2022 06:14:31 +0000 (08:14 +0200)]
Rollup merge of #103355 - compiler-errors:rpitit-default-check, r=oli-obk
Handle return-position `impl Trait` in traits properly in `register_hidden_type`
The bounds that we get by calling `bound_explicit_item_bounds` from an RPITIT have projections, not opaques, but when we're *registering* an opaque, we want to treat it like an opaque.
Coincidentally fixes #102688 as well, which makes sense, since that was failing because we were inferring an opaque type to be equal to itself (opaque cycle error => "cannot resolve opaque type").
Matthias Krüger [Sun, 23 Oct 2022 06:14:30 +0000 (08:14 +0200)]
Rollup merge of #103123 - compiler-errors:early-binder-iter, r=cjgillot
Introduce `subst_iter` and `subst_iter_copied` on `EarlyBinder`
Makes working with bounds lists a bit easier, which I seem to do a lot.
Specifically, means that we don't need to do `.transpose_iter().map(|(pred, _)| *pred)` every time we want to iterate through an `EarlyBinder<&'tcx [(Predicate, Span)]>` (and even then, still have to call `subst` later), which was a very awkward idiom imo.
bors [Sun, 23 Oct 2022 05:05:23 +0000 (05:05 +0000)]
Auto merge of #9688 - Alexendoo:msrv-tests, r=Manishearth
Move MSRV tests into the lint specific test files
There are currently two ways MSRV tests are done in the ui test suite, adding a case to the `#![clippy::msrv = "1.0"]` `tests/ui/min_rust_version_attr.rs` or adding the two `msrv_1_xx` functions to the test file of the lint in question
This updates the clippy book to suggest the `msrv_1_xx` style, and replaces the tests in `tests/ui/min_rust_version_attr.rs` with ones of that style
Almost the entire diff is just moving stuff around as a result, I made sure to check the line numbers the lints are emitted at correspond with the right `msrv` case, so feel free to only skim that part
Josh Triplett [Sat, 22 Oct 2022 14:37:46 +0000 (15:37 +0100)]
Fix wrapped valid-range handling in ty_find_init_error
Rust's niche handling allows for wrapping valid ranges with end < start;
for instance, a valid range with start=43 and end=41 means a niche of
42. Most places in the compiler handle this correctly, but
ty_find_init_error assumed that `lo > 0` means the type cannot contain a
zero.
projects / rust.git / log