This is an extremely marginal error, so the cost of properly threading
`Handler` everywhere just not seemed justified. However, it's useful
to panic when we create a file, and not when we slice strings with
overflown indexes somewhere in the guts of the compiler.
For this reason, while we provide safe `try_new_source_file`, we don't
change the existing public interface and just panic more or less
cleanly.
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.
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
