type is too big -> values of the type are too big
strictly speaking, `[u8; usize::MAX]` or even `[[[u128; usize::MAX]; usize::MAX]; usize::MAX]` are absolutely fine types as long as you don't try to deal with any values of it.
This error message seems to cause some confusion imo, for example in https://github.com/rust-lang/rust/pull/79135#issuecomment-729361380 so I would prefer us to be more precise here.
See the added test case which uses one of these types without causing an error.
r? ``@oli-obk``
Fix handling of panic calls
This should make Clippy more resilient and will unblock #78343.
This PR is made against rust-lang/rust to avoid the need for a subtree
sync at ``@flip1995's`` suggestion in rust-lang/rust-clippy#6310.
r? ``@flip1995``
cc ``@m-ou-se``
bootstrap: use the same version number for rustc and cargo
Historically the stable tarballs were named after the version number ofthe specific tool, instead of the version number of Rust. For example, both of the following tarballs were part of the same release:
rustc-1.48.0-x86_64-unknown-linux-gnu.tar.xz
cargo-0.49.0-x86_64-unknown-linux-gnu.tar.xz
PR #77336 changed the dist code to instead use Rust's version number for all the tarballs, regardless of the tool they contain:
rustc-1.48.0-x86_64-unknown-linux-gnu.tar.xz
cargo-1.48.0-x86_64-unknown-linux-gnu.tar.xz
Because of that there is no need anymore to have a separate `cargo` field in `src/stage0.txt`, as the Cargo version will always be the same as the rustc version. This PR removes the field, simplifying the code and the maintenance work required while producing releases.
r? ``@Mark-Simulacrum``
Add `Item::from_def_id_and_kind` to reduce duplication in rustdoc
This makes it harder to make typos, and also makes it much more clear what's intentionally different rather than a typo (look for `what_rustc_thinks`).
Found this while working on https://github.com/rust-lang/rust/issues/76998, I really didn't want to add `const_visibility` in 20 different places.
r? `@GuillaumeGomez`
Prepare beta 1.49.0
This PR sets everything up for beta 1.49.0, and backports the following PRs to it:
* #79107 - build-manifest: strip newline from rustc version
* #78986 - Avoid installing external LLVM dylibs
* #79074 - Install CI llvm into the library directory
* #78364 - Update RELEASES.md for 1.48.0
* #77939 - Ensure that the source code display is working with DOS backline
r? `@ghost`
cc `@rust-lang/release`
This should make Clippy more resilient and will unblock #78343.
This PR is made against rust-lang/rust to avoid the need for a subtree
sync at @flip1995's suggestion in rust-lang/rust-clippy#6310.
- Add `Item::from_hir_id_and_kind` convenience wrapper
- Make name parameter mandatory
`tcx.opt_item_name` doesn't handle renames, so this is necessary
for any item that could be renamed, which is almost all of them.
- Override visibilities to be `Inherited` for enum variants
`tcx.visibility` returns the effective visibility, not the visibility
that was written in the source code. `pub enum E { A, B }` always has
public variants `A` and `B`, so there's no sense printing `pub` again.
- Don't duplicate handling of `Visibility::Crate`
Instead, represent it as just another `Restricted` path.
Visibility needs much less information than a full path, since modules
can never have generics. This allows constructing a Visibility from only
a DefId.
Note that this means that paths are now normalized to their DefPath.
In other words, `pub(self)` or `pub(super)` now always shows `pub(in
path)` instead of preserving the original text.
Remove duplicate `Trait::auto` field
It was exactly the same as `is_auto`.
I found this while working on #78082, but it's not required for that PR.
r? `@GuillaumeGomez`
Get rid of clean::{Method, TyMethod}
They're redundant and almost the same as `clean::Function`.
I needed this for https://github.com/rust-lang/rust/pull/78082, although I forget why.
r? `@GuillaumeGomez`
Get rid of `highlight::Class::None`
This is mostly me learning the codebase for https://github.com/rust-lang/rust/pull/77939, so feel free to close the PR.
It does have the small benefit that we statically know rustdoc isn't generating useless `span`s, though.
r? `@GuillaumeGomez`
cc `@matklad`
Rustdoc test compiler output color
Fixes#72915
We just need to be sure it doesn't break rustdoc doctests' compilation checks. Maybe some other unforeseen consequences too?
r? `@ehuss`
cc `@rust-lang/rustdoc`
Historically the stable tarballs were named after the version number of
the specific tool, instead of the version number of Rust. For example,
both of the following tarballs were part of the same release:
rustc-1.48.0-x86_64-unknown-linux-gnu.tar.xz
cargo-0.49.0-x86_64-unknown-linux-gnu.tar.xz
PR #77336 changed the dist code to instead use Rust's version number for
all the tarballs, regardless of the tool they contain:
rustc-1.48.0-x86_64-unknown-linux-gnu.tar.xz
cargo-1.48.0-x86_64-unknown-linux-gnu.tar.xz
Because of that there is no need anymore to have a separate `cargo`
field in src/stage0.txt, as the Cargo version will always be the same as
the rustc version. This PR removes the field, simplifying the code and
the maintenance work required while producing releases.
Introduce `TypeVisitor::BreakTy`
Implements MCP rust-lang/compiler-team#383.
r? `@ghost`
cc `@lcnr` `@oli-obk`
~~Blocked on FCP in rust-lang/compiler-team#383.~~
If the LLVM was externally provided, then we don't currently copy artifacts into
the sysroot. This is not necessarily the right choice (in particular, it will
require the LLVM dylib to be in the linker's load path at runtime), but the
common use case for external LLVMs is distribution provided LLVMs, and in that
case they're usually in the standard search path (e.g., /usr/lib) and copying
them here is going to cause problems as we may end up with the wrong files and
isn't what distributions want.
This behavior may be revisited in the future though.
build-manifest: strip newline from rustc version
Backport of https://github.com/rust-lang/rust/pull/79096 on the master branch. This will also need to be included in the beta bump tomorrow.
r? `@Mark-Simulacrum`
`@rustbot` modify labels: beta-nominated beta-accepted T-infra
RFC-2229: Implement Precise Capture Analysis
### This PR introduces
- Feature gate for RFC-2229 (incomplete) `capture_disjoint_field`
- Rustc Attribute to print out the capture analysis `rustc_capture_analysis`
- Precise capture analysis
### Description of the analysis
1. If the feature gate is not set then all variables that are not local to the closure will be added to the list of captures. (This is for backcompat)
2. The rest of the analysis is based entirely on how the captured `Place`s are used within the closure. Precise information (i.e. projections) about the `Place` is maintained throughout.
3. To reduce the amount of information we need to keep track of, we do a minimization step. In this step, we determine a list such that no Place within this list represents an ancestor path to another entry in the list. Check rust-lang/project-rfc-2229#9 for more detailed examples.
4. To keep the compiler functional as before we implement a Bridge between the results of this new analysis to existing data structures used for closure captures. Note the new capture analysis results are only part of MaybeTypeckTables that is the information is only available during typeck-ing.
### Known issues
- Statements like `let _ = x` will make the compiler ICE when used within a closure with the feature enabled. More generally speaking the issue is caused by `let` statements that create no bindings and are init'ed using a Place expression.
### Testing
We removed the code that would handle the case where the feature gate is not set, to enable the feature as default and did a bors try and perf run. More information here: #78762
### Thanks
This has been slowly in the works for a while now.
I want to call out `@Azhng` `@ChrisPardy` `@null-sleep` `@jenniferwills` `@logmosier` `@roxelo` for working on this and the previous PRs that led up to this, `@nikomatsakis` for guiding us.
Closesrust-lang/project-rfc-2229#7Closesrust-lang/project-rfc-2229#9Closesrust-lang/project-rfc-2229#6Closesrust-lang/project-rfc-2229#19
r? `@nikomatsakis`
