This is needed to track anon const parents properly once we implement
`ConstArgKind::Path` (which requires moving anon const def-creation
outside of `DefCollector`):
Why do we need this in addition to [`Self::current_hir_id_owner`]?
Currently (as of June 2024), anonymous constants are not HIR owners;
however, they do get their own DefIds. Some of these DefIds have to be
created during AST lowering, rather than def collection, because we
can't tell until after name resolution whether an anonymous constant
will end up instead being a [`rustc_hir::ConstArgKind::Path`]. However,
to compute which generics are available to an anonymous constant nested
inside another, we need to make sure that the parent is recorded as the
parent anon const, not the enclosing item. So we need to track parent
defs differently from HIR owners, since they will be finer-grained in
the case of anon consts.
Clean up more comments near use declarations
#125443 will reformat all use declarations in the repository. There are a few edge cases involving comments on use declarations that require care. This PR fixes them up so #125443 can go ahead with a simple `x fmt --all`. A follow-up to #126717.
r? ``@cuviper``
... this is a special attribute that was made to be a target-feature in
LLVM 18+, but in all previous versions, this "feature" is a naked
attribute. We will have to handle this situation differently than all
other target-features.
There are some comments describing multiple subsequent `use` items. When
the big `use` reformatting happens some of these `use` items will be
reordered, possibly moving them away from the comment. With this
additional level of formatting it's not really feasible to have comments
of this type. This commit removes them in various ways:
- merging separate `use` items when appropriate;
- inserting blank lines between the comment and the first `use` item;
- outright deletion (for comments that are relatively low-value);
- adding a separate "top-level" comment.
We also entirely skip formatting for four library files that contain
nothing but `pub use` re-exports, where reordering would be painful.
Invert infer `error_reporting` mod struture
Parallel change to #127493, which moves `rustc_infer::infer::error_reporting` to `rustc_infer::error_reporting::infer`. After this, we should just be able to merge this into `rustc_trait_selection::error_reporting::infer`, and pull down `TypeErrCtxt` into that crate. 👍
r? lcnr
Deny keyword lifetimes pre-expansion
https://github.com/rust-lang/rust/pull/126452#issuecomment-2179464266
> Secondly, we confirmed that we're OK with moving the validation of keywords in lifetimes to pre-expansion from post-expansion. We similarly consider this a bug fix. While the breakage of the convenience feature of the with_locals crate that relies on this is unfortunate, and we wish we had not overlooked this earlier for that reason, we're fortunate that the breakage is contained to only one crate, and we're going to accept this breakage as the extra complexity we'd need to carry in the compiler to work around this isn't deemed worth it.
T-lang considers it to be a bugfix to deny `'keyword` lifetimes in the parser, rather than during AST validation that only happens post-expansion. This has one breakage: https://github.com/rust-lang/rust/pull/126452#issuecomment-2171654756
This probably should get lang FCP'd just for consistency.
Delegation: support coercion for target expression
(solves https://github.com/rust-lang/rust/issues/118212#issuecomment-2160723092)
The implementation consist of 2 parts. Firstly, method call is generated instead of fully qualified call in AST->HIR lowering if there were no generic arguments or `Qpath` were provided. These restrictions are imposed due to the loss of information after desugaring. For example in
```rust
trait Trait {
fn foo(&self) {}
}
reuse <u8 as Trait>::foo;
```
We would like to generate such a code:
```rust
fn foo<u8: Trait>(x: &u8) {
x.foo(x)
}
```
however, the signature is inherited during HIR analysis where `u8` was discarded.
Then, we probe the single pre-resolved method.
P.S In the future, we would like to avoid restrictions on the callee path by `Self` autoref/autoderef in fully qualified calls, but at the moment it didn't work out.
r? `@petrochenkov`
Sync ar_archive_writer to LLVM 18.1.3
From LLVM 15.0.0-rc3. This adds support for COFF archives containing Arm64EC object files and has various fixes for AIX big archive files.
Various ast validation simplifications
Changes pulled out of https://github.com/rust-lang/rust/pull/127524
These are needed to make ast validation a mutable visitor, as we can't keep immutable references to the AST around in that case. But I think they are simplifying things in general and can stand on their own
Fix a bunch of sites that were walking instead of visiting, making it impossible for visitor impls to look at these values
This doesn't affects anything right now, but a `MutVisitor` impl could be surprised by this.
The reason this doesn't affect anything is that no one overrrides `visit_lifetime` or `visit_param_bounds` currently.
Make ErrorGuaranteed discoverable outside types, consts, and lifetimes
types like `PatKind` could contain `ErrorGuaranteed`, but not return them via `tainted_by_errors` or `error_reported` (see https://github.com/rust-lang/rust/pull/127687#discussion_r1679027883). Now this happens, but it's a bit fragile as you can see with the `TypeSuperVisitable for Ty` impl.
We will catch any problems around Ty, Region or Const at runtime with an assert, and everything using derives will not have such issues, as it will just invoke the `TypeVisitable for ErrorGuaranteed` impl
Fix and enforce `unsafe_op_in_unsafe_fn` in compiler
In preparation for edition 2024, this PR previews the fallout of enabling the `unsafe_op_in_unsafe_fn` lint in the compiler, since it's defaulting to warn in the new edition (#112038).
The major annoyance comes primarily from the `rustc_codegen_llvm` module, where there's a ton of unsafe calls. I tended to wrap individual calls to unsafe fns in `unsafe {}`, but there a handful of places I chose to just wrap several calls in an `unsafe {}` block just because it would've been excessive to wrap each call individually.
This doesn't enable the lint for the standard library, since I'm not totally certain what T-libs prefers w/ this lint.
match lowering: Use an iterator to find `expand_until`
A small cleanup that I noticed while looking at #127164.
This makes it easier to see that the split point is always the index after the found item, or the whole list if no stopping point was found.
r? `@Nadrieril`
when the `C-cmse-nonsecure-call` ABI is used, arguments and return values must be passed via registers. Failing to do so (i.e. spilling to the stack) causes an LLVM error down the line, but now rustc will properly emit an error a bit earlier in the chain
Make sure trait def ids match before zipping args in `note_function_argument_obligation`
Fixes#126416Fixes#127745
Didn't add both tests b/c I felt like it was unnecessary.
match lowering: Move `MatchPair` tree creation to its own module
This makes it easier to see that `MatchPair::new` has only one non-recursive caller, because the recursive callers are all in this module. No functional changes.
---
I have used `git diff --color-moved` to verify that the moved code is identical to the old code, except for reduced visibility on the helper methods.
It only has two call sites, and it extremely similar to
`Parser::parse_expr_dot_or_call_with`, in both name and behaviour. The
only difference is the latter has an `attrs` argument and an
`ensure_sufficient_stack` call. We can pass in an empty `attrs` as
necessary, as is already done at some `parse_expr_dot_or_call_with` call
sites.
