Find bytes in core #2
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
bluss
force-pushed
the
find-bytes-in-core
branch
from
c2d1026 to
1526065
Compare
bluss
pushed a commit
that referenced
this pull request
Aug 21, 2016
rustc_trans: don't Assert(Overflow(Neg)) when overflow checks are off. Generic functions using `Neg` on primitive types would panic even in release mode, with MIR trans. The solution is a bit hacky, as I'm checking the message, since there's no dedicated `CheckedUnOp`. Blocks Servo rustup ([failure #1](http://build.servo.org/builders/linux-rel/builds/2477/steps/test_3/logs/stdio), [failure #2](http://build.servo.org/builders/mac-rel-css/builds/2364/steps/test/logs/stdio)) - this should be the last hurdle, it affects only one test.
Implement the `loop_break_value` feature. This implements RFC 1624, tracking issue rust-lang#37339. - `FnCtxt` (in typeck) gets a stack of `LoopCtxt`s, which store the currently deduced type of that loop, the desired type, and a list of break expressions currently seen. `loop` loops get a fresh type variable as their initial type (this logic is stolen from that for arrays). `while` loops get `()`. - `break {expr}` looks up the broken loop, and unifies the type of `expr` with the type of the loop. - `break` with no expr unifies the loop's type with `()`. - When building MIR, loops no longer construct a `()` value at termination of the loop; rather, the `break` expression assigns the result of the loop. - ~~I have also changed the loop scoping in MIR-building so that the test of a while loop is not considered to be part of that loop. This makes the rules consistent with rust-lang#37360. The new loop scopes in typeck also follow this rule. That means that `loop { while (break) {} }` now terminates instead of looping forever. This is technically a breaking change.~~ - ~~On that note, expressions like `while break {}` and `if break {}` no longer parse because `{}` is interpreted as an expression argument to `break`. But no code except compiler test cases should do that anyway because it makes no sense.~~ - The RFC did not make it clear, but I chose to make `break ()` inside of a `while` loop illegal, just in case we wanted to do anything with that design space in the future. This is my first time dealing with this part of rustc so I'm sure there's plenty of problems to pick on here ^_^
…rators These iterators can use a pointer comparison instead of computing the length.
add --crate-type metadata r? @alexcrichton
Add a method for setting permissions directly on an open file. On unix like systems, the underlying file corresponding to any given path may change at any time. This function makes it possible to set the permissions of the a file corresponding to a `File` object even if its path changes. @retep998, what's the best way to do this on Windows? I looked into `SetFileInformationByHandle` but couldn't find a way to do it atomically risking clobbering access time information. This is a first step towards fixing rust-lang#37885. This function doesn't *have* to be public but this is useful functionality that should probably be exposed.
Make the example use DoubleEndedIterator for map, like it said it would.
configure: Fix string equality
…ndturner Provide hint when cast needs a dereference For a given code: ``` rust vec![0.0].iter().map(|s| s as i16).collect::<Vec<i16>>(); ``` display: ``` nocode error: casting `&f64` as `i16` is invalid --> file3.rs:2:35 | 2 | vec![0.0].iter().map(|s| s as i16).collect::<Vec<i16>>(); | - ^^^ | | | did you mean `*s`? ``` instead of: ``` nocode error: casting `&f64` as `i16` is invalid --> <anon>:2:30 | 2 | vec![0.0].iter().map(|s| s as i16).collect(); | ^^^^^^^^ | = help: cast through a raw pointer first ``` Fixes rust-lang#37338.
… r=arielb1 Type walker small vector These two changes avoid allocations on some hot paths and speed up a few workloads (some from rustc-benchmarks, as well as the workload from rust-lang#36799) by 1--2%.
…ence-comment, r=GuillaumeGomez Clarify the reference's status. The former wording only gave part of the picture, we want to be crystal clear about this. /cc @petrochenkov, who had concerns about rust-lang#37820
Add a regression test for issue 23699. This should close rust-lang#23699
Add missing examples for SocketAddrV4 r? @steveklabnik cc @frewsxcv
…eklabnik Add some internal docs links for Args/ArgsOs In many places the docs link to other sections and I noticed it was lacking here. Not sure if there is a standard for if inter-linking is appropriate.
…es, r=eddyb Move the myriad-closures.rs test case to run-pass-full test suite. r? @eddyb
…ctors, r=nikomatsakis ICH: Add test case for struct constructor expressions. r? @nikomatsakis
Rollup of 7 pull requests - Successful merges: rust-lang#37442, rust-lang#37760, rust-lang#37836, rust-lang#37851, rust-lang#37859, rust-lang#37913, rust-lang#37925 - Failed merges:
Expand is_uninhabited
This allows code such as this to compile:
``` rust
let x: ! = ...;
match x {};
let y: (u32, !) = ...;
match y {};
```
@eddyb You were worried about making this change. Do you have any idea about what could break? Are there any special tests that need to be written for it?
…chton Remove unused functions from rustc_llvm
Add String::split_off. This seems to match up with the latest version of the collection reform, and seems useful enough to add. First pull request!
evaluate obligations in LIFO order during closure projection This is an annoying gotcha with the projection cache's handling of nested obligations. Nested projection obligations enter the issue in this case: ``` DEBUG:rustc::traits::project: AssociatedTypeNormalizer: depth=3 normalized <std::iter::Map<std::ops::Range<i32>, [closure@not-a-recursion-error.rs:5:30: 5:53]> as std::iter::IntoIterator>::Item to _#7t with 12 add'l obligations ``` Here the normalization result is the result of the nested impl `<[closure@not-a-recursion-error.rs:5:30: 5:53] as FnMut(i32)>::Output`, which is an additional obligation that is a part of "add'l obligations". By itself, this is proper behaviour - the additional obligation is returned, and the RFC 447 rules ensure that it is processed before the output `#_7t` is used in any way. However, the projection cache breaks this - it caches the `<std::iter::Map<std::ops::Range<i32>,[closure@not-a-recursion-error.rs:5:30: 5:53]> as std::iter::IntoIterator>::Item = #_7t` resolution. Now everybody else that attempts to look up the projection will just get `#_7t` *without* any additional obligations. This obviously causes all sorts of trouble (here a spurious `EvaluatedToAmbig` results in specializations not being discarded [here](https://github.com/rust-lang/rust/blob/9ca50bd4d50b55456e88a8c3ad8fcc9798f57522/src/librustc/traits/select.rs#L1705)). The compiler works even with this projection cache gotcha because in most cases during "one-pass evaluation". we tend to process obligations in LIFO order - after an obligation is added to the cache, we process its nested obligations before we do anything else (and if we have a cycle, we handle it specifically) - which makes sure the inference variables are resolved before they are used. That "LIFO" order That was not done when projecting out of a closure, so let's just fix that for the time being. Fixes rust-lang#38033. Beta-nominating because regression. r? @nikomatsakis
print option to dump target spec as JSON This lets the user dump out the target spec that the compiler is using. This is useful to people defining their own target.json to compare it against existing targets or understand how different targets change internal settings. It is also potentially useful for Cargo to determine if something has changed with a target and it needs to rebuild things.
Add new #[target_feature = "..."] attribute.
This commit adds a new attribute that instructs the compiler to emit
target specific code for a single function. For example, the following
function is permitted to use instructions that are part of SSE 4.2:
#[target_feature = "+sse4.2"]
fn foo() { ... }
In particular, use of this attribute does not require setting the
-C target-feature or -C target-cpu options on rustc.
This attribute does not have any protections built into it. For example,
nothing stops one from calling the above `foo` function on hosts without
SSE 4.2 support. Doing so may result in a SIGILL.
I've also expanded the x86 target feature whitelist.
Add missing examples for Ipv6Addr r? @steveklabnik cc @frewsxcv
add regression test for rust-lang#36168 Fixes rust-lang#36168 r? @michaelwoerister
…ewsxcv Add part of missing UdpSocket's urls and examples r? @frewsxcv
Refactor one_bound_for_assoc_type to take an Iterator instead of Vec I doubt the performance implications will be serious, but it will avoid allocating one-element Vecs for the successful case (and avoid allocating vecs at all for any case, too). `--stage 2` tests passed locally.
Fix verify.rs Finishing d2f8fb0 from @jseyfried
Show `Trait` instead of `<Struct as Trait>` in E0323
For a given file
```
trait Foo {
fn bar(&self);
}
pub struct FooConstForMethod;
impl Foo for FooConstForMethod {
const bar: u64 = 1;
}
```
show
```
error[E0323]: item `bar` is an associated const, which doesn't match its trait `Foo`
```
instead of
```
error[E0323]: item `bar` is an associated const, which doesn't match its trait `<FooConstForMethod as Foo>`
```
Fix rust-lang#37618
bootstrap/README: fix small typo
Add missing examples for IpAddr enum r? @frewsxcv
…test-on-aarch64, r=alexcrichton debuginfo: Ignore macro-stepping test on aarch64 See rust-lang#37225. r? @alexcrichton
Add cloned example for Option r? @frewsxcv
…nfo, r=nikomatsakis incr.comp.: Add more output to -Z incremental-info. Also makes sure that all output from `-Z incremental-info` is prefixed with `incremental:` for better grep-ability. r? @nikomatsakis
Minor fix to testing concurrency section
… r=michaelwoerister add a `-Z incremental-dump-hash` flag This causes us to dump a bunch of has information to stdout that can be useful in tracking down incremental compilation invalidations, particularly across crates.
Update items section in reference Make clear that items must be definitions, and add missing extern block
…wsxcv Add Component examples r? @frewsxcv
Rollup of 15 pull requests - Successful merges: rust-lang#37859, rust-lang#37919, rust-lang#38020, rust-lang#38028, rust-lang#38029, rust-lang#38065, rust-lang#38073, rust-lang#38077, rust-lang#38089, rust-lang#38090, rust-lang#38096, rust-lang#38112, rust-lang#38113, rust-lang#38130, rust-lang#38141 - Failed merges:
…lwoerister [LLVM 4.0] Handle new DIFlags enum
…37864, r=mw in region, treat current (and future) item-likes alike The `visit_fn` code mutates its surrounding context. Between *items*, this was saved/restored, but between impl items it was not. This meant that we wound up with `CallSiteScope` entries with two parents (or more!). As far as I can tell, this is harmless in actual type-checking, since the regions you interact with are always from at most one of those branches. But it can slow things down. Before, the effect was limited, since it only applied to impl items within an impl. After rust-lang#37660, impl items are visisted all together at the end, and hence this could create a very messed up hierarchy. Isolating impl item properly solves both issues. I cannot come up with a way to unit-test this; for posterity, however, you can observe the messed up hierarchies with a test as simple as the following, which would create a callsite scope with two parents both before and after ``` struct Foo { } impl Foo { fn bar(&self) -> usize { 22 } fn baz(&self) -> usize { 22 } } fn main() { } ``` Fixes rust-lang#37864. r? @michaelwoerister cc @pnkfelix -- can you think of a way to make a regr test?
bluss
force-pushed
the
find-bytes-in-core
branch
from
1526065 to
d14d74d
Compare
bluss
pushed a commit
that referenced
this pull request
Mar 3, 2018
When given the following code:
```rust
fn give_any<F: for<'r> FnOnce(&'r ())>(f: F) {
f(&());
}
fn main() {
let mut x = None;
give_any(|y| x = Some(y));
}
```
provide a custom error:
```
error: borrowed data cannot be moved outside of its closure
--> file.rs:7:27
|
6 | let mut x = None;
| ----- binding declared outside of closure
7 | give_any(|y| x = Some(y));
| --- ^ cannot be assigned to binding outside of its closure
| |
| closure you can't escape
```
instead of the generic lifetime error:
```
error[E0495]: cannot infer an appropriate lifetime due to conflicting requirements
--> file.rs:7:27
|
7 | give_any(|y| x = Some(y));
| ^
|
note: first, the lifetime cannot outlive the anonymous lifetime #2 defined on the body at 7:14...
--> file.rs:7:14
|
7 | give_any(|y| x = Some(y));
| ^^^^^^^^^^^^^^^
note: ...so that expression is assignable (expected &(), found &())
--> file.rs:7:27
|
7 | give_any(|y| x = Some(y));
| ^
note: but, the lifetime must be valid for the block suffix following statement 0 at 6:5...
--> file.rs:6:5
|
6 | / let mut x = None;
7 | | give_any(|y| x = Some(y));
8 | | }
| |_^
note: ...so that variable is valid at time of its declaration
--> file.rs:6:9
|
6 | let mut x = None;
| ^^^^^
```
bluss
pushed a commit
that referenced
this pull request
Mar 3, 2018
…sakis
Custom error when moving arg outside of its closure
When given the following code:
```rust
fn give_any<F: for<'r> FnOnce(&'r ())>(f: F) {
f(&());
}
fn main() {
let mut x = None;
give_any(|y| x = Some(y));
}
```
provide a custom error:
```
error: borrowed data cannot be moved outside of its closure
--> file.rs:7:27
|
6 | let mut x = None;
| ----- borrowed data cannot be moved into here...
7 | give_any(|y| x = Some(y));
| --- ^ cannot be moved outside of its closure
| |
| ...because it cannot outlive this closure
```
instead of the generic lifetime error:
```
error[E0495]: cannot infer an appropriate lifetime due to conflicting requirements
--> file.rs:7:27
|
7 | give_any(|y| x = Some(y));
| ^
|
note: first, the lifetime cannot outlive the anonymous lifetime #2 defined on the body at 7:14...
--> file.rs:7:14
|
7 | give_any(|y| x = Some(y));
| ^^^^^^^^^^^^^^^
note: ...so that expression is assignable (expected &(), found &())
--> file.rs:7:27
|
7 | give_any(|y| x = Some(y));
| ^
note: but, the lifetime must be valid for the block suffix following statement 0 at 6:5...
--> file.rs:6:5
|
6 | / let mut x = None;
7 | | give_any(|y| x = Some(y));
8 | | }
| |_^
note: ...so that variable is valid at time of its declaration
--> file.rs:6:9
|
6 | let mut x = None;
| ^^^^^
```
Fix rust-lang#45983.
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.