appveyor: Downgrade MinGW to 6.2.0
It looks like the 6.3.0 MinGW comes with a gdb which has issues (#40184) that an
attempted workaround (#40777) does not actually fix (#40835). The original
motivation for upgradin MinGW was to fix build flakiness (#40546) due to newer
builds not exhibiting the same bug, so let's hope that 6.2.0 isn't too far back
in time and still contains the fix we need.
Closes#40835
rustbuild: Fix compiler docs again
The docs need to be built with the rustbuild feature so the correct
stability attributes (rustc_private) get applied.
r? @alexcrichton
Fix typo in char::to_uppercase documentation
Original documentation appears to have been copied from `char::to_lowercase` in a manner that made it imply that `char::to_uppercase` actually mapped unicode characters to their **lowercase** equivalent.
libcore: fix compilation on 16bit target (MSP430).
Since PR #40601 has been merged, libcore no longer compiles on MSP430.
The reason is this code in `break_patterns`:
```rust
let mut random = len;
random ^= random << 13;
random ^= random >> 17;
random ^= random << 5;
random &= modulus - 1;
```
It assumes that `len` is at least a 32 bit integer.
As a workaround replace `break_patterns` with an empty function for 16bit targets.
cc @stjepang
cc @alexcrichton
rustdoc to accept `#` at the start of a markdown file #40560
This may be a bit odd if `#` and `%` lines are mixed up, but that's not something I've found while doing my search and replace.
Link ParseBoolError to from_str method of bool
Referencing task in #29375. Sorry for not opening another branch on my fork for this. Was working on this early this morning and forgot to branch off master
Update cargo submodule
I'm not really sure what we want the cadence here to be. We'll at the very least
update the Cargo submodule right before all releases, but otherwise I figured we
could just do it whenever needed or otherwise weekly (or something like that).
In any case, I don't have a super strong particular reason to do this, it's just
been a week or so since the release!
on-demand-ify `custom_coerce_unsized_kind` and `inherent-impls`
This "on-demand" task both checks for errors and computes the custom unsized kind, if any. This task is only defined on impls of `CoerceUnsized`; invoking it on any other kind of impl results in a bug. This is just to avoid having an `Option`, could easily be changed.
r? @eddyb
std: Don't cache stdio handles on Windows
This alters the stdio code on Windows to always call `GetStdHandle` whenever the
stdio read/write functions are called as this allows us to track changes to the
value over time (such as if a process calls `SetStdHandle` while it's running).
Closes#40490
It looks like the 6.3.0 MinGW comes with a gdb which has issues (#40184) that an
attempted workaround (#40777) does not actually fix (#40835). The original
motivation for upgradin MinGW was to fix build flakiness (#40546) due to newer
builds not exhibiting the same bug, so let's hope that 6.2.0 isn't too far back
in time and still contains the fix we need.
Closes#40835
keep the AST node-id when lowering ExprKind::Range
When the Range expression is the root of a constant, its node-id is
used for the def-id of the body, so it has to be preserved in the AST ->
HIR lowering.
Fixes#40749.
r? @eddyb
beta-nominating because regression
Allow `use` macro imports to shadow global macros
Terminology:
- global scope: builtin macros, macros from the prelude, `#[macro_use]`, or `#![plugin(..)]`.
- legacy scope: crate-local `macro_rules!`.
- modern scope: `use` macro imports, `macro` (once implemented).
Today, the legacy scope can shadow the global scope (modulo RFC 1560 expanded shadowing restrictions). However, the modern scope cannot shadow or be shadowed by either the global or legacy scopes, leading to ambiguity errors.
This PR allows the modern scope to shadow the global scope (subject to some restrictions).
More specifically, a name in the global scope is as shadowable as a glob import in the module `self`. In other words, we imagine a special, implicit glob import in each module item:
```rust
mod foo {
#[lexical_only] // Not accessible via `foo::<name>`, like pre-RFC 1560 `use` imports.
#[shadowable_by_legacy_scope] // for back-compat
use <global_macros>::*;
}
```
r? @nrc
Remove internal liblog
This commit deletes the internal liblog in favor of the implementation that
lives on crates.io. Similarly it's also setting a convention for adding crates
to the compiler. The main restriction right now is that we want compiler
implementation details to be unreachable from normal Rust code (e.g. requires a
feature), and by default everything in the sysroot is reachable via `extern
crate`.
The proposal here is to require that crates pulled in have these lines in their
`src/lib.rs`:
#![cfg_attr(rustbuild, feature(staged_api, rustc_private))]
#![cfg_attr(rustbuild, unstable(feature = "rustc_private", issue = "27812"))]
This'll mean that by default they're not using these attributes but when
compiled as part of the compiler they do a few things:
* Mark themselves as entirely unstable via the `staged_api` feature and the
`#![unstable]` attribute.
* Allow usage of other unstable crates via `feature(rustc_private)` which is
required if the crate relies on any other crates to compile (other than std).
try to fix the build on emscripten
The "upstream" emscripten tar.gz now extracts to `emsdk-portable` instead of `emsdk_portable`, breaking our CI. It might be better to vendor a specific version of emscripten instead of using the latest, but I could not find a good way of doing that.
r? @alexcrichton
try to fix the build on emscripten
The "upstream" emscripten tar.gz now extracts to `emsdk-portable` instead of `emsdk_portable`, breaking our CI. It might be better to vendor a specific version of emscripten instead of using the latest, but I could not find a good way of doing that.
r? @alexcrichton
Optimize insertion sort
This change slightly changes the main iteration loop so that LLVM can optimize it more efficiently.
Benchmark:
```
name before ns/iter after ns/iter diff ns/iter diff %
slice::sort_unstable_small_ascending 39 (2051 MB/s) 38 (2105 MB/s) -1 -2.56%
slice::sort_unstable_small_big_random 579 (2210 MB/s) 575 (2226 MB/s) -4 -0.69%
slice::sort_unstable_small_descending 80 (1000 MB/s) 70 (1142 MB/s) -10 -12.50%
slice::sort_unstable_small_random 396 (202 MB/s) 386 -10 -2.53%
```
The benchmark is not a fluke. I can see that performance on `small_descending` is consistently better after this change. I'm not 100% sure why this makes things faster, but my guess would be that `v.len()+1` to the compiler looks like it could in theory overflow.
Add warning for use of lifetime parameter with 'static bound
Previously a `'static` lifetime bound would result in an `undeclared lifetime` error when compiling, even though it could be considered valid.
However, it is unnecessary to use it as a lifetime bound so we present the user with a warning instead and suggest using the `'static` lifetime directly, in place of the lifetime parameter. We can change this to an error (or warning with lint) if that's decided to be more appropriate.
Example output:
```
warning: unnecessary lifetime parameter `'a`
--> ../static-lifetime-bound.rs:3:10
|
3 | fn f<'a: 'static>(val: &'a i32) {
| ^^^^^^^^^^^
|
= help: you can use the `'static` lifetime directly, in place `'a`
```
Fixes#40661
r? @jseyfried
Rewrite `io::BufRead` doc examples to better demonstrate behaviors.
Prior to this commit, most of the `BufRead` examples used `StdinLock` to
demonstrate how certain `BufRead` methods worked. Using `StdinLock` is
not ideal since:
* Relying on run-time data means we can't show concrete examples of how
these methods work up-front. The user is required to run them in order
to see how they behave.
* If the user tries to run an example in the playpen, it won't work
because the playpen doesn't support user input to stdin.
