Prepared std::sys for removal, and made begin_unwind simpler
#10120
Conversation
| @"mod __std_macros { | ||
| pub fn std_macros() -> &'static str { | ||
| // XXX: Leaving off the `return` causes a weird | ||
| // "not all control paths return a value" compile error |
There was a problem hiding this comment.
Did you remember to remove the trailing ;?
There was a problem hiding this comment.
Also, I'm not so sure about making this not @str, since it's only ever used as a @str.
There was a problem hiding this comment.
Trailing ; ... whoops!
Well, we plan to move away from the @ sigil either way, and copying a &'static str into a @str should be just as efficient as returning a newly constructed @str every time.
|
Awesome! Could you add some tests exercising functionality calling the Also, could you add a implementation of |
|
All fail variants already have run-fail tests. I'll look into fmt::Arguments - I'm not yet familiar with how the formatting stuff is implemented. :) |
|
I tried it, and making |
| } | ||
| } | ||
|
|
||
| impl<T: Any + Send + 'static> FailMessage for ~T { |
There was a problem hiding this comment.
Can you add a comment for why the extra Send bound is necessary? I don't think that 'static is necessary because it should get implied by Send (can't send borrowed pointers for sure).
There was a problem hiding this comment.
Casting a generic type to a owned trait object requires both a Send and a 'static bound, if I remove either of them it won't compile
EDIT:
Actually, 'static really doesn't seem necessary, I'm removing it.
|
There where some repeated discussions about this on IRC, and I'm starting to think that There are only two situations where that causes a problem: Hypothetical failure on OOM, and propagating an received However, both can be addressed by simply providing alternative library functions for initiating failure, so that's not really an issue. I'm updating this PR to include the necessary changes. |
|
I updated the PR to also simplify our |
| begin_unwind_internal(msg, file, line) | ||
| } | ||
|
|
||
| pub fn begin_unwind_internal(msg: UnwindMessage, file: &'static str, line: uint) -> ! { |
There was a problem hiding this comment.
If this is truly internal, I feel like this shouldn't be pub
|
This looks great! I really like the way that this is looking now. So long as the remaining uses of |
- `begin_unwind` is now generic over any `T: Any + Send`. - Every value you fail with gets boxed as an `~Any`. - Because of implementation details, `&'static str` and `~str` are still handled specially behind the scenes. - Changed the big macro source string in libsyntax to a raw string literal, and enabled doc comments there.
- `begin_unwind` and `fail!` is now generic over any `T: Any + Send`. - Every value you fail with gets boxed as an `~Any`. - Because of implementation issues, `&'static str` and `~str` are still handled specially behind the scenes. - Changed the big macro source string in libsyntax to a raw string literal, and enabled doc comments there.
"try this" -> "try" Current help messages contain a mix of "try", "try this", and one "try this instead". In the spirit of rust-lang#10631, this PR adopts the first, as it is the most concise. It also updates the `lint_message_conventions` test to catch cases of "try this". (Aside: rust-lang#10120 unfairly contained multiple changes in one PR. I am trying to break that PR up into smaller pieces.) changelog: Make help messages more concise ("try this" -> "try").
`unwrap_or_else_default` -> `unwrap_or_default` and improve resulting lint Resolves rust-lang#10080 (though it doesn't implement exactly what's described there) This PR does the following: 1. Merges `unwrap_or_else_default.rs`'s code into `or_fun_call.rs` 2. Extracts the code to handle `unwrap_or(/* default value */)` and similar, and moves it into `unwrap_or_else_default` 3. Implements the missing functionality from rust-lang#9342, e.g.,, to handle `or_insert_with(Default::default)` 4. Renames `unwrap_or_else_default` to `unwrap_or_default` (since the "new" lint handles both `unwrap_or` and `unwrap_or_else`, it seemed sensible to use the shortened name) This PR is currently two commits. The first implements 1-3, the second implements 4. A word about 2: the `or_fun_call` lint currently produces warnings like the following: ``` error: use of `unwrap_or` followed by a call to `new` --> $DIR/or_fun_call.rs:56:14 | LL | with_new.unwrap_or(Vec::new()); | ^^^^^^^^^^^^^^^^^^^^^ help: try: `unwrap_or_default()` ``` To me, such warnings look like they should come from `unwrap_or_else_default`, not `or_fun_call`, especially since `or_fun_call` is [in the nursery](rust-lang/rust-clippy#9829). --- changelog: Move: Renamed `unwrap_or_else_default` to [`unwrap_or_default`] [rust-lang#10120](rust-lang/rust-clippy#10120) changelog: Enhancement: [`unwrap_or_default`]: Now handles more functions, like `or_insert_with` [rust-lang#10120](rust-lang/rust-clippy#10120) <!-- changelog_checked-->
begin_unwindandfail!is now generic over anyT: Any + Send.~Any.&'static strand~strare stillhandled specially behind the scenes.
literal, and enabled doc comments there.