- 13 10月, 2015 2 次提交
-
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
-
- 11 10月, 2015 1 次提交
-
-
由 Steve Klabnik 提交于
"Crate features" isn't a thing in Rust, but you do need to add this line to your crate root. Fixes #28944
-
- 10 10月, 2015 1 次提交
-
-
由 Barosl Lee 提交于
Previously, `/**/` was incorrectly regarded as a doc comment because it starts with `/**` and ends with `*/`. However, this caused an ICE because some code assumed that the length of a doc comment is at least 5. This commit adds an additional check to `is_block_doc_comment` that tests the length of the input. Fixes #28844.
-
- 09 10月, 2015 4 次提交
-
-
由 Felix S. Klock II 提交于
-
由 Nick Cameron 提交于
-
由 Nick Cameron 提交于
and some unrelated test cleanups
-
由 Cristi Cobzarenco 提交于
-
- 08 10月, 2015 3 次提交
-
-
由 Felix S. Klock II 提交于
Added tests illustrating when and when not to use the UGEH attribute w.r.t. types in negative position.
-
由 Felix S. Klock II 提交于
-
由 Felix S. Klock II 提交于
-
- 07 10月, 2015 3 次提交
-
-
由 Björn Steinbrink 提交于
Fixes #28839
-
由 Simonas Kazlauskas 提交于
-
由 Carlos Liam 提交于
Sorry I didn’t get this in the last PR (#28864), I hadn’t thought of it.
-
- 06 10月, 2015 3 次提交
-
-
由 Felix S. Klock II 提交于
(It is not *exactly* the text from the RFC, but the only thing it adds is a call to a no-op function that is just an attempt to make it clear where the potential for impl specialization comes from.)
-
由 Felix S. Klock II 提交于
-
由 Felix S. Klock II 提交于
One just checks that we are feature-gating the UGEH attribute (as usual for attributes associated with unstable features). The other is adapted from the RFC 1238 text, except that it has been extended somewhat to actually *illustrate* the scenario that we are trying to prevent, namely observing the state of data, from safe code, after the destructor for that data has been executed.
-
- 05 10月, 2015 1 次提交
-
-
由 Jed Davis 提交于
This turned up as part of #3170. When constructing an `undef` value to return in the error case, we were trying to get the element type of the Rust-level value being indexed instead of the underlying array; when indexing a slice, that's not an array and the LLVM assertion failure reflects this. The regression test is a lightly altered copy of `const-array-oob.rs`.
-
- 03 10月, 2015 3 次提交
-
-
由 Ariel Ben-Yehuda 提交于
also, ensure that callers are checked.
-
由 Ariel Ben-Yehuda 提交于
looks like some mix of #18653 and `projection_must_outlive`, but that needs to be investigated further (crater run?)
-
由 Ariel Ben-Yehuda 提交于
By RFC1214: Before calling a fn, we check that its argument and return types are WF. This check takes place after all higher-ranked lifetimes have been instantiated. Checking the argument types ensures that the implied bounds due to argument types are correct. Checking the return type ensures that the resulting type of the call is WF. The previous code only checked the trait-ref, which was not enough in several cases. As this is a soundness fix, it is a [breaking-change]. Fixes #28609
-
- 02 10月, 2015 2 次提交
-
-
由 Seo Sanghyeon 提交于
-
由 Seo Sanghyeon 提交于
-
- 01 10月, 2015 4 次提交
-
-
由 Ariel Ben-Yehuda 提交于
Fixes #28776
-
由 Ariel Ben-Yehuda 提交于
Fixes #27890 Fixes #28099 Fixes #28113
-
由 Eli Friedman 提交于
The behavior here isn't really ideal, but we can't really do much better given the current state of constant evaluation. Fixes #28670, and probably a bunch of duplicates.
-
由 Alex Crichton 提交于
This lint warning was originally intended to help against misuse of the old Rust `int` and `uint` types in FFI bindings where the Rust `int` was not equal to the C `int`. This confusion no longer exists (as Rust's types are now `isize` and `usize`), and as a result the need for this lint has become much less over time. Additionally, starting with [the RFC for libc][rfc] it's likely that `isize` and `usize` will be quite common in FFI bindings (e.g. they're the definition of `size_t` and `ssize_t` on many platforms). [rfc]: https://github.com/rust-lang/rfcs/pull/1291 This commit disables these lints to instead consider `isize` and `usize` valid types to have in FFI signatures.
-
- 27 9月, 2015 3 次提交
-
-
由 Ariel Ben-Yehuda 提交于
Fixes #28568
-
由 Ariel Ben-Yehuda 提交于
different supertraits can suffer from the same object-safety violation, leading to duplication in the error message. Avoid it. Fixes #20692
-
由 Ariel Ben-Yehuda 提交于
Because of type inference, duplicate obligations exist and cause duplicate errors. To avoid this, only display the first error for each (predicate,span). The inclusion of the span is somewhat bikesheddy, but *is* the more conservative option (it does not remove some instability, as duplicate obligations are ignored by `duplicate_set` under some inference conditions). Fixes #28098 cc #21528 (is it a dupe?)
-
- 24 9月, 2015 3 次提交
-
-
由 Ariel Ben-Yehuda 提交于
Fixes #28576
-
由 Eduard Burtescu 提交于
-
由 Sebastian Wicki 提交于
This adds a new target property, `target_vendor` which can be used as a matcher for conditional compilation. The vendor is part of the autoconf target triple: <arch><sub>-<vendor>-<os>-<env> The default value for `target_vendor` is "unknown". Matching against the `target_vendor` with `#[cfg]` is currently feature gated as `cfg_target_vendor`.
-
- 23 9月, 2015 1 次提交
-
-
由 Seo Sanghyeon 提交于
walk_expr includes call to visit_expr for subexpressions.
-
- 22 9月, 2015 1 次提交
-
-
由 Lee Jeffery 提交于
-
- 20 9月, 2015 3 次提交
-
-
由 Lee Jeffery 提交于
-
由 Andrew Paseltiner 提交于
Closes #28091.
-
由 William Throwe 提交于
I assume the expected error changed during the development of pull request #28321 and that wasn't noticed because the test was accidentally not running.
-
- 19 9月, 2015 2 次提交
-
-
由 Vadim Petrochenkov 提交于
-
由 Jorge Aparicio 提交于
-