increment depth of nested obligations
properly fixes the root cause of #109268. While we didn't get hangs here before, I ended up encountering its root cause again with #138785.
r? types
Note potential but private items in show_candidates
Closes#138626 .
We should add potential private items to give ample hints.
And for the other seemingly false positive ` pub use crate:1️⃣:Foo;` should be kept because we don't know if the user wants to import other module's items or not, and therefore should be given the full option to do so.
r? compiler
remove `feature(inline_const_pat)`
Summarizing https://rust-lang.zulipchat.com/#narrow/channel/144729-t-types/topic/remove.20feature.28inline_const_pat.29.20and.20shared.20borrowck.
With https://github.com/rust-lang/types-team/issues/129 we will start to borrowck items together with their typeck parent. This is necessary to correctly support opaque types, blocking the new solver and TAIT/ATPIT stabilization with the old one. This means that we cannot really support `inline_const_pat` as they are implemented right now:
- we want to typeck inline consts together with their parent body to allow inference to flow both ways and to allow the const to refer to local regions of its parent.This means we also need to borrowck the inline const together with its parent as that's necessary to properly support opaque types
- we want the inline const pattern to participate in exhaustiveness checking
- to participate in exhaustiveness checking we need to evaluate it, which requires borrowck, which now relies on borrowck of the typeck root, which ends up checking exhaustiveness again. **This is a query cycle**.
There are 4 possible ways to handle this:
- stop typechecking inline const patterns together with their parent
- causes inline const patterns to be different than inline const exprs
- prevents bidirectional inference, we need to either fail to compile `if let const { 1 } = 1u32` or `if let const { 1u32 } = 1`
- region inference for inline consts will be harder, it feels non-trivial to support inline consts referencing local regions from the parent fn
- inline consts no longer participate in exhaustiveness checking. Treat them like `pat if pat == const { .. }` instead. We then only evaluate them after borrowck
- difference between `const { 1 }` and `const FOO: usize = 1; match x { FOO => () }`. This is confusing
- do they carry their weight if they are now just equivalent to using an if-guard
- delay exhaustiveness checking until after borrowck
- should be possible in theory, but is a quite involved change and may have some unexpected challenges
- remove this feature for now
I believe we should either delay exhaustiveness checking or remove the feature entirely. As moving exhaustiveness checking to after borrow checking is quite complex I think the right course of action is to fully remove the feature for now and to add it again once/if we've got that implementation figured out.
`const { .. }`-expressions remain stable. These seem to have been the main motivation for https://github.com/rust-lang/rfcs/issues/2920.
r? types
cc `@rust-lang/types` `@rust-lang/lang` #76001
`ast::Item` has an `ident` field.
- It's always non-empty for these item kinds: `ExternCrate`, `Static`,
`Const`, `Fn`, `Mod`, `TyAlias`, `Enum`, `Struct`, `Union`,
`Trait`, `TraitAlias`, `MacroDef`, `Delegation`.
- It's always empty for these item kinds: `Use`, `ForeignMod`,
`GlobalAsm`, `Impl`, `MacCall`, `DelegationMac`.
There is a similar story for `AssocItemKind` and `ForeignItemKind`.
Some sites that handle items check for an empty ident, some don't. This
is a very C-like way of doing things, but this is Rust, we have sum
types, we can do this properly and never forget to check for the
exceptional case and never YOLO possibly empty identifiers (or possibly
dummy spans) around and hope that things will work out.
The commit is large but it's mostly obvious plumbing work. Some notable
things.
- `ast::Item` got 8 bytes bigger. This could be avoided by boxing the
fields within some of the `ast::ItemKind` variants (specifically:
`Struct`, `Union`, `Enum`). I might do that in a follow-up; this
commit is big enough already.
- For the visitors: `FnKind` no longer needs an `ident` field because
the `Fn` within how has one.
- In the parser, the `ItemInfo` typedef is no longer needed. It was used
in various places to return an `Ident` alongside an `ItemKind`, but
now the `Ident` (if present) is within the `ItemKind`.
- In a few places I renamed identifier variables called `name` (or
`foo_name`) as `ident` (or `foo_ident`), to better match the type, and
because `name` is normally used for `Symbol`s. It's confusing to see
something like `foo_name.name`.
`expand_test_case` looks for any item with a `#[test_case]` attribute
and adds a `test_path_symbol` attribute to it while also fiddling with
the item's ident's span.
This is pretty weird, because `#[test_case]` is only valid on
`fn`/`const`/`static` items, as far as I can tell. But you don't
currently get an error or warning if you use it on other kinds of items.
This commit changes things so that a `#[test_case]` item is modified
only if it is `fn`/`const`/`static`. This is relevant for moving idents
from `Item` to `ItemKind`, because some item kinds don't have an ident,
e.g. `impl` blocks.
The commit also does the following.
- Renames a local variable `test_id` as `test_ident`.
- Changes a `const` to `static` in
`tests/ui/custom_test_frameworks/full.rs` to give the `static` case
some test coverage.
- Adds a `struct` and `impl` to the same test to give some test coverage
to the non-affected item kinds. These have a `FIXME` comment
identifying the weirdness here. Hopefully this will be useful
breadcrumbs for somebody else in the future.
`FmtVisitor::visit_mac` has an `Option<Ident>` arg which is always
either `None` or `Some(kw::Empty)`, because `ItemKind::MacCall` always
has an empty ident. This value is passed through various functions until
it reaches `rewrite_macro_name`, which treats `None` and
`Some(kw::Empty)` the same.
In other words, the argument is useless. This commit removes it. There
is no change in behaviour. The commit also changes a few `symbol::Ident`
occurrences to `Ident` in `macros.rs`; `Symbol` is imported in that file
so `Ident` might as well be, too.
(This is a good example of why it's a bad idea for `Itemt` to have an
`ident` field when various item kinds don't have an identifier. It's
easy to get confused when "empty identifier" is used to mean "no
identifier". This will be fixed in a subsequent commit.)
Instead of putting the item inside it, just pass the ident and
visibility (the only things needed) alongside it where necessary.
This helps with the next commit, which will move the ident's location.
Specifically, it gets rid of the `match visitor_kind` in
`rewrite_type_alias`.
This is a way to shrink call spans that doesn't involve mixing different spans,
and avoids overlap with argument spans.
This patch also removes some low-value comments that were causing rustfmt to
ignore the match arms.
This test is intended to demonstrate that a particular macro-argument span
doesn't get lost during span-refinement, but it turns out that span-extraction
currently doesn't yield any MIR spans for this position.
This patch therefore tweaks the test to add a function call in that position,
so that it still remains relevant to span refinement.
Remove fragile equal-pointers-unequal/*/print3.rs tests.
These tests were added in #127003
The print3.rs tests stop working when I change implementation details of format_args!(). (For example, in https://github.com/rust-lang/rust/pull/139175 and https://github.com/rust-lang/rust/pull/139135). These tests shouldn't rely on such implementation details. It gets in the way for format_args!() improvements.
If they test anything that aren't already covered by the other tests in this directory, they should be expressed in a less fragile way that doesn't rely on internal details of format_args!().
cc ``@GrigorenkoPV,`` author of these tests.
tidy: properly check for orphaned unstable_book pages
This also recommends using underscores - something that took me a little bit too long to figure out.
Note: this PR deletes the page `src/doc/unstable-book/src/library-features/c-variadic.md`. The page `src/doc/unstable-book/src/lang-features/c-variadic.md` remains.
Fix `armv7-sony-vita-newlibeabihf` LLVM target triple
It was previously normalized by LLVM to `thumbv7a-vita-unknown-eabihf` (can be seen with `clang -target thumbv7a-vita-eabihf -v`), which seems wrong, as Vita is the OS name.
Motivation: To make it easier to verify that [`cc-rs`' conversion from `rustc` to Clang/LLVM triples](https://github.com/rust-lang/cc-rs/issues/1431) is correct.
CC target maintainers ``@nikarh,`` ``@pheki`` and ``@ZetaNumbers.``
r? jieyouxu
