| Age | Commit message (Collapse) | Author | Lines |
|
LLVM 9 is adding support for a "pic" relocation model for wasm code,
which is quite different than the current model. In order to preserve
the mode of compilation that we have today default to "static" to ensure
that we don't accidentally start creating experimental relocatable
binaries.
|
|
Rollup of 8 pull requests
Successful merges:
- #59470 (Document std::fs::File close behavior ignoring errors)
- #59555 (update miri)
- #59556 (update stdsimd)
- #59596 (Forward formatter settings to bounds of `Range<T>` in `fmt::Debug` impl)
- #59639 (Never return uninhabited values at all)
- #59671 (Make some of lexer's API private)
- #59685 (Add description for -Os and -Oz in rustc.1)
- #59686 (Temporarily disable stack probing for gnux32.)
Failed merges:
r? @ghost
|
|
Temporarily disable stack probing for gnux32.
|
|
Add description for -Os and -Oz in rustc.1
|
|
Make some of lexer's API private
Lexer is a `pub` type, so it feels wrong that its fields are just pub (I guess it wasn't exported initially), so let's minimize visibility.
Context: I am looking into extracting rust-lexer into a library, which can be shared by rust-analyzer and rustc. I hope that a simple interface like `fn next_token(src: &str) -> (TokenKind, usize)` would work, but to try this out I need to understand what is the current API of the lexer.
|
|
Never return uninhabited values at all
Functions with uninhabited return values are already marked `noreturn`,
but we were still generating return instructions for this. When running
with `-C passes=lint`, LLVM prints:
Unusual: Return statement in function with noreturn attribute
The LLVM manual makes a stronger statement about `noreturn` though:
> This produces undefined behavior at runtime if the function ever does
dynamically return.
We now emit an `abort` anywhere that would have tried to return an
uninhabited value.
Fixes #48227
cc #7463 #48229
r? @eddyb
|
|
Forward formatter settings to bounds of `Range<T>` in `fmt::Debug` impl
Before this change, formatter settings were lost when printing a `Range`. For example, printing a `Range<f32>` with `{:.2?}` would not apply the precision modifier when printing the floats. Now the `Debug` impls look a bit more verbose, but modifier are not lost.
---
I assume the exact output of `Debug` impls in `std` cannot be relied on by users and thus can change, right?
|
|
update stdsimd
Cc @gnzlbg
|
|
update miri
r? @oli-obk
Fixes https://github.com/rust-lang/rust/issues/59477
|
|
Document std::fs::File close behavior ignoring errors
Resolves #52685
|
|
wasi: Implement more of the standard library
This commit fills out more of the `wasm32-unknown-wasi` target's standard library, notably the `std::fs` module and all of its internals. A few tweaks were made along the way to non-`fs` modules, but the last commit contains the bulk of the work which is to wire up all APIs to their equivalent on WASI targets instead of unconditionally returning "unsupported". After this some basic filesystem operations and such should all be working in WASI!
|
|
Move query definitions over to the proc macro
r? @oli-obk
|
|
|
|
Support using LLVM's libunwind as the unwinder implementation
This avoids the dependency on host libraries such as libgcc_s which
may be undesirable in some deployment environments where these aren't
available.
|
|
|
|
|
|
Rollup of 6 pull requests
Successful merges:
- #59316 (Internal lints take 2)
- #59663 (Be more direct about borrow contract)
- #59664 (Updated the documentation of spin_loop and spin_loop_hint)
- #59666 (Updated the environment description in rustc.)
- #59669 (Reduce repetition in librustc(_lint) wrt. impl LintPass by using macros)
- #59677 (rustfix coverage: Skip UI tests with non-json error-format)
Failed merges:
r? @ghost
|
|
phansch:rustfix_coverage_handle_other_error_formats, r=oli-obk
rustfix coverage: Skip UI tests with non-json error-format
When using the `rustfix-coverage` flag, some tests currently fail
because they define a different error-format than `json`.
The current implementation crashes when encountering those tests. Since
we don't care about non-json test output when collecting the coverage
data, we handle those tests by returning an empty `Vec` instead.
r? @oli-obk
|
|
Reduce repetition in librustc(_lint) wrt. impl LintPass by using macros
r? @oli-obk
cc @Zoxc
|
|
r=GuillaumeGomez
Updated the environment description in rustc.
# Description
- Updated the "environment" description in the `rustc` man pages
The old wording suggested that all the mentioned flags influenced the output of the compiler,
where this was not the case.
closes #59504
|
|
Updated the documentation of spin_loop and spin_loop_hint
# Description
- Updated the description of `core::hints::spin_loop`
- Updated the description of `core::async::spin_loop_hint`
Both documentation is rewritten to better reflect when one should prefer using a busy-wait spin-loop (and the `spin_loop` and `spin_loop_hint` functions) over `yield_now`. It also dives a little bit deeper on what the function actually does.
closes #55418
|
|
Be more direct about borrow contract
I always was confused by the difference between Borrow and AsRef, despite the fact that I've read all available docs at least a dozen of times.
I finally grokked the difference between the two when I realized the Borrow invariant:
> If you implement Borrow, you **must** make sure that Eq, Ord and Hash implementations are equivalent for borrowed and owned data
My problem was that this invariant is not stated explicitly in documentation, and instead some vague and philosophical notions are used.
So I suggest to mention the requirements of `Borrow` very explicitly: instead of "use Borrow when X and use AsRef when Y", let's phrase this as `Borrow` differs from `AsRef` in `W`, so that's why `Borrow` is for `X` and `AsRef` is for `Y`.
Note that this change could be seen as tightening contract of the Borrow. Let's say Alice has written the following code:
```rust
#[derive(PartialEq, Eq, Hash, PartialOrd, Ord)]
struct Person {
first_name: String,
last_name: String,
}
impl Borrow<str> for Person {
fn borrow(&self) -> &str { self.first_name.as_str() }
}
```
Now Bob uses this `Person` struct, puts it into `HashMap` and tries to look it up using `&str` for the first name. Bob's code naturally fails.
The question is, who is to blame: Alice, who has written the impl, or Bob, who uses the HashMap. If I read the current docs literally, I would say that `Bob` is to blame: `Eq` and `Hash` bounds appear on HashMap, so it is the HashMap which requires that they are consistent. By using a type for which the `Borrow` impl does not yield well-behaved `Eq`, Bob is violating contract of HashMap.
If, as this PR proposes, we unconditionally require that Eq & friends for borrow should be valid, then the blame shifts to Alice, which I think is more reasonable.
closes https://github.com/rust-lang/rust/issues/44868
|
|
Internal lints take 2
cc #58701
cc #49509
TODO: Add `#![warn(internal)]` to crates (and fix violations)
Crates depending on `rustc_data_structures`
- [x] librustc_resolve
- [x] librustc_driver
- [x] librustc_passes
- [x] librustc_metadata
- [x] librustc_interface
- [x] librustc_save_analysis
- [x] librustc_lint
- [x] librustc
- [x] librustc_incremental
- [x] librustc_codegen_utils
- [x] libarena
- [x] librustc_target
- [x] librustc_allocator
- [x] librustc_privacy
- [x] librustc_traits
- [x] librustc_borrowck
- [x] libsyntax
- [x] librustc_codegen_ssa
- [x] libsyntax_ext
- [x] librustc_errors
- [x] librustc_mir
- [x] libsyntax_pos
- [x] librustc_typeck
Crates with `feature(rustc_private)`
Excluding crates, which are already in the list above. Also excluding tools and tests.
- [ ] ~~libstd~~
- [x] libfmt_macros
- [x] librustdoc
r? @oli-obk
|
|
Revert rust-lld place changes
Fixes #59661.
Instead of https://github.com/rust-lang/rust/pull/59668 it reverts only failed part.
|
|
Functions with uninhabited return values are already marked `noreturn`,
but we were still generating return instructions for this. When running
with `-C passes=lint`, LLVM prints:
Unusual: Return statement in function with noreturn attribute
The LLVM manual makes a stronger statement about `noreturn` though:
> This produces undefined behavior at runtime if the function ever does
dynamically return.
We now emit an `abort` anywhere that would have tried to return an
uninhabited value.
|
|
|
|
When using the `rustfix-coverage` flag, some tests currently fail
because they define a different error-format than `json`.
The current implementation crashes when encountering those tests. Since
we don't care about non-json test output when collecting the coverage
data, we handle those tests by returning an empty `Vec` instead.
|
|
This avoids the dependency on host libraries such as libgcc_s which
may be undesirable in some deployment environments where these aren't
available.
|
|
|
|
- libfmt_macros
- librustdoc
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- libarena
- librustc_allocator
- librustc_borrowck
- librustc_codegen_ssa
- librustc_codegen_utils
- librustc_driver
- librustc_errors
- librustc_incremental
- librustc_metadata
- librustc_passes
- librustc_privacy
- librustc_resolve
- librustc_save_analysis
- librustc_target
- librustc_traits
- libsyntax
- libsyntax_ext
- libsyntax_pos
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|