| Age | Commit message (Collapse) | Author | Lines |
|
|
|
|
|
In the previous implementation, if the standard streams were open,
but the RLIMIT_NOFILE value was below three, the poll would fail
with EINVAL:
> ERRORS: EINVAL The nfds value exceeds the RLIMIT_NOFILE value.
Switch to the existing fcntl based implementation to avoid the issue.
|
|
Rollup of 7 pull requests
Successful merges:
- #96543 (Remove hacks in `make_token_stream`.)
- #96887 (rustdoc: correct path to type alias methods)
- #96896 (Add regression test for #68408)
- #96900 (Fix js error)
- #96903 (Use lifetimes on type-alias-impl-trait used in function signatures to infer output type lifetimes)
- #96916 (simplify length count)
- #96925 (Fix issue #95151)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Fix issue #95151
Fixes #95151
Nothing special here, just a test for a thing that used to ICE.
|
|
r=compiler-errors
Use lifetimes on type-alias-impl-trait used in function signatures to infer output type lifetimes
fixes https://github.com/rust-lang/rust/issues/96564
TLDR:
```rust
fn execute(ty: Ty<'_>) -> &str { todo!() }
```
(`Ty` being a type alias impl trait) used to produce the following error before this PR
```
error[E0581]: return type references an anonymous lifetime, which is not constrained by the fn input types
--> src/lib.rs:4:27
|
4 | fn execute(ty: Ty<'_>) -> &str { todo!() }
| ^^^^
|
= note: lifetimes appearing in an associated type are not considered constrained
```
|
|
Fix js error
On the source code pages, we get a JS error:

It's fixed in the first commit. The second one is removing an unused CSS rule and the third one is a little cleanup of a GUI test.
cc ``@jsha``
r? ``@notriddle``
|
|
Add regression test for #68408
Closes https://github.com/rust-lang/rust/issues/68408
|
|
rustdoc: correct path to type alias methods
Fixes #83991
|
|
Use `FxIndexSet` to avoid sorting fake borrows
This fixes #96449, but I haven't yet been able to
make the reproducer work using `#[cfg]` attributes,
so we can't use the 'revision' infra to write a test
The previous implementation relied on sorting by `PlaceRef`.
This requires sorting by a `DefId`, which uses untracked state
(see #93315)
|
|
This isn't an ordering test really, anyway...
|
|
|
|
|
|
|
|
|
|
|
|
This removes a special case that doesn't seem to do anything
any more.
|
|
Rollup of 6 pull requests
Successful merges:
- #96717 (Handle mismatched generic param kinds in trait impls betterly)
- #96725 (Expose process windows_process_extensions_main_thread_handle on Windows)
- #96849 (Move some tests to more reasonable places)
- #96861 (Use Rust 2021 prelude in std itself.)
- #96879 (rustdoc: search result ranking fix)
- #96882 (Don't subst an AdtDef with its own substs)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
rustdoc: search result ranking fix
# Before

# After

|
|
Move some tests to more reasonable places
cc https://github.com/rust-lang/rust/issues/73494
r? `@petrochenkov`
|
|
Handle mismatched generic param kinds in trait impls betterly
- Check that generic params on a generic associated type are the same as in the trait definition
- Check that const generics are not used in place of type generics (and the other way round too)
r? `@lcnr`
|
|
output type lifetimes
|
|
|
|
Check hidden types for well formedness at the definition site instead of only at the opaque type itself
work towards #90409 . We'll need to look into closure and generator bodies of closures and generators nested inside the hidden type in order to fix that. In hindsight this PR is not necessary for that, but it may be a bit easier with it and we'll get better diagnostics from it on its own.
|
|
|
|
|
|
only at the opaque type itself
|
|
|
|
make sure ScalarPair enums have ScalarPair variants; add some layout sanity checks
`@eddyb` suggested that it might be reasonable for `ScalarPair` enums to simply adjust the ABI of their variants accordingly, such that the layout invariant Miri expects actually holds. This PR implements that. I should note though that I don't know much about this layout computation code and what non-Miri consumers expect from it, so tread with caution!
I also added a function to sanity-check that computed layouts are internally consistent. This helped a lot in figuring out the final shape of this PR, though I am also not 100% sure that these sanity checks are the right ones.
Cc `@oli-obk`
Fixes https://github.com/rust-lang/rust/issues/96221
|
|
Do not lint on explicit outlives requirements from external macros.
The current implementation of the list rightfully skipped where predicates from external macros.
However, if the where predicate came from the current macro but the bounds were from an external macro, the lint still fired.
Closes https://github.com/rust-lang/rust/issues/96640
|
|
This fixes #96449, but I haven't yet been able to
make the reproducer work using `#[cfg]` attributes,
so we can't use the 'revision' infra to write a test
The previous implementation relied on sorting by `PlaceRef`.
This requires sorting by a `DefId`, which uses untracked state
(see #93315)
|
|
|
|
Fortify handing of where bounds on trait & trait alias definitions
Closes https://github.com/rust-lang/rust/issues/96664
Closes https://github.com/rust-lang/rust/issues/96665
Since https://github.com/rust-lang/rust/pull/93803, when listing all bounds and predicates we now need to account for the possible presence of predicates on any of the generic parameters. Both bugs were hidden by the special handling of bounds at the generic parameter declaration position.
Trait alias expansion used to confuse predicates on `Self` and where predicates.
Exiting too late when listing all the bounds caused a cycle error.
|
|
|
|
|
|
|
|
Actually fix ICE from #96583
PR #96746 fixed a very similar bug, so the same logic is used in a different place.
I originally concluded that the two issues (#96583 and #96738) were identical by comparing the backtrace, but I didn't look close enough.
|
|
fmease:warn-on-useless-doc-hidden-on-assoc-impl-items, r=lcnr
Warn on unused `#[doc(hidden)]` attributes on trait impl items
[Zulip conversation](https://rust-lang.zulipchat.com/#narrow/stream/266220-rustdoc/topic/.E2.9C.94.20Validy.20checks.20for.20.60.23.5Bdoc.28hidden.29.5D.60).
Whether an associated item in a trait impl is shown or hidden in the documentation entirely depends on the corresponding item in the trait declaration. Rustdoc completely ignores `#[doc(hidden)]` attributes on impl items. No error or warning is emitted:
```rust
pub trait Tr { fn f(); }
pub struct Ty;
impl Tr for Ty { #[doc(hidden)] fn f() {} }
// ^^^^^^^^^^^^^^ ignored by rustdoc and currently
// no error or warning issued
```
This may lead users to the wrong belief that the attribute has an effect. In fact, several such cases are found in the standard library (I've removed all of them in this PR).
There does not seem to exist any incentive to allow this in the future either: Impl'ing a trait for a type means the type *fully* conforms to its API. Users can add `#[doc(hidden)]` to the whole impl if they want to hide the implementation or add the attribute to the corresponding associated item in the trait declaration to hide the specific item. Hiding an implementation of an associated item does not make much sense: The associated item can still be found on the trait page.
This PR emits the warn-by-default lint `unused_attribute` for this case with a future-incompat warning.
`@rustbot` label T-compiler T-rustdoc A-lint
|
|
|
|
checks
|
|
|
|
Remove `#[rustc_deprecated]`
This removes `#[rustc_deprecated]` and introduces diagnostics to help users to the right direction (that being `#[deprecated]`). All uses of `#[rustc_deprecated]` have been converted. CI is expected to fail initially; this requires #95958, which includes converting `stdarch`.
I plan on following up in a short while (maybe a bootstrap cycle?) removing the diagnostics, as they're only intended to be short-term.
|
|
Support tool lints with the `#[expect]` attribute (RFC 2383)
This PR fixes the ICE https://github.com/rust-lang/rust/issues/94953 by making the assert for converted expectation IDs conditional.
Additionally, it moves the lint expectation check into a separate query to support rustdoc and other tools. On the way, I've also added some tests to ensure that the attribute works for Clippy and rustdoc lints.
The number of changes comes from the long test file. This may look like a monster PR, this may smell like a monster PR and this may be a monster PR, but it's a harmless monster. :sauropod:
---
Closes: https://github.com/rust-lang/rust/issues/94953
cc: https://github.com/rust-lang/rust/issues/85549
r? `@wesleywiser`
cc: `@rust-lang/rustdoc`
|
|
Rollup of 5 pull requests
Successful merges:
- #96617 (Fix incorrect syntax suggestion with `pub async fn`)
- #96828 (Further elaborate the lack of guarantees from `Hasher`)
- #96829 (Fix the `x.py clippy` command)
- #96830 (Add and tweak const-generics tests)
- #96835 (Add more eslint rules)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
Add and tweak const-generics tests
Closes #96654
Also correct the src/test/ui/const-generics/issues/issue-77357.rs test's issue number.
|
|
ken-matsui:fix-incorrect-syntax-suggestion-with-pub-async-fn, r=cjgillot
Fix incorrect syntax suggestion with `pub async fn`
This PR closes: https://github.com/rust-lang/rust/issues/96555
|
|
Add more diagnostic items
This just adds a handful diagnostic items I noticed were missing.
Would it be worth doing this for all of the remaining types? I'm willing to do it if it'd be helpful.
|