| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Migrate GUI colors test to original CSS color format
Follow-up of https://github.com/rust-lang/rust/pull/111459.
r? `@notriddle`
|
|
Emit unused doc comment warnings for pat and expr fields
Fixes #115462
|
|
|
|
|
|
|
|
[rustdoc] Fix type based search
Fixes https://github.com/rust-lang/rust/issues/114522.
The problem was a bit more tricky than I originally thought it would be: we only kept type ID and generics in short, but as soon as there was a full path in the user query, the element didn't get an ID anymore because the ID map didn't know about `x::y` (although it knew about `y`). So for this first problem, I instead always pass the element name to get the ID.
Then a new problem occurred: we actually needed to check if paths matched, otherwise whatever the path, as long as the "end types" match, it's all good. meaning, we needed to add path information, but to do so, we needed it to be added into the search index directly as there was no mapping between `"p"` and `"q"`.
I hope this explanation makes sense to someone else than me. ^^'
r? `@notriddle`
|
|
Migrate GUI colors test to original CSS color format
Follow-up of https://github.com/rust-lang/rust/pull/111459.
r? `@notriddle`
|
|
|
|
|
|
Optimize Take::{fold, for_each} when wrapping TrustedRandomAccess iterators
|
|
|
|
Fall through when resolving elided assoc const lifetimes
`@QuineDot` makes a good point in https://github.com/rust-lang/rust/issues/115010#issuecomment-1702127634 that we probably should not accept *more* code due to #115011 even though that code will eventually become a forbid-warning in a few versions (https://github.com/rust-lang/rust/issues/115010#issuecomment-1701598067).
Fall through when walking thru the `AnonymousWarnToStatic` (renamed to `AnonymousWarn`) rib so that we can resolve as a fresh lifetime like we did before.
|
|
Skip rendering metadata strings from include_str!/include_bytes!
The const rendering code in rustdoc completely ignores consts from expansions, but the compiler was rendering all consts. So some consts (namely those from `include_bytes!`) were rendered then ignored.
Most of the diff here is from moving `print_const_expr` from rustdoc into `rustc_hir_pretty` so that it can be used in rustdoc and when building rmeta files.
|
|
Implement Step for ascii::Char
This allows iterating over ranges of `ascii::Char`, similarly to ranges of `char`.
Note that `ascii::Char` is still unstable, tracked in #110998.
|
|
r=GuillaumeGomez
rustdoc: correctly deal with self ty params when eliding default object lifetimes
Fixes #115179.
|
|
|
|
diagnostics: avoid wrong `unused_parens` on `x as (T) < y`
Fixes #106413
Fixes #80636
|
|
lifetimes
|
|
|
|
Replace old private-in-public diagnostic with type privacy lints
Next part of RFC https://github.com/rust-lang/rust/issues/48054.
r? `@petrochenkov`
|
|
Lower `Or` pattern without allocating place
cc `@azizghuloum` `@cjgillot`
Related to #111583 and #111644
While reviewing #111644, it occurs to me that while we directly lower conjunctive predicates, which are connected with `&&`, into the desirable control flow, today we don't directly lower the disjunctive predicates, which are connected with `||`, in the similar fashion. Instead, we allocate a place for the boolean temporary to hold the result of evaluating the `||` expression.
Usually I would expect optimization at later stages to "inline" the evaluation of boolean predicates into simple CFG, but #111583 is an example where `&&` is failing to be optimized away and the assembly shows that both the expensive operands are evaluated. Therefore, I would like to make a small change to make the CFG a bit more straight-forward without invoking the `as_temp` machinery, and plus avoid allocating the place to hold the boolean result as well.
|
|
|
|
Permit recursive weak type aliases
I saw #63097 and thought "we can do ~~better~~ funnier". So here it is. It's not useful, but it's certainly something. This may actually become feasible with lazy norm (so in 5 years (constant, not reducing over time)).
r? `@estebank`
cc `@GuillaumeGomez`
|
|
Return ident for ExprField and PatField HIR nodes
Fixes #115264
|
|
|
|
|
|
compiler-errors:associated-type-bound-implicit-lifetimes, r=jackh726
Capture lifetimes for associated type bounds destined to be lowered to opaques
Some associated type bounds get lowered to opaques, but they're not represented in the AST as opaques.
That means that we never collect lifetimes for them (`record_lifetime_params_for_impl_trait`) which are used currently for RPITITs, which capture all of their in-scope lifetimes[^1]. This means that the nested RPITITs that arise from some type like `impl Foo<Type: Bar>` (~> `impl Foo<Type = impl Bar>`) don't capture any lifetimes, leading to ICEs.
This PR makes sure we collect the lifetimes for associated type bounds as well, and make sure that they are set up correctly for opaque type lowering later.
Fixes #115360
[^1]: #114489
|
|
|
|
fix(resolve): update def if binding is warning ambiguity
Fixes #115380
|
|
Work around ICE in diagnostics for local super-universes missing `UniverseInfo`s
In issue #114907, canonicalization of liveness dropck-outlives results (IIUC) encounters universes absent from the original query. Some local universes [are created](https://github.com/lqd/rust/blob/f3a1bae88c617330b8956818da3cea256336c1cf/compiler/rustc_infer/src/infer/canonical/query_response.rs#L417-L425) for the mapping, but importantly, they won't have associated causes.
These missing `UniverseInfo`s can be [needed](https://github.com/lqd/rust/blob/f3a1bae88c617330b8956818da3cea256336c1cf/compiler/rustc_borrowck/src/diagnostics/region_errors.rs#L376) during diagnostics, [causing the `IndexMap: key not found` ICE](https://github.com/lqd/rust/blob/d55522aad87c5605d7edd5dd4b37926e8b446117/compiler/rustc_borrowck/src/region_infer/mod.rs#L2252) seen in the issue.
This PR works around this by returning the suboptimal catch-all cause, to avoid the ICE. It does results in suboptimal diagnostics right now, but it's better than an ICE.
r? `@matthewjasper.`
Let me know if there's a good easy-ish way to fix this, but I believe that for some of these erroneous cases and diagnostics, that inference/canonicalization/higher-ranked subtyping/etc may not behave exactly the same with the new trait solver? If that's the case then it'd probably be best to wait a bit more to do the correct fix.
Fixes #114907.
cc `@aliemjay`
|
|
|
|
`rustc_layout_scalar_valid_range` makes ctors unsafe
We already validate this when we use the ctor in a call, e.g. `Variant(1)`, but not if we use the ctor as a fn ptr, e.g. `.map(Variant)`. The easiest way to fix the latter is (afaict) is by marking the ctor as unsafe itself.
Fixes #115284
|
|
`ignore-cross-compile` remaining tests that run binaries
Follow up to https://github.com/rust-lang/rust/pull/114958
|
|
Don't record spans for predicates in coherence
Should improve perf (https://github.com/rust-lang/rust/pull/115107#issuecomment-1695090589) for https://github.com/rust-lang/rust/pull/114023#issuecomment-1688514709
r? aliemjay
|
|
Fix inlining with -Zalways-encode-mir
Only inline functions that are considered eligible for inlining
by the reachability pass.
This constraint was previously indirectly enforced by only exporting MIR
of eligible functions, but that approach doesn't work with
-Zalways-encode-mir enabled.
|
|
Also remove a note that I don't consider to be very useful in context.
|
|
|
|
Add `ParallelGuard` type to handle unwinding in parallel sections
This adds a `ParallelGuard` type to handle unwinding in parallel sections instead of manually dealing with panics in each parallel operation. This also adds proper panic handling to the `join` operation.
cc `@SparrowLii`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This reverts commit cb9467515b5a9b15aaa905683c6b4dd9e851056c, reversing
changes made to 57781b24c54f9548722927ba88c343ff28da94ce.
|
|
|
|
Co-authored-by: Abdulaziz Ghuloum <aghuloum@gmail.com>
|
|
|
|
Don't suggest adding parentheses to call an inaccessible method.
Previously, code of this form would emit E0615 (attempt to use a method as a field), thus emphasizing the existence of private methods that the programmer probably does not care about. Now it ignores their existence instead, producing error E0609 (no field). The motivating example is:
```rust
let x = std::rc::Rc::new(());
x.inner;
```
which would previously mention the private method `Rc::inner()`, even though `Rc<T>` intentionally has no public methods so that it can be a transparent smart pointer for any `T`.
```rust
error[E0615]: attempted to take value of method `inner` on type `Rc<()>`
--> src/main.rs:3:3
|
3 | x.inner;
| ^^^^^ method, not a field
|
help: use parentheses to call the method
|
3 | x.inner();
| ++
```
With this change, it emits E0609 and no suggestion.
|
|
new solver: handle edge case of a recursion limit of 0
Apparently a recursion limit of 0 is possible/valid/useful/used/cute, the more you know 🌟 .
(It's somewhat interesting to me that the old solver seemingly handles this, and that the new solver currently requires a recursion limit of 2 here)
r? `@compiler-errors.`
Fixes #115351.
|
