| Age | Commit message (Collapse) | Author | Lines |
|---|
|
expand: Treat more macro calls as statement macro calls
This PR implements the suggestion from https://github.com/rust-lang/rust/pull/87981#issuecomment-906641052 and treats fn-like macro calls inside `StmtKind::Item` and `StmtKind::Semi` as statement macro calls, which is consistent with treatment of attribute invocations in the same positions and with token-based macro expansion model in general.
This also allows to remove a special case in `NodeId` assignment (previously tried in #87779), and to use statement `NodeId`s for linting (`assign_id!`).
r? `@Aaron1011`
|
|
Point at unclosed delimiters as part of the primary MultiSpan
Both the place where the parser encounters a needed closed delimiter and
the unclosed opening delimiter are important, so they should get the
same level of highlighting in the output.
_Context: https://twitter.com/mwk4/status/1430631546432675840_
|
|
Path remapping: Make behavior of diagnostics output dependent on presence of --remap-path-prefix.
This PR fixes a regression (#87745) with `--remap-path-prefix` where the flag stopped causing diagnostic messages to be remapped as well. The regression was introduced in https://github.com/rust-lang/rust/pull/83813 where we erroneously assumed that remapping of diagnostic messages was not desired anymore (because #70642 partially undid that functionality with nobody objecting).
The issue is fixed by making `--remap-path-prefix` remap diagnostic messages again, including for paths that have been remapped in upstream crates (e.g. the standard library). This means that "sysroot-localization" (implemented in #70642) is also disabled if `rustc` is invoked with `--remap-path-prefix`. The assumption is that once someone starts explicitly remapping paths they also don't want paths to their local Rust installation in their build output.
In the future we might want to give more fine-grained control over this behavior via compiler flags (see https://github.com/rust-lang/rfcs/pull/3127 for a related RFC). For now this PR is intended as a regression fix.
This PR is an alternative to https://github.com/rust-lang/rust/pull/88191, which makes diagnostic messages be remapped unconditionally. That approach, however, would effectively revert #70642.
Fixes https://github.com/rust-lang/rust/issues/87745.
cc `@cbeuw`
r? `@ghost`
|
|
Preserve most sub-obligations in the projection cache
Fixes https://github.com/rust-lang/rust/issues/85360
When we evaluate a projection predicate, we may produce sub-obligations. During trait evaluation, evaluating these sub-obligations might cause us to produce `EvaluatedToOkModuloRegions`.
When we cache the result of projection in our projection cache, we try to throw away some of the sub-obligations, so that we don't need to re-evaluate/process them the next time we need to perform this particular projection. However, we may end up throwing away predicates that will (recursively) evaluate to `EvaluatedToOkModuloRegions`. If we do, then the result of evaluating a predicate will depend on the state of the predicate cache - this is global untracked state, which interacts badly with incremental compilation.
To fix this, we now only discard global predicates that evaluate to `EvaluatedToOk`. This ensures that any predicates that (may) evaluate to `EvaluatedToOkModuloRegions` are kept in the cache, and influence the results of any queries which perform this projection.
|
|
Fix ICE in const check
Fixes https://github.com/rust-lang/rust/issues/88433
|
|
rustdoc: Don't panic on ambiguous inherent associated types
Instead, return `Type::Infer` since compilation should fail anyway.
That's how rustdoc handles `hir::TyKind::Err`s, so this just extends
that behavior to `ty::Err`s when analyzing associated types.
For some reason, the error is printed twice with rustdoc (though only
once with rustc). I'm not sure why that is, but it's better than
panicking.
This commit also makes rustdoc fail early in the non-projection,
non-error case, instead of returning a `Res::Err` that would likely
cause rustdoc to panic later on. This change is originally from #88379.
r? `@GuillaumeGomez`
|
|
Add regression test for issue 83190
Reduced from `bioyino-metric` by ````@hellow554```` and myself.
Closes #83190.
r? ````@spastorino````
|
|
r=estebank
Improve closure dummy capture suggestion in macros.
Fixes some cases of https://github.com/rust-lang/rust/issues/88440
Fixes https://crater-reports.s3.amazonaws.com/pr-87190-3/try%23a7a572ce3edd6d476191fbfe92c9c1986e009b34/reg/rcodec-1.0.1/log.txt
|
|
Upgrade array_into_iter lint to include Deref-to-array types.
Fixes https://github.com/rust-lang/rust/issues/88099
Fixes the issue mentioned here: https://github.com/rust-lang/rust/pull/84147#issuecomment-819000436
|
|
|
|
|
|
|
|
|
|
Instead, return `Type::Infer` since compilation should fail anyway.
That's how rustdoc handles `hir::TyKind::Err`s, so this just extends
that behavior to `ty::Err`s when analyzing associated types.
For some reason, the error is printed twice with rustdoc (though only
once with rustc). I'm not sure why that is, but it's better than
panicking.
This commit also makes rustdoc fail early in the non-projection,
non-error case, instead of returning a `Res::Err` that would likely
cause rustdoc to panic later on. This change is originally from #88379.
|
|
r=camelid,Manishearth
Display associated types of implementors
Fixes #86631.
Contrary to before, it doesn't display methods. I also had to "resurrect" the `auto-hide-trait-implementations` setting. :3
Only question at this point: should I move the `render_impl` boolean arguments into one struct? We're starting to have quite a lot of them...
cc `@cynecx`
r? `@camelid`
|
|
|
|
|
|
Doctest persist full binaries when persisting
Tested by adding an extra debug to echo the whole compiler line. Trimmed significantly:
Persisted but not running -> full compile so we get binaries (new behavior).
```
$ rustdoc -Zunstable-options --test --persist-doctests doctests --no-run --extern t=libt.rlib t.rs
DEBUG rustdoc::doctest run_test compiler "rustc" "--crate-type" "bin" "--edition" "2015" "-o" "doctests/t_rs_8_0/rust_out" "--extern" "t=libt.rlib" "-Ccodegen-units=1" "-Z" "unstable-options" "--target" "x86_64-unknown-linux-gnu" "--color" "always"
DEBUG rustdoc::doctest run_test compiler "rustc" "--crate-type" "bin" "--edition" "2015" "-o" "doctests/t_rs_2_0/rust_out" "--extern" "t=libt.rlib" "-Ccodegen-units=1" "-Z" "unstable-options" "--target" "x86_64-unknown-linux-gnu" "--color" "always"
test t.rs - foople (line 2) - compile ... ok
test t.rs - florp (line 8) - compile ... ok
```
Persisted and running -> full compile.
```
$ rustdoc -Zunstable-options --test --persist-doctests doctests --extern t=libt.rlib t.rs
DEBUG rustdoc::doctest run_test compiler "rustc" "--crate-type" "bin" "--edition" "2015" "-o" "doctests/t_rs_8_0/rust_out" "--extern" "t=libt.rlib" "-Ccodegen-units=1" "-Z" "unstable-options" "--target" "x86_64-unknown-linux-gnu" "--color" "always"
DEBUG rustdoc::doctest run_test compiler "rustc" "--crate-type" "bin" "--edition" "2015" "-o" "doctests/t_rs_2_0/rust_out" "--extern" "t=libt.rlib" "-Ccodegen-units=1" "-Z" "unstable-options" "--target" "x86_64-unknown-linux-gnu" "--color" "always"
```
Running but not persisted -> full compile only
```
$ rustdoc --test --extern t=libt.rlib t.rs
DEBUG rustdoc::doctest run_test compiler "rustc" "--crate-type" "bin" "--edition" "2015" "-o" "/tmp/rustdoctestixWAUI/rust_out" "--extern" "t=libt.rlib" "-Ccodegen-units=1" "--target" "x86_64-unknown-linux-gnu" "--color" "always"
DEBUG rustdoc::doctest run_test compiler "rustc" "--crate-type" "bin" "--edition" "2015" "-o" "/tmp/rustdoctestKEaJQu/rust_out" "--extern" "t=libt.rlib" "-Ccodegen-units=1" "--target" "x86_64-unknown-linux-gnu" "--color" "always"
```
Not running and not persisting -> save time and only run metadata.
```
RUSTDOC_LOG=rustdoc=debug,std::test=debug rustdoc -Zunstable-options --no-run --test --extern t=libt.rlib t.rs
DEBUG rustdoc::doctest run_test compiler "rustc" "--crate-type" "bin" "--edition" "2015" "-o" "/tmp/rustdoctest8twt2c/rust_out" "--extern" "t=libt.rlib" "-Ccodegen-units=1" "-Z" "unstable-options" "--emit=metadata" "--target" "x86_64-unknown-linux-gnu" "--color" "always"
DEBUG rustdoc::doctest run_test compiler "rustc" "--crate-type" "bin" "--edition" "2015" "-o" "/tmp/rustdoctest3miSqv/rust_out" "--extern" "t=libt.rlib" "-Ccodegen-units=1" "-Z" "unstable-options" "--emit=metadata" "--target" "x86_64-unknown-linux-gnu" "--color" "always"
```
I can't see any infrastructure for automating this sort of test. Am I missing it?
|
|
|
|
r=petrochenkov
fix(rustc_typeck): produce better errors for dyn auto trait
Fixes #85026
|
|
Remove bolding on associated constants
Associated types don't get bolded, so it looks off to have one kind
bolded and one not.
|
|
add support for clobbering xer, cr, and cr[0-7] for asm! on OpenPower/PowerPC
Fixes #88315
|
|
Emit specific warning to clarify that `#[no_mangle]` should not be applied on foreign statics or functions
Foreign statics and foreign functions should not have `#[no_mangle]` applied, as it does nothing to the name and has some extra hidden behavior that is normally unwanted. There was an existing warning for this, but it says the attribute is only allowed on "statics or functions", which to the user can be confusing.
This PR adds a specific version of the unused `#[no_mangle]` warning that explains that the target is a *foreign* static or function and that they do not need the attribute.
Fixes #78989
|
|
Improve errors for recursive type aliases
Fixes #17539.
|
|
Introduce `let...else`
Tracking issue: #87335
The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..`, but I decided against this because, when a "mismatched type" error is found in typeck, there is no way to trace where in the HIR the expected type originated, AFAICT. In order to pass down this information, I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType`, but I left that as a future enhancement. For now, I simply assert that the block is `!` with a custom `ObligationCauseCode`, and I think this is clear enough, at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect.
Overall, I believe this PR is feature-complete with regard to the RFC.
|
|
|
|
|
|
Associated types don't get bolded, so it looks off to have one kind
bolded and one not.
|
|
Keep turbofish in prelude collision lint.
Fixes https://github.com/rust-lang/rust/issues/88442
|
|
Use right span in prelude collision suggestions with macros.
Fixes https://github.com/rust-lang/rust/issues/88347
r? `@estebank`
|
|
Allow `~const` bounds on trait assoc functions
r? `@oli-obk`
|
|
Disallow the aapcs CC on Aarch64
This never really worked and makes LLVM assert.
|
|
r=camelid,notriddle
Fix json tuple struct enum variant
Fixes #87887.
cc `@dsherret` `@camelid`
r? `@notriddle`
|
|
Co-authored-by: Vadim Petrochenkov <vadim.petrochenkov@gmail.com>
|
|
|
|
m-ou-se:dyn-no-left-shift-right-shift-just-single-angle-brackets-please-thanks, r=petrochenkov
Don't suggest extra <> in dyn suggestion.
Fixes https://github.com/rust-lang/rust/issues/88508
|
|
Warn when [T; N].into_iter() is ambiguous in the new edition.
Fixes https://github.com/rust-lang/rust/issues/88475
In https://github.com/rust-lang/rust/issues/88475, a situation was found where `[T; N].into_iter()` becomes *ambiguous* in the new edition. This is different than the case where `(&[T; N]).into_iter()` resolves differently, which was the only case handled by the `array_into_iter` lint. This is almost identical to the new-traits-in-the-prelude problem. Effectively, due to the array-into-iter hack disappearing in Rust 2021, we effectively added `IntoIterator` to the 'prelude' in Rust 2021 specifically for arrays.
This modifies the prelude collisions lint to detect that case and emit a `array_into_iter` lint in that case.
|
|
Fix prelude collision suggestions for glob imported traits.
Fixes https://github.com/rust-lang/rust/issues/88471
cc `@nikomatsakis`
|
|
r=petrochenkov
Fix prelude collision lint suggestion for generics with lifetimes
Fixes https://github.com/rust-lang/rust/issues/88470
cc `@nikomatsakis`
|
|
fix(rustc_parse): correct span in `maybe_whole_expr!`
Fixes #87812
|
|
Add weird return types TAIT test
r? `@oli-obk`
Related to #86727
|
|
Add auto trait leakage TAIT test
r? `@oli-obk`
Related to #86727
|
|
Add inference cycle TAIT test
r? `@oli-obk`
Related to #86727
|
|
Tait nest infer test
r? `@oli-obk`
Related to #86727
|
|
2229: Drop any deref in move closure
Fixes: #88431
r? `@nikomatsakis`
|
|
Fixes #85026
|
|
Don't use `guess_head_span` in `predicates_of` for foreign span
Previously, the result of `predicates_of` for a foreign trait
would depend on the *current* state of the corresponding source
file in the foreign crate. This could lead to ICEs during incremental
compilation, since the on-disk contents of the upstream source file
could potentially change without the upstream crate being recompiled.
Additionally, this ensure that that the metadata we produce for a crate
only depends on its *compiled* upstream dependencies (e.g an rlib or
rmeta file), *not* the current on-disk state of the upstream crate
source files.
|
|
|
|
|
|
|
