Currently, `early_error` and `early_warn` in `librustc::session` always
use `ColorConfig::Auto`. Modify them to follow the color configuration
set by the `--color` option.
As colored output is also printed during the early stage, parsing the
`--color` option should be done as early as possible. However, there are
still some cases when the output needs to be colored before knowing the
exact color settings. In these cases, it will be defaulted to
`ColorConfig::Auto`, which is the same as before.
Fixes#27879.
On Linux the flag is just ignored if it is not supported:
https://lwn.net/Articles/588444/
Still needs the values of O_CLOEXEC on the BSDs.
Touches #24237.
- All the libstd tests are passing in the optimized build against
a Zenfone2 and the x86 Android emulator.
I haven't tested the other libraries though.
Some hoedown FFI changes:
- `HOEDOWN_EXT_NO_INTRA_EMPHASIS` constant changed.
- Updated/tidied up all callback function signatures.
- All opaque data access has an additional layer of indirection for some reason (`hoedown_renderer_data`).
This also fixes#27862.
This increases regionck performance greatly - type-checking on
librustc decreased from 9.1s to 8.1s. Because of Amdahl's law,
total performance is improved only by about 1.5% (LLVM wizards,
this is your opportunity to shine!).
before:
576.91user 4.26system 7:42.36elapsed 125%CPU (0avgtext+0avgdata 1142192maxresident)k
after:
566.50user 4.84system 7:36.84elapsed 125%CPU (0avgtext+0avgdata 1124304maxresident)k
I am somewhat worried really need to find out why we have this Red Queen's
Race going on here. Originally I suspected it may be a problem from RFC1214's
warnings, but it seems to be an effect from other changes.
However, the increase seems to be mostly in LLVM's time, so I guess
it's the LLVM wizards' problem.
r? @nikomatsakis
This increases regionck performance greatly - type-checking on
librustc decreased from 9.1s to 8.1s. Because of Amdahl's law,
total performance is improved only by about 1.5% (LLVM wizards,
this is your opportunity to shine!).
before:
576.91user 4.26system 7:42.36elapsed 125%CPU (0avgtext+0avgdata 1142192maxresident)k
after:
566.50user 4.84system 7:36.84elapsed 125%CPU (0avgtext+0avgdata 1124304maxresident)k
I am somewhat worried really need to find out why we have this Red Queen's
Race going on here. Originally I suspected it may be a problem from RFC1214's
warnings, but it seems to be an effect from other changes.
However, the increase seems to be mostly in LLVM's time, so I guess
it's the LLVM wizards' problem.
Since enums are namespaced now, should we also remove the `Fk` prefixes from `FnKind` and remove the reexport? (The reexport must be removed because otherwise it clashes with glob imports containing `ItemFn`). IMO writing `FnKind::Method` is much clearer than `FkMethod`.
It doesn't really make sense for DefId to be in libsyntax -- it is concerned with a single crate only. It is the compiler that understands the idea of many crates. (At some point, there might be a useful intermediate point here.) This is a refactoring in support of incr. compilation, which will be adjusting the notion of a DefId to make it more durable across compilations.
This will probably be a [breaking-change] for every plugin ever. You need to adjust things as follows:
use rustc::middle::def_id::{DefId, LOCAL_CRATE}; // two most common definitions
ast_util::is_local(def_id) => def_id.is_local()
ast_util::local_def(node_id) => DefId::local(node_id)
We're currently possibly introducing an unneeded temporary, make use of
InsertValue which is said to kick us off of FastISel and we generate
loads/stores of first class aggregates, which is bad as well. Let's not
do all these things.
Part of #24407.
This PR doesn't have code example since I didn't find how to raise it. If someone finds a code which does, please say it !
cc @pnkfelix
cc @eddyb
r? @Manishearth
We're currently possibly introducing an unneeded temporary, make use of
InsertValue which is said to kick us off of FastISel and we generate
loads/stores of first class aggregates, which is bad as well. Let's not
do all these things.
It came up twice in quick succession on IRC that rustdoc doesn't run tests in bin crates, and doesn't give any explanation/warning either as to why. I thought it couldn't hurt to emphasize that in the Book.
The chapter on concurrency has two examples that both start with:
let something = thread::spawn(…
but the returned values have different types, because the second example has `.join()` at the end of the expression.
I haven't noticed that join at first, and was wondering how is that possible that the result can have `.is_err()` and `.join()` methods.
I've changed the second example to have the same structure as the first, so they're easy to compare.
