Fixes#26646.
Loops over all `#[repr(..)]` attributes instead of stopping at the first one to make sure they are all marked as used. Previously it stopped after the first `#[repr(C)]` was found causing all other attributes to be skipped by the linter.
Update substring search to use the Two Way algorithm
To improve our substring search performance, revive the two way searcher
and adapt it to the Pattern API.
Fixes#25483, a performance bug: that particular case now completes faster
in optimized rust than in ruby (but they share the same order of magnitude).
Many thanks to @gereeter who helped me understand the reverse case
better and wrote the comment explaining `next_back` in the code.
I had quickcheck to fuzz test forward and reverse searching thoroughly.
The two way searcher implements both forward and reverse search,
but not double ended search. The forward and reverse parts of the two
way searcher are completely independent.
The two way searcher algorithm has very small, constant space overhead,
requiring no dynamic allocation. Our implementation is relatively fast,
especially due to the `byteset` addition to the algorithm, which speeds
up many no-match cases.
A bad case for the two way algorithm is:
```
let haystack = (0..10_000).map(|_| "dac").collect::<String>();
let needle = (0..100).map(|_| "bac").collect::<String>());
```
For this particular case, two way is not much faster than the naive
implementation it replaces.
This was originally motivated by checking for HRTB hygiene, but I found several other bugs on the way.
This does not fix the biggest user of ty_walk, which is dtorck - I would prefer to coordinate that with @pnkfelix.
r? @eddyb
This fixes two false positives for the unconditional recursion lint, when functions use themselves (or almost-themselves) internally, without actually being recursive.
````rust
fn main() { let _ = main; }
```
```rust
trait Bar {
fn method<T: Bar>(&self, x: &T) {
x.method(x)
}
}
```
This catches the case when a trait defines a default method that calls
itself, but on a type that isn't necessarily `Self`, e.g. there's no
reason that `T = Self` in the following, so the call isn't necessarily
recursive (`T` may override the call).
trait Bar {
fn method<T: Bar>(&self, x: &T) {
x.method(x)
}
}
Fixes#26333.
Namely:
* Change parameter `old` to read `current` so it is clearer what the argument refers to (originally
suggested `expected`, but shot down by Steve);
* Add some formatting and fix some mistakes like referring to the method as `swap` rather than
`compare_and_swap`.
Namely:
* Change parameter `old` to read `current` so it is clearer what the argument refers to (originally
suggested `expected`, but shot down by Steve);
* Add some formatting and fix some mistakes like referring to the method as `swap` rather than
`compare_and_swap`.
In Chapter 5.9 (References and Borrowing), there is an example [at the very end](https://doc.rust-lang.org/stable/book/references-and-borrowing.html#use-after-free) which shows that declaring a reference before declaring the variable that it points to results in a compilation error. The book does not really mention why this happens though -- in the sections before, it has described how different scopes affects the lifetime of resources, but there is no mention of how resources within the same scope work.
This confused me a little, so I asked on #rust and got the answer that the resources are destroyed in the reverse order that they are declared, but the book makes no mention of it (as far as I can find) -- except in Chapter 5.21 (Drop), where it says:
> When `x` goes out of scope at the end of `main()`, the code for `Drop` will run. `Drop` has one method, which is also called `drop()`. It takes a mutable reference to `self`.
>
> That’s it! The mechanics of `Drop` are very simple, but there are some subtleties. For example, values are dropped in the opposite order they are declared. [...]
---
I feel like Chapter 5.9 (References and Borrowing) is probably the best place to put this information (as I have done in my additions), since it deals with other types of referencing and borrowing. However, since English is not my native language, the wording of my additions perhaps are a little "off" -- any feedback on them is appreciated.
This branch begins the work of unifying our type checking contexts into a single piece of state. The goal is to eventually have a single context that we can pass around instead of the fractured situation we currently have. There are still several things that must be done before beginning to make tables item local:
- [ ] move FulfillmentContext into InferCtxt
- [ ] modify SelectionContext to only take a single context argument
- [ ] remove remaining typer impls
- [ ] remove the ClosureTyper + Typer trait
- [ ] do some renaming to make these things more applicable to their new roles
r? @nikomatsakis
As a side note there are a couple oddities that are temporary refactors that will be quickly cleaned up in a follow-up PR.
cc @eddyb @Aatch @arielb1 @nrc
Setting append without write doesn't give you a writeable file. Showing it as an example in the docs is confusing at best ([reddit](https://www.reddit.com/r/rust/comments/3bbz8w/why_is_writing_a_file_not_working_for_me/))
Using truncate (O_TRUNC) on a read-only file is an error on POSIX systems ("unspecified"). Note however that using create (O_CREAT) with read-only flags is fine.
Related: #26103 (which IMHO is wrong; saying "append is different than write" when should simply be "append needs write". My vote is to make append imply write)
Setting append without write doesn't give you a writeable file. Showing
it as an example in the docs is confusing at best.
Using truncate on a read-only file is an error on POSIX systems (note
however that using create with read-only flags is fine).
This series of commits (currently rebased on https://github.com/rust-lang/rust/pull/26569 to avoid conflicts) adds support for the standard library to run on Windows XP. The main motivation behind this PR is that to enable any Rust code in Firefox we need to support Windows XP.
This PR doesn't yet intend to be a move to make Windows XP an officially supported platform, but instead simply get Rust code running on it. APIs like condition variables and RWLocks will immediately panic currently on XP, and it's unclear if that story wants to change much. Additionally, we may bind APIs like IOCP which aren't available on XP and would be *very* difficult to provide a fallback implementation. Essentially this PR enables running Rust on XP, but you still have to be careful to avoid non-XP portions of the standard library.
The major components of this PR are:
* Support for a new `i686-pc-windows-msvc` triple. This primarily involves a lot of build system hackery, but there are also a number of floating point functions which had to get switched up a bit.
* All APIs not available on Windows are now accessed through our dynamic-detection mechanism
* Mutexes on Windows were rewritten to use SRWLOCK as an optimization but can fall back to CRITICAL_SECTION.
This commit enables executables linked against the standard library to run on
Windows XP. There are two main components of this commit:
* APIs not available on XP are shimmed to have a fallback implementation and use
runtime detection to determine if they are available.
* Mutexes on Windows were reimplemented to use critical sections on XP where
rwlocks are not available.
The APIs which are not available on XP are:
* SetFileInformationByHandle - this is just used by `File::truncate` and that
function just returns an error now.
* SetThreadStackGuarantee - this is used by the stack overflow support on
windows, but if this isn't available then it's just ignored (it seems
non-critical).
* All condition variable APIs are missing - the shims added for these apis
simply always panic for now. We may eventually provide a fallback
implementation, but for now the standard library does not rely on condition
variables for normal use.
* RWLocks, like condition variables, are missing entirely. The same story for
condition variables is taken here. These APIs are all now panicking stubs as
the standard library doesn't rely on RWLocks for normal use.
Currently, as an optimization, we use SRWLOCKs for the standard `sync::Mutex`
implementation on Windows, which is indeed required for normal operation of the
standard library. To allow the standard library to run on XP, this commit
reimplements mutexes on Windows to use SRWLOCK instances *if available* and
otherwise a CriticalSection is used (with some checking for recursive
locking).
With all these changes put together, a 32-bit MSVC-built executable can run on
Windows XP and print "hello world"
Closes#12842Closes#19992Closes#24776
bors
Corey Farwell
Ariel Ben-Yehuda
Huon Wilson
Steve Klabnik
Eljay
Simonas Kazlauskas
Manish Goregaokar
Guillaume Gomez
Richo Healey
Peter Elmers
Remi Rampin
Jared Roesch
Alex Crichton