| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Fix stray trait mismatch in `resolve_associated_item` for `AsyncFn`
Copy-paste error meant that we were calling `fn_trait_kind_from_def_id` instead of `async_fn_trait_kind_from_def_id`. But turns out we don't even need to do that, since we already matched the trait def id above.
Fixes #121306
r? oli-obk
|
|
Expand weak alias types before collecting constrained/referenced late bound regions + refactorings
Fixes #114220.
Follow-up to #120780.
r? `@oli-obk`
|
|
Don't use raw parameter types in `find_builder_fn`
We shouldn't really ever be using `EarlyBinder::skip_binder` then performing type equality, since param types will never be equal to other types. When checking compatibility with the signature, we instead create some fresh args.
Fixes #121314
|
|
Don't ICE when hitting overflow limit in fulfillment loop in next solver
As the title says, let's not ICE when hitting the overflow limit in fulfill. On the other hand, we don't want to treat these as true errors, since it means that whether something is considered a true error or an ambiguity is dependent on overflow handling in the solver, which seems not worth it.
Now that we use the presence of true errors in fulfillment for implicit negative coherence, we especially don't want to tie together coherence and overflow.
I guess I could also drain these errors out of fulfillment and put them into some `ambiguities` storage so we could return them in `select_all_or_error` without having to re-process them every time we call `select_where_possible`. Let me know if that's desired.
r? lcnr
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- #121167 (resolve: Scale back unloading of speculatively loaded crates)
- #121196 (Always inline check in `assert_unsafe_precondition` with cfg(debug_assertions))
- #121241 (Implement `NonZero` traits generically.)
- #121278 (Remove the "codegen" profile from bootstrap)
- #121286 (Rename `ConstPropLint` to `KnownPanicsLint`)
- #121291 (target: Revert default to the medium code model on LoongArch targets)
- #121302 (Remove `RefMutL` hack in `proc_macro::bridge`)
- #121318 (Trigger `unsafe_code` lint on invocations of `global_asm`)
Failed merges:
- #121206 (Top level error handling)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
r=Nilstrieb
Trigger `unsafe_code` lint on invocations of `global_asm`
`unsafe_code` already warns about things that don't involve the `unsafe` keyword, e.g. `#[no_mangle]`. This makes it warn on `core::arch::global_asm` too.
Fixes #103078
|
|
Implement `NonZero` traits generically.
Tracking issue: https://github.com/rust-lang/rust/issues/120257
r? ````@dtolnay````
|
|
resolve: Scale back unloading of speculatively loaded crates
Fixes https://github.com/rust-lang/rust/issues/120830 and fixes https://github.com/rust-lang/rust/issues/120909 while still unblocking https://github.com/rust-lang/rust/pull/117772.
I cannot reproduce https://github.com/parasyte/crash-rustc as an UI test for some reason, but I tested all the cases linked above manually.
|
|
Use intrinsics::debug_assertions in debug_assert_nounwind
This is the first item in https://github.com/rust-lang/rust/issues/120848.
Based on the benchmarking in this PR, it looks like, for the programs in our benchmark suite, enabling all these additional checks does not introduce significant compile-time overhead, with the single exception of `Alignment::new_unchecked`. Therefore, I've added `#[cfg(debug_assertions)]` to that one call site, so that it remains compiled out in the distributed standard library.
The trailing commas in the previous calls to `debug_assert_nounwind!` were causing the macro to expand to `panic_nouwnind_fmt`, which requires more work to set up its arguments, and that overhead alone is measured between this perf run and the next: https://github.com/rust-lang/rust/pull/120863#issuecomment-1937423502
|
|
r=davidtwco
Overhaul `Diagnostic` and `DiagnosticBuilder`
Implements the first part of https://github.com/rust-lang/compiler-team/issues/722, which moves functionality and use away from `Diagnostic`, onto `DiagnosticBuilder`.
Likely follow-ups:
- Move things around, because this PR was written to minimize diff size, so some things end up in sub-optimal places. E.g. `DiagnosticBuilder` has impls in both `diagnostic.rs` and `diagnostic_builder.rs`.
- Rename `Diagnostic` as `DiagInner` and `DiagnosticBuilder` as `Diag`.
r? `@davidtwco`
|
|
Always evaluate free constants and statics, even if previous errors occurred
work towards https://github.com/rust-lang/rust/issues/79738
We will need to evaluate static items before the `definitions.freeze()` below, as we will start creating new `DefId`s (for nested allocations) within the `eval_static_initializer` query.
But even without that motivation, this is a good change. Hard errors should always be reported and not silenced if other errors happened earlier.
|
|
return `ty::Error` when equating `ty::Error`
This helps iron out a difference in diagnostics between `Sub` and `Equate` relations, which I'm currently trying to unify.
r? oli-obk
|
|
Add regression test for #103369
The issue was fixed in 1.70.0.
Closes #103369.
|
|
Drive-by `DUMMY_SP` -> `Span` and fmt changes
Noticed these while doing something else. There's no practical change, but it's preferable to use `DUMMY_SP` as little as possible, particularly when we have perfectlly useful `Span`s available.
|
|
Merge `CompilerError::CompilationFailed` and `CompilerError::ICE`.
`CompilerError` has `CompilationFailed` and `ICE` variants, which seems reasonable at first. But the way it identifies them is flawed:
- If compilation errors out, i.e. `RunCompiler::run` returns an `Err`, it uses `CompilationFailed`, which is reasonable.
- If compilation panics with `FatalError`, it catches the panic and uses `ICE`. This is sometimes right, because ICEs do cause `FatalError` panics, but sometimes wrong, because certain compiler errors also cause `FatalError` panics. (The compiler/rustdoc/clippy/whatever just catches the `FatalError` with `catch_with_exit_code` in `main`.)
In other words, certain non-ICE compilation failures get miscategorized as ICEs. It's not possible to reliably distinguish the two cases, so this commit merges them. It also renames the combined variant as just `Failed`, to better match the existing `Interrupted` and `Skipped` variants.
Here is an example of a non-ICE failure that causes a `FatalError` panic, from `tests/ui/recursion_limit/issue-105700.rs`:
```
#![recursion_limit="4"]
#![invalid_attribute]
#![invalid_attribute]
#![invalid_attribute]
#![invalid_attribute]
#![invalid_attribute]
//~^ERROR recursion limit reached while expanding
fn main() {{}}
```
r? ``@spastorino``
|
|
Change leak check and suspicious auto trait lint warning messages
The leak check lint message "this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!" is misleading as some cases may not be phased out and could end being accepted. This is under discussion still.
The suspicious auto trait lint the change in behavior already happened, so the new message is probably more accurate.
r? `@lcnr`
Closes #93367
|
|
|
|
|
|
Currently many diagnostic modifier methods are available on both
`Diagnostic` and `DiagnosticBuilder`. This commit removes most of them
from `Diagnostic`. To minimize the diff size, it keeps them within
`diagnostic.rs` but changes the surrounding `impl Diagnostic` block to
`impl DiagnosticBuilder`. (I intend to move things around later, to give
a more sensible code layout.)
`Diagnostic` keeps a few methods that it still needs, like `sub`,
`arg`, and `replace_args`.
The `forward!` macro, which defined two additional methods per call
(e.g. `note` and `with_note`), is replaced by the `with_fn!` macro,
which defines one additional method per call (e.g. `with_note`). It's
now also only used when necessary -- not all modifier methods currently
need a `with_*` form. (New ones can be easily added as necessary.)
All this also requires changing `trait AddToDiagnostic` so its methods
take `DiagnosticBuilder` instead of `Diagnostic`, which leads to many
mechanical changes. `SubdiagnosticMessageOp` gains a type parameter `G`.
There are three subdiagnostics -- `DelayedAtWithoutNewline`,
`DelayedAtWithNewline`, and `InvalidFlushedDelayedDiagnosticLevel` --
that are created within the diagnostics machinery and appended to
external diagnostics. These are handled at the `Diagnostic` level, which
means it's now hard to construct them via `derive(Diagnostic)`, so
instead we construct them by hand. This has no effect on what they look
like when printed.
There are lots of new `allow` markers for `untranslatable_diagnostics`
and `diagnostics_outside_of_impl`. This is because
`#[rustc_lint_diagnostics]` annotations were present on the `Diagnostic`
modifier methods, but missing from the `DiagnosticBuilder` modifier
methods. They're now present.
|
|
|
|
|
|
This helps iron out a difference between Sub and Equate
|
|
|
|
|
|
deduplicate infer var instantiation
Having 3 separate implementations of one of the most subtle parts of our type system is not a good strategy if we want to maintain a sound type system :sparkles: while working on this I already found some subtle bugs in the existing code, so that's awesome :tada: cc #121159
This was necessary as I am not confident in my nll changes in #119106, so I am first cleaning this up in a separate PR.
r? `@BoxyUwU`
|
|
|
|
Move locks to `sys`
Part of #117276.
r? `@ChrisDenton`
|
|
|
|
Noticed these while doing something else. There's no practical change, but it's preferable to use `DUMMY_SP` as little as possible, particularly when we have perfectlly useful `Span`s available.
|
|
add test for panicking attribute macros
|
|
Add `Future` and `IntoFuture` to the 2024 prelude
Implements rust-lang/rfcs#3509.
|
|
Continue reporting remaining errors instead of silently dropping them
I was too eager to add assertions in https://github.com/rust-lang/rust/pull/120342/files#diff-593003090e0fb5c21f31413ce5feb506e235ec33c4775da88b853980429b9ff1R741
fixes #120864
|
|
Implements RFC 3509.
|
|
|
|
|
|
macro_rules: Preserve all metavariable spans in a global side table
This PR preserves spans of `tt` metavariables used to pass tokens to declarative macros.
Such metavariable spans can then be used in span combination operations like `Span::to` to improve all kinds of diagnostics.
Spans of non-`tt` metavariables are currently kept in nonterminal tokens, but the long term plan is remove all nonterminal tokens from rustc parser and rely on the proc macro model with invisible delimiters (#114647, #67062).
In particular, `NtIdent` nonterminal (corresponding to `ident` metavariables) becomes easy to remove when this PR lands (#119412 does it).
The metavariable spans are kept in a global side table keyed by `Span`s of original tokens.
The alternative to the side table is keeping them in `SpanData` instead, but the performance regressions would be large because any spans from tokens passed to declarative macros would stop being inline and would work through span interner instead, and the penalty would be paid even if we never use the metavar span for the given original span.
(But also see the comment on `fn maybe_use_metavar_location` describing the map collision issues with the side table approach.)
There are also other alternatives - keeping the metavar span in `Token` or `TokenTree`, but associating it with `Span` itsel is the most natural choice because metavar spans are used in span combining operations, and those operations are not necessarily tied to tokens.
|
|
|
|
Add help to `hir_analysis_unrecognized_intrinsic_function`
To help remind forgetful people like me what step they forgot.
(If this just ICE'd, https://github.com/rust-lang/compiler-team/issues/620 style, the stack trace would point me here, but since there's a "nice" error that information is lost.)
|
|
make "invalid fragment specifier" translatable
|
|
|
|
Tracking import use types for more accurate redundant import checking
fixes #117448
By tracking import use types to check whether it is scope uses or the other situations like module-relative uses, we can do more accurate redundant import checking.
For example unnecessary imports in std::prelude that can be eliminated:
```rust
use std::option::Option::Some;//~ WARNING the item `Some` is imported redundantly
use std::option::Option::None; //~ WARNING the item `None` is imported redundantly
```
|
|
situations like module-relative uses, we can do more accurate redundant import checking.
fixes #117448
For example unnecessary imports in std::prelude that can be eliminated:
```rust
use std::option::Option::Some;//~ WARNING the item `Some` is imported redundantly
use std::option::Option::None; //~ WARNING the item `None` is imported redundantly
```
|
|
|
|
Improve wording of `static_mut_ref`
Close #120964
|
|
To help remind forgetful people like me what step they forgot.
|
|
Rollup of 7 pull requests
Successful merges:
- #120526 (rustdoc: Correctly handle long crate names on mobile)
- #121100 (Detect when method call on argument could be removed to fulfill failed trait bound)
- #121160 (rustdoc: fix and refactor HTML rendering a bit)
- #121198 (Add more checks for `unnamed_fields` during HIR analysis)
- #121218 (Fix missing trait impls for type in rustc docs)
- #121221 (AstConv: Refactor lowering of associated item bindings a bit)
- #121237 (Use better heuristic for printing Cargo specific diagnostics)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Use better heuristic for printing Cargo specific diagnostics
It was [reported](https://github.com/rust-lang/rust/issues/82450#issuecomment-1948574677) in the check-cfg call for testing that the Rust for Linux project is setting the `CARGO` env without compiling with it, which is an issue since we are using the `CARGO` env as a proxy for "was launched from Cargo".
This PR switch to the `CARGO_CRATE_NAME` [Cargo env](https://doc.rust-lang.org/cargo/reference/environment-variables.html#environment-variables-cargo-sets-for-crates), which shouldn't collide (as much) with other build systems. I also took the opportunity to consolidate all the checks under the same function.
|
|
Fix missing trait impls for type in rustc docs
Fixes #76736
|
