LruEntry nodes previously used Option to encapsulate the key and value
fields. This was used merely as a way avoid having values for the sigil
node. Apart from wasting a few bytes for the discriminant, this
cluttered the rest of the code, since these fields always contained
Some on regular nodes as a class invariant.
The Option wrapping was removed, and the values in the sigil field are
initialized using mem::init, so that they don't contain any real data.
Instead of allocating both head and tail nodes for the ends of the node
list, a single node can be allocated and linked circularly instead,
making it act as both the head and the tail of the list at the same
time.
Renamed the methods in Bitv that test all bits to have names that, ehm, "roll off the tongue" a bit more easily. :)
Also added tests for them while at it, since they seemed to be missing.
Syntax-only crates are no longer registered with the cstore, so there's no need
to allocate crate numbers to them. This ends up leaving gaps in the crate
numbering scheme which is not expected in the rest of the compiler.
Closes#13560
Fix#12856.
I wanted to put this up first because I wanted to get feedback about the second commit in the series, commit 8599236. Its the more invasive part of the patch and is largely just belt-and-suspenders assertion checking; in the commit message I mentioned at least one other approach we could take here. Or we could drop the belt-and-suspenders and just rely on the guard added in the first patch, commit 8d6a005 (which is really quite trivial on its own).
So any feedback on what would be better is appreciated.
r? @nikomatsakis
This version of `is_to_be_inferred` double-checks the result from
`inferred_map` by querying the `named_region_map` and `ast_map` and
then asserts that the `inferred_map` state is consistent with its own
findings. (See issue 13261 for further discussion of the approaches).
This is the first snapshot build by mingw-w64 with the win32 threading model I believe (Closes#13501).
Curiously, this successfully built a snapshot on freebsd when the auto builder is continuously segfaulting. Who knew!
structure's Data2 and Data3 members expect WORD types instead of DWORD. I
discovered this discrepancy while experimenting with some bindings to
Microsoft's OLE2 api. The discrepancy was corrupting the contents of the
string returned by UuidToString after I used known GUIDs to test the
accuracy of the function binding. I didn't add test cases because it would
mean adding a dependency to my rather incomplete binding library. However,
the fix produces expected string values when tested.
Closes#13561. All definition lists have been converted to unordered lists. This is a temporary measure; please revert this when Sundown (or any replacement) gets a support for definition lists in the future.
Part of this required added an override of `fold_type_method` in the
Folder for Ctx impl; it follows the same pattern as `fold_method`.
Also, as a drive-by fix, I moved all of the calls to `folder.new_id`
in syntax::fold's no-op default traversal to really be the first
statement in each function.
* This is to uphold the invariant that `folder.new_id` is always
called first (an unfortunate requirement of the current `ast_map`
code), an invariant that we seemingly were breaking in e.g. the
previous `noop_fold_block`.
* Now it should be easier to see when adding new code that this
invariant must be upheld.
* (note that the breakage in `noop_fold_block` may not have mattered
so much previously, since the only thing that blocks can bind are
lifetimes, which I am only adding support for now.)
Before adding a variance constrant for a given early-bound param,
check if it was meant to be inferred.
To support the above, added `fn is_to_be_inferred` to
`variance::ConstraintContext`.
When instantiating trait default methods for certain implementation,
`typeck` correctly combined type parameters from trait bound with those
from method bound, but didn't do so for lifetime parameters. Applies
the same logic to lifetime parameters.
Closes#13204
Some of this documentation got a little out of date. There was no mention of a
`SyncSender`, and the entire "Outside the runtime" section isn't really true any
more (or really all that relevant).
This also updates a few other doc blocks and adds some examples.
* Use `setq-local` instead of `(set (make-local-variable 'var) value)`. Provides a version for older Emacsen.
* Remove use of `cl.el`.
* Use \' in file regexp instead of line end match $.
* Use type for `defcustom` and add parent group.
This commit changes the way move errors are reported when some value is
captured by a PatIdent. First, we collect all of the "cannot move out
of" errors before reporting them, and those errors with the same "move
source" are reported together. If the move is caused by a PatIdent (that
binds by value), we add a note indicating where it is and suggest the
user to put `ref` if they don't want the value to move. This makes the
"cannot move out of" error in match expression nicer (though the extra
note may not feel that helpful in other places :P). For example, with
the following code snippet,
```rust
enum Foo {
Foo1(~u32, ~u32),
Foo2(~u32),
Foo3,
}
fn main() {
let f = &Foo1(~1u32, ~2u32);
match *f {
Foo1(num1, num2) => (),
Foo2(num) => (),
Foo3 => ()
}
}
```
Errors before the change:
```rust
test.rs:10:9: 10:25 error: cannot move out of dereference of `&`-pointer
test.rs:10 Foo1(num1, num2) => (),
^~~~~~~~~~~~~~~~
test.rs:10:9: 10:25 error: cannot move out of dereference of `&`-pointer
test.rs:10 Foo1(num1, num2) => (),
^~~~~~~~~~~~~~~~
test.rs:11:9: 11:18 error: cannot move out of dereference of `&`-pointer
test.rs:11 Foo2(num) => (),
^~~~~~~~~
```
After:
```rust
test.rs:9:11: 9:13 error: cannot move out of dereference of `&`-pointer
test.rs:9 match *f {
^~
test.rs:10:14: 10:18 note: attempting to move value to here (to prevent the move, use `ref num1` or `ref mut num1` to capture value by reference)
test.rs:10 Foo1(num1, num2) => (),
^~~~
test.rs:10:20: 10:24 note: and here (use `ref num2` or `ref mut num2`)
test.rs:10 Foo1(num1, num2) => (),
^~~~
test.rs:11:14: 11:17 note: and here (use `ref num` or `ref mut num`)
test.rs:11 Foo2(num) => (),
^~~
```
Close#8064
structure's Data2 and Data3 members expect WORD types instead of DWORD. I
discovered this discrepancy while experimenting with some bindings to
Microsoft's OLE2 api. The discrepancy was corrupting the contents of the
string returned by UuidToString after I used known GUIDs to test the
accuracy of the function binding. I didn't add test cases because it would
mean adding a dependency to my rather incomplete binding library. However,
the fix produces expected string values when tested.
Syntax-only crates are no longer registered with the cstore, so there's no need
to allocate crate numbers to them. This ends up leaving gaps in the crate
numbering scheme which is not expected in the rest of the compiler.
Closes#13560
Them removes all the glob reexports from liblibc. I did it by removing them all, and then adding back per-platform explicit reexports until everything built again.
I realize this isn't the best strategy for determining an API, but this is the lowest-impact change that solves the problem, plus I'm dissatisfied with the design of this library for other reasons and think it needs to be reconsidered from top to bottom (later).
Progress on #11870.
When instantiating trait default methods for certain implementation,
`typeck` correctly combined type parameters from trait bound with those
from method bound, but didn't do so for lifetime parameters. Applies
the same logic to lifetime parameters.
Closes#13204
This removes the `priv` keyword from the language and removes private enum
variants as a result. The remaining use cases of private enum variants were all
updated to be a struct with one private field that is a private enum.
RFC: 0006-remove-priv
Closes#13535
There's now one unified way to return things from a macro, instead of
being able to choose the `AnyMacro` trait or the `MRItem`/`MRExpr`
variants of the `MacResult` enum. This does simplify the logic handling
the expansions, but the biggest value of this is it makes macros in (for
example) type position easier to implement, as there's this single thing
to modify.
By my measurements (using `-Z time-passes` on libstd and librustc etc.),
this appears to have little-to-no impact on expansion speed. There are
presumably larger costs than the small number of extra allocations and
virtual calls this adds (notably, all `macro_rules!`-defined macros have
not changed in behaviour, since they had to use the `AnyMacro` trait
anyway).
---
Summary of changes for dynamic syntax extension maintainers:
- `MacResult` is now a trait, and is returned as `~MacResult`
- `MRExpr` & `MRItem` are now `MacExpr::new` and `MacItem:new` respectively (which return `~MacResult`s)
- `MacResult::dummy_...` is `DummyResult::any` or `DummyResult::expr`
work started from @gereeter's PR: https://github.com/mozilla/rust/pull/13114
but adjusted bits
```
before
test hash::sip::tests::bench_u64 ... bench: 34 ns/iter (+/- 0)
test hash::sip::tests::bench_str_under_8_bytes ... bench: 37 ns/iter (+/- 1)
test hash::sip::tests::bench_str_of_8_bytes ... bench: 43 ns/iter (+/- 1)
test hash::sip::tests::bench_str_over_8_bytes ... bench: 50 ns/iter (+/- 1)
test hash::sip::tests::bench_long_str ... bench: 613 ns/iter (+/- 14)
test hash::sip::tests::bench_compound_1 ... bench: 114 ns/iter (+/- 11)
after
test hash::sip::tests::bench_u64 ... bench: 25 ns/iter (+/- 0)
test hash::sip::tests::bench_str_under_8_bytes ... bench: 31 ns/iter (+/- 0)
test hash::sip::tests::bench_str_of_8_bytes ... bench: 36 ns/iter (+/- 0)
test hash::sip::tests::bench_str_over_8_bytes ... bench: 40 ns/iter (+/- 0)
test hash::sip::tests::bench_long_str ... bench: 600 ns/iter (+/- 14)
test hash::sip::tests::bench_compound_1 ... bench: 64 ns/iter (+/- 6)
```
Notably it seems smaller keys will hash faster. A long string doesn't see much gains, but compound cuts in half (once compound used a `int` and `u64`).
There's now one unified way to return things from a macro, instead of
being able to choose the `AnyMacro` trait or the `MRItem`/`MRExpr`
variants of the `MacResult` enum. This does simplify the logic handling
the expansions, but the biggest value of this is it makes macros in (for
example) type position easier to implement, as there's this single thing
to modify.
By my measurements (using `-Z time-passes` on libstd and librustc etc.),
this appears to have little-to-no impact on expansion speed. There are
presumably larger costs than the small number of extra allocations and
virtual calls this adds (notably, all `macro_rules!`-defined macros have
not changed in behaviour, since they had to use the `AnyMacro` trait
anyway).
