typeck: extract expr type-checking to expr.rs + refactor check_expr_kind
In this PR we:
- Extract out the bulk of the expression type checking logic from `check/mod.rs` into a new file `check/expr.rs`.
- Refactor `fn check_expr_kind` into several smaller functions.
More functions should probably be moved but I think this is a reasonable start.
r? @oli-obk
cc @eddyb
submodules: update clippy from 7b2a7a22 to be5d17fe
Changes:
````
Fix wrong lifetime of TyCtxt
Use replace_region_in_file for creating the lint list
Restructure rename tests
Register rename to the LintStore.
Rename REDUNDANT_STATIC_LIFETIME to REDUNDANT_STATIC_LIFETIMES.
Remove pub from RedundantStaticLifetime.visit_type function.
Rename const_static_lifetime to redundant_static_lifetime.
Merge StaticConst and StaticStatic lints into StaticConst.
Use RedundantStaticLifetime in StaticStatic.
Move type-checking logic in StaticConst to RedundantStaticLifetime.
Add lint for statics with explicit static lifetime.
minor fix
make it pass dogfood
run rustfmt
fix padding and put clippy someplaces
show default lint levels
group printing
prelim arg parse
move Lint static def into its own module
switch to sorted usable lints
Update clippy_dev/src/main.rs
initial commit for help improvements on clippy-driver
````
Fixes clippy toolstate.
r? @oli-obk
weird-exprs: if if if if
The `if` keyword can be chained as long as there are enough `{...} else {...}` following, and they all return a `bool` (not required for the last one).
`if` expression can be also put inside a `match` arm guard, thus making the whole thing a little bit more confusing.
Discovered this clusterfunk while reading the reference because I have nothing better to do.
librustc_codegen_llvm: Use repr(transparent) for bitflags over repr(C…
…) (#61306)
In order to make sure that Rust's bitflags types are passed the same way in the Rust ABI as they are in the C ABI, we need to use the attribute repr(transparent) over the repr(C) attribute for the single-field bitflags structs in in order to prevent ABI mismatches. Thanks to Michael Karcher for finding this bug.
create a "provisional cache" to restore performance in the case of cycles
Introduce a "provisional cache" that caches the results of auto trait resolutions but keeps them from entering the *main* cache until everything is ready. This turned out a bit more complex than I hoped, but I don't see another short term fix -- happy to take suggestions! In the meantime, it's very clear we need to rework the trait solver. This resolves the extreme performance slowdown experienced in #60846 -- I plan to add a perf.rust-lang.org regression test to track this.
Caveat: I've not run `x.py test` in full yet.
r? @pnkfelix
cc @arielb1
Fixes#60846
Separate unit tests
I'm working on #61097.
About half of the modules are done but dozens of modules are still remaining. I will rebase and squash the commits later.
Changes:
````
Fix wrong lifetime of TyCtxt
Use replace_region_in_file for creating the lint list
Restructure rename tests
Register rename to the LintStore.
Rename REDUNDANT_STATIC_LIFETIME to REDUNDANT_STATIC_LIFETIMES.
Remove pub from RedundantStaticLifetime.visit_type function.
Rename const_static_lifetime to redundant_static_lifetime.
Merge StaticConst and StaticStatic lints into StaticConst.
Use RedundantStaticLifetime in StaticStatic.
Move type-checking logic in StaticConst to RedundantStaticLifetime.
Add lint for statics with explicit static lifetime.
minor fix
make it pass dogfood
run rustfmt
fix padding and put clippy someplaces
show default lint levels
group printing
prelim arg parse
move Lint static def into its own module
switch to sorted usable lints
Update clippy_dev/src/main.rs
initial commit for help improvements on clippy-driver
````
Optimize matches
Attempt to fix or improve #60571
This is breaking some diagnostics because the MIR for match arms isn't in source order any more.
cc @centril
rustbuild: include llvm-libunwind in dist tarball
Without this we cannot build with llvm-libunwind enabled from a release tarball.
Could it be backported in a beta rollup somehow so that this gets fixed before 1.36 is released?
Pass LLVM linker flags to librustc_llvm build
Some -L and -l flags may be needed even when building librustc_llvm,
for example when using static libc++ on Linux we may need to manually
specify the library search path and -ldl -lpthread as additional link
dependencies. We pass LLVM linker flags from config to librustc_llvm
build to make sure these cases are handled.
Add some Vec <-> VecDeque documentation
These are more than just `.into_iter().collect()`, so talk about some of their nuances.
For VecDeque -> Vec I'm trying to intentionally not write a guarantee for people making their own `Vec`s, since the rules are more complicated than I think we want to commit to forever.
The "Vec -> VecDeque doesn't reallocate" guarantee seems reasonable, though. (And I'm intentionally ambiguous about when it's O(1) instead of O(n).)
In order to make sure that Rust's bitflags types are passed the same
way in the Rust ABI as they are in the C ABI, we need to use the attribute
repr(transparent) over the repr(C) attribute for the single-field bitflags
structs in in order to prevent ABI mismatches. Thanks to Michael Karcher
for finding this bug.
make sure we use cfg-if as a std dependency
xargo currently fails to build libstd because this feature is missing. My guess is that it works in rustc because the feature is enabled elsewhere, but that does not help for a libstd-only build.
Miri is currently in a state where it is shipped but broken, which makes CI fail for projects that are tested in Miri. So this is kind of urgent.
Cc @alexcrichton https://github.com/rust-lang/rust/pull/61720
Rollup of 6 pull requests
Successful merges:
- #61785 (note some safety concerns of raw-ptr-to-ref casts)
- #61805 (typeck: Fix ICE for blocks in repeat expr count.)
- #61813 (Remove some unnecessary symbol interner ops)
- #61824 (in which we decline to lint single-use lifetimes in `derive`d impls)
- #61844 (Change `...` to `..=` where applicable)
- #61854 (Minor cosmetic improvements to accompany PR 61825)
Failed merges:
r? @ghost
Change `...` to `..=` where applicable
This is mainly to fix#61816, but I decided to manually check a few thousand `...` throughout the code base to check for any other cases. I think I found a documentation bug in `src\libsyntax\ast.rs` where both `1..` and `1...` where mentioned. If there is internal support for both `1..` and `1..=` (that can exist before error handling gets to it), then I can add that back.
There were some other cases that look like `// struct Closure<'l0...'li, T0...Tj, CK, CS, U0...Uk> {`, `// <P0 as Trait<P1...Pn>>::Foo: 'a`, and `assert!(min <= max, "discriminant range is {}...{}", min, max);`, but I am not sure if I should change those.
There are a bunch of cases in the `/test/` directory that could be changed, but I presume I should just leave those be.
Remove some unnecessary symbol interner ops
* Don't gensym symbols that don't need to worry about colliding with other symbols
* Use symbol constants instead of interning string literals in a few places.
* Don't generate a module in `__register_diagnostic`
r? @petrochenkov
typeck: Fix ICE for blocks in repeat expr count.
Fixes#61336 (again). This PR fixes an ICE that occured when a block expression resolving to a const generic was used for the count of an array repeat expression.
r? @varkor
Limit dylib symbols
This makes `windows-gnu` match the behavior of `windows-msvc`. It probably doesn't make sense to export these symbols on other platforms either.
type_alias_enum_variants: fix#61801; allow a path pattern to infer
Fix#61801.
Given a type-relative path pattern referring to an enum variant through a type alias, allow inferring the generic argument applied in the expectation set by the scrutinee of a `match` expression.
Similar issues may exist for `let` statements but I don't know how to test for that since `PhantomData<T>` is necessary...)
The gist of the problem here was that `resolve_ty_and_res_ufcs` was called twice which is apparently no good... It is possible that this PR is papering over some deeper problem, but that is beyond my knowledge of the compiler.
r? @petrochenkov
cc @eddyb @alexreg
cc https://github.com/rust-lang/rust/pull/61682
cc https://github.com/rust-lang/rust/issues/49683
