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
