I.e. the following situation:
```
fn foo() {
mod bar {
fn qux() {
// Prelude path here (e.g. macro use prelude or extern prelude).
}
}
}
```
Those were previously unresolved, because, in order to support `self` and `super` properly, since #15148 we do not ascend block paths when there is a module in between, but only crate def maps register preludes, not block def maps, and we can't change this because block def map prelude can always be overridden by another block. E.g.
```
fn foo() {
struct WithTheSameNameAsPreludeItem;
{
WithTheSameNameAsPreludeItem
}
}
```
Here `WithTheSameNameAsPreludeItem` refer to the item from the top block, but if we would register prelude items in each block the child block would overwrite it incorrectly.
Rename macro `SmartPointer` to `CoercePointee`
As per resolution #129104 we will rename the macro to better reflect the technical specification of the feature and clarify the communication.
- `SmartPointer` is renamed to `CoerceReferent`
- `#[pointee]` attribute is renamed to `#[referent]`
- `#![feature(derive_smart_pointer)]` gate is renamed to `#![feature(derive_coerce_referent)]`.
- Any mention of `SmartPointer` in the file names are renamed accordingly.
r? `@compiler-errors`
cc `@nikomatsakis` `@Darksonn`
Round negative signed integer towards zero in `iN::midpoint`
This PR changes the implementation of `iN::midpoint` (the signed variants) to round negative signed integers **towards zero** *instead* of negative infinity as is currently the case.
This is done so that the obvious expectations[^1] of `midpoint(a, b) == midpoint(b, a)` and `midpoint(-a, -b) == -midpoint(a, b)` are true, which makes the even more obvious implementation `(a + b) / 2` always true.
The unsigned variants `uN::midpoint` (which are being [FCP-ed](https://github.com/rust-lang/rust/pull/131784#issuecomment-2417188117)) already rounds towards zero, so there is no consistency issue.
cc `@scottmcm`
r? `@dtolnay`
[^1]: https://github.com/rust-lang/rust/issues/110840#issuecomment-2336753931
coverage: Don't rely on the custom traversal to find enclosing loops
This opens up the possibility of modifying or removing the custom graph traversal used in coverage counter creation, without losing access to the heuristics that care about a node's enclosing loops.
Actually changing the traversal is left for future work, because this PR on its own doesn't change the emitted coverage mappings at all.
Rollup of 4 pull requests
Successful merges:
- #132123 (allow type-based search on foreign functions)
- #132183 (Fix code HTML items making big blocks if too long)
- #132192 (expand: Stop using artificial `ast::Item` for macros loaded from metadata)
- #132205 (docs: Correctly link riscv32e from platform-support.md)
r? `@ghost`
`@rustbot` modify labels: rollup
docs: Correctly link riscv32e from platform-support.md
Correctly link the riscv32e platform support page.
Just a mistake during the iteration of https://github.com/rust-lang/rust/pull/130555 that was missed in review. Presumably the rv32e-none and rv32i-none pages eventually should get merged, but this is a relatively recent addition to the ISA definition so it is not clear the current RISCV Embedded group has the expertise on-hand... nor did it have their consent.
expand: Stop using artificial `ast::Item` for macros loaded from metadata
You don't need a full `Item` for that, and not using a piece of AST helps with https://github.com/rust-lang/rust/pull/131808.
allow type-based search on foreign functions
fixes https://github.com/rust-lang/rust/issues/131804
preferably will be merged after #129708, but that may take a while to be approved due to being a new feature, whereas this is definitely a bug, and should be fixed.
Replace some LLVMRust wrappers with calls to the LLVM C API
This PR removes the LLVMRust wrapper functions for getting/setting linkage and visibility, and replaces them with direct calls to the corresponding functions in LLVM's C API.
To make this convenient and sound, two pieces of supporting code have also been added:
- A simple proc-macro that derives `TryFrom<u32>` for fieldless enums
- A wrapper type for C enum values returned by LLVM functions, to ensure soundness if LLVM returns an enum value we don't know about
In a few places, the use of safe wrapper functions means that an `unsafe` block is no longer needed, so the affected code has changed its indentation level.
rustc_target: Add pauth-lr aarch64 target feature
Add the pauth-lr target feature, corresponding to aarch64 FEAT_PAuth_LR. This feature has been added in LLVM 19.
It is currently not supported by the Linux hwcap and so we cannot add runtime feature detection for it at this time.
r? `@Amanieu`
Instead of towards negative infinity as is currently the case.
This done so that the obvious expectations of
`midpoint(a, b) == midpoint(b, a)` and
`midpoint(-a, -b) == -midpoint(a, b)` are true, which makes the even
more obvious implementation `(a + b) / 2` true.
https://github.com/rust-lang/rust/issues/110840#issuecomment-2336753931
Downgrade `untranslatable_diagnostic` and `diagnostic_outside_of_impl` to `allow`
Current implementation of translatable diagnostics infrastructure unfortunately causes some friction for compiler contributors. While we don't have a redesign that causes less friction in place, let's downgrade the internal `untranslatable_diagnostic` and `diagnostic_outside_of_impl` lints so we don't indicate to contributors that they *have* to use the current translation infra.
I purposefully left `#[allow(untranslatable_diagnostic)]` and `#[allow(diagnostic_outside_of_impl)]` instances untouched because that seems like unnecessary additional churn.
See <https://github.com/rust-lang/rust/issues/132181> for context.
r? `@davidtwco` (or wg-diagnostics/compiler)
(Big performance change) Do not run lints that cannot emit
Before this change, adding a lint was a difficult matter because it always had some overhead involved. This was because all lints would run, no matter their default level, or if the user had `#![allow]`ed them. This PR changes that. This change would improve both the Rust lint infrastructure and Clippy, but Clippy will see the most benefit, as it has about 900 registered lints (and growing!)
So yeah, with this little patch we filter all lints pre-linting, and remove any lint that is either:
- Manually `#![allow]`ed in the whole crate,
- Allowed in the command line, or
- Not manually enabled with `#[warn]` or similar, and its default level is `Allow`
As some lints **need** to run, this PR also adds **loadbearing lints**. On a lint declaration, you can use the ``@eval_always` = true` marker to label it as loadbearing. A loadbearing lint will never be filtered (it will always run)
Fixes#106983
