-
Notifications
You must be signed in to change notification settings - Fork 12.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 13 pull requests #81113
Rollup of 13 pull requests #81113
Commits on Jan 2, 2021
-
Configuration menu - View commit details
-
Copy full SHA for b498870 - Browse repository at this point
Copy the full SHA b498870View commit details
Commits on Jan 11, 2021
-
Configuration menu - View commit details
-
Copy full SHA for b7071b2 - Browse repository at this point
Copy the full SHA b7071b2View commit details
Commits on Jan 13, 2021
-
Remove is_dllimport_foreign_item def from cg_ssa
It overwrites the definition from rustc_metadata
Configuration menu - View commit details
-
Copy full SHA for 7aca2fa - Browse repository at this point
Copy the full SHA 7aca2faView commit details
Commits on Jan 16, 2021
-
Allow downloading LLVM on Windows
- 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.
Configuration menu - View commit details
-
Copy full SHA for 6766070 - Browse repository at this point
Copy the full SHA 6766070View commit details -
Add all tier 1 platforms to supported platforms for "if-available"
... and update the comment in `config.toml.example`
Configuration menu - View commit details
-
Copy full SHA for 5c4adbe - Browse repository at this point
Copy the full SHA 5c4adbeView commit details -
Configuration menu - View commit details
-
Copy full SHA for 8b702e0 - Browse repository at this point
Copy the full SHA 8b702e0View commit details -
Configuration menu - View commit details
-
Copy full SHA for c17ed34 - Browse repository at this point
Copy the full SHA c17ed34View commit details -
Configuration menu - View commit details
-
Copy full SHA for 53989e4 - Browse repository at this point
Copy the full SHA 53989e4View commit details -
Configuration menu - View commit details
-
Copy full SHA for 50ee0b2 - Browse repository at this point
Copy the full SHA 50ee0b2View commit details -
Configuration menu - View commit details
-
Copy full SHA for 15f0921 - Browse repository at this point
Copy the full SHA 15f0921View commit details -
Configuration menu - View commit details
-
Copy full SHA for 76003f3 - Browse repository at this point
Copy the full SHA 76003f3View commit details -
Configuration menu - View commit details
-
Copy full SHA for 5a706cf - Browse repository at this point
Copy the full SHA 5a706cfView commit details -
Configuration menu - View commit details
-
Copy full SHA for 7f9a2cf - Browse repository at this point
Copy the full SHA 7f9a2cfView commit details
Commits on Jan 17, 2021
-
Configuration menu - View commit details
-
Copy full SHA for 4e27ed3 - Browse repository at this point
Copy the full SHA 4e27ed3View commit details -
Add NonZeroUn::is_power_of_two
This saves instructions on both new and old machines.
Configuration menu - View commit details
-
Copy full SHA for 3e16e92 - Browse repository at this point
Copy the full SHA 3e16e92View commit details -
Configuration menu - View commit details
-
Copy full SHA for f07dd6d - Browse repository at this point
Copy the full SHA f07dd6dView commit details -
Configuration menu - View commit details
-
Copy full SHA for c127ed6 - Browse repository at this point
Copy the full SHA c127ed6View commit details -
Rollup merge of rust-lang#79298 - lcnr:new-elysium, r=matthewjasper
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```
Configuration menu - View commit details
-
Copy full SHA for f783871 - Browse repository at this point
Copy the full SHA f783871View commit details -
Rollup merge of rust-lang#80031 - petrochenkov:builtina, r=estebank
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.
Configuration menu - View commit details
-
Copy full SHA for 3d5e7e0 - Browse repository at this point
Copy the full SHA 3d5e7e0View commit details -
Rollup merge of rust-lang#80201 - saethlin:bufreader-read-exact, r=Ko…
…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) ```
Configuration menu - View commit details
-
Copy full SHA for 152f425 - Browse repository at this point
Copy the full SHA 152f425View commit details -
Rollup merge of rust-lang#80635 - sexxi-goose:use-place-instead-of-sy…
…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```
Configuration menu - View commit details
-
Copy full SHA for 19f9780 - Browse repository at this point
Copy the full SHA 19f9780View commit details -
Rollup merge of rust-lang#80765 - petrochenkov:traitsinscope, r=matth…
…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```
Configuration menu - View commit details
-
Copy full SHA for ffcbeef - Browse repository at this point
Copy the full SHA ffcbeefView commit details -
Rollup merge of rust-lang#80932 - jyn514:download-windows-llvm, r=Mar…
…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 ```
Configuration menu - View commit details
-
Copy full SHA for cfe2253 - Browse repository at this point
Copy the full SHA cfe2253View commit details -
Rollup merge of rust-lang#80983 - bjorn3:no_dup_is_dllimport_foreign_…
…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.
Configuration menu - View commit details
-
Copy full SHA for 8f2ee87 - Browse repository at this point
Copy the full SHA 8f2ee87View commit details -
Rollup merge of rust-lang#81064 - Mark-Simulacrum:support-stage1-chec…
…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```
Configuration menu - View commit details
-
Copy full SHA for 92dbfb5 - Browse repository at this point
Copy the full SHA 92dbfb5View commit details -
Rollup merge of rust-lang#81080 - bugadani:vec-diag, r=oli-obk,m-ou-se
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
Configuration menu - View commit details
-
Copy full SHA for 19370a4 - Browse repository at this point
Copy the full SHA 19370a4View commit details -
Rollup merge of rust-lang#81082 - ssomers:btree_cleanup_comments, r=M…
…ark-Simulacrum BTreeMap: clean up a few more comments And mark `pop` as unsafe. r? ```@Mark-Simulacrum```
Configuration menu - View commit details
-
Copy full SHA for 366f97b - Browse repository at this point
Copy the full SHA 366f97bView commit details -
Rollup merge of rust-lang#81084 - LingMan:map, r=oli-obk
Use Option::map instead of open-coding it r? ```@oli-obk``` ```@rustbot``` modify labels +C-cleanup +T-compiler
Configuration menu - View commit details
-
Copy full SHA for 34e073f - Browse repository at this point
Copy the full SHA 34e073fView commit details -
Rollup merge of rust-lang#81095 - LingMan:unwrap, r=oli-obk
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
Configuration menu - View commit details
-
Copy full SHA for 7e2425a - Browse repository at this point
Copy the full SHA 7e2425aView commit details -
Rollup merge of rust-lang#81107 - scottmcm:nonzero-is_power_of_two, r…
…=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`.
Configuration menu - View commit details
-
Copy full SHA for 8016846 - Browse repository at this point
Copy the full SHA 8016846View commit details