It looks like `from_vec` was subsumed by new at some point,
but the documentation still refers to it as `from_vec`.
This updates the documentation for `from_vec_unchecked`
so that it properly says that it's the unchecked version of `new`.
Also, from_vec_unchecked requires a actual Vec<u8> while
new can take anything that is Into<Vec<u8>>, so I also
mention that in the documentation.
The "static and dynamic dispatch" chapter seems to no longer exist but there is a dead link from the Traits chapter pointing to it.
Have changed the link to point to "Trait Objects" which covers static and dynamic dispatch.
* In `noop_fold_expr`, call `new_span` in these cases:
- `ExprMethodCall`'s identifier
- `ExprField`'s identifier
- `ExprTupField`'s integer
Calling `new_span` for `ExprMethodCall`'s identifier is necessary to print
an acceptable diagnostic for `write!(&2, "")`. We see this error:
```
<std macros>:2:20: 2:66 error: type `&mut _` does not implement any method in scope named `write_fmt`
<std macros>:2 ( & mut * $ dst ) . write_fmt ( format_args ! ( $ ( $ arg ) * ) ) )
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
With this change, we also see a macro expansion backtrace leading to
the `write!(&2, "")` call site.
* After fully expanding a macro, we replace the expansion expression's
span with the original span. Call `fld.new_span` to add a backtrace to
this span. (Note that I'm call `new_span` after `bt.pop()`, so the macro
just expanded isn't on the backtrace.)
The motivating example for this change is `println!("{}")`. The format
string literal is `concat!($fmt, "arg")` and is inside the libstd macro.
We need to see the backtrace to find the `println!` call site.
* Add a backtrace to the `format_args!` format expression span.
r? alexcrichton
Addresses #23459
We provide tools to tell what exact symbols to emit for any fn or static, but
don’t quite check if that won’t cause any issues later on. Some of the issues
include LLVM mangling our names again and our names pointing to wrong locations,
us generating dumb foreign call wrappers, linker errors, extern functions
resolving to different symbols altogether (`extern {fn fail();} fail();` in some
cases calling `fail1()`), etc.
Before the commit we had a function called `note_unique_llvm_symbol`, so it is
clear somebody was aware of the issue at some point, but the function was barely
used, mostly in irrelevant locations.
Along with working on it I took liberty to start refactoring trans/base into
a few smaller modules. The refactoring is incomplete and I hope I will find some
motivation to carry on with it.
This is possibly a [breaking-change] because it makes dumbly written code
properly invalid.
This fixes all those issues about incorrect use of #[no_mangle] being not reported/misreported/ICEd by the compiler.
NB. This PR does not attempt to tackle the parallel codegen issue that was mentioned in https://github.com/rust-lang/rust/pull/22811, but I believe it should be very straightforward in a follow up PR by modifying `trans::declare::get_defined_value` to look at all the contexts.
cc @alexcrichton @huonw @nrc because you commented on the original RFC issue.
EDIT: wow, this became much bigger than I initially intended.
* In noop_fold_expr, call new_span in these cases:
- ExprMethodCall's identifier
- ExprField's identifier
- ExprTupField's integer
Calling new_span for ExprMethodCall's identifier is necessary to print
an acceptable diagnostic for write!(&2, ""). We see this error:
<std macros>:2:20: 2:66 error: type `&mut _` does not implement any method in scope named `write_fmt`
<std macros>:2 ( & mut * $ dst ) . write_fmt ( format_args ! ( $ ( $ arg ) * ) ) )
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
With this change, we also see a macro expansion backtrace leading to
the write!(&2, "") call site.
* After fully expanding a macro, we replace the expansion expression's
span with the original span. Call fld.new_span to add a backtrace to
this span. (Note that I'm call new_span after bt.pop(), so the macro
just expanded isn't on the backtrace.)
The motivating example for this change is println!("{}"). The format
string literal is concat!($fmt, "arg") and is inside the libstd macro.
We need to see the backtrace to find the println! call site.
* Add a backtrace to the format_args! format expression span.
Addresses #23459
This fixes the bug described in issue #23150. This affected formatting any floating point number into a string in a formatting pattern that: a) required rounding up, and b) required an extra digit on the front.
So `format!("{:.0}", 9.9)` would fail, but `format!("{:.0}", 8.9)` would succeed. This was due to a negative integer being cast to a `usize` resulting in an 'arithmetic operation overflowed' panic.
The fix was to change the order of operations so that the number is zero before casting.
From [here](http://doc.rust-lang.org/nightly/std/primitive.i8.html):
> `fn rotate_right(self, n: u32) -> i8`
> Shifts the bits to the right by a specified __amount amount__, n, wrapping the truncated bits to the beginning of the resulting integer.
...to be less confusing. Since 0 is the smallest number possible for usize, it doesn't make sense to mention it if it's already included, and it should be more clear that the length of the vector is a valid index with the new wording.
r? @steveklabnik
Don't use skolemized parameters but rather fresh variables in coherence. Skolemized parameters wind up preventing unification. Surprised we had no test for this! Fixes#24241.
r? @pnkfelix
Example showing sample inputs, old message, new message:
https://gist.github.com/nikomatsakis/11126784ac678b7eb6ba
Also adds infrastructure for reporting suggestions \"in situ\" and does some (minor) cleanups to `CodeMap`.
r? @brson
Now that the new TOC has landed, I've started doing an editing pass to get the old content into the right shape. I felt this introduction was significant enough to send as its own PR, though, as it's the introduction.
It's possible that we may just want to replace 'the intro' with this directly, but this PR doesn't do that.
This fixes the bug described in issue #23150. This affected formatting any floating point number into a string in a formatting pattern that: a) required rounding up, and b) required an extra digit on the front.
So `format!(\"{:.0}\", 9.9)` would fail, but `format!(\"{:.0}\", 8.9)` would succeed. This was due to a negative integer being cast to a `usize` resulting in an 'arithmetic operation overflowed' panic.
The fix was to change the order of operations so that the number is zero before casting.
