There was an overflow bug in .size_hint() for signed iterators, which
produced an hilariously incorrect size or an overflow panic.
Incorrect size is a serious bug since the iterators are marked
ExactSizeIterator. (And leads to abort() on (-1i8..127).collect() when
the collection tries to preallocate too much).
All signed range iterators were affected.
> (-1i8..127).size_hint()
(18446744073709551488, Some(18446744073709551488))
Bug found using quickcheck.
Fixes#24851
This commit modifies the standard library and its dependencies to link correctly
when built against MUSL. This primarily ensures that the right libraries are
linked against and when they're linked against they're linked against
statically.
This commit adds support for x86_64-unknown-linux-musl as a target of the
compiler. There's some comments in the commit about some of the more flavorful
flags passed to the linker as it's not quite as trivial as the normal specs.
This commit adds support to the makefiles, configuration script, and build
system to understand MUSL. This is broken up into a few parts:
* Any target of the form `*-musl` requires the `--musl-root` option to
`./configure` which will indicate the root of the MUSL installation. It is
also expected that there is a libunwind build inside of that installation
built against that MUSL.
* Objects from MUSL are copied into the build tree for Rust to be statically
linked into the appropriate Rust library.
* Objects for binary startup and shutdown are included in each Rust installation
by default for MUSL. This requires MUSL to only be installed on the machine
compiling rust. Only a linker will be necessary for compiling against MUSL on
a target machine.
Eventually a MUSL and/or libunwind build may be integrated by default into the
build but for now they are just always assumed to exist externally.
Closes#17841.
The majority of the work should be done, e.g. trait and inherent impls, different forms of UFCS syntax, defaults, and cross-crate usage. It's probably enough to replace the constants in `f32`, `i8`, and so on, or close to good enough.
There is still some significant functionality missing from this commit:
- ~~Associated consts can't be used in match patterns at all. This is simply because I haven't updated the relevant bits in the parser or `resolve`, but it's *probably* not hard to get working.~~
- Since you can't select an impl for trait-associated consts until partway through type-checking, there are some problems with code that assumes that you can check constants earlier. Associated consts that are not in inherent impls cause ICEs if you try to use them in array sizes or match ranges. For similar reasons, `check_static_recursion` doesn't check them properly, so the stack goes ka-blooey if you use an associated constant that's recursively defined. That's a bit trickier to solve; I'm not entirely sure what the best approach is yet.
- Dealing with consts associated with type parameters will raise some new issues (e.g. if you have a `T: Int` type parameter and want to use `<T>::ZERO`). See rust-lang/rfcs#865.
- ~~Unused associated consts don't seem to trigger the `dead_code` lint when they should. Probably easy to fix.~~
Also, this is the first time I've been spelunking in rustc to such a large extent, so I've probably done some silly things in a couple of places.
This adds a new `#[cfg]` matcher against the `target_env` property of the
destination target triple. For example all windows triples today end with `-gnu`
but we will also hopefully support non-`gnu` targets for Windows, at which point
we'll need to differentiate between the two. This new `target_env` matches is
provided and filled in with the target's environment name.
Currently the only non-empty value of this name is `gnu`, but `musl` will be
shortly added for the linux triples.
Remove the name "multi-line string literal" since the rule appears to affect each line-break individually rather than the whole string literal. Re-word, and remove the stray reference to raw strings.
A user in IRC was having trouble because they used `main.rs` when they were trying
to migrate a library. The `[[lib]]` key is not easily found, and the `main.rs`/`lib.rs`
distinction doesn't seem to exist in trpl
r? @steveklabnik
Improve example for as_string and add example for as_vec
Provide a better example of `as_string` / `DerefString`'s unique capabilities.
Use an example where (for an unspecified reason) you need a &String, and
show how `as_string` solves the problem without needing an allocation.
The minus sign ‘−’ is the same width as the plus sign ‘+’, so the button’s transition between the two symbols will look slightly smoother.
If you don’t want to use literal Unicode characters, I can change ‘−’ to `\u2212`. I’m not starting with that suggestion because ‘−’ is easier to read and understand, and if I used `\u2212`, it would probably be necessary to also comment the usage on each line to explain what character is being used.
Kudos to dotdash for tracking down this fix.
Presumably the use of `ByRef` was because this value is a reference to
the drop-flag; but an Lvalue will serve just as well for that. dotdash
argues:
> since the drop_flag is in its "final home", Lvalue seems to be the
> correct choice.
That is, scheduled drops are executed in reverse order, so for
correctness, we *schedule* the lifetime end before we schedule the
drop, so that when they are executed, the drop will be executed
*before* the lifetime end.
Fix `make_command_line` for the case of backslashes at the end of an
argument requiring quotes. We must encode the command and arguments
such that `CommandLineToArgvW` recovers them in the spawned process.
Simplify the logic by using a running count of backslashes as they
are encountered instead of looking ahead for quotes following them.
Extend `test_make_command_line` to additionally cover:
* a leading quote in an argument that requires quotes,
* a backslash before a quote in an argument that requires quotes,
* a backslash at the end of an argument that requires quotes, and
* a backslash at the end of an argument that does not require quotes.
Remove the name "multi-line string literal" since the rule appears to affect each line-break individually rather than the whole string literal. Re-word, and remove the stray reference to raw strings.
So that if people accidentally delete the character, they won’t re-type it as a hyphen, which would cause bugs.
I changed ‘+’ too, even though it won’t be re-typed incorrectly, so that it is easier to see when plus is used as a symbol for the button, and when it is used as an operator in code. It also makes it clearer that the use of an entity for minus is on purpose, so people won’t be tempted to replace the entity incorrectly with a hyphen character.
I figure I'd start easy with fixing a simple documentation bug. This is also a test to see that I got everything right w r t the fork/pull request process.
