- 17 9月, 2018 6 次提交
-
-
由 memoryruins 提交于
-
由 bors 提交于
Improve output if no_lookup_host_duplicates test fails If the test fails, output the offending addresses and a helpful error message. Also slightly improve legibility of the preceding line that puts the addresses into a HashMap.
-
由 bors 提交于
Move std::os::raw::c_void into libcore and re-export in libstd Implements the first part of [RFC 2521](https://github.com/rust-lang/rfcs/pull/2521). cc #53856
-
由 bors 提交于
resolve: Do not error on access to proc macros imported with `#[macro_use]` This error is artificial, but previously, when `#[macro_use] extern crate x;` was stable, but non-derive proc macros were not, it worked like kind of a feature gate. Now both features are stable, so the error is no longer necessary. This PR simplifies how `#[macro_use] extern crate x;` works - it takes all items from macro namespace of `x`'s root and puts them into macro prelude from which they all can now be accessed.
-
由 Vadim Petrochenkov 提交于
-
由 bors 提交于
fix some uses of pointer intrinsics with invalid pointers [Found by miri](https://github.com/solson/miri/pull/446): * `Vec::into_iter` calls `ptr::read` (and the underlying `copy_nonoverlapping`) with an unaligned pointer to a ZST. [According to LLVM devs](https://bugs.llvm.org/show_bug.cgi?id=38583), this is UB because it contradicts the metadata we are attaching to that pointer. * `HashMap` creation calls `ptr:.write_bytes` on a NULL pointer with a count of 0. This is likely not currently UB *currently*, but it violates the rules we are setting in https://github.com/rust-lang/rust/pull/53783, and we might want to exploit those rules later (e.g. with more `nonnull` attributes for LLVM). Probably what `HashMap` really should do is use `NonNull::dangling()` instead of 0 for the empty case, but that would require a more careful analysis of the code. It seems like ideally, we should do a review of usage of such intrinsics all over libstd to ensure that they use valid pointers even when the size is 0. Is it worth opening an issue for that?
-
- 16 9月, 2018 18 次提交
-
-
由 bors 提交于
Rollup of 5 pull requests Successful merges: - #53941 (rustdoc: Sort implementors) - #54181 (Suggest && and || instead of 'and' and 'or') - #54209 (Partially revert 674a5db1 "Fix undesirable fallout [from macro modularization]") - #54213 (De-overlap the lifetimes of `flow_inits` and `flow_{un,ever_}inits`.) - #54244 (Add a small search box to seach Rust's standary library) Failed merges: r? @ghost
-
由 Ralf Jung 提交于
-
由 Guillaume Gomez 提交于
Add a small search box to seach Rust's standary library This change partially addresses #14572. No CSS doesn't look fancy but at least it is functional.
-
由 Guillaume Gomez 提交于
De-overlap the lifetimes of `flow_inits` and `flow_{un,ever_}inits`. This reduces `max-rss` for an `nll-check` build by 27% for `keccak`, and by 8% for `inflate`. r? @nikomatsakis
-
由 Guillaume Gomez 提交于
Partially revert 674a5db1 "Fix undesirable fallout [from macro modularization]" Partially revert https://github.com/rust-lang/rust/commit/674a5db1a50e25dd60a8ee6669edee9a366c9fab ~~Closes~~ (see pnkfelix comments below) https://github.com/rust-lang/rust/issues/53675
-
由 Guillaume Gomez 提交于
Suggest && and || instead of 'and' and 'or' Resolves #54109. Note: competing pull reqeust: #54179 r? @csmoe
-
由 Guillaume Gomez 提交于
rustdoc: Sort implementors Fixes #53812
-
由 bors 提交于
use structured suggestion for "missing mut" label Fixes #54133 for both NLL and non-NLL. r? @estebank I'm not super happy with the existing wording here, since it's now a suggestion. I wonder if the message would work better as something like "help: make binding mutable: `mut foo`"? Also, are the `HELP` and `SUGGESTION` comments necessary?
-
由 Kazuyoshi Kato 提交于
-
由 bors 提交于
stabilize slice_align_to This is very hard to implement correctly, and leads to [serious bugs](https://github.com/llogiq/bytecount/pull/42) when done incorrectly. Moreover, this is needed to be able to run code that opportunistically exploits alignment on miri. So code using `align_to`/`align_to_mut` gets the benefit of a well-tested implementation *and* of being able to run in miri to test for (some kinds of) UB. This PR also clarifies the guarantee wrt. the middle part being as long as possible. Should the docs say under which circumstances the middle part could be shorter? Currently, that can only happen when running in miri.
-
由 bors 提交于
rustc_resolve: allow only core, std, meta and --extern in Rust 2018 paths. As per https://github.com/rust-lang/rust/issues/53166#issuecomment-419265401: * Rust 2018 imports can no longer refer to crates not in "extern prelude" * `::foo` won't load a crate named `foo` unless `foo` is in the "extern prelude" * `extern crate foo;`, however, remains unchanged (can load arbitrary crates) * `--extern crate_name` is added (note the lack of `=path`) as an unstable option * adds `crate_name` to the "extern prelude" (see above) * crate is searched in sysroot & library paths, just like `extern crate crate_name`. * `Cargo` support will be added later * `core`, `std` and ~~`proc_macro`~~ `meta` are *always* available in the extern prelude * warning for interaction with `no_std` / `no_core` will be added later * **EDIT**: `proc_macro` was replaced by `meta`, see https://github.com/rust-lang/rust/issues/53166#issuecomment-421137230 * note that there is no crate named `meta` being added, so `use meta::...;` will fail, we're only whitelisting it so we can start producing `uniform_paths` compatibility errors Fixes #54006 (as the example now requires `--extern alloc`, which is unstable). Fixes #54253 (hit during fixing RLS). r? @petrochenkov cc @aturon @alexcrichton @Centril @joshtriplett
-
由 Eduard-Mihai Burtescu 提交于
This reverts commit 9f53c87b, reversing changes made to cba0fdf4.
-
由 Eduard-Mihai Burtescu 提交于
-
由 Eduard-Mihai Burtescu 提交于
-
由 Eduard-Mihai Burtescu 提交于
-
由 Eduard-Mihai Burtescu 提交于
-
由 Eduard-Mihai Burtescu 提交于
-
由 Eduard-Mihai Burtescu 提交于
-
- 15 9月, 2018 11 次提交
-
-
由 Philip Munksgaard 提交于
If the test fails, output the offending addresses and a helpful error message. Also slightly improve legibility of the preceding line that puts the addresses into a HashMap.
-
由 bors 提交于
Add option to run all tests This adds the "--include-ignored" flag to libtest, which allows running ignored and unignored tests in one go. Closes #50363
-
由 bors 提交于
Add inspection and setter methods to proc_macro::Diagnostic. A few useful methods for `proc_macro::Diagnostic`. r? @alexcrichton
-
由 bors 提交于
Update Clippy Clippy one commit behind #54226. This should work r? @Manishearth
-
由 bors 提交于
Remove bitslice.rs As the comment in `bitslice.rs` says: > FIXME: merge with `bitvec`
-
由 Kazuyoshi Kato 提交于
This change partially addresses #14572. No CSS doesn't look fancy but at least it is functional.
-
由 Kazuyoshi Kato 提交于
The way it defines implementations is unrealistic though.
-
由 bors 提交于
A few cleanups for hir - prefer `if let` to `match` when only 1 branch matters - `chain` iterable items that are looped over in sequence - `sort_by_key` instead of `sort_by` when possible - change cloning `map`s to `cloned()` - use `unwrap_or_else` and `ok` when applicable - a few other minor readability improvements - whitespace fixes
-
由 Vitaly _Vi Shukela 提交于
-
由 bors 提交于
resolve: Introduce two sub-namespaces in macro namespace Two sub-namespaces are introduced in the macro namespace - one for bang macros and one for attribute-like macros (attributes, derives). "Sub-namespace" means this is not a newly introduced full namespace, the single macro namespace is still in place. I.e. you still can't define/import two macros with the same name in a single module, `use` imports still import only one name in macro namespace (from any sub-namespace) and not possibly two. However, when we are searching for a name used in a `!` macro call context (`my_macro!()`) we skip attribute names in scope, and when we are searching for a name used in attribute context (`#[my_macro]`/`#[derive(my_macro)]`) we are skipping bang macro names in scope. In other words, bang macros cannot shadow attribute macros and vice versa. For a non-macro analogy, we could e.g. skip non-traits when searching for `MyTrait` in `impl MyTrait for Type { ... }`. However we do not do it in non-macro namespaces because we don't have practical issues with e.g. non-traits shadowing traits with the same name, but with macros we do, especially after macro modularization. For `#[test]` and `#[bench]` we have a hack in the compiler right now preventing their shadowing by `macro_rules! test` and similar things. This hack was introduced after making `#[test]`/`#[bench]` built-in macros instead of built-in attributes (https://github.com/rust-lang/rust/pull/53410), something that needed to be done from the start since they are "active" attributes transforming their inputs. Now they are passed through normal name resolution and can be shadowed, but that's a breaking change, so we have a special hack basically applying this PR for `#[test]` and `#[bench]` only. Soon all potentially built-in attributes will be passed through normal name resolution (https://github.com/rust-lang/rust/pull/53913) and that uncovers even more cases where the strict "macro namespace is a single namespace" rule needs to be broken. For example, with strict rules, built-in macro `cfg!(...)` would shadow built-in attribute `#[cfg]` (they are different things), standard library macro `thread_local!(...)` would shadow built-in attribute `#[thread_local]` - both of these cases are covered by special hacks in https://github.com/rust-lang/rust/pull/53913 as well. Crater run uncovered more cases of attributes being shadowed by user-defined macros (`warn`, `doc`, `main`, even `deprecated`), we cannot add exceptions in the compiler for all of them. Regressions with user-defined attributes like https://github.com/rust-lang/rust/issues/53583 and https://github.com/rust-lang/rust/issues/53898 also appeared after enabling macro modularization. People are also usually confused (https://github.com/rust-lang/rust/issues/53205#issuecomment-411552763, https://github.com/rust-lang/rust/issues/53583#issuecomment-415447800) when they see conflicts between attributes and non-attribute macros for the first time. So my proposed solution is to solve this issue by introducing two sub-namespaces and thus skipping resolutions of the wrong kind and preventing more error-causing cases of shadowing. Fixes https://github.com/rust-lang/rust/issues/53583
-
由 bors 提交于
rustc_resolve: don't treat uniform_paths canaries as ambiguities unless they resolve to distinct Def's. In particular, this allows this pattern that @cramertj mentioned in https://github.com/rust-lang/rust/issues/53130#issuecomment-420848814: ```rust use log::{debug, log}; fn main() { use log::{debug, log}; debug!(...); } ``` The canaries for the inner `use log::...;`, *in the macro namespace*, see the `log` macro imported at the module scope, and the (same) `log` macro, imported in the block scope inside `main`. Previously, these two possible (macro namspace) `log` resolutions would be considered ambiguous (from a forwards-compat standpoint, where we might make imports aware of block scopes). With this PR, such a case is allowed *if and only if* all the possible resolutions refer to the same definition (more specifically, because the *same* `log` macro is being imported twice). This condition subsumes previous (weaker) checks like #54005 and the second commit of #54011. Only the last commit is the main change, the other two are cleanups. r? @petrochenkov cc @Centril @joshtriplett
-
- 14 9月, 2018 5 次提交
-
-
由 bors 提交于
[NLL] Suggest let binding Closes #49821 Also adds an alternative to `explain_why_borrow_contains_point` that allows changing error messages based on the reason that will be given. This will also be useful for #51026, #51169 and maybe further changes to does not live long enough messages.
-
由 Isaac Woods 提交于
-
由 bors 提交于
Addressed #53692 @sunjay @estebank @csmoe hopefully this answer #53692 Please let me know if you have any suggestion
-
由 flip1995 提交于
-