- 24 8月, 2021 4 次提交
-
-
由 jackh726 提交于
-
由 jackh726 提交于
-
由 jackh726 提交于
-
由 bors 提交于
2229: Handle MutBorrow/UniqueImmBorrow better We only want to use UniqueImmBorrow when the capture place is truncated and we drop Deref of a MutRef. r? `@nikomatsakis` Fixes: https://github.com/rust-lang/project-rfc-2229/issues/56
-
- 23 8月, 2021 17 次提交
-
-
由 bors 提交于
Improve error reporting for closure return type mismatches Fixes #87461.
-
由 bors 提交于
⬆ rust-analyzer -
由 bors 提交于
Implement `AsFd` etc. for `UnixListener`. Implement `AsFd`, `From<OwnedFd>`, and `Into<OwnedFd>` for `UnixListener`. This is a follow-up to #87329. r? `@joshtriplett`
-
由 Laurențiu Nicola 提交于
-
由 bors 提交于
Add doctests for HashMap's into_values and into_keys methods Fixes #87591
-
由 bors 提交于
Test TAITs different lifetimes in defining uses fail r? `@oli-obk` Related to #86727
-
由 Dan Gohman 提交于
-
由 bors 提交于
Stop emitting the `dso_local` LLVM attribute for external symbols under the static relocation model on macOS. This matches Clang's behavior: https://github.com/llvm/llvm-project/blob/973cb2c326be9f256da0897c4d2ef117dc22761d/clang/lib/CodeGen/CodeGenModule.cpp#L1038-L1040 Even if `dso_local` were properly supported in this way on macOS, it seems incorrect to add this annotation as liberally as we did. The `dso_local` annotation is for symbols that ultimately end up in the same linkage unit, but we were adding this annotation even for `static` values inside `extern` blocks marked with `#[link(type="framework")]`, which should be considered dynamically linked. Note that Clang likewise avoids emitting `dso_local` for `dllimport` symbols: https://github.com/llvm/llvm-project/blob/973cb2c326be9f256da0897c4d2ef117dc22761d/clang/lib/CodeGen/CodeGenModule.cpp#L1005-L1007 This issue caused breakage in the `ring` crate, which links to a symbol defined in `Security.framework` that ultimately resolves to address `0x0`: https://github.com/briansmith/ring/blob/b94d61e044b42827fefd71d5f61e8c58a7659870/src/rand.rs#L390 For this symbol, the use of `dso_local` causes LLVM to emit a relocation of type `X86_64_RELOC_SIGNED`, which is a 32-bit signed PC-relative offset. If the binary is large enough, `0x0` might be out of range, and the link will fail. Avoiding `dso_local` causes LLVM to use the GOT instead, emitting a relocation of type `X86_64_RELOC_GOT_LOAD`, which will properly handle the large offset and cause the link to succeed. As a side note, the static relocation model is effectively deprecated for security reasons on macOS, as it prohibits PIE. It's also completely unsupported on Apple Silicon, so I don't think it's worth going to the effort of properly supporting this model on that platform.
-
由 bors 提交于
Rollup of 7 pull requests Successful merges: - #86747 (Improve wording of the `drop_bounds` lint) - #87166 (Show discriminant before overflow in diagnostic for duplicate values.) - #88077 (Generate an iOS LLVM target with a specific version) - #88164 (PassWrapper: adapt for LLVM 14 changes) - #88211 (cleanup: `Span::new` -> `Span::with_lo`) - #88229 (Suggest importing the right kind of macro.) - #88238 (Stop tracking namespace in used_imports.) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
-
由 Guillaume Gomez 提交于
Stop tracking namespace in used_imports. This changes `used_imports` from a `FxHashSet<(NodeId, Namespace)>` to a `FxHashSet<NodeId>`, as the Namespace information isn't used. The only point that uses it did three lookups, `|=`'ing them together. r? `@estebank`
-
由 Guillaume Gomez 提交于
Suggest importing the right kind of macro. Fixes #88228. r? `@estebank`
-
由 Guillaume Gomez 提交于
cleanup: `Span::new` -> `Span::with_lo` Extracted from https://github.com/rust-lang/rust/pull/84373 as suggested in https://github.com/rust-lang/rust/pull/84373#issuecomment-857773867. It turned out less useful then I expected, but anyway. r? `@cjgillot` `@bors` rollup
-
由 Guillaume Gomez 提交于
PassWrapper: adapt for LLVM 14 changes These API changes appear to have all taken place in https://reviews.llvm.org/D105007, which moved HWAddressSanitizerPass and AddressSanitizerPass to only accept their options type as a ctor argument instead of the sequence of bools etc. This required a couple of parameter additions, which I made match the default prior to the mentioned upstream LLVM change. This patch restores rustc to building (though not quite passing all tests, I've mailed other patches for those issues) against LLVM HEAD.
-
由 Guillaume Gomez 提交于
Generate an iOS LLVM target with a specific version This commit adds the `LC_VERSION_MIN_IPHONEOS` load command to the Mach-O header generated for `aarch64-apple-ios` binaries. The operating system will look for this load command to determine the minimum supported operating system version and will not allow the binary to run if it's absent. This logic already exists for the simulator toolchain. I've been using `otool` from a [cctools](https://github.com/tpoechtrager/cctools-port) toolchain to parse the header and validate that this change adds the required load command. This change appears to be enough to build Rust binaries that can run on a jailbroken iPhone.
-
由 Guillaume Gomez 提交于
Show discriminant before overflow in diagnostic for duplicate values. This PR adds the value before overflow for explicit discriminant values in the error for duplicate discriminant values. I found it rather confusing to see only the overflowed value. It only does this for literals, since overflows in const evaluated arithmetic are already a hard error. This is my first PR to the compiler, so please let me know if the implementation can be improved :) Before: ![image](https://user-images.githubusercontent.com/786213/125850097-bf5fb7e0-d800-4386-a738-c30f41822964.png) After: ![image](https://user-images.githubusercontent.com/786213/125850120-e2bb765d-ad86-4888-a6cb-dec34fba3fea.png)
-
由 Guillaume Gomez 提交于
Improve wording of the `drop_bounds` lint This PR addresses #86653. The issue is sort of a false positive of the `drop_bounds` lint, but I would argue that the best solution for #86653 is simply a rewording of the warning message and lint description, because even if the lint is _technically_ wrong, it still forces the programmer to think about what they are doing, and they can always use `#[allow(drop_bounds)]` if they think that they really need the `Drop` bound. There are two issues with the current warning message and lint description: - First, it says that `Drop` bounds are "useless", which is technically incorrect because they actually do have the effect of allowing you e.g. to call methods that also have a `Drop` bound on their generic arguments for some reason. I have changed the wording to emphasize not that the bound is "useless", but that it is most likely not what was intended. - Second, it claims that `std::mem::needs_drop` detects whether a type has a destructor. But I think this is also technically wrong: The `Drop` bound says whether the type has a destructor or not, whereas `std::mem::needs_drop` also takes nested types with destructors into account, even if the top-level type does not itself have one (although I'm not 100% sure about the exact terminology here, i.e. whether the "drop glue" of the top-level type counts as a destructor or not). cc `@jonhoo,` does this solve the issue for you? r? `@GuillaumeGomez`
-
由 bors 提交于
canonicalize consts before calling try_unify_abstract_consts query Fixes #88022 Fixes #86953 Fixes #77708 Fixes #82034 Fixes #85031 these ICEs were all caused by calling the `try_unify_abstract_consts` query with inference vars in substs r? `@lcnr`
-
- 22 8月, 2021 19 次提交
-
-
由 Mara Bos 提交于
The information was tracked, but unused.
-
由 Santiago Pastorino 提交于
-
由 bors 提交于
Fix clippy::collapsible_match with let expressions This fixes rust-lang/rust-clippy#7575 which is a regression from #80357. I am fixing the bug here instead of in the clippy repo (if that's okay) because a) the regression has not been synced yet and b) I would like to land the fix on nightly asap. The fix is basically to re-generalize `match` and `if let` for the lint implementation (they were split because `if let` no longer desugars to `match` in the HIR). Also fixes rust-lang/rust-clippy#7586 and fixes rust-lang/rust-clippy#7591 cc `@rust-lang/clippy` `@xFrednet` do you want to review this?
-
由 ccQpein 提交于
-
由 Mara Bos 提交于
-
由 bors 提交于
marker_traits: require `EvaluatedToOk` during winnowing closes #84955, while it doesn't really fix it in a way that makes me happy it should prevent the issue for now and this test can't be reproduced anyways, so it doesn't make much sense to keep it open. fixes #84917 as only one of the impls depends on regions, so we now drop the ambiguous one instead of the correct one. cc https://rust-lang.zulipchat.com/#narrow/stream/144729-wg-traits/topic/winnowing.20soundly/near/247899832 r? `@nikomatsakis`
-
由 bors 提交于
Fix example in `Extend<(A, B)>` impl After looking over the examples in my last PR (#85835) on doc.rust-lang.org/nightly I realized that the example didn't actually show what I wanted it to show
😅 So here's the better example -
由 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.
-
由 Dan Gohman 提交于
Implement `AsFd`, `From<OwnedFd>`, and `Into<OwnedFd>` for `UnixListener`. This is a follow-up to #87329.
-
由 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
-