It's crazy to have the integer methods in something close to random
order.
The reordering makes the gaps clear: `const_i64`, `const_i128`,
`const_isize`, and `const_u16`. I guess they just aren't needed.
In `get_fn` there is a complicated set of if/elses to determine if
`hidden` visibility should be applied. There are five calls to
`LLVMRustSetVisibility` and some repetition in the comments.
This commit streamlines it a bit:
- Computes `hidden` and then uses it to determine if a single call to
`LLVMRustSetVisibility` occurs.
- Converts some of the if/elses into boolean expressions.
- Removes the repetitive comments.
Overall this makes it quite a bit shorter, and I find it easier to read.
Never patterns constitute a read for unsafety
This code is otherwise unsound if we don't emit an unsafety error here. Noticed when fixing #130528, but it's totally unrelated.
r? `@Nadrieril`
Check params for unsafety in THIR
Self-explanatory. I'm not surprised this was overlooked, given the way that THIR visitors work. Perhaps we should provide a better entrypoint.
Fixes#130528
Further improve diagnostics for expressions in pattern position
Follow-up of #118625, see #121697.
```rs
fn main() {
match 'b' {
y.0.0.1.z().f()? as u32 => {},
}
}
```
Before:
```
error: expected one of `=>`, ``@`,` `if`, or `|`, found `.`
--> src/main.rs:3:10
|
3 | y.0.0.1.z().f()? as u32 => {},
| ^ expected one of `=>`, ``@`,` `if`, or `|`
```
After:
```
error: expected a pattern, found an expression
--> src/main.rs:3:9
|
3 | y.0.0.1.z().f()? as u32 => {},
| ^^^^^^^^^^^^^^^^^^^^^^^ arbitrary expressions are not allowed in patterns
|
help: consider moving the expression to a match arm guard
|
3 | val if val == y.0.0.1.z().f()? as u32 => {},
| ~~~ +++++++++++++++++++++++++++++++++
help: consider extracting the expression into a `const`
|
2 + const VAL: /* Type */ = y.0.0.1.z().f()? as u32;
3 ~ match 'b' {
4 ~ VAL => {},
|
help: consider wrapping the expression in an inline `const` (requires `#![feature(inline_const_pat)]`)
|
3 | const { y.0.0.1.z().f()? as u32 } => {},
| +++++++ +
```
---
r? fmease
`@rustbot` label +A-diagnostics +A-parser +A-patterns +C-enhancement
Update the minimum external LLVM to 18
With this change, we'll have stable support for LLVM 18 and 19.
For reference, the previous increase to LLVM 17 was #122649.
cc `@rust-lang/wg-llvm`
r? nikic
Reduce confusion about `make_indirect_byval` by renaming it
As part of doing so, remove the incorrect handling of the wasm target's `make_indirect_byval` (i.e. using it at all).
Gate `repr(Rust)` correctly on non-ADT items
#114201 added `repr(Rust)` but didn't add any attribute validation to it like `repr(C)` has, to only allow it on ADT items.
I consider this code to be nonsense, for example:
```
#[repr(Rust)]
fn foo() {}
```
Reminder that it's different from `extern "Rust"`, which *is* valid on function items. But also this now disallows `repr(Rust)` on modules, impls, traits, etc.
I'll crater it, if it looks bad then I'll add an FCW.
---
https://github.com/rust-lang/rust/labels/relnotes: Compatibility (minor breaking change).
Do not ICE with incorrect empty suggestion
When we have two types with the same name, one without type parameters and the other with type parameters and a derive macro, we were before incorrectly suggesting to remove type parameters from the former, which ICEd because we were suggesting to remove nothing. We now gate against this.
The output is still not perfect. E0107 should explicitly detect this case and provide better context, but for now let's avoid the ICE.
Fix#108748.
This commit adds basic support for reborrowing `Pin` types in argument
position. At the moment it only supports reborrowing `Pin<&mut T>` as
`Pin<&mut T>` by inserting a call to `Pin::as_mut()`, and only in
argument position (not as the receiver in a method call).
The previous name is just an LLVMism, which conveys almost nothing about
what is actually meant by the function relative to the ABI.
In doing so, remove an already-addressed FIXME.
When we have two types with the same name, one without type parameters and the other with type parameters and a derive macro, we were before incorrectly suggesting to remove type parameters from the former, which ICEd because we were suggesting to remove nothing. We now gate against this.
The output is still not perfect. E0107 should explicitly detect this case and provide better context, but for now let's avoid the ICE.
doc: the source of `LetStmt` can also be `AssignDesugar`
For example, the two following statements are desugared into a block whose `LetStmt` source is `AssignDesugar`:
```rust
_ = ignoring_some_result();
(a, b) = (b, a);
```
llvm-wrapper: adapt for LLVM API changes, second try
This is a re-work of https://github.com/rust-lang/rust/pull/129749 after LLVM brought back the APIs used by rust.
No functional changes intended.
`@rustbot` label: +llvm-main
r? `@nikic`
cc: `@tmandry`
Improve handling of raw-idents in check-cfg
This PR improves the handling of raw-idents in the check-cfg diagnostics.
In particular the list of expected names and the suggestion now correctly take into account the "keyword-ness" of the ident, and correctly prefix the ident with `r#` when necessary.
`@rustbot` labels +F-check-cfg
For example, the two following statements are desugared into a block
whose `LetStmt` source is `AssignDesugar`:
```rust
_ = ignoring_some_result();
(a, b) = (b, a);
```
Rollup of 3 pull requests
Successful merges:
- #130466 (tests: add repr/transparent test for aarch64)
- #130468 (Make sure that def id <=> lang item map is bidirectional)
- #130499 (Add myself to the libs review rotation)
r? `@ghost`
`@rustbot` modify labels: rollup
Make sure that def id <=> lang item map is bidirectional
Self-explanatory from assertion. Just makes sure of an invariant that I forgot to enforce when I added `LanguageItems::from_def_id`.
Fix circular fn_sig queries to correct number of args for methods
Fixes#130400. This was a [debug assert](28e8f01c2a/compiler/rustc_hir_typeck/src/fn_ctxt/checks.rs (L2557)) added to some argument error reporting code in #129320 which verified that the number of params (from the HIR) matched the `matched_inputs` which ultimately come from ty::FnSig. In the reduced test case:
```
fn foo(&mut self) -> _ {
foo()
}
```
There is a circular dependency computing the ty::FnSig -- when trying to compute it, we try to figure out the return value, which again depends on this ty::FnSig. In #105162, this was supported by short-circuiting the cycle by synthesizing a FnSig with error types for parameters. The [code in question](https://github.com/rust-lang/rust/pull/105162/files#diff-a65feec6bfffb19fbdc60a80becd1030c82a56c16b177182cd277478fdb04592R44) computes the number of parameters by taking the number of parameters from the hir::FnDecl and adding 1 if there is an implicit self parameter.
I might be missing a subtlety here, but AFAICT the adjustment for implicit self args is unnecessary and results in one too many args. For example, for this non-errorful code:
```
trait Foo {
fn bar(&self) {}
}
```
The resulting hir::FnDecl and ty::FnSig both have the same number of inputs -- 1. So, this PR removes that adjustment and adds a test for the debug ICE.
r? `@compiler-errors`
Implement a Method to Seal `DiagInner`'s Suggestions
This PR adds a method on `DiagInner` called `.seal_suggestions()` to prevent new suggestions from being added while preserving existing suggestions.
This is useful because currently there is no way to prevent new suggestions from being added to a diagnostic. `.disable_suggestions()` is the closest but it gets rid of all suggestions before and after the call.
Therefore, `.seal_suggestions()` can be used when, for example, misspelled keyword is detected and reported. In such cases, we may want to prevent other suggestions from being added to the diagnostic, as they would likely be meaningless once the misspelled keyword is identified. For context: https://github.com/rust-lang/rust/pull/129899#discussion_r1741307132
To store an additional state, the type of the `suggestions` field in `DiagInner` was changed into a three variant enum. While this change affects files across different crates, care was taken to preserve the existing code's semantics. This is validated by the fact that all UI tests pass without any modifications.
r? chenyukang
Use the same precedence for all macro-like exprs
No need to make these have a different precedence since they're all written like `whatever!(expr)`, and it makes it simpler when adding new macro-based built-in operators in the future.
Don't call `extern_crate` when local crate name is the same as a dependency and we have a trait error
#124944 implemented logic to point out when a trait bound failure involves a *trait* and *type* who come from identically named but different crates. This logic calls the `extern_crate` query which is not valid on `LOCAL_CRATE` cnum, so let's filter that out eagerly.
Fixes#130272Fixes#129184
Encode `coroutine_by_move_body_def_id` in crate metadata
We synthesize the MIR for a by-move body for the `FnOnce` implementation of async closures. It can be accessed with the `coroutine_by_move_body_def_id` query. We weren't encoding this query in the metadata though, nor were we properly recording that synthetic MIR in `mir_keys`, so the `optimized_mir` wasn't getting encoded either!
Stacked on top is a fix to consider `DefKind::SyntheticCoroutineBody` to return true in several places I missed. Specifically, we should consider the def-kind in `fn DefKind::is_fn_like()`, since that's what we were using to make sure we ensure `query mir_inliner_callees` before the MIR gets stolen for the body. This led to some CI failures that were caught by miri but which I added a test for.
Use `Vec` in `rustc_interface::Config::locale_resources`
This allows a third-party tool to injects its own resources, when receiving the config via `rustc_driver::Callbacks::config`.
Fix#128930: Print documentation of CLI options missing their arg
Fix#128930. Failing to give an argument to CLI options which require it now prints something like:
```
$ rustc --print
error: Argument to option 'print' missing
Usage:
--print [crate-name|file-names|sysroot|target-libdir|cfg|check-cfg|calling-conventions|target-list|target-cpus|target-features|relocation-models|code-models|tls-models|target-spec-json|all-target-specs-json|native-static-libs|stack-protector-strategies|link-args|deployment-target]
Compiler information to print on stdout
```
Relate receiver invariantly in method probe for `Mode::Path`
Effectively reverts part of #126128Fixes#126227
This PR changes method probing to use equality for fully path-based method lookup, and subtyping for receiver `.` method lookup.
r? lcnr
Remove semi-nondeterminism of `DefPathHash` ordering from inliner
Déjà vu or something because I kinda thought I had put this PR up before. I recall a discussion somewhere where I think it was `@saethlin` mentioning that this check was no longer needed since we have "proper" cycle detection. Putting that up as a PR now.
This may slighlty negatively affect inlining, since the cycle breaking here means that we still inlined some cycles when the def path hashes were ordered in certain ways, this leads to really bad nondeterminism that makes minimizing ICEs and putting up inliner bugfixes difficult.
r? `@cjgillot` or `@saethlin` or someone else idk
`'mir` is not a good lifetime name in `LocalAnalyzer`, because it's used
on two unrelated fields. `'a` is more standard for a situation like this
(e.g. #130022).
coverage: Clarify some parts of coverage counter creation
This is a series of semi-related changes that are trying to make the `counters` module easier to read, understand, and modify.
For example, the existing code happens to avoid ever using the count for a `TerminatorKind::Yield` node as the count for its sole out-edge (since doing so would be incorrect), but doesn't do so explicitly, so seemingly-innocent changes can result in baffling test failures.
This PR also takes the opportunity to simplify some debug-logging code that was making its surrounding code disproportionately hard to read.
There should be no changes to the resulting coverage instrumentation/mappings, as demonstrated by the absence of changes to the coverage test suite.
layout computation: gracefully handle unsized types in unexpected locations
This PR reworks the layout computation to eagerly return an error when encountering an unsized field where a sized field was expected, rather than delaying a bug and attempting to recover a layout. This is required, because with trivially false where clauses like `[T]: Sized`, any field can possible be an unsized type, without causing a compile error.
Since this PR removes the `delayed_bug` method from the `LayoutCalculator` trait, it essentially becomes the same as the `HasDataLayout` trait, so I've also refactored the `LayoutCalculator` to be a simple wrapper struct around a type that implements `HasDataLayout`.
The majority of the diff is whitespace changes, so viewing with whitespace ignored is advised.
implements https://github.com/rust-lang/rust/pull/123169#issuecomment-2025788480
r? `@compiler-errors` or compiler
fixes https://github.com/rust-lang/rust/issues/123134
fixes https://github.com/rust-lang/rust/issues/124182
fixes https://github.com/rust-lang/rust/issues/126939
fixes https://github.com/rust-lang/rust/issues/127737
Supertraits of `BuilderMethods` are all called `XyzBuilderMethods`.
Supertraits of `CodegenMethods` are all called `XyzMethods`. This commit
changes the latter to `XyzCodegenMethods`, for consistency.
It's a trait that aggregates five other traits. But consider the places
that use it.
- `BuilderMethods`: requires three of the five traits.
- `CodegenMethods`: requires zero(!) of the five traits.
- `BaseTypeMethods`: requires two of the five traits.
- `LayoutTypeMethods`: requires three of the five traits.
- `TypeMembershipMethods`: requires one of the five traits.
This commit just removes it, which makes everything simpler.
It has `Backend` and `Deref` boudns, plus an associated type
`CodegenCx`, and it has a single use. This commit "inlines" it into
`BuilderMethods`, which makes the complicated backend trait situation a
little simpler.
It only needs `Self::Value` and `Self::Type`, so it can be a subtrait of
`BackendTypes`. That is a smaller and simpler trait than `HasCodegen`
(which includes `BackendTypes` and a lot more).
For structs that cannot be unsized, the layout algorithm sometimes moves
unsized fields to the end of the struct, which circumvented the error
for unexpected unsized fields and returned an unsized layout anyway.
This commit makes it so that the unexpected unsized error is always
returned for structs that cannot be unsized, allowing us to remove an
old hack and fixing some old ICE.
Rollup of 3 pull requests
Successful merges:
- #130033 (Don't call `fn_arg_names` query for non-`fn` foreign items in resolver)
- #130282 (Do not report an excessive number of overflow errors for an ever-growing deref impl)
- #130437 (Avoid crashing on variadic functions when producing arg-mismatch errors)
r? `@ghost`
`@rustbot` modify labels: rollup
Avoid crashing on variadic functions when producing arg-mismatch errors
Fixes#130372 by accommodating how variadic functions change the argument list length between HIR body and FnDecls.
Also degrades the zip_eq to a debug_assert! to match other asserts in the area to avoid being disruptive to users. There is at least one other crash in this area I am working on in #130400 and also considering how we might refactor some of this code to hoist some of this logic up higher.
r? `@compiler-errors`
Do not report an excessive number of overflow errors for an ever-growing deref impl
Check that we don't first hit the recursion limit in `get_field_candidates_considering_privacy` before probing for methods when we have a method lookup failure and we want to see if `.field.method()` exists. We also silence overflow error messages if we're probing for methods for diagnostics.
Also renames some functions to make it clearer that they're only for diagnostics, and sprinkle some `Autoderef::silence_errors` around to silence unnecessary overflow errors that come from diagnostics.
Fixes#130224.
Rollup of 4 pull requests
Successful merges:
- #123436 (linker: Allow MSVC to use import libraries following the Meson/MinGW convention)
- #130410 (Don't ICE when generating `Fn` shim for async closure with borrowck error)
- #130412 (Don't ICE when RPITIT captures more method args than trait definition)
- #130436 (Ignore reduce-fadd-unordered on SGX platform)
r? `@ghost`
`@rustbot` modify labels: rollup
Don't ICE when RPITIT captures more method args than trait definition
Make sure we don't ICE when an RPITIT captures more method args than the trait definition, which is not allowed. This was because we were using the wrong def id for error reporting.
Due to the default lifetime capture rules of RPITITs (capturing everything in scope), this is only doable if we use precise capturing, which isn't currently allowed for RPITITs anyways but we still end up reaching the relevant codepaths.
Fixes#129850
