Add docs for question mark operator for Option
As a beginner learning rust, it took me a while to figure out what `?` was doing with Options. I think the documentation of this could be improved.
I've used the question mark documentation from the `Result` type as a template here, and tried to come up with a simple example as well.
Some attributes are only valid on function items. When checking these
attributes, codegen_attrs previously sometimes called `fn_sig` on the
item they were attached to without first ensuring that the item was a
function. This led to an ICE (#105594), since `fn_sig` can
only be called on functions.
After this change, we skip calling `fn_sig` if the item the attribute is
attached to must be a function but invalidly isn't, because `check_attr`
will reject such cases without codegen_attrs's intervention.
Combine `ty::Projection` and `ty::Opaque` into `ty::Alias`
Implements https://github.com/rust-lang/types-team/issues/79.
This PR consolidates `ty::Projection` and `ty::Opaque` into a single `ty::Alias`, with an `AliasKind` and `AliasTy` type (renamed from `ty::ProjectionTy`, which is the inner data of `ty::Projection`) defined as so:
```
enum AliasKind {
Projection,
Opaque,
}
struct AliasTy<'tcx> {
def_id: DefId,
substs: SubstsRef<'tcx>,
}
```
Since we don't have access to `TyCtxt` in type flags computation, and because repeatedly calling `DefKind` on the def-id is expensive, these two types are distinguished with `ty::AliasKind`, conveniently glob-imported into `ty::{Projection, Opaque}`. For example:
```diff
match ty.kind() {
- ty::Opaque(..) =>
+ ty::Alias(ty::Opaque, ..) => {}
_ => {}
}
```
This PR also consolidates match arms that treated `ty::Opaque` and `ty::Projection` identically.
r? `@ghost`
Rollup of 7 pull requests
Successful merges:
- #105147 (Allow unsafe through inline const)
- #105438 (Move some codegen-y methods from `rustc_hir_analysis::collect` -> `rustc_codegen_ssa`)
- #105464 (Support #[track_caller] on async closures)
- #105476 (Change pattern borrowing suggestions to be verbose and remove invalid suggestion)
- #105500 (Make some diagnostics not depend on the source of what they reference being available)
- #105628 (Small doc fixes)
- #105659 (Don't require owned data in `MaybeStorageLive`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Don't require owned data in `MaybeStorageLive`
Small improvement that avoids a clone. I don't expect this to have any noticeable perf effects, but better to have it than not to.
r? ``@tmiasko``
Change pattern borrowing suggestions to be verbose and remove invalid suggestion
Synthesize a more accurate span and use verbose suggestion output to
make the message clearer.
Do not suggest borrowing binding in pattern in let else. Fix#104838.
Move some codegen-y methods from `rustc_hir_analysis::collect` -> `rustc_codegen_ssa`
Unclear if they should live here, but they seem codegen-y enough, and `rustc_hir_analysis::collect` is extremely long, so it should probably lose some methods.
Allow unsafe through inline const
Handle similar to closures.
Address https://github.com/rust-lang/rust/pull/104087#issuecomment-1324173328
Note that this PR does not fix the issue for `unsafe { [0; function_requiring_unsafe()] }`. This is fundamentally unfixable for MIR unsafeck IMO.
This PR also does not fix unsafety checking for inline const in pattern position. It actually breaks it, allowing unsafe functions to be used in inline const in pattern position without unsafe blocks. Inline const in pattern position is not visible in MIR so ignored by MIR unsafety checking (currently it is also not checked by borrow checker, which is the reason why it's considered an incomplete feature).
`@rustbot` label: +T-lang +F-inline_const
Simpler diagnostic when passing arg to closure and missing borrow
fixes#64915
I followed roughly the instructions and the older PR #76362.
The number of references for the expected and the found types will be compared and depending on which has more the diagnostic will be emitted.
I'm not quite sure if my approach with the many `span_bug!`s is good, it could lead to some ICEs. Would it be better if those errors are ignored?
As far as I know the following code works similarly but in a different context. Is this probably reusable since it looks like it would emit better diagnostics?
a688a0305f/compiler/rustc_hir_analysis/src/check/demand.rs (L713-L1061)
When running the tests locally, a codegen test failed. Is there something I can/ should do about that?
If you have some improvements/ corrections please say so and I will happily include them.
r? `@estebank` (as you added the mentoring instructions to the issue)
Remove previously existing fallback that tried to give a good turbofish
suggestion, `need_type_info` is already good enough.
Special case `::<Vec<_>` suggestion for `Iterator::collect`.
* Merge the color-changing block into the regular rules, which was
probably written that way because it used to be in the theme files,
but has no reason to be written this way now that it's in rustdoc.css
* Get rid of redundant `display: block`, since `position: absolute`
blockifies the layout anyway.
