- 28 3月, 2021 29 次提交
-
-
由 bors 提交于
rustc_target: Avoid unwraps when adding linker flags These `unwrap`s assume that some linker flags were already added by `*_base::opts()` methods, but that's doesn't necessarily remain the case when we are reducing the number of flags hardcoded in targets, as https://github.com/rust-lang/rust/pull/83587 shows. r? `@nagisa`
-
由 bors 提交于
Fixes API soundness issue in join() Fixes #80335
-
由 bors 提交于
Instruct LLVM that binary_search returns a valid index This allows removing bound checks when the return value of `binary_search` is used to index into the slice it was call on. I also added a codegen test for this, not sure if it's the right thing to do (I didn't find anything on the dev guide), but it felt so.
-
由 bors 提交于
linker: Use `--as-needed` by default when linker supports it Do it in a centralized way in `link.rs` instead of individual target specs. Majority of relevant target specs were already passing it.
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
-
由 bors 提交于
resolve: Partially unify early and late scope-relative identifier resolution Reuse `early_resolve_ident_in_lexical_scope` instead of a chunk of code in `resolve_ident_in_lexical_scope` doing the same job. `early_resolve_ident_in_lexical_scope`/`visit_scopes` had to be slightly extended to be able to 1) start from a specific module instead of the current parent scope and 2) report one deprecation lint. `early_resolve_ident_in_lexical_scope` still doesn't support walking through "ribs", that part is left in `resolve_ident_in_lexical_scope` (moreover, I'm pretty sure it's buggy, but that's a separate issue, cc https://github.com/rust-lang/rust/issues/52389 at least).
-
由 Vadim Petrochenkov 提交于
-
由 bors 提交于
Rollup of 8 pull requests Successful merges: - #81351 (combine: stop eagerly evaluating consts) - #82525 (make unaligned_references future-incompat lint warn-by-default) - #82626 (update array missing `IntoIterator` msg) - #82917 (Add function core::iter::zip) - #82993 (rustdoc: Use diagnostics for error when including sources) - #83522 (Improve fs error open_from unix) - #83548 (Always preserve `None`-delimited groups in a captured `TokenStream`) - #83555 (Add #[inline] to io::Error methods) Failed merges: - #83130 (escape_ascii take 2) r? `@ghost` `@rustbot` modify labels: rollup
-
由 Dylan DPC 提交于
Add #[inline] to io::Error methods Fixes #82812
-
由 Dylan DPC 提交于
Always preserve `None`-delimited groups in a captured `TokenStream` Previously, we would silently remove any `None`-delimiters when capturing a `TokenStream`, 'flattenting' them to their inner tokens. This was not normally visible, since we usually have `TokenKind::Interpolated` (which gets converted to a `None`-delimited group during macro invocation) instead of an actual `None`-delimited group. However, there are a couple of cases where this becomes visible to proc-macros: 1. A cross-crate `macro_rules!` macro has a `None`-delimited group stored in its body (as a result of being produced by another `macro_rules!` macro). The cross-crate `macro_rules!` invocation can then expand to an attribute macro invocation, which needs to be able to see the `None`-delimited group. 2. A proc-macro can invoke an attribute proc-macro with its re-collected input. If there are any nonterminals present in the input, they will get re-collected to `None`-delimited groups, which will then get captured as part of the attribute macro invocation. Both of these cases are incredibly obscure, so there hopefully won't be any breakage. This change will allow more agressive 'flattenting' of nonterminals in #82608 without losing `None`-delimited groups.
-
由 Dylan DPC 提交于
Improve fs error open_from unix Consistency for #79399 Suggested by JohnTitor r? `@JohnTitor` Not user if the error is too long now, do we handle long errors well?
-
由 Dylan DPC 提交于
rustdoc: Use diagnostics for error when including sources This error probably almost never happens, but we should still use the diagnostic infrastructure. My guess is that the error was added back before rustdoc used the rustc diagnostic infrastructure (it was all `println!` and `eprintln!` back then!) and since it likely rarely occurs and this code doesn't change that much, no one thought to transition it to using diagnostics. Note that the old error was actually a warning (it didn't stop the rest of doc building). It seems very unlikely that this would fail without the rest of the doc build failing, so it makes more sense for it to be a hard error. The error looks like this: error: failed to render source code for `src/test/rustdoc/smart-punct.rs`: "bar": foo --> src/test/rustdoc/smart-punct.rs:3:1 | 3 | / #![crate_name = "foo"] 4 | | 5 | | //! This is the "start" of the 'document'! How'd you know that "it's" ... 6 | | //! ... | 22 | | //! I say "don't smart-punct me -- please!" 23 | | //! ``` | |_______^ I wasn't sure how to trigger the error, so to create that message I temporarily made rustdoc always emit it. That's also why it says "bar" and "foo" instead of a real error message. Note that the span of the diagnostic starts at line 3 because line 1 of that file is a (non-doc) comment and line 2 is a blank line.
-
由 Dylan DPC 提交于
Add function core::iter::zip This makes it a little easier to `zip` iterators: ```rust for (x, y) in zip(xs, ys) {} // vs. for (x, y) in xs.into_iter().zip(ys) {} ``` You can `zip(&mut xs, &ys)` for the conventional `iter_mut()` and `iter()`, respectively. This can also support arbitrary nesting, where it's easier to see the item layout than with arbitrary `zip` chains: ```rust for ((x, y), z) in zip(zip(xs, ys), zs) {} for (x, (y, z)) in zip(xs, zip(ys, zs)) {} // vs. for ((x, y), z) in xs.into_iter().zip(ys).zip(xz) {} for (x, (y, z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {} ``` It may also format more nicely, especially when the first iterator is a longer chain of methods -- for example: ```rust iter::zip( trait_ref.substs.types().skip(1), impl_trait_ref.substs.types().skip(1), ) // vs. trait_ref .substs .types() .skip(1) .zip(impl_trait_ref.substs.types().skip(1)) ``` This replaces the tuple-pair `IntoIterator` in #78204. There is prior art for the utility of this in [`itertools::zip`]. [`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html
-
由 Dylan DPC 提交于
update array missing `IntoIterator` msg fixes #82602 r? ```@estebank``` do you know whether we can use the expr span in `rustc_on_unimplemented`? The label isn't too great rn
-
由 Dylan DPC 提交于
make unaligned_references future-incompat lint warn-by-default and also remove the safe_packed_borrows lint that it replaces. `std::ptr::addr_of!` has hit beta now and will hit stable in a month, so I propose we start fixing https://github.com/rust-lang/rust/issues/27060 for real: creating a reference to a field of a packed struct needs to eventually become a hard error; this PR makes it a warn-by-default future-incompat lint. (The lint already existed, this just raises its default level.) At the same time I removed the corresponding code from unsafety checking; really there's no reason an `unsafe` block should make any difference here. For references to packed fields outside `unsafe` blocks, this means `unaligned_refereces` replaces the previous `safe_packed_borrows` warning with a link to https://github.com/rust-lang/rust/issues/82523 (and no more talk about unsafe blocks making any difference). So behavior barely changes, the warning is just worded differently. For references to packed fields inside `unsafe` blocks, this PR shows a new future-incompat warning. Closes https://github.com/rust-lang/rust/issues/46043 because that lint no longer exists.
-
由 Dylan DPC 提交于
combine: stop eagerly evaluating consts `super_relate_consts` eagerly evaluates constants which doesn't seem too great. I now also finally understand why all of the unused substs test passed. The reason being that we just evaluated the constants in `super_relate_consts`
😆 While this change isn't strictly necessary as evaluating consts here doesn't hurt, it still feels a lot cleaner to do it this way r? `@oli-obk` `@nikomatsakis` -
由 Josh Stone 提交于
-
由 bors 提交于
Rollup of 10 pull requests Successful merges: - #79399 (Use detailed and shorter fs error explaination) - #83348 (format macro argument parsing fix) - #83462 (ExitStatus: print "exit status: {}" rather than "exit code: {}" on unix) - #83526 (lazily calls some fns) - #83558 (Use DebugStruct::finish_non_exhaustive() in std.) - #83559 (Fix Debug implementation for RwLock{Read,Write}Guard.) - #83560 (Derive Debug for io::Chain instead of manually implementing it.) - #83561 (Improve Debug implementations of Mutex and RwLock.) - #83567 (Update rustup cross-compilation docs link) - #83569 (Add regression tests for #56445) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
-
由 Yuki Okushi 提交于
Add regression tests for #56445 Closes #56445.
-
由 Yuki Okushi 提交于
Update rustup cross-compilation docs link
-
由 Yuki Okushi 提交于
Improve Debug implementations of Mutex and RwLock. This improves the Debug implementations of Mutex and RwLock. They now show the poison flag and use debug_non_exhaustive. (See #67364.)
-
由 Yuki Okushi 提交于
Derive Debug for io::Chain instead of manually implementing it. This derives Debug for io::Chain instead of manually implementing it. The manual implementation has the same bounds, so I don't think there's any reason for a manual implementation. The names used in the derive implementation are even nicer (`first`/`second`) than the manual implementation (`t`/`u`), and include the `done_first` field too.
-
由 Yuki Okushi 提交于
Fix Debug implementation for RwLock{Read,Write}Guard. This would attempt to print the Debug representation of the lock that the guard has locked, which will try to lock again, fail, and just print `"<locked>"` unhelpfully. After this change, this just prints the contents of the mutex, like the other smart pointers (and MutexGuard) do. MutexGuard had this problem too: https://github.com/rust-lang/rust/issues/57702
-
由 Yuki Okushi 提交于
Use DebugStruct::finish_non_exhaustive() in std. See https://github.com/rust-lang/rust/issues/67364
-
由 Yuki Okushi 提交于
lazily calls some fns Replaced some fn's with it's lazy variants.
-
由 Yuki Okushi 提交于
ExitStatus: print "exit status: {}" rather than "exit code: {}" on unix Proper Unix terminology is "exit status" (vs "wait status"). "exit code" is imprecise on Unix and therefore unclear. (As far as I can tell, "exit code" is correct terminology on Windows.) This new wording is unfortunately inconsistent with the identifier names in the Rust stdlib. It is the identifier names that are wrong, as discussed at length in eg https://doc.rust-lang.org/nightly/std/process/struct.ExitStatus.html https://doc.rust-lang.org/nightly/std/os/unix/process/trait.ExitStatusExt.html Unfortunately for API stability reasons it would be a lot of work, and a lot of disruption, to change the names in the stdlib (eg to rename `std::process::ExitStatus` to `std::process::ChildStatus` or something), but we should fix the message output. Many (probably most) readers of these messages about exit statuses will be users and system administrators, not programmers, who won't even know that Rust has this wrong terminology. So I think the right thing is to fix the documentation (as I have already done) and, now, the terminology in the implementation. This is a user-visible change to the behaviour of all Rust programs which run Unix subprocesses. Hopefully no-one is matching against the exit status string, except perhaps in tests.
-
由 Yuki Okushi 提交于
format macro argument parsing fix When the character next to `{}` is "shifted" (when mapping a byte index in the format string to span) we should avoid shifting the span end index, so first map the index of `}` to span, then bump the span, instead of first mapping the next byte index to a span (which causes bumping the end span too much). Regression test added. Fixes #83344 --- r? ```@estebank```
-
由 Yuki Okushi 提交于
Use detailed and shorter fs error explaination Includes suggestion from `@the8472` https://github.com/rust-lang/rust/issues/79390#issuecomment-733263336
-
- 27 3月, 2021 11 次提交
-
-
由 Ralf Jung 提交于
make unaligned_refereces future-incompat lint warn-by-default, and remove the safe_packed_borrows lint that it replaces
-
由 lcnr 提交于
-
由 Bastian Kauschke 提交于
-
由 Simon Jakobi 提交于
Closes #56445.
-
由 Jon Jensen 提交于
-
由 bors 提交于
Generalize and inline slice::fill specializations This makes the memset specialization applicable to more types. And since the code now lives in a generic method it is also eligible for cross-crate inlining which should fix #83235
-
由 Ivan Tham 提交于
Consistency for #79399 Suggested by JohnTitor Improve fs error invaild input for sys_common The text was duplicated from unix.
-
由 Ivan Tham 提交于
Includes suggestion from the8472 https://github.com/rust-lang/rust/issues/79390#issuecomment-733263336 More detail error explanation in fs doc
-
由 Mara Bos 提交于
They now show the poison flag and use debug_non_exhaustive.
-
由 Mara Bos 提交于
The manual implementation has the same bounds, so I don't think there's any reason for a manual implementation. The names used in the derive implementation are even nicer (`first`/`second`) than the manual implementation (`t`/`u`), and include the `done_first` field too.
-
由 Mara Bos 提交于
This would attempt to print the Debug representation of the lock that the guard has locked, which will try to lock again, fail, and just print "<locked>" unhelpfully. After this change, this just prints the contents of the mutex, like the other smart pointers (and MutexGuard) do.
-