Uh oh!
There was an error while loading. Please reload this page.
Prepared std::sys for removal, and made begin_unwind simpler - #10120
Conversation
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.
alexcrichton
commented
Oct 28, 2013
Awesome! Could you add some tests exercising functionality calling the Also, could you add a implementation of |
Kimundi
commented
Oct 28, 2013
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. :) |
Kimundi
commented
Oct 28, 2013
I tried it, and making |
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.
Kimundi
commented
Oct 29, 2013
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. |
Kimundi
commented
Oct 30, 2013
I updated the PR to also simplify our |
There was a problem hiding this comment.
If this is truly internal, I feel like this shouldn't be pub
alexcrichton
commented
Oct 30, 2013
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 Resolvesrust-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-->
11287: fix: rust-analyzer spamming overly error message when workspace not being loaded r=lnicola a=Milo123459 Fixesrust-lang#10120 Co-authored-by: Milo <50248166+Milo123459@users.noreply.github.com>
begin_unwindandfail!is now generic over anyT: Any + Send.~Any.&'static strand~strare stillhandled specially behind the scenes.
literal, and enabled doc comments there.