| Age | Commit message (Collapse) | Author | Lines |
|---|
|
core library: Disable fpmath tests for i586 ...
This patch disables the floating-point epsilon test for i586 since x87 registers are too imprecise and can't produce the expected results.
|
|
doc: expand description for f32 and f64 associated constants
This explains the meaning of some of the floating-point associated constants.
|
|
Remove mir::LocalDecl::internal.
It does not serve any purpose, as we don't have typeck-based generator witnesses any more.
|
|
Rollup of 5 pull requests
Successful merges:
- #116223 (Fix misuses of a vs an)
- #116296 (More accurately point to where default return type should go)
- #116429 (Diagnostics: Be more careful when suggesting struct fields)
- #116431 (Tweak wording of E0562)
- #116432 (rustdoc: rename `issue-\d+.rs` tests to have meaningful names (part 2))
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
rustdoc: rename `issue-\d+.rs` tests to have meaningful names (part 2)
Follow up https://github.com/rust-lang/rust/pull/116214
|
|
Tweak wording of E0562
Fix #80476.
|
|
Diagnostics: Be more careful when suggesting struct fields
Consolidate the various places which filter out struct fields that shouldn't be suggested into a single function.
Previously, each of those code paths had slightly different and incomplete metrics for no good reason. Now, there's only a single 'complete' metric (namely `is_field_suggestable`) which also filters out hygienic fields that come from different syntax contexts.
Fixes #116334.
|
|
More accurately point to where default return type should go
When getting the "default return type" span, instead of pointing to the low span of the next token, point to the high span of the previous token. This:
1. Makes forming return type suggestions more uniform, since we expect them all in the same place.
2. Arguably makes labels easier to understand, since we're pointing to where the implicit `-> ()` would've gone, rather than the starting brace or the semicolon.
r? ```@estebank```
|
|
Fix misuses of a vs an
Fixes the misuse of "a" vs "an", according to English grammatical
expectations and using https://www.a-or-an.com/
|
|
Only trigger `refining_impl_trait` lint on reachable traits
Public but unreachable traits don't matter 😸
r? `@tmandry`
|
|
Add `async_fn_in_trait` lint
cc https://github.com/rust-lang/rust/pull/115822#issuecomment-1731168465
Mostly unsure what the messaging should be. Feedback required.
r? `@tmandry`
|
|
Remove the `TypedArena::alloc_from_iter` specialization.
It was added in #78569. It's complicated and doesn't actually help
performance.
r? `@cjgillot`
|
|
Co-authored-by: Travis Cross <tc@traviscross.com>
|
|
|
|
|
|
|
|
|
|
chinedufn:fix-expect-unused-in-impl-block-rust-issue-114416, r=cjgillot
Fix multiple `expect` attribs in impl block
Closes #114416
|
|
|
|
|
|
Fix #80476.
|
|
|
|
|
|
Disable CFI for core and std CFI violations
Work around https://github.com/rust-lang/rust/issues/115199 by temporarily disabling CFI for core and std CFI violations to allow the user rebuild and use both core and std with CFI enabled using the Cargo build-std feature.
|
|
|
|
Updates documentation for LLVM CFI support with recommended information
since the user can now rebuild and use both core and std with CFI
enabled using the Cargo build-std feature.
|
|
Works around #115199 by temporarily disabling CFI for core and std CFI
violations to allow the user rebuild and use both core and std with CFI
enabled using the Cargo build-std feature.
|
|
Remove E0551
Because it's the same as E0539.
Fixes #51489.
r? `@Nilstrieb`
|
|
Remove wasm32-unknown-emscripten tests from CI
This builder tested the wasm32-unknown-emscripten target, which is tier 2 (and so not eligible for testing). In the recent beta [promotion](https://github.com/rust-lang/rust/pull/116362#issuecomment-1744960904), we ran into a problem with this target: emscripten doesn't support passing environment variables into the std environment, so we can't enable RUSTC_BOOTSTRAP for libtest in order to pass -Zunstable-options.
We worked around this for the beta/stable branches, but given this problem, and its tier 2 status, just dropping the target's tests entirely seems warranted. Downgrading to tier 3 may also be a good idea, but that is a separate conversation not proposed here.
|
|
Point to full `async fn` for future
Semi-follow-up to https://github.com/rust-lang/rust/pull/116296#discussion_r1342007575
cc `@asquared31415`
|
|
Add new bors try branches to CI
Workflows for the new bors weren't launching, because its branches weren't whitelisted here.
r? `@Mark-Simulacrum`
|
|
Because it's the same as E0539.
Fixes #51489.
|
|
It's easier to read in sorted order.
|
|
Update cargo
9 commits in 59596f0f31a94fde48b5aa7e945cd0b7ceca9620..794d0a82547f3081044c0aca7b6083733ce51344
2023-09-29 19:29:17 +0000 to 2023-10-03 23:19:33 +0000
- Prep for automating MSRV management (rust-lang/cargo#12767)
- chore(deps): update rust crate itertools to 0.11.0 (rust-lang/cargo#12759)
- fix bug: corruption when cargo killed while writing (rust-lang/cargo#12744)
- Disable custom_target::custom_bin_target on windows-gnu (rust-lang/cargo#12763)
- chore(deps): update compatible (rust-lang/cargo#12757)
- Add more missing `strip` info to docs. (rust-lang/cargo#12754)
- chore(deps): update actions/checkout action to v4 (rust-lang/cargo#12762)
- chore(deps): update rust crate cargo_metadata to 0.18.0 (rust-lang/cargo#12758)
- fix(test): Add back in newlines to diffs (rust-lang/cargo#12753)
r? ghost
|
|
Rollup of 7 pull requests
Successful merges:
- #115961 (Replace 'mutex' with 'lock' in RwLock documentation)
- #116146 (Clarify `arg` and `args` documentation)
- #116363 (Adapt `todo!` documentation to mention displaying custom values)
- #116365 (bootstrap: make copying linker binaries conditional)
- #116388 (rustdoc: fix & clean up handling of cross-crate higher-ranked parameters)
- #116393 (Emit feature gate *warning* for `auto` traits pre-expansion)
- #116395 (Mark myself as vacation or whatever)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Mark myself as vacation or whatever
I think I have the capacity to review PRs currently assigned to me, before vacation, but I won't be able to take any more. So, until everything settles down, I don't want to be assigned to new PRs.
|
|
Emit feature gate *warning* for `auto` traits pre-expansion
Auto traits were introduced before we were more careful about not stabilizing new syntax pre-expansion.
This is a more conservative step in the general direction we want to go in https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Removal.20of.20.60auto.20trait.60.20syntax.
Fixes #116121
|
|
fmease:rustdoc-fix-n-clean-up-x-crate-higher-ranked-params, r=notriddle
rustdoc: fix & clean up handling of cross-crate higher-ranked parameters
Preparatory work for the refactoring planned in #113015 (for correctness & maintainability).
---
1. Render the higher-ranked parameters of cross-crate function pointer types **(*)**.
2. Replace occurrences of `collect_referenced_late_bound_regions()` (CRLBR) with `bound_vars()`.
The former is quite problematic and the use of the latter allows us to yank a lot of hacky code **(†)**
as you can tell from the diff! :)
3. Add support for cross-crate higher-ranked types (`#![feature(non_lifetime_binders)]`).
We were previously ICE'ing on them (see `inline_cross/non_lifetime_binders.rs`).
---
**(*)**: Extracted from test `inline_cross/fn-type.rs`:
```diff
- fn(_: &'z fn(_: &'b str), _: &'a ()) -> &'a ()
+ for<'z, 'a, '_unused> fn(_: &'z for<'b> fn(_: &'b str), _: &'a ()) -> &'a ()
```
**(†)**: It returns an `FxHashSet` which isn't *predictable* or *stable* wrt. source code (`.rmeta`) changes. To elaborate, the ordering of late-bound regions doesn't necessarily reflect the ordering found in the source code. It does seem to be stable across compilations but modifying the source code of the to-be-documented crates (like adding or renaming items) may result in a different order:
<details><summary>Example</summary>
Let's assume that we're documenting the cross-crate re-export of `produce` from the code below. On `master`, rustdoc would render the list of binders as `for<'x, 'y, 'z>`. However, once you add back the functions `a`–`l`, it would be rendered as `for<'z, 'y, 'x>` (reverse order)! Results may vary. `bound_vars()` fixes this as it returns them in source order.
```rs
// pub fn a() {}
// pub fn b() {}
// pub fn c() {}
// pub fn d() {}
// pub fn e() {}
// pub fn f() {}
// pub fn g() {}
// pub fn h() {}
// pub fn i() {}
// pub fn j() {}
// pub fn k() {}
// pub fn l() {}
pub fn produce() -> impl for<'x, 'y, 'z> Trait<'z, 'y, 'x> {}
pub trait Trait<'a, 'b, 'c> {}
impl Trait<'_, '_, '_> for () {}
```
</details>
Further, as the name suggests, CRLBR only collects *referenced* regions and thus we drop unused binders. `bound_vars()` contains unused binders on the other hand. Let's stay closer to the source where possible and keep unused binders.
Lastly, using `bound_vars()` allows us to get rid of
* the deduplication and alphabetical sorting hack in `simplify.rs`
* the weird field `bound_params` on `EqPredicate`
both of which were introduced by me in #102707 back when I didn't know better.
To illustrate, let's look at the cross-crate bound `T: for<'a, 'b> Trait<A<'a> = (), B<'b> = ()>`.
* With CRLBR + `EqPredicate.bound_params`, *before* bounds simplification we would have the bounds `T: Trait`, `for<'a> <T as Trait>::A<'a> == ()` and `for<'b> <T as Trait>::B<'b> == ()` which required us to merge `for<>`, `for<'a>` and `for<'b>` into `for<'a, 'b>` in a deterministic manner and without introducing duplicate binders.
* With `bound_vars()`, we now have the bounds `for<'a, b> T: Trait`, `<T as Trait>::A<'a> == ()` and `<T as Trait>::B<'b> == ()` before bound simplification similar to rustc itself. This obviously no longer requires any funny merging of `for<>`s. On top of that `for<'a, 'b>` is guaranteed to be in source order.
|
|
bootstrap: make copying linker binaries conditional
The change in #116276 breaks bootstrapping if you don't use `lld` for linking with your stage0 compiler. Making this copy conditional should be enough to fix it.
|
|
Adapt `todo!` documentation to mention displaying custom values
Resolves #116130.
I copied from the [existing documentation](https://doc.rust-lang.org/std/macro.unimplemented.html) for `unimplemented!` more or less directly, down to the example trait used. I also took the liberty of fixing some formatting and typographical errors that I noticed.
|
|
Clarify `arg` and `args` documentation
Fixes #95400
|
|
Replace 'mutex' with 'lock' in RwLock documentation
When copying the documentation for `clear_poison` from Mutex, not every occurence of 'mutex' was replaced with 'lock'.
|
|
|
|
Add missing inline attributes to Duration trait impls
Currently `Duration::checked_add` is marked `#[inline]` but it's trait relative `Add::add` is not.
Leading to a case where:
```rust
pub fn foo() -> Duration {
Duration::from_secs(10) + Duration::from_millis(6)
}
pub fn bar() -> Duration {
Duration::from_secs(10).checked_add(Duration::from_millis(6)).expect("overflow when adding durations")
}
```
compiles to:
```asm
playground::foo:
movl $10, %edi
xorl %esi, %esi
xorl %edx, %edx
movl $6000000, %ecx
jmpq *<core::time::Duration as core::ops::arith::Add>::add@GOTPCREL(%rip)
playground::bar:
movl $10, %eax
movl $6000000, %edx
retq
```
(The same happens for all arithmetic operation)
|
|
Use `addr_eq` in `{Arc,Rc}::ptr_eq`
Since it's made for stuff like this (see #106447)
|
|
Signed-off-by: cui fliter <imcusg@gmail.com>
|
|
Improve UdpSocket documentation
I tried working with `UdpSocket` and ran into `EINVAL` errors with no clear indication of what causes the error. Also, it was uncharacteristically hard to figure this module out, compared to other Rust `std` modules.
1. `send` and `send_to` return a `usize` This one is just clarity. Usually, returned `usize`s indicate that the buffer might have only been sent partially. This is not the case with UDP. Since that `usize` must always be `buffer.len()`, I have documented that.
2. `bind` limits `connect` and `send_to` When you bind to a limited address space like localhost, you can only `connect` to addresses in that same address space. Error kind: `AddrNotAvailable`.
3. `connect`ing to localhost locks you to localhost On Linux, if you first `connect` to localhost, subsequent `connect`s to
non-localhost addresses fail. Error kind: `InvalidInput`.
For debugging the third one, it was really hard to find someone else who already had that problem. I only managed to find this thread: https://www.mail-archive.com/netdev@vger.kernel.org/msg159519.html
|
|
|
|
|
|
coverage: Allow each coverage statement to have multiple code regions
The original implementation of coverage instrumentation was built around the assumption that a coverage counter/expression would be associated with *up to one* code region. When it was discovered that *multiple* regions would sometimes need to share a counter, a workaround was found: for the remaining regions, the instrumentor would create a fresh expression that adds zero to the existing counter/expression.
That got the job done, but resulted in some awkward code, and produces unnecessarily complicated coverage maps in the final binary.
---
This PR removes that tension by changing `StatementKind::Coverage`'s code region field from `Option<CodeRegion>` to `Vec<CodeRegion>`.
The changes on the codegen side are fairly straightforward. As long as each `CoverageKind::Counter` only injects one `llvm.instrprof.increment`, the rest of coverage codegen is happy to handle multiple regions mapped to the same counter/expression, with only minor option-to-vec adjustments.
On the instrumentor/mir-transform side, we can get rid of the code that creates extra (x + 0) expressions. Instead we gather all of the code regions associated with a single BCB, and inject them all into one coverage statement.
---
There are several patches here but they can be divided in to three phases:
- Preparatory work
- Actually switching over to multiple regions per coverage statement
- Cleaning up
So viewing the patches individually may be easier.
|
