.copy_from_slice() does the same job of .clone_from_slice(), but the
former is explicitly for Copy elements and calls `memcpy` directly, and
thus is it efficient without optimization too.
This commit adds support for *truly* unstable options in the compiler, as well
as adding warnings for the start of the deprecation path of
unstable-but-not-really options. Specifically, the following behavior is now in
place for handling unstable options:
* As before, an unconditional error is emitted if an unstable option is passed
and the `-Z unstable-options` flag is not present. Note that passing another
`-Z` flag does not require passing `-Z unstable-options` as well.
* New flags added to the compiler will be in the `Unstable` category as opposed
to the `UnstableButNotReally` category which means they will unconditionally
emit an error when used on stable.
* All current flags are in a category where they will emit warnings when used
that the option will soon be a hard error.
Also as before, it is intended that `-Z` is akin to `#![feature]` in a crate
where it is required to unlock unstable functionality. A nightly compiler which
is used without any `-Z` flags should only be exercising stable behavior.
This commit adds support for *truly* unstable options in the compiler, as well
as adding warnings for the start of the deprecation path of
unstable-but-not-really options. Specifically, the following behavior is now in
place for handling unstable options:
* As before, an unconditional error is emitted if an unstable option is passed
and the `-Z unstable-options` flag is not present. Note that passing another
`-Z` flag does not require passing `-Z unstable-options` as well.
* New flags added to the compiler will be in the `Unstable` category as opposed
to the `UnstableButNotReally` category which means they will unconditionally
emit an error when used on stable.
* All current flags are in a category where they will emit warnings when used
that the option will soon be a hard error.
Also as before, it is intended that `-Z` is akin to `#![feature]` in a crate
where it is required to unlock unstable functionality. A nightly compiler which
is used without any `-Z` flags should only be exercising stable behavior.
The standard library doesn't depend on rustc_bitflags, so move it to explicit
dependencies on all other crates. Additionally, the arena/fmt_macros deps could
be dropped from libsyntax.
The standard library doesn't depend on rustc_bitflags, so move it to explicit
dependencies on all other crates. Additionally, the arena/fmt_macros deps could
be dropped from libsyntax.
This warning was introduced on Nov 28, 2015 and got into 1.6 stable, it was later requalified from a hardwired warning to a warn-by-default lint.
If this patch is landed soon enough, then `match_of_unit_variant_via_paren_dotdot` will get into 1.8 stable as a deny-by-default lint.
My intention is to turn it into a hard error after March 3, 2016, then it will hit stable at 1.9.
r? @nikomatsakis
cc @pnkfelix
this improves typeck performance by 5% (LLVM times are still huge).
Basically fixes#25916 (still O(n^2), but the example takes <1s to
compile).
r? @nikomatsakis
<sup>**context:** moving back to a layered approach to type checking.</sup>
It looks like they'd not ended up tightly coupled in the time one was owned by the other. Every instance outside of `FnCtxt.inh` was from an `InferCtxt` created and dropped in the same function body.
This conflicts slightly with #30652, but there too it looks like the `FulfillmentContext` is from an `InferCtxt` that is created and dropped within the same function body (across one call to a module-private function).
That said, I heard that the PR that originally moved `FulfillmentContext` into `InferCtxt` was big, which leaves me concerned that I'm missing something.
r? @nikomatsakis
This fixes#31512 for me.
A bit of explanation: I want to have `check_block_post(&mut self, &Context, &Block)` and `check_crate_post(&mut self, &Context, &Crate)` methods in both early and late lint passes. Ideally we'd have _post methods for all operations that walk, but this'll do for now.
@Manishearth r?
r? @brson
cc @alexcrichton
I still need to add error code explanation test with this, but I can't figure out a way to generate the `.md` files in order to test example source codes.
Will fix#27328.
Tools which rely on DWARF for generating code coverage report, don't generate accurate numbers on test builds. For instance, [this sample main](757bdbf388/src/main.rs) returns [100% coverage](https://coveralls.io/builds/4940156/source?filename=main.rs) when [kcov](https://github.com/SimonKagstrom/kcov/) runs.
With @pnkfelix 's great help, we could narrow down the issue: The linker strips unused function during phase 6. Here's a patch which stops stripping when someone calls `rustc --test $ARGS`. @pnkfelix wasn't sure if we should add a new flag, or just use --test. What do you think @alexcrichton ?
Also, I'm not too sure: where is the best place to add a test for this addition?
Thanks for the help!
