There was a buildbot failure recently of an arithmetic overflow in the isaac
module of the rand crate, so I've imported the isaac implementation from
out-of-tree which makes somewhat more liberal usage of the wrapping primitives.
Hopefull this quelches any future overflow!
There was a buildbot failure recently of an arithmetic overflow in the isaac
module of the rand crate, so I've imported the isaac implementation from
out-of-tree which makes somewhat more liberal usage of the wrapping primitives.
Hopefull this quelches any future overflow!
This may not be quite ready to go out, I fixed some docs but suspect I missed a bunch.
I also wound up fixing a bunch of redundant `[]` suffixes, but on closer inspection I don't believe that can land until after a snapshot.
Namely:
* `quote`
* `link_args`
* `link_llvm_intrinsics`
* `thread_local`
* `unsafe_destructor`
Also updates test for `plugin_registrar` to make it clear that
it is only testing the `plugin_registrar` feature gate.
Cc #22820.
Motivated by the test output not lining up when it could, I normalized all of the issue-* tests.
While doing it, I found some lexer tests that could be unignored and fixed an int -> isize.
If we end the `scoped` call with a semicolon, the `JoinGuard` will be
dropped and not returned from the `map`. The thread will start up and
we immediately block, making for a very expensive sequential loop.
rustc will ICE if you specify an outfile path that is bare without a
directory. As a workaround, before this -o ./foo will work
It wasn't clear to me where I could put a test that actually invokes rustc from a shell, although I think I can add doctests to that machinery in librustc_driver that will arrange for this to be called with arguments that would trigger the ICE
Motivated by the test output not lining up when it could, I normalized all of the issue-* tests.
While doing it, I found some lexer tests that could be unignored and fixed an int -> isize.
If we end the `scoped` call with a semicolon, the `JoinGuard` will be
dropped and not returned from the `map`. The thread will start up and
we immediately block, making for a very expensive sequential loop.
The docs currently define `array_expr`s as:
array_expr : '[' \"mut\" ? vec_elems? ']' ;
array_elems : [expr [',' expr]*] | [expr ',' \"..\" expr] ;
`vec_elems` is not defined anywhere else so it is probably a typo for `array_elems`.
