| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
To avoid potential duplicate diagnostics and separate the error reporting logic
|
|
|
|
|
|
|
|
causes an error during evaluation
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fix spurious CI filures due to OOM
Fixes #66397
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
review comment
|
|
|
|
|
|
|
|
[beta] Update cargo
1 commits in 5da4b4d47963868d9878480197581ccbbdaece74..bc8e4c8be13c8f8d1583f9d52e55fda038c0f9d4
2019-10-28 21:53:41 +0000 to 2019-11-22 17:45:44 +0000
- [beta] Extend documentation on security concerns of crate names in a registry. (rust-lang/cargo#7619)
|
|
|
|
|
|
|
|
It's super unclear why this broke when we switched to beta but not
previously -- but at least it's hopefully fixed now.
|
|
|
|
Statically link libstdc++ on windows-gnu
Fixes https://github.com/rust-lang/rust/issues/61561 by not shipping `libstdc++-6.dll` which can conflict with the GCC.
|
|
Clarify pattern-matching usefulness algorithm
This PR clarifies a bit the usefulness algorithm by emphasizing that each row of the matrix can be seen as a sort of stack from which we pop constructors. It also moves code around to increase separation of concerns.
This is part of my splitting of https://github.com/rust-lang/rust/pull/65160 into smaller PRs.
|
|
expand: Feature gate out-of-line modules in proc macro input
Extracted from https://github.com/rust-lang/rust/pull/64273.
We are currently gating attributes applied directly to `mod` items because there are unresolved questions about out-of-line modules and their behavior is very likely to change.
However, you can sneak an out-of-line module into an attribute macro input using modules nested into other items like
```rust
#[my_attr]
fn m() {
#[path = "zzz.rs"]
mod n; // what tokens does the `my_attr` macro see?
}
```
This PR prevents that and emits a feature gate error for this case as well.
r? @Centril
It would be great to land this before beta.
|
|
|
|
Remove LintBuffer from Session
This moves the `LintBuffer` from `Session` into the `Resolver`, where it is used until lowering is done and then consumed by early lint passes. This also happily removes the failure mode of buffering lints too late where it would have previously lead to ICEs; it is statically no longer possible to do so.
I suspect that with a bit more work a similar move could be done for the lint buffer inside `ParseSess`, but this PR doesn't touch it (in part to keep itself small).
The last commit is the "interesting" commit -- the ones before it don't work (though they compile) as they sort of prepare the various crates for the lint buffer to be passed in rather than accessed through Session.
|
|
|
|
This allows us to directly pass in a lint buffer
|
|
|
|
|
|
|
|
|
|
Reduce amount of errors given unclosed delimiter
When in a file with a non-terminated item, catch the error and consume
the block instead of trying to recover it on a more granular way in order to
reduce the amount of unrelated errors that would be fixed after adding
the missing closing brace. Also point out the possible location of the
missing closing brace.
Fix #63690.
|
|
r=Mark-Simulacrum
Move help popup generation code
The first commit is just a small cleanup.
The idea behind this PR is to reduce a bit more the generated HTML files by moving the duplicated code into one place instead.
r? @kinnison
|
|
Allow foreign exceptions to unwind through Rust code and Rust panics to unwind through FFI
This PR fixes interactions between Rust panics and foreign (mainly C++) exceptions.
C++ exceptions (and other FFI exceptions) can now safely unwind through Rust code:
- The FFI function causing the unwind must be marked with `#[unwind(allowed)]`. If this is not the case then LLVM may optimize landing pads away with the assumption that they are unreachable.
- Drop code will be executed as the exception unwinds through the stack, as with a Rust panic.
- `catch_unwind` will *not* catch the exception, instead the exception will silently continue unwinding past it.
Rust panics can now safely unwind through C++ code:
- C++ destructors will be called as the stack unwinds.
- The Rust panic can only be caught with `catch (...)`, after which it can be either rethrown or discarded.
- C++ cannot name the type of the Rust exception object used for unwinding, which means that it can't be caught explicitly or have its contents inspected.
Tests have been added to ensure all of the above works correctly.
Some notes about non-C++ exceptions:
- `pthread_cancel` and `pthread_exit` use unwinding on glibc. This has the same behavior as a C++ exception: destructors are run but it cannot be caught by `catch_unwind`.
- `longjmp` on Windows is implemented using unwinding. Destructors are run on MSVC, but not on MinGW. In both cases the unwind cannot be caught by `catch_unwind`.
- As with C++ exceptions, you need to mark the relevant FFI functions with `#[unwind(allowed)]`, otherwise LLVM will optimize out the destructors since they seem unreachable.
I haven't updated any of the documentation, so officially unwinding through FFI is still UB. However this is a step towards making it well-defined.
Fixes #65441
cc @gnzlbg
r? @alexcrichton
|
|
Validate error patterns and error annotation in ui tests when present
Previously, when compilation succeeded, neither error patterns nor error
annotation would be validated. Additionally, when compilation failed,
only error patterns would be validated if both error patterns and error
annotation were present.
Now both error patterns and error annotation are validated when present,
regardless of compilation status. Furthermore, for test that should run,
the error patterns are matched against executable output, which is what
some of tests already expect to happen, and when #65506 is merged even
more ui tests will.
Fixes #56277
|
|
|
