The parser already has special logic for parsing `>` tokens from `>>`, and this
commit extends the logic to the acquiring a `>` from the `>=` and `>>=` tokens
as well.
Closes#15043
The struct and module doc comments are reformulated. The `execute`
method's documentation are put up to date, and failure information
is added. A test is also added to address the possible failure.
```test_harness
#[test]
fn foo() {}
```
will now compile and run the tests, rather than just ignoring & stripping them (i.e. it is as if `--test` was passed).
Also, the specific example in https://github.com/rust-lang/rust/issues/12242 was fixed (but that issue is broader than that example).
rustdoc now supports compiling things with `--test` so the examples in
this guide can be compiled & tested properly (revealing a few issues &
out-dated behaviours).
Also, reword an example to be clearer, cc #12242.
Continuing from #15012, this makes four changes to the `rustdoc` static files.
- Change the placeholder text of the search bar to `Click or press 'S' to search, '?' for more options...` to make keyboard hotkeys more apparent (capitalizing the `S` to match the help text).
- Change the `main.js` file to use browser-normalized key codes (`e.which`, from `jQuery`), instead of `e.keyCode`.
- Change the key code for `?` to be the correct `191` instead of `188`, so that the hotkey works to bring up search information.
- Change the search information to display `tab` and `shift+tab` instead of `up` and `down`, as those do not yet work outside of Firefox (see #15011). Also, adjust the height so it does not cut off the help text.
<s>I've also opened up #15038 about the non-functional `up` and `down` functionality, although this does nothing to fix it.</s>
This test was added long time ago and marked as ignored.
The same test was added later in #8485 as run-fail/issue-3907.rs,
but the old one was not deleted.
Updated search bar to match help text.
Used correct, normalized hotkeys in search.
Updated shortcut menu with working shortcuts (tabs).
Changed height of search help.
This adds the `test_harness` directive that runs a code block using the
test runner, to allow for `#[test]` items to be demonstrated and still
tested (currently they are just stripped and not even compiled, let
alone run).
The lexer already ignores CRLF in between tokens, but it doesn't
properly handle carriage returns inside strings and doc comments. Teach
it to treat CRLF as LF inside these tokens, and to disallow carriage
returns that are not followed by linefeeds. This includes handling an
escaped CRLF inside a regular string token the same way it handles an
escaped LF.
This is technically a breaking change, as bare carriage returns are no
longer allowed, and CRLF sequences are now treated as LF inside strings
and doc comments, but it's very unlikely to actually affect any
real-world code.
This change is necessary to have Rust code compile on Windows the same
way it does on Unix. The mozilla/rust repository explicitly sets eol=lf
for Rust source files, but other Rust repositories don't. Notably,
rust-http cannot be compiled on Windows without converting the CRLF line
endings back to LF.
[breaking-change]
The lexer already ignores CRLF in between tokens, but it doesn't
properly handle carriage returns inside strings and doc comments. Teach
it to treat CRLF as LF inside these tokens, and to disallow carriage
returns that are not followed by linefeeds. This includes handling an
escaped CRLF inside a regular string token the same way it handles an
escaped LF.
This is technically a breaking change, as bare carriage returns are no
longer allowed, and CRLF sequences are now treated as LF inside strings
and doc comments, but it's very unlikely to actually affect any
real-world code.
This change is necessary to have Rust code compile on Windows the same
way it does on Unix. The mozilla/rust repository explicitly sets eol=lf
for Rust source files, but other Rust repositories don't. Notably,
rust-http cannot be compiled on Windows without converting the CRLF line
endings back to LF.
[breaking-change]
This creates a stability baseline for all crates that we distribute that are not `std`. In general, all library code must start as experimental and progress in stages to become stable.
Closes#14480 (vim: Add :RustRun and associated commands)
Closes#14917 (Deprecate free-standing endian conversions in favor of methods on Int. Merge Bitwise into Int and add more bit operations.)
Closes#14981 (librustc: Use expr_ty_adjusted in trans_overloaded_call.)
Closes#14989 (std::task - Revamp TaskBuilder API)
Closes#14997 (Reject double moves out of array elements)
Closes#14998 (Vim: highlight escapes for byte literals.)
Closes#15002 (Fix FIXME #5275)
Closes#15004 (Fix#14865)
Closes#15007 (debuginfo: Add test case for issue #14411.)
Closes#15012 ((doc) Change search placeholder text.)
Closes#15013 (Update compiler-rt.)
Closes#15017 (Deprecate the bytes!() macro.)
Replace its usage with byte string literals, except in `bytes!()` tests.
Also add a new snapshot, to be able to use the new b"foo" syntax.
The src/etc/2014-06-rewrite-bytes-macros.py script automatically
rewrites `bytes!()` invocations into byte string literals.
Pass it filenames as arguments to generate a diff that you can inspect,
or `--apply` followed by filenames to apply the changes in place.
Diffs can be piped into `tip` or `pygmentize -l diff` for coloring.
Fixes a codegen bug which generates illegal non-terminated LLVM block
when there are wildcard pattern with guard and enum patterns in a match
expression. Also refactors the code a little.
Closes#14865
This patch consolidates and cleans up the task spawning APIs:
* Removes the problematic `future_result` method from `std::task::TaskBuilder`,
and adds a `try_future` that both spawns the task and returns a future
representing its eventual result (or failure).
* Removes the public `opts` field from `TaskBuilder`, instead adding appropriate
builder methods to configure the task.
* Adds extension traits to libgreen and libnative that add methods to
`TaskBuilder` for spawning the task as a green or native thread.
Previously, there was no way to benefit from the `TaskBuilder` functionality and
also set the scheduler to spawn within.
With this change, all task spawning scenarios are supported through the
`TaskBuilder` interface.
Closes#3725.
[breaking-change]
