- 23 8月, 2021 1 次提交
-
-
由 Frank Steffahn 提交于
-
- 22 8月, 2021 22 次提交
-
-
由 Frank Steffahn 提交于
-
由 Frank Steffahn 提交于
-
由 Frank Steffahn 提交于
-
由 Frank Steffahn 提交于
-
由 bors 提交于
add file_prefix method to std::path This is an initial implementation of `std::path::Path::file_prefix`. It is effectively a "left" variant of the existing [`file_stem`](https://doc.rust-lang.org/std/path/struct.Path.html#method.file_stem) method. An illustration of the difference is ```rust use std::path::Path; let path = Path::new("foo.tar.gz"); assert_eq!(path.file_stem(), Some("foo.tar")); assert_eq!(path.file_prefix(), Some("foo")); ``` In my own development, I generally find I almost always want the prefix, rather than the stem, so I thought it might be best to suggest it's addition to libstd. Of course, as this is my first contribution, I expect there is probably more work that needs to be done. Additionally, if the libstd team feel this isn't appropriate then so be it. There has been some [discussion about this on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/file_lstem/near/238076313) and a user there suggested I open a PR to see whether someone in the libstd team thinks it is worth pursuing.
-
由 bors 提交于
Rollup of 13 pull requests Successful merges: - #87604 (CI: Verify commits in beta & stable are in upstream branches.) - #88057 (Update RELEASES to clarify attribute macro values.) - #88072 (Allow the iOS toolchain to be built on Linux) - #88170 (Update release note for 1.55.0.) - #88172 (Test that type alias impl trait happens in a submodule) - #88179 (Mailmap entry for myself) - #88182 (We meant to use a trait instead of lifetime here) - #88183 (test TAIT in different positions) - #88189 (Add TAIT struct test) - #88192 (Use of impl trait in an impl as the value for an associated type in a dyn) - #88194 (Test use of impl Trait in an impl as the value for an associated type in an impl trait) - #88197 (Test tait use in a fn type) - #88201 (Test that incomplete inference for TAITs fail) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
-
由 Jack Huey 提交于
Test that incomplete inference for TAITs fail r? `@oli-obk` Related to #86727
-
由 Jack Huey 提交于
Test tait use in a fn type r? `@oli-obk` I thought this was going to work but doesn't, quickly checked with Niko and he told me that we ruled this out for now. I'm not exactly sure why and how but here we have a test with a FIXME :) Related to #86727
-
由 Jack Huey 提交于
Test use of impl Trait in an impl as the value for an associated type in an impl trait r? `@oli-obk` Related to #86727
-
由 Jack Huey 提交于
Use of impl trait in an impl as the value for an associated type in a dyn r? `@oli-obk` Related to #86727
-
由 Jack Huey 提交于
Add TAIT struct test r? `@oli-obk` Related to #86727
-
由 Jack Huey 提交于
test TAIT in different positions r? `@oli-obk` Related to #86727
-
由 Jack Huey 提交于
We meant to use a trait instead of lifetime here r? `@oli-obk` Related to #86727
-
由 Jack Huey 提交于
Mailmap entry for myself
-
由 Jack Huey 提交于
Test that type alias impl trait happens in a submodule r? `@oli-obk` Related to #86727
-
由 Jack Huey 提交于
Update release note for 1.55.0. Added a line about new formatting option, `{lib}`, for `cargo tree` (https://github.com/rust-lang/cargo/pull/9663).
-
由 Jack Huey 提交于
Allow the iOS toolchain to be built on Linux The iOS toolchain can be built on Linux with minor changes. The compilation will invoke `xcrun` to find the path to the iPhone SDK but a fake `xcrun` executable can be used. ``` #!/bin/sh echo "/path/to/sdk" ``` The iOS toolchain can then be built and linked with rustup. ``` $ ./x.py build --stage 2 --host x86_64-unknown-linux-gnu \ --target aarch64-apple-ios $ rustup toolchain link stage1 build/x86_64-unknown-linux-gnu/stage1 ``` It's possible to take this toolchain and compile an iOS executable with it. This requires the ld64 linker and an iOS SDK. The ld64 linker can be taken from [cctools](https://github.com/tpoechtrager/cctools-port). A project's .cargo/config can then be edited to use the linker for this target. ``` [target.aarch64-apple-ios] linker = "/path/to/cctools/bin/arm-apple-darwin-ld" rustflags = [ "-C", """ link-args= -F/path/to/sdk/System/Library/Frameworks -L/path/to/sdk/usr/lib -L/path/to/sdk/usr/lib/system/ -adhoc_codesign """, ] ```
-
由 Jack Huey 提交于
Update RELEASES to clarify attribute macro values. As noted in #87681, macros do not work with the `#[path]` attribute. Since the places where macros *can* be used is very limited, I have changed this to just focus on `#[doc]` which is the only attribute where this is really useful.
-
由 Jack Huey 提交于
CI: Verify commits in beta & stable are in upstream branches. Closes #74721 I think this does the trick. https://github.com/rust-lang/rust/pull/87597 is an example of it failing as it should.
-
由 bors 提交于
Optimize unnecessary check in VecDeque::retain This pr is highly inspired by https://github.com/rust-lang/rust/pull/88060 which shared the same idea: we can split the `for` loop into stages so that we can remove unnecessary checks like `del > 0`. ## Benchmarks Before ```rust test collections::vec_deque::tests::bench_retain_half_10000 ... bench: 290,125 ns/iter (+/- 8,717) test collections::vec_deque::tests::bench_retain_odd_10000 ... bench: 291,588 ns/iter (+/- 9,621) test collections::vec_deque::tests::bench_retain_whole_10000 ... bench: 287,426 ns/iter (+/- 9,009) ``` After ```rust test collections::vec_deque::tests::bench_retain_half_10000 ... bench: 243,940 ns/iter (+/- 8,563) test collections::vec_deque::tests::bench_retain_odd_10000 ... bench: 242,768 ns/iter (+/- 3,903) test collections::vec_deque::tests::bench_retain_whole_10000 ... bench: 202,926 ns/iter (+/- 6,332) ``` Based on the current benchmark, this PR will improve the perf of `VecDeque::retain` by around 16%. For special cases, the improvement will be up to 30%. Signed-off-by: NXuanwo <github@xuanwo.io>
-
由 bors 提交于
Trait upcasting coercion (part 3) By using separate candidates for each possible choice, this fixes type-checking issues in previous commits. r? `@nikomatsakis`
-
由 bors 提交于
Give precedence to `html_root_url` over `--extern-html-root-url` by default, but add a way to opt-in to the previous behavior ## What is an HTML root url? It tells rustdoc where it should link when documentation for a crate is not available locally; for example, when a crate is a dependency of a crate documented with `cargo doc --no-deps`. ## What is the difference between `html_root_url` and `--extern-html-root-url`? Both of these tell rustdoc what the HTML root should be set to. `doc(html_root_url)` is set by the crate author, while `--extern-html-root-url` is set by the person documenting the crate. These are often different. For example, docs.rs uses `--extern-html-root-url https://docs.rs/crate-name/version` to ensure all crates have documentation, even if `html_root_url` is not set. Conversely, crates such as Rocket set `doc(html_root_url = "https://api.rocket.rs")`, because they prefer users to view the documentation on their own site. Crates also set `html_root_url` to ensure they have documentation when building locally when offline. This is unfortunate to require, because it's more work from the library author. It also makes it impossible to distinguish between crates that want to be viewed on a different site (e.g. Rocket) and crates that just want documentation to be visible offline at all (e.g. Tokio). I have authored a separate change to the API guidelines to no longer recommend doing this: rust-lang/api-guidelines#230. ## Why change the default? In the past, docs.rs has been the main user of `--extern-html-root-url`. However, it's useful for other projects as well. In particular, Cargo wants to pass it by default when running `--no-deps` (rust-lang/cargo#8296). Unfortunately, for these other use cases, the priority order is inverted. They want to give *precedence* to the URL the crate picks, and only fall back to the `--extern-html-root` if no `html_root_url` is present. That allows passing `--extern-html-root` unconditionally, without having to parse the source code to see what attributes are present. For docs.rs, however, we still want to keep the old behavior, so that all links on docs.rs stay on the site.
-
- 21 8月, 2021 17 次提交
-
-
由 bors 提交于
Force warn improvements As part of stablization of the `--force-warn` option (#86516) I've made the following changes: * Error when the `warnings` lint group is based to the `--force-warn` option * Tests have been updated to make it easier to understand the semantics of `--force-warn` r? `@nikomatsakis`
-
由 bors 提交于
Add needs-asm-support to more tests These were found as test failures on s390x for RHEL and Fedora.
-
由 bors 提交于
Upgrade to LLVM 13 Work in progress update to LLVM 13. Main changes: * InlineAsm diagnostics reported using SrcMgr diagnostic kind are now handled. Previously these used a separate diag handler. * Codegen tests are updated for additional attributes. * Some data layouts have changed. * Switch `#[used]` attribute from `llvm.used` to `llvm.compiler.used` to avoid SHF_GNU_RETAIN flag introduced in https://reviews.llvm.org/D97448, which appears to trigger a bug in older versions of gold. * Set `LLVM_INCLUDE_TESTS=OFF` to avoid Python 3.6 requirement. Upstream issues: * ~~https://bugs.llvm.org/show_bug.cgi?id=51210 (InlineAsm diagnostic reporting for module asm)~~ Fixed by https://github.com/llvm/llvm-project/commit/1558bb80c01b695ce12642527cbfccf16cf54ece. * ~~https://bugs.llvm.org/show_bug.cgi?id=51476 (Miscompile on AArch64 due to incorrect comparison elimination)~~ Fixed by https://github.com/llvm/llvm-project/commit/81b106584f2baf33e09be2362c35c1bf2f6bfe94. * https://bugs.llvm.org/show_bug.cgi?id=51207 (Can't set custom section flags anymore). Problematic change reverted in our fork, https://reviews.llvm.org/D107216 posted for upstream revert. * https://bugs.llvm.org/show_bug.cgi?id=51211 (Regression in codegen for #83623). This is an optimization regression that we may likely have to eat for this release. The fix for #83623 was based on an incorrect premise, and this needs to be properly addressed in the MergeICmps pass. The [compile-time impact](https://perf.rust-lang.org/compare.html?start=ef9549b6c0efb7525c9b012148689c8d070f9bc0&end=0983094463497eec22d550dad25576a894687002) is mixed, but quite positive as LLVM upgrades go. The LLVM 13 final release is scheduled for Sep 21st. The current nightly is scheduled for stable release on Oct 21st. r? `@ghost`
-
由 Nikita Popov 提交于
This follows what clang does in CoverageMappingGen. Using just llvm.compiler.used is insufficient at least for MSVC targets.
-
由 bors 提交于
⬆ rust-analyzer -
由 Santiago Pastorino 提交于
-
由 bors 提交于
Refactor fallback code to prepare for never type This PR contains cherry-picks of some of `@nikomatsakis's` work from #79366, and shouldn't (AFAICT) represent any change in behavior. However, the refactoring is good regardless of the never type work being landed, and will reduce the size of those eventual PR(s) (and rebase pain). I am not personally an expert on this code, and the commits are essentially 100% `@nikomatsakis's,` but they do seem reasonable to me by my understanding. Happy to edit with review, of course. Commits are best reviewed in sequence rather than all together. r? `@jackh726` perhaps?
-
由 Santiago Pastorino 提交于
-
由 bors 提交于
Check that a box expression's type is Sized This resolves [issue 87935](https://github.com/rust-lang/rust/issues/87935). This makes E0161 (move from an unsized rvalue) much less common. I've replaced the test to use [this case](https://github.com/rust-lang/rust/blob/master/src/test/ui/object-safety/object-safety-by-value-self-use.rs), when a boxed `dyn` trait is passed by value, but that isn't an error when `unsized_locals` is enabled. I think it may be possible to get rid of E0161 entirely by checking that case earlier, but I'm not sure if that's desirable?
-
由 Santiago Pastorino 提交于
-
由 Niko Matsakis 提交于
Along the way, simplify and document the logic more clearly.
-
由 Niko Matsakis 提交于
Motivation: in upcoming commits, we are going to create a graph of the coercion relationships between variables. We want to distinguish *coercion* specifically from other sorts of subtyping, as it indicates values flowing from one place to another via assignment.
-
由 Niko Matsakis 提交于
I didn't like the sub-unify code executing when a predicate was ENQUEUED, that felt fragile. I would have preferred to move the sub-unify code so that it only occurred during generalization, but that impacted diagnostics, so having it also occur when we process subtype predicates felt pretty reasonable. (I guess we only need one or the other, but I kind of prefer both, since the generalizer ultimately feels like the *right* place to guarantee the properties we want.)
-
由 Santiago Pastorino 提交于
-
由 Santiago Pastorino 提交于
-
由 bors 提交于
where available use AtomicU{64,128} instead of mutex for Instant backsliding protection This decreases the overhead of backsliding protection on x86 systems with unreliable TSC, e.g. windows. And on aarch64 systems where 128bit atomics are available. The following benchmarks were taken on x86_64 linux though by overriding `actually_monotonic()`, the numbers may look different on other platforms ``` # actually_monotonic() == true test time::tests::instant_contention_01_threads ... bench: 44 ns/iter (+/- 0) test time::tests::instant_contention_02_threads ... bench: 44 ns/iter (+/- 0) test time::tests::instant_contention_04_threads ... bench: 44 ns/iter (+/- 0) test time::tests::instant_contention_08_threads ... bench: 44 ns/iter (+/- 0) test time::tests::instant_contention_16_threads ... bench: 44 ns/iter (+/- 0) # 1x AtomicU64 test time::tests::instant_contention_01_threads ... bench: 65 ns/iter (+/- 0) test time::tests::instant_contention_02_threads ... bench: 157 ns/iter (+/- 20) test time::tests::instant_contention_04_threads ... bench: 281 ns/iter (+/- 53) test time::tests::instant_contention_08_threads ... bench: 555 ns/iter (+/- 77) test time::tests::instant_contention_16_threads ... bench: 883 ns/iter (+/- 107) # mutex test time::tests::instant_contention_01_threads ... bench: 60 ns/iter (+/- 2) test time::tests::instant_contention_02_threads ... bench: 770 ns/iter (+/- 231) test time::tests::instant_contention_04_threads ... bench: 1,347 ns/iter (+/- 45) test time::tests::instant_contention_08_threads ... bench: 2,693 ns/iter (+/- 114) test time::tests::instant_contention_16_threads ... bench: 5,244 ns/iter (+/- 487) ``` Since I don't have an arm machine with 128bit atomics I wasn't able to benchmark the AtomicU128 implementation.
-
由 The8472 提交于
-