- 07 7月, 2021 6 次提交
-
-
由 Ryan Levick 提交于
-
由 Ryan Levick 提交于
-
由 Ryan Levick 提交于
-
由 Ryan Levick 提交于
-
由 Ryan Levick 提交于
-
由 Ryan Levick 提交于
-
- 06 7月, 2021 30 次提交
-
-
由 bors 提交于
Replace per-target ABI denylist with an allowlist It makes very little sense to maintain denylists of ABIs when, as far as non-generic ABIs are concerned, targets usually only support a small subset of the available ABIs. This has historically been a cause of bugs such as us allowing use of the platform-specific ABIs on x86 targets – these in turn would cause LLVM errors or assertions to fire. In this PR we got rid of the per-target ABI denylists, and instead compute which ABIs are supported with a simple match based on, mostly, the `Target::arch` field. Among other things, this makes it impossible to forget to consider this problem (in either direction) and forces one to consider what the ABI support looks like when adding an ABI (rarely) rather than target (often), which should hopefully also reduce the cognitive load on both contributors as well as reviewers. Fixes #57182 Sponsored by: standard.ai --- ## Summary for teams One significant user-facing change after this PR is that there's now a future compat warning when building… * `stdcall`, `fastcall`, `thiscall` using code with targets other than 32-bit x86 (i386...i686) or *-windows-*; * `vectorcall` using code when building for targets other than x86 (either 32 or 64 bit) or *-windows-*. Previously these ABIs have been accepted much more broadly, even for architectures and targets where this made no sense (e.g. on wasm32) and would fall back to the C ABI. In practice this doesn't seem to be used too widely and the [breakages in crater](https://github.com/rust-lang/rust/pull/86231#issuecomment-866300943) that we see are mostly about Windows-specific code that was missing relevant `cfg`s and just happened to successfully `check` on Linux for one reason or another. The intention is that this warning becomes a hard error after some time.
-
由 bors 提交于
Reland "Merge CrateDisambiguator into StableCrateId" Reverts https://github.com/rust-lang/rust/pull/85891 as this revert of #85804 made perf even worse. r? `@Mark-Simulacrum`
-
由 Simonas Kazlauskas 提交于
It makes very little sense to maintain denylists of ABIs when, as far as non-generic ABIs are concerned, targets usually only support a small subset of the available ABIs. This has historically been a cause of bugs such as us allowing use of the platform-specific ABIs on x86 targets – these in turn would cause LLVM errors or assertions to fire. Fixes #57182 Sponsored by: standard.ai
-
由 bjorn3 提交于
-
由 bjorn3 提交于
-
由 bors 提交于
Store macro parent module in ExpnData. As a consequence, its value is hashed as part of the ExpnId's stable hash. Closes #85999
-
由 Camille GILLOT 提交于
-
由 bors 提交于
rustdoc: Replace `FakeDefId` with new `ItemId` type Follow up from #84707 `@Manishearth` [suggested](https://github.com/rust-lang/rust/pull/84707#issuecomment-831994669) that there should be a new `ItemId` type that can distinguish between auto traits, normal ids, and blanket impls instead of using `FakeDefId`s. This type is introduced by this PR. There are still some `FIXME`s left, because I was unsure what the best solution for them would be. Especially the naming in general now is a bit weird right now and needs to be cleaned up. Now there are no "fake" ids so the `is_fake` method on `Item` does not really make sense and maybe the methods on `ItemId` should be renamed too? Also, we need to represent the new item ids in the JSON backend somehow.
-
由 bors 提交于
Cleanup the computation of lint levels This now uses an `IndexVec` and a special root `LintStackIndex = 0` to encode command-line levels.
-
由 bors 提交于
Remove LibSource The information is stored in used_crate_source too anyway. Split out of #86105 r? `@petrochenkov`
-
由 bors 提交于
Rollup of 7 pull requests Successful merges: - #83581 (Add std::os::unix::fs::DirEntryExt2::file_name_ref(&self) -> &OsStr) - #85377 (aborts: Clarify documentation and comments) - #86685 (double-check mutability inside Allocation) - #86794 (Stabilize `Seek::rewind()`) - #86852 (Remove some doc aliases) - #86878 (
⬆ rust-analyzer) - #86886 (Remove `impl Clean for {Ident, Symbol}`) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup -
由 Justus K 提交于
-
由 Justus K 提交于
-
由 Justus K 提交于
-
由 Justus K 提交于
This reverts commit 41a345d4c46dad1a98c9993bc78513415994e8ba.
-
由 Justus K 提交于
-
由 Justus K 提交于
-
由 Justus K 提交于
-
由 Yuki Okushi 提交于
Remove `impl Clean for {Ident, Symbol}` These were only used once, in a place where it was trivial to replace. Also, it's unclear what 'clean' would mean for these, so it seems better to be explicit. Found while reviewing https://github.com/rust-lang/rust/pull/86841, which makes the same change to `build_macro`, so the two will conflict. r? `@GuillaumeGomez`
-
由 Yuki Okushi 提交于
⬆ rust-analyzer -
由 Yuki Okushi 提交于
Remove some doc aliases As per the new doc alias policy in https://github.com/rust-lang/std-dev-guide/pull/25, this removes some controversial doc aliases: - `malloc`, `alloc`, `realloc`, etc. - `length` (alias for `len`) - `delete` (alias for `remove` in collections and also file/directory deletion) r? `@joshtriplett`
-
由 Yuki Okushi 提交于
Stabilize `Seek::rewind()` This stabilizes `Seek::rewind`. It seemed to fit into one of the existing tests, so I extended that test rather than adding a new one. Closes #85149.
-
由 Yuki Okushi 提交于
double-check mutability inside Allocation r? `@oli-obk`
-
由 Yuki Okushi 提交于
aborts: Clarify documentation and comments In the docs for intrinsics::abort(): * Strengthen the recommendation by to use process::abort instead. * Document the fact that it sometimes (ab)uses an LLVM debug trap and what the likely consequences are. * State that the precise behaviour is unstable. In the docs for process::abort(): * Promise that we have the same behaviour as C `abort()`. * Document the likely consequences, including, specifically, the consequences on Unix. In the internal comment for unix::abort_internal: * Refer to the public docs for the public API functions. * Correct and expand the description of libc::abort. Specifically: * Do not claim that abort() unregisters signal handlers. It doesn't; it honours the SIGABRT handler. * Discuss, extensively, the issue with abort() flushing stdio buffers. * Describe the glibc behaviour in some detail. Co-authored-by: NMark Wooding <mdw@distorted.org.uk> Signed-off-by: NIan Jackson <ijackson@chiark.greenend.org.uk> Fixes #40230
-
由 Yuki Okushi 提交于
Add std::os::unix::fs::DirEntryExt2::file_name_ref(&self) -> &OsStr Greetings! This is my first PR here, so please forgive me if I've missed an important step or otherwise done something wrong. I'm very open to suggestions/fixes/corrections. This PR adds a function that allows `std::fs::DirEntry` to vend a borrow of its filename on Unix platforms, which is especially useful for sorting. (Windows has (as I understand it) encoding differences that require an allocation.) This new function sits alongside the cross-platform [`file_name(&self) -> OsString`](https://doc.rust-lang.org/std/fs/struct.DirEntry.html#method.file_name) function. I pitched this idea in an [internals thread](https://internals.rust-lang.org/t/allow-std-direntry-to-vend-borrows-of-its-filename/14328/4), and no one objected vehemently, so here we are. I understand features in general, I believe, but I'm not at all confident that my whole-cloth invention of a new feature string (as required by the compiler) was correct (or that the name is appropriate). Further, there doesn't appear to be a test for the sibling `ino` function, so I didn't add one for this similarly trivial function either. If it's desirable that I should do so, I'd be happy to [figure out how to] do that. The following is a trivial sample of a use-case for this function, in which directory entries are sorted without any additional allocations: ```rust use std::os::unix::fs::DirEntryExt; use std::{fs, io}; fn main() -> io::Result<()> { let mut entries = fs::read_dir(".")?.collect::<Result<Vec<_>, io::Error>>()?; entries.sort_unstable_by(|a, b| a.file_name_ref().cmp(b.file_name_ref())); for p in entries { println!("{:?}", p); } Ok(()) } ```
-
由 bors 提交于
Query-ify global limit attribute handling Currently, we read various 'global limits' from inner attributes the crate root (`recursion_limit`, `move_size_limit`, `type_length_limit`, `const_eval_limit`). These limits are then stored in `Sessions`, allowing them to be access from a `TyCtxt` without registering a dependency on the crate root attributes. This PR moves the calculation of these global limits behind queries, so that we properly track dependencies on crate root attributes. During the setup of macro expansion (before we've created a `TyCtxt`), we need to access the recursion limit, which is now done by directly calling into the code shared by the normal query implementations.
-
- 05 7月, 2021 4 次提交
-
-
由 bjorn3 提交于
-
由 Joshua Nelson 提交于
These were only used once, in a place where it was trivial to replace. Also, it's unclear what 'clean' would mean for these, so it seems better to be explicit.
-
由 Mara Bos 提交于
Co-authored-by: NYuki Okushi <jtitor@2k36.org>
-
由 bors 提交于
Inline Iterator as IntoIterator. For some reason, it appears on rustc's own perf stats.
-