Implement tuples using recursion
Because it is c00l3r™, requires less repetition and can be used as a reference for external people.
This change is non-essential and I am not sure about potential performance impacts so feel free to close this PR if desired.
r? `@petrochenkov`
Move name resolution logic to a dedicated file
The code resolution logic from an Ident is scattered between several files.
The first commits creates `rustc_resolve::probe` module to hold the different mutually recursive functions together. Just a move, no code change.
The following commits attempt to make the logic a bit more readable.
The two fields `last_import_segment` and `unusable_binding` are replaced by function parameters.
In order to manage the fallout, `maybe_` variants of the function are added, dedicated to speculative resolution.
r? `@petrochenkov`
Rustdoc: Discriminate required and provided associated constants and types
Currently, rustdoc merely separates required and provided associated _functions_ (i.e. methods). This PR extends this to constants (fixes#94652) and types. This makes the documentation of all three kinds of associated items more alike and consistent.
As an aside, associated types may actually be provided / have a default when users enable the unstable feature `associated_type_defaults`.
| Before | After |
|---|---|
|  |  |
|  |  |
### `clean::types::ItemKind` modification
* `ItemKind::TypedefItem(.., true)` → `ItemKind::AssocTypeItem(..)`
* `ItemKind::TypedefItem(.., false)` → `ItemKind::TypedefItem(..)`
Further, I added `ItemKind::TyAssoc{Const,Type}Item`, the “required” variant of `ItemKind::Assoc{Const,Type}Item`, analogous to `ItemKind::TyMethodItem` with `ItemKind::MethodItem`. These new variants don't contain new information really, they are just the result of me getting rid of the `Option<_>` field in `AssocConstItem` and `AssocTypeItem`.
**Goal**: Make associated items more consistent.
Originally I thought modifying `ItemKind` was necessary to achieve the new functionality of this PR but in retrospect, it does not. If you don't like the changes to `ItemKind`, I think I _can_ get rid of them.
This change is the root cause of those tiny changes in a lot of different files.
### Concerns and Open Questions
* **breaking changes** to hyperlinks: Some heading IDs change:
* `associated-const` (sic!) -> `{provided,required}-associated-consts`
* `associated-types` -> `{provided,required}-associated-types`
* **verbosity** of the headings _{Required,Provided} Associated {Constants,Types}_
* For some files, I am not sure if the changes I made are correct. So please take extra care when reviewing `conversions.rs` (conversion to JSON), `cache.rs`/`fold_item`, `stripper.rs`/`fold_item`, `check_doc_test_visibility.rs`/`should_have_doc_example`, `collect_intra_doc_links.rs`/`from_assoc_item`
* JSON output: I still map `AssocTypeItem`s to `Typedef` etc. (FIXME)
Rollup of 4 pull requests
Successful merges:
- #95783 (rustdoc doctest: include signal number in exit status)
- #95794 (`parse_tt`: a few more tweaks)
- #95963 ([bootstrap] Grab the right FileCheck binary for dist when cross-compiling.)
- #95975 (Don't test -Cdefault-linker-libraries=yes when cross compiling.)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
[bootstrap] Grab the right FileCheck binary for dist when cross-compiling.
Fixes#95862
We were using the target dir for all the other LLVM tools (`llvm-config`, `llvm-ar`, etc) but the build target dir for `FileCheck`. This meant for targets which are cross-compiled, we were copying the wrong binary.
Skip `Lazy` for some metadata tables
Some metadata tables encode their entries indirectly, through the Lazy construct. This is useful when dealing with variable length encoding, but incurs the extra cost of one u32.
Meanwhile, some fields can be encoded in a single u8, or can use a short fixed-length encoding. This PR proposes to do so, and avoid the overhead.
`impl const Default for Box<[T]>` and `Box<str>`
The unstable `const_default_impls` (#87864) already include empty `Vec<T>` and `String`. Now we extend that concept to `Box<[T]>` and `Box<str>` as well.
This obviates a hack in `rustc_ast`'s `P::<[T]>::new`.
feat: Allow usage of sudo [while not accessing root] in x.py
# Fixes
This PR should fix#93344
# Info
Allows usage of sudo (while not accessing root) in x.py
Rollup of 7 pull requests
Successful merges:
- #95320 (Document the current MIR semantics that are clear from existing code)
- #95722 (pre-push.sh: Use python3 if python is not found)
- #95881 (Use `to_string` instead of `format!`)
- #95909 (rustdoc: Reduce allocations in a `theme` function)
- #95910 (Fix crate_type attribute to not warn on duplicates)
- #95920 (use `Span::find_ancestor_inside` to get right span in CastCheck)
- #95936 (Fix a bad error message for `relative paths are not supported in visibilities` error)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Instead of checking only the user provided sysroot or the default (when
no sysroot is provided), search user provided sysroot and then check
default sysroots for locale requested by the user.
Signed-off-by: David Wood <david.wood@huawei.com>
use `Span::find_ancestor_inside` to get right span in CastCheck
This is a quick fix. This bad suggestion likely lives in other places... but thought it would be useful to fix all of the CastCheck ones first.
Let me know if reviewer would prefer I add more tests for each of the diagnostics in CastCheck, or would like to do a more thorough review of other suggestions that use spans in typeck. I would also be open to further suggestions on how to better expose an API that gives us the "best" span for a diagnostic suggestion.
Fixed#95919
Fix crate_type attribute to not warn on duplicates
In #88681 I accidentally marked the `crate_type` attribute as only allowing a single attribute. However, multiple attributes are allowed (they are joined together [here](027a232755/compiler/rustc_interface/src/util.rs (L530-L542))). This fixes it to not report a warning if duplicates are found.
Closes#95902
