fixes https://github.com/rust-lang/rust-clippy/issues/13734
This PR renames `unchecked_duration_subtraction` lint to
`unchecked_time_subtraction` and extends it to include `Duration -
Duration` operations. Previously, it was only `Instant - Duration`.
`Duration - Duration` is a common operation which may panic in the same
way.
Note: This is my first clippy PR, feedback is appreciated.
changelog: [`unchecked_time_subtraction`]: renamed from
`unchecked_duration_subtraction`, extend lint to include subtraction of
a `Duration` with a `Duration`
Bazel requires knowledge of outputs from actions at analysis time,
including file or directory name. In order to work around the lack of
predictable output name for dwo files, we group the dwo files in a
subdirectory of --out-dir as a post-processing step before returning
control to bazel. Unfortunately some debugging workflows rely on
directly opening the dwo file rather than loading the merged dwp file,
and our trick of moving the files breaks those users. We can't just
hardlink the file or copy it, because with remote build execution we
wouldn't end up with the un-moved file copied back to the developer's
workstation. As a fix, we add this unstable flag that causes dwo files
to be written to a build-system-controllable location, which then lets
bazel hoover up the dwo files, but the objects also have the correct
path for the dwo files.
mbe: Simplify check_redundant_vis_repetition
Eliminate a use of `map_or` in favor of a match.
Inline some variable definitions that don't add clarity, and that
prevent short-circuiting.
Add new `tyalias` intra-doc link disambiguator
Fixes https://github.com/rust-lang/rust/issues/146855.
Alternative to rust-lang/rust#146866.
This adds support for a new disambiguator: `tyalias`. I think it's common enough to have type aliases nowaday, so no reason to not be able to have a disambiguator for them.
cc ``@fmease``
r? lolbinarycat
Reduce some uses of `LegacyBang`
- **Switch `dummy_bang` from `LegacyBang` to `Bang`**
- **mbe: Switch dummy extension used for errors from `LegacyBang` to `Bang`**
Use standard attribute logic for allocator shim
Use llfn_attrs_from_instance() to generate the attributes for the allocator shim. This ensures that we generate all the usual attributes (and don't get to find out one-by-one that a certain attribute is important for a certain target). Additionally this will enable emitting the allocator-specific attributes (not included here).
This change is quite awkward because the allocator shim uses SimpleCx, while llfn_attrs_from_instance uses CodegenCx. I've switched it to use SimpleCx plus tcx/sess arguments where necessary. If there's a simpler way to do this, I'd love to know about it...
Stop linking rs{begin,end} objects on x86_64-*-windows-gnu
Until now, x86_64-pc-windows-gnu linked `rsbegin.o` and `rsend.o` just like i686-pc-windows-gnu, even though they were no-ops for it. This was likely done for the simplicity back when it was introduced.
Today the things are different and these startup/end objects harm other features, like `build-std`. Given the demotion of i686-pc-windows-gnu from tier 1, there is no point in hurting x86_64-pc-windows-gnu, which remains a tier 1.
The files are still shipped in case downstream crates expect them, as in case of the unmaintained `xargo`.
Fixes https://github.com/rust-lang/rust/issues/146739
Demote both armebv7r-none-* targets.
OK, slightly more controversial than https://github.com/rust-lang/rust/pull/146520 and https://github.com/rust-lang/rust/pull/146522 - I'd like to drop the bare-metal **big-endian** Armv7-R targets down to Tier 3.
The reason is simple - we cannot test them in https://github.com/rust-embedded/cortex-ar/. This because QEMU support for Big Endian Armv7-R is broken. I tried quite hard, but all the strings I printed with semihosting came out byte swapped (or "etybawa depp") because of how QEMU kludges the access to memory in big-endian mode.
The target also has only a single maintainer. Although, if ````@chrisnc```` wants to put up a case for keeping it at Tier 2 though, I'm happy to hear it!
This PR wil be rebased once https://github.com/rust-lang/rust/pull/146419 completes the queue.
support opaque types in method selection
See my notes in https://hackmd.io/4ILASx3mQ3u_gW9r1JyqCw.
This PR builds on https://github.com/rust-lang/rust/pull/145993 and allows not-yet defined opaque types as self types in the `method_autoderef_chain`.
E.g. for `Box<impl Deref<impl Foo>>` this results in the autoderef chain `Box<impl Deref> -> ?deref_hidden_ty -> ?foo_hidden_ty`. Method selection stays ambiguous if the final autoderef step is still an infer var unless that var is an opaque.
TODO: treating opaques as rigid jank.
r? `@BoxyUwU`
We'll still error due to the `opt_bad_ty` of `method_autoderef_steps`.
This slightly worsens the span of `infer_var.method()` which is now the
same as for `Box::new(infer_var).method()`.
Unlike `structurally_resolve_type`, `probe_op` does not check whether
the infcx is already tainted, so this results in 2 previously not emitted
errors.
