| Age | Commit message (Collapse) | Author | Lines |
|
r=lcnr
Do not mention private types from other crates as impl candidates
Fixes #99080
|
|
Deny float const params even when `adt_const_params` is enabled
Supersedes #98825
Fixes #98813
r? ``@oli-obk``
|
|
r=davidtwco
explain doc comments in macros a bit
Open to suggestions on improving this... macro parsing is very foreign to me.
Should we have a structured suggestion to turn them into their regular non-doc comments?
Fixes #92846
Fixes #97850
|
|
Currently, for the enums and comparison traits we always check the tag
for equality before doing anything else. This is a bit clumsy. This
commit changes things so that the tags are handled very much like a
zeroth field in the enum.
For `eq`/ne` this makes the code slightly cleaner.
For `partial_cmp` and `cmp` it's a more notable change: in the case
where the tags aren't equal, instead of having a tag equality check
followed by a tag comparison, it just does a single tag comparison.
The commit also improves how `Hash` works for enums: instead of having
duplicated code to hash the tag for every arm within the match, we do
it just once before the match.
All this required replacing the `EnumNonMatchingCollapsed` value with a
new `EnumTag` value.
For fieldless enums the new code is particularly improved. All the code
now produced is close to optimal, being very similar to what you'd write
by hand.
|
|
|
|
|
|
|
|
|
|
|
|
Use `tag` in names of things referring to tags, instead of the
mysterious `vi`.
Also change `arg_N` in output to `argN`, which has the same length as
`self` and so results in nicer vertical alignments.
|
|
By producing `&T` expressions for fields instead of `T`. This matches
what the existing comments (e.g. on `FieldInfo`) claim is happening, and
it's also what most of the trait-specific code needs.
The exception is `PartialEq`, which needs `T` expressions for lots of
special case error messaging to work. So we now convert the `&T` back to
a `T` for `PartialEq`.
|
|
E.g. improving code like this:
```
match &*self {
&Enum1::Single { x: ref __self_0 } => {
::core::hash::Hash::hash(&*__self_0, state)
}
}
```
to this:
```
match self {
Enum1::Single { x: __self_0 } => {
::core::hash::Hash::hash(&*__self_0, state)
}
}
```
by removing the `&*`, the `&`, and the `ref`.
I suspect the current generated code predates deref-coercion.
The commit also gets rid of `use_temporaries`, instead passing around
`always_copy`, which makes things a little clearer. And it fixes up some
comments.
|
|
|
|
|
|
Remove duplicate notes from error on inter-crate ambiguous impl of traits
Fixes #99092
|
|
promote placeholder bounds to 'static obligations
In NLL, when we are promoting a bound out from a closure, if we have a requirement that `T: 'a` where `'a` is in a higher universe, we were previously ignoring that, which is totally wrong. We should be promoting those constraints to `'static`, since universes are not expressible across closure boundaries.
Fixes #98693
~~(Marking as WIP because I'm still running tests, haven't add the new test, etc)~~
r? ``@jackh726``
|
|
Because the generated code is different to fieldless enum with multiple
variants.
|
|
Because the generatedd code is different to a `Copy` packed struct.
|
|
It's an interesting case, requiring the use of `&&` in `Debug::fmt`.
|
|
used across an await
Previously, drop-tracking would incorrectly assume the struct would be dropped immediately, which
was not true: when the field had a type with a manual `Drop` impl, the drop becomes observable and
has to be dropped after the await instead.
For reasons I don't understand, this also fixes another error crater popped up related to type parameters.
#98476
|
|
|
|
|
|
r=estebank
Do not call `check_expr` in `check_compatible`, since it has side-effects
Fixes a weird suggestion in #98784
found later:
Fixes #98894
Fixes #98897
|
|
proc_macro: Fix expand_expr expansion of bool literals
Previously, the expand_expr method would expand bool literals as a
`Literal` token containing a `LitKind::Bool`, rather than as an `Ident`.
This is not a valid token, and the `LitKind::Bool` case needs to be
handled seperately.
Tests were added to more deeply compare the streams in the expand-expr
test suite to catch mistakes like this in the future.
|
|
(fix #99092)
|
|
This doesn't stabilize methods working on mutable pointers.
|
|
and we've already checked all args
|
|
Adding suggestion for E0530
Closes #98974
|
|
fix ICE in ConstProp
Fixes https://github.com/rust-lang/rust/issues/96169
|
|
Before, there was more or less duplicated suggestions to add type hints.
Fix by clearing more generic suggestions when a more specific suggestion
is possible.
This fixes #93506 .
|
|
Methods are defined within the context of a struct and their first parameter is always self
Associated functions don’t take self as a parameter
modified: compiler/rustc_typeck/src/check/method/suggest.rs
modified: src/test/ui/auto-ref-slice-plus-ref.stderr
modified: src/test/ui/block-result/issue-3563.stderr
modified: src/test/ui/issues/issue-28344.stderr
modified: src/test/ui/suggestions/dont-suggest-pin-array-dot-set.stderr
modified: src/test/ui/suggestions/suggest-methods.stderr
modified: src/test/ui/traits/trait-upcasting/subtrait-method.stderr
|
|
Track implicit `Sized` obligations in type params
When we evaluate `ty::GenericPredicates` we introduce the implicit
`Sized` predicate of type params, but we do so with only the `Predicate`
its `Span` as context, we don't have an `Obligation` or
`ObligationCauseCode` we could influence. To try and carry this
information through, we add a new field to `ty::GenericPredicates` that
tracks both which predicates come from a type param and whether that
param has any bounds already (to use in suggestions).
We also suggest adding a `?Sized` bound if appropriate on E0599.
Address part of #98539.
|
|
|
|
|
|
|
|
|
|
|
|
don't succeed `evaluate_obligation` query if new opaque types were registered
fixes #98608
fixes #98604
The root cause of all this is that in type flag computation we entirely ignore nongeneric things like struct fields and the signature of function items. So if a flag had to be set for a struct if it is set for a field, that will only happen if the field is generic, as only the generic parameters are checked.
I now believe we cannot use type flags to handle opaque types. They seem like the wrong tool for this.
Instead, this PR replaces the previous logic by adding a new variant of `EvaluatedToOk`: `EvaluatedToOkModuloOpaqueTypes`, which says that there were some opaque types that got hidden types bound, but that binding may not have been legal (because we don't know if the opaque type was in its defining scope or not).
|
|
Rollup of 4 pull requests
Successful merges:
- #98533 (Add a `-Zdump-drop-tracking-cfg` debugging flag)
- #98654 (An optimization for `pest-2.1.3`)
- #98657 (Migrate some diagnostics from `rustc_const_eval` to `SessionDiagnostic`)
- #98794 (Highlight conflicting param-env candidates)
Failed merges:
- #98957 ( don't allow ZST in ScalarInt )
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
layout_scalar_valid_range logic
|
|
|
|
r=michaelwoerister
Highlight conflicting param-env candidates
This could probably be further improved by noting _why_ equivalent param-env candidates (modulo regions) leads to ambiguity.
Fixes #98786
|
|
r=Mark-Simulacrum
More derive output improvements
This PR includes:
- Some test improvements.
- Some cosmetic changes to derive output that make the code look more like what a human would write.
- Some more fundamental improvements to `cmp` and `partial_cmp` generation.
r? `@Mark-Simulacrum`
|
|
|
|
|
|
Stabilize `into_future`
https://github.com/rust-lang/rust/issues/67644 has been labeled with [S-tracking-ready-to-stabilize](https://github.com/rust-lang/rust/labels/S-tracking-ready-to-stabilize) - which mentions someone needs to file a stabilization PR. So hence this PR! :sparkles: Thanks!
Closes https://github.com/rust-lang/rust/issues/67644
r? ``@joshtriplett``
|
|
sess: stabilize `--terminal-width` as `--diagnostic-width`
Formerly `-Zterminal-width`, `--terminal-width` allows the user or build
tool to inform rustc of the width of the terminal so that diagnostics
can be truncated.
Pending agreement to stabilize, see tracking issue at #84673.
r? ```@oli-obk```
|
|
|
|
Shorten def_span of closures to just their header
Continuation of https://github.com/rust-lang/rust/pull/93967.
|
|
|