Add `rustc_deny_explicit_impl`
Also adjust `E0322` error message to be more general, since it's used for `DiscriminantKind` and `Pointee` as well.
Also add `rustc_deny_explicit_impl` on the `Tuple` and `Destruct` marker traits.
Remove unused symbols and diagnostic items
As the title suggests, this removes unused symbols from `sym::` and `#[rustc_diagnostic_item]` annotations that weren't mentioned anywhere.
Originally I tried to use grep, to find symbols and item names that are never mentioned via `sym::name`, however this produced a lot of false positives (?), for example clippy matching on `Symbol::as_str` or macros "implicitly" adding `sym::`. I ended up fixing all these false positives (?) by hand, but tbh I'm not sure if it was worth it...
Add the `#[derive_const]` attribute
Closes#102371. This is a minimal patchset for the attribute to work. There are no restrictions on what traits this attribute applies to.
r? `````@oli-obk`````
Add support for custom mir
This implements rust-lang/compiler-team#564 . Details about the design, motivation, etc. can be found in there.
r? ```@oli-obk```
Avoid possible infinite loop when next_point reaching the end of file
Fixes#103451
If we return a span with `lo` = `hi`, `span_to_snippet` will always get `Ok("")`, which may introduce infinite loop if we don't care.
This PR make `find_width_of_character_at_span` return `width` with 1, so that `span_to_snippet` will get an `Err`.
Enable varargs support for calling conventions other than C or cdecl
This patch makes it possible to use varargs for calling conventions,
which are either based on C (efiapi) or C is based on them (sysv64 and win64).
Also pinging ``@phlopsi,`` because he noticed first this oversight when writing a library for UEFI.
Fix line numbers for MIR inlined code
`should_collapse_debuginfo` detects if the specified span is part of a
macro expansion however it does this by checking if the span is anything
other than a normal (non-expanded) kind, then the span sequence is
walked backwards to the root span.
This doesn't work when the MIR inliner inlines code as it creates spans
with expansion information set to `ExprKind::Inlined` and results in the
line number being attributed to the inline callsite rather than the
normal line number of the inlined code.
Fixes#103068
Shorten the `lookup_line` code slightly
The `match` looks like it's exactly the same as `checked_sub(1)`, so we might as well see if perf says we can just do that to save a couple lines.
This patch makes it possible to use varargs for calling conventions,
which are either based on C (like efiapi) or C is based
on them (for example sysv64 and win64).
Fix the bug of next_point in source_map
There is a bug in `next_point`, the new span won't move to next position when be called in the first time.
For this reason, our current code is working like this:
1. When we really want to move to the next position, we called two times of `next_point`
2. Some code which use `next_point` actually done the same thing with `shrink_to_hi`
This fix make sure when `next_point` is called, span will move with the width at least 1, and also work correctly in the scenario of multiple bytes.
Ref: https://github.com/rust-lang/rust/pull/103140#discussion_r997710998
r? `@davidtwco`
`should_collapse_debuginfo` detects if the specified span is part of a
macro expansion however it does this by checking if the span is anything
other than a normal (non-expanded) kind, then the span sequence is
walked backwards to the root span.
This doesn't work when the MIR inliner inlines code as it creates spans
with expansion information set to `ExprKind::Inlined` and results in the
line number being attributed to the inline callsite rather than the
normal line number of the inlined code.
Add missing documentation for FileNameDisplayPreference variants
Took me a while to find the information when I needed it so hopefully it should save some time for the next ones.
r? ``@thomcc``
Manually order `DefId` on 64-bit big-endian
`DefId` uses different field orders on 64-bit big-endian vs. others, in
order to optimize its `Hash` implementation. However, that also made it
derive different lexical ordering for `PartialOrd` and `Ord`. That
caused spurious differences wherever `DefId`s are sorted, like the
candidate sources list in `report_method_error`.
Now we manually implement `PartialOrd` and `Ord` on 64-bit big-endian to
match the same lexical ordering as other targets, fixing at least one
test, `src/test/ui/methods/method-ambig-two-traits-cross-crate.rs`.
Add `#[rustc_safe_intrinsic]`
This PR adds the `#[rustc_safe_intrinsic]` attribute as mentionned on Zulip. The goal of this attribute is to avoid keeping a list of symbols as the source for stable intrinsics, and instead rely on an attribute. This is similar to `#[rustc_const_stable]` and `#[rustc_const_unstable]`, which among other things, are used to mark the constness of intrinsic functions.
Rollup of 8 pull requests
Successful merges:
- #100747 (Add long description and test for E0311)
- #102232 (Stabilize bench_black_box)
- #102288 (Suggest unwrapping `???<T>` if a method cannot be found on it but is present on `T`.)
- #102338 (Deny associated type bindings within associated type bindings)
- #102347 (Unescaping cleanups)
- #102348 (Tweak `FulfillProcessor`.)
- #102378 (Use already resolved `self_ty` in `confirm_fn_pointer_candidate`)
- #102380 (rustdoc: remove redundant mobile `.source > .sidebar` CSS)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
`DefId` uses different field orders on 64-bit big-endian vs. others, in
order to optimize its `Hash` implementation. However, that also made it
derive different lexical ordering for `PartialOrd` and `Ord`. That
caused spurious differences wherever `DefId`s are sorted, like the
candidate sources list in `report_method_error`.
Now we manually implement `PartialOrd` and `Ord` on 64-bit big-endian to
match the same lexical ordering as other targets, fixing at least one
test, `src/test/ui/methods/method-ambig-two-traits-cross-crate.rs`.
bors