Use `&mut Diagnostic` instead of `&mut DiagnosticBuilder` unless needed
This seems to be the established convention (02ff9e0) when `DiagnosticBuilder` was first added. I am guilty of introducing some of these.
Remove duplicated temporaries creating during box derefs elaboration
Temporaries created with `MirPatch::new_temp` will be declared after
patch application. Remove manually created duplicate declarations.
Removing duplicates exposes another issue. Visitor elaborates
terminator twice and attempts to access new, but not yet available,
local declarations. Remove duplicated call to `visit_terminator`.
Extracted from #99946.
Determine match_has_guard from candidates instead of looking up thir table again
Currently looking through mir build of matches because of interest in deref patterns. Finding some micro-optimizable things.
Check if enum from foreign crate has any non exhaustive variants when attempting a cast
Fixes#91161
As stated in the issue, this will require a crater run as it might break other people's stuff.
Keep going if normalized projection has unevaluated consts in `QueryNormalizer`
#100312 was the wrong approach, I think this is the right one.
When normalizing a type, if we see that it's a projection, we currently defer to `tcx.normalize_projection_ty`, which normalizes the projections away but doesn't touch the unevaluated constants. So now we just continue to fold the type if it has unevaluated constants so we make sure to evaluate those too, if we can.
Fixes#100217Fixes#83972Fixes#84669Fixes#86710Fixes#82268Fixes#73298
Add support for link-flavor rust-lld for macOS
Also refactor iOS, watchOS and tvOS common code.
The ``-arch`` argument was moved to the ``apple_base`` module instead of the target definitions for macOS.
As ld64 requires ``-syslibroot`` to be passed, ``add_apple_sdk`` was modified accordingly.
Rollup of 8 pull requests
Successful merges:
- #99573 (Stabilize backtrace)
- #100069 (Add error if link_ordinal used with unsupported link kind)
- #100086 (Add more `// unit-test`s to MIR opt tests)
- #100332 (Rename integer log* methods to ilog*)
- #100334 (Suggest a missing semicolon before an array)
- #100340 (Iterate generics_def_id_map in reverse order to fix P-critical issue)
- #100345 (docs: remove repetition in `is_numeric` function docs)
- #100352 (Update cargo)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Add error if link_ordinal used with unsupported link kind
The `link_ordinal` attribute only has an affect if the `raw-dylib` link kind is used, so add an error if it is used with any other link kind.
Stabilize backtrace
This PR stabilizes the std::backtrace module. As of #99431, the std::Error::backtrace item has been removed, and so the rest of the backtrace feature is set to be stabilized.
Previous discussion can be found in #72981, #3156.
Stabilized API summary:
```rust
pub mod std {
pub mod backtrace {
pub struct Backtrace { }
pub enum BacktraceStatus {
Unsupported,
Disabled,
Captured,
}
impl fmt::Debug for Backtrace {}
impl Backtrace {
pub fn capture() -> Backtrace;
pub fn force_capture() -> Backtrace;
pub const fn disabled() -> Backtrace;
pub fn status(&self) -> BacktraceStatus;
}
impl fmt::Display for Backtrace {}
}
}
```
`@yaahc`
Set tainted errors bit before emitting coerce suggestions.
Fixes#100246.
#89576 basically got 99% of the way there but the match typechecking code (which calls `coerce_inner`) also needed a similar fix.
Add some high-level docs to `FnCtxt` and `ItemCtxt`
I haven't understood the difference between these before, but
``@compiler-errors`` helped me clear it up. Hopefully this will help other
people who've been confused!
r? `@compiler-errors`
Some "this expression has a field"-related fixes
Each commit does something different and is worth reviewing, but the final diff from `master..HEAD` contains the sum of the changes to the UI tests, since some commits added UI tests "regressions" which were later removed in other commits.
The only change I could see adding on top of this is suppressing `Clone::clone` from the "this expression has a field that has this method" suggestion, since it's so commonly implemented by types that it's not worthwhile suggesting in general.
Error on broken pipe but do not backtrace or ICE
Windows will report a broken pipe as a normal error which in turn `println!` will panic on. Currently this causes rustc to produce a backtrace and ICE. However, this is not a bug with rustc so a backtrace is overly verbose and ultimately unhelpful to the user.
Kind of fixes#98700. Although this is admittedly a bit of a hack because at panic time all we have is a string to inspect. On zulip it was suggested that libstd might someday provide a way to indicate a soft panic but that day isn't today.
consider unnormalized types for implied bounds
extracted, and slightly modified, from #98900
The idea here is that generally, rustc is split into things which can assume its inputs are well formed[^1], and things which have verify that themselves.
Generally most predicates should only deal with well formed inputs, e.g. a `&'a &'b (): Trait` predicate should be able to assume that `'b: 'a` holds. Normalization can loosen wf requirements (see #91068) and must therefore not be used in places which still have to check well formedness. The only such place should hopefully be `WellFormed` predicates
fixes#87748 and #98543
r? `@jackh726` cc `@rust-lang/types`
[^1]: These places may still encounter non-wf inputs and have to deal with them without causing an ICE as we may check for well formedness out of order.
Don't ICE while suggesting updating item path.
When an item isn't found, we may suggest an appropriate import to `use`. Along with that, we also suggest updating the path to work with the `use`. Unfortunately, if the code in question originates from a macro, the span used to indicate which part of the path needs updating may not be suitable and cause an ICE (*). Since, such code is not adjustable directly by the user without modifying the macro, just skip the suggestion in such cases.
(*) The ICE happens because the emitter want to indicate to the user what code to delete by referencing a certain span. But in this case, said span has `lo == hi == 0` which means it thinks it's a dummy span. Adding a space before the proc macro attribute is enough to stop it from ICE'ing but even then the suggestion doesn't really make any sense:
```
help: if you import `DataStore`, refer to it directly
|
1 - #[dbstruct::dbstruct]
1 + #[dbstruct::dbstruct]
```
Since suggestions are best-effort, I just gated this one on `can_be_used_for_suggestions` which catches cases like this.
Fixes#100199
Don't document impossible to call default trait items on impls
Closes#100176
This only skips documenting _default_ trait items on impls, not ones that are written inside the impl block. This is a conservative approach, since I think we should document all items written in an impl block (I guess unless hidden or whatever), but the existence of this new query I added makes this easy to extend to other rustdoc cases.
Implement `#[rustc_default_body_unstable]`
This PR implements a new stability attribute — `#[rustc_default_body_unstable]`.
`#[rustc_default_body_unstable]` controls the stability of default bodies in traits.
For example:
```rust
pub trait Trait {
#[rustc_default_body_unstable(feature = "feat", isssue = "none")]
fn item() {}
}
```
In order to implement `Trait` user needs to either
- implement `item` (even though it has a default implementation)
- enable `#![feature(feat)]`
This is useful in conjunction with [`#[rustc_must_implement_one_of]`](https://github.com/rust-lang/rust/pull/92164), we may want to relax requirements for a trait, for example allowing implementing either of `PartialEq::{eq, ne}`, but do so in a safe way — making implementation of only `PartialEq::ne` unstable.
r? `@Aaron1011`
cc `@nrc` (iirc you were interested in this wrt `read_buf`), `@danielhenrymantilla` (you were interested in the related `#[rustc_must_implement_one_of]`)
P.S. This is my first time working with stability attributes, so I'm not sure if I did everything right 😅
Add option to `mir::MutVisitor` to not invalidate CFG.
This also applies that option to some uses of the visitor. I had considered a design more similar to #100087 in which we detect if the CFG needs to be invalidated, but that is more difficult with the visitor API and so I decided against it. Another alternative to this design is to offer an API for "saving" and "restoring" CFG caches across arbitrary code. Such an API is more general, and so we may eventually want it anyway, but it seems overkill for this use case.
r? `@tmiasko`
