Rollup of 13 pull requests #81113
Merged
Rollup of 13 pull requests #81113
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
It overwrites the definition from rustc_metadata
- Don't ignore packaging `llvm/lib/` for `rust-dev` when LLVM is linked statically - Add `link-type.txt` so bootstrap knows whether llvm was linked statically or dynamically - Don't assume CI LLVM is linked dynamically in `bootstrap::config` - Fall back to dynamic linking if `link-type.txt` doesn't exist - Fix existing bug that split the output of `llvm-config` on lines, not spaces - Enable building LLVM tests This works around the following llvm bug: ``` llvm-config: error: component libraries and shared library llvm-config: error: missing: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/llvm/build/lib/libgtest.a llvm-config: error: missing: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/llvm/build/lib/libgtest_main.a llvm-config: error: missing: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/llvm/build/lib/libLLVMTestingSupport.a thread 'main' panicked at 'command did not execute successfully: "/home/joshua/rustc2/build/x86_64-unknown-linux-gnu/llvm/build/bin/llvm-config" "--libfiles" ``` I'm not sure why llvm-config thinks these are required, but to avoid the error, this builds them anyway. - Temporarily set windows as the try builder. This should be reverted before merging. - Bump version of `download-ci-llvm-stamp` `src/llvm-project` hasn't changed, but the generated tarball has. - Only special case MacOS when dynamic linking. Static linking works fine. - Store `link-type.txt` to the top-level of the tarball This allows writing the link type unconditionally. Previously, bootstrap had to keep track of whether the file IO *would* succeed (it would fail if `lib/` didn't exist), which was prone to bugs. - Make `link-type.txt` required Anyone downloading this from CI should be using a version of bootstrap that matches the version of the uploaded artifacts. So a missing link-type indicates a bug in x.py.
... and update the comment in `config.toml.example`
This saves instructions on both new and old machines.
correctly deal with late-bound lifetimes in anon consts
adds support for using late bound lifetimes of the parent context in anon consts.
```rust
#![feature(const_generics)]
const fn inner<'a>() -> usize where &'a (): Sized { 3 }
fn test<'a>() {
let _: [u8; inner::<'a>()];
}
```
The lifetime `'a` is late bound in `test` so it's not included in its generics but is instead dealt with separately in borrowck.
This didn't previously work for anon consts as they have to use the late bound lifetimes of their parent which has
to be explicitly handled.
r? ```@matthewjasper``` cc ```@varkor``` ```@eddyb```
resolve: Reject ambiguity built-in attr vs different built-in attr Fixes rust-lang#79798. Resolution ensures that inert attributes cannot be used through imports like this, but built-in attributes don't go through initial resolution (only through resolution validation), so we have to keep some extra data (the built-in attribute name) to prevent it from happening.
…drAus Add benchmark and fast path for BufReader::read_exact At work, we have a wrapper type that implements this optimization. It would be nice if the standard library were faster. Before: ``` test io::buffered::tests::bench_buffered_reader_small_reads ... bench: 7,670 ns/iter (+/- 45) ``` After: ``` test io::buffered::tests::bench_buffered_reader_small_reads ... bench: 4,457 ns/iter (+/- 41) ```
…mbol, r=nikomatsakis` Improve diagnostics when closure doesn't meet trait bound Improves the diagnostics when closure doesn't meet trait bound by modifying `TypeckResuts::closure_kind_origins` such that `hir::Place` is used instead of `Symbol`. Using `hir::Place` to describe which capture influenced the decision of selecting a trait a closure satisfies to (Fn/FnMut/FnOnce, Copy) allows us to show precise path in the diagnostics when `capture_disjoint_field` feature is enabled. Closes rust-lang/project-rfc-2229/issues/21 r? ```@nikomatsakis```
…ewjasper resolve: Simplify collection of traits in scope "Traits in scope" for a given location are collected by walking all scopes in type namespace, collecting traits in them and pruning traits that don't have an associated item with the given name and namespace. Previously we tried to prune traits using some kind of hygienic resolution for associated items, but that was complex and likely incorrect, e.g. in rust-lang#80762 correction to visibilites of trait items caused some traits to not be in scope anymore. I previously had some comments and concerns about this in rust-lang#65351. In this PR we are doing some much simpler pruning based on `Symbol` and `Namespace` comparisons, it should be enough to throw away 99.9% of unnecessary traits. It is not necessary for pruning to be precise because for trait aliases, for example, we don't do any pruning at all, and precise hygienic resolution for associated items needs to be done in typeck anyway. The somewhat unexpected effect is that trait imports introduced by macros 2.0 now bring traits into scope due to the removed hygienic check on associated item names. I'm not sure whether it is desirable or not, but I think it's acceptable for now. The old check was certainly incorrect because macros 2.0 did bring trait aliases into scope. If doing this is not desirable, then we should come up with some other way to avoid bringing traits from macros 2.0 into scope, that would accommodate for trait aliases as well. --- The PR also contains a couple of pure refactorings - Scope walk is done by using `visit_scopes` instead of a hand-rolled version. - Code is restructured to accomodate for rustdoc that also wants to query traits in scope, but doesn't want to filter them by associated items at all. r? ```@matthewjasper```
…k-Simulacrum Allow downloading LLVM on Windows and MacOS - Don't ignore packaging `llvm/lib/` for `rust-dev` when LLVM is linked statically - Add `link-type.txt` so bootstrap knows whether llvm was linked statically or dynamically - Don't assume CI LLVM is linked dynamically in `bootstrap::config` - Fall back to dynamic linking if `link-type.txt` doesn't exist - Fix existing bug that split the output of `llvm-config` on lines, not spaces - Only special case MacOS when dynamic linking. Static linking works fine. - Enable building LLVM tests This works around the following llvm bug: ``` llvm-config: error: component libraries and shared library llvm-config: error: missing: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/llvm/build/lib/libgtest.a llvm-config: error: missing: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/llvm/build/lib/libgtest_main.a llvm-config: error: missing: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/llvm/build/lib/libLLVMTestingSupport.a thread 'main' panicked at 'command did not execute successfully: "/home/joshua/rustc2/build/x86_64-unknown-linux-gnu/llvm/build/bin/llvm-config" "--libfiles" ``` I'm not sure why llvm-config thinks these are required, but to avoid the error, this builds them anyway. - Bump version of `download-ci-llvm-stamp` `src/llvm-project` hasn't changed, but the generated tarball has. Fixes rust-lang#77084. # Current Status This works on both MacOS and Windows! 🎉 🎉 Thanks to ```@nagisa,``` ```@halkcyon,``` ```@Lokathor,``` ```@jryans,``` and ```@poliorcetics``` for helping me test! The `if-available` check now supports all tier 1 platforms. Although only x64 apple and x64 msvc have been tested, none of the changes here are Windows or Mac specific, and I expect this to work anywhere that LLVM artifacts are uploaded to CI (i.e. the `rust-dev` component exists). ## Windows Note that if you have an old version of MSVC build tools you'll need to update them. VS Build Tools 2019 14.28 and later are known to work. With old tools, you may see an error like the following: ``` error LNK2001: unresolved external symbol __imp___std_init_once_complete ```
…item, r=nagisa Remove is_dllimport_foreign_item definition from cg_ssa It overwrites the definition from rustc_metadata. cc https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/query.20provided.20twice/near/218927806 Marked as draft to test if this breaks anything.
…k, r=jyn514 Support non-stage0 check Seems to work locally - a full stage 1 check succeeds, building std (because we can't get away with checking it), and then checking the compiler and other tools. This ran into the problem that a unconditional x.py check in stage 1 *both* checks and builds stage 1 std, and then has to clean up because for some reason the rmeta and rlib artifacts conflict (though I'm not actually entirely sure why, but it doesn't seem worth digging in in too much detail). Ideally we wouldn't be building and checking like that but it's a minor worry as checking std is pretty fast and you can avoid it if you're aiming for speed by passing the compiler (e.g., compiler/rustc) explicitly. r? ```@jyn514```
Force vec![] to expression position only r? `@oli-obk` I went with the lazy way of only changing what broke. I moved the test to ui/macros because the diagnostics no longer give suggestions. Closes rust-lang#61933
…ark-Simulacrum BTreeMap: clean up a few more comments And mark `pop` as unsafe. r? ```@Mark-Simulacrum```
Use Option::map instead of open-coding it r? ```@oli-obk``` ```@rustbot``` modify labels +C-cleanup +T-compiler
Use Option::unwrap_or instead of open-coding it r? ```@oli-obk``` Noticed this while we were talking about the other PR just now 😆 ```@rustbot``` modify labels +C-cleanup +T-compiler
…=kennytm Add NonZeroUn::is_power_of_two This saves instructions on both new and old machines <https://rust.godbolt.org/z/4fjTMz> - On the default x64 target (with no fancy instructions available) it saves a few instructions by not needing to also check for zero. - On newer targets (with BMI1) it uses `BLSR` for super-short assembly. This can be used for things like checks against alignments stored in `NonZeroUsize`.
|
@bors r+ p=13 rollup=never |
|
📌 Commit 8016846 has been approved by |
bors
added
the
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
This was referenced Jan 17, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup