Rollup of 18 pull requests#159871
Closed
jhpratt wants to merge 73 commits into
Closed
Conversation
Co-authored-by: Noah Lev <camelidcamel@gmail.com>
This is probably not what the user wants:
error: nested Markdown emphasis in HTML `style` tag
--> $DIR/invalid-html-tags-correct-script-style.rs:11:16
|
LL | /// One <style>*emph*</style>
| ^^^^^^ Markdown translates this into HTML, but the browser parses it as CSS
|
help: to turn off Markdown parsing, put the tag at the start of the line
|
LL ~ /// One
LL ~ /// <style>*emph*</style>
|
The `test_dir_remove_file` test currently fails under Windows 7 on:
```
thread 'fs::tests::test_dir_remove_file' (2028) panicked at library/std/src/fs/tests.rs:2590:5:
dir.remove_file("foo.txt") failed with: The parameter is incorrect. (os error 87)
```
Looking into it, this is because the `FILE_DISPOSITION_INFO_EX` variant
of the `SetFileInformationByHandle` API is used while it is only
available starting from Windows 10 1607. However,
`FILE_DISPOSITION_INFO` is still available since Vista.
This is therefore fixed by introducing a fallback to the latter API if
the former fails. This is achieved by re-using some logic that is
already available through `File::delete` and that does exactly this.
Signed-off-by: Paul Mabileau <paul.mabileau@harfanglab.fr>
Canonicalize and evaluate next-gen region constraints before query response canonicalization so equivalent constraints merge structurally.
Cover the dyn object supertrait case that used to leave equivalent next-gen region constraints in different shapes.
This is currently a no-op, but will be useful when const in `global_asm!` can be pointers.
Currently global_asm already have symbol names when using v0 scheme, this makes them obtain symbols with legacy scheme too.
This gives the asm-const code the basic ability to deal wiht pointer and provenances, which lays the ground work for asm_const_ptr. Note that `SymStatic` is not fully removed, a specialized is kept and renamed as `SymThreadLocalStatic`, for `#[thread_local]` statics where CTFE does not support naming. The `#[thread_local]` is unstable feature and it's not clear if we want to support this in `sym`, but removal of it should be a separate PR.
With the previous commit, now we can see there are some code duplication for the handling of `GlobalAlloc` inside backends. Do some clean up to unify them.
CTFE pointers created via type ID, `without_provenance` or pointers to const ZSTs can now be codegenned with all 3 backends. These pointers are generated in the same way as integers.
also add a test for cross-crate static initializers
…ef const after scheduling. That works only when a later phase emits a real diagnostics. For function item (associated fn), the lowering needs parent trait and self args
The backend now fully supports codegen of const pointers, remove the block inside typeck behind a new feature gate. Tests are also added.
…gic, r=aapoalas,nia-e,nikic document #[global_allocator] constraints `#[global_allocator]` is opsem magic. For instance, even if we do ```rust use std::alloc::System; #[global_allocator] static ALLOC: System = System; ``` it is still UB to allocate via `std::alloc::alloc()` and deallocate via `System.dealloc()`. This is because we add special magic LLVM attributes in the `#[global_allocator]` machinery that tell LLVM about our global allocation methods so it can optimize accordingly, and mixing allocators is against those rules. Cc @rust-lang/opsem @rust-lang/lang @nia-e @maxdexh @nikic is this enough to ensure that adding your intrinsics is sound?
…cote optimization: don't look for diagnostic/canonical items without rustc_attrs enabled
…ls, r=bjorn3 reuse regular exported_non_generic_symbols logic in Miri This is some gnarly code we have duplicated in Miri, let's try to reuse the version from rustc. r? @bjorn3
…ptrs, r=WaffleLapkin check `extern "custom"` function pointers tracking issue: rust-lang#140829 related RFC: rust-lang/rfcs#3980 Best reviewed commit-by-commit. This PR makes 3 changes - extend the ABI checks we already performed on function definitions and trait and foreign declarations to function pointer types. This touches the various `interupt` ABIs and `extern "custom"`. - remove the ability for `extern "custom"` to return `!` - improve the suggestion when `safe` is used in a function pointer type
…nore-hidden-js-tests, r=notriddle rustdoc-js: ignore editor temp files in test folder discovery `tester.js` previously treated every `*.js` entry under `--test-folder` as a test. Editor temporary files such as Emacs `.#alias-4.js` also end with `.js`, so discovering them caused `rustdoc-js-std` to fail with `ENOENT` when the lock file was a dead symlink. This change mirrors compiletest's `is_test` filtering and skips names that start with `.`, `#`, or `~` during folder discovery. Explicit `--test-file` paths are unchanged. Fixes rust-lang#142648.
…-cfg-note, r=GuillaumeGomez std::sync::poison: disable auto_cfg on PoisonError::new `PoisonError::new` is defined twice, once for `#[cfg(panic = "unwind")]` and once for its negation. While exactly one definition survives expansion in any given build, the method itself is actually present in every configuration. Currently, rustdoc's `auto_cfg` only looks at whichever `cfg` survived expansion and tags the method accordingly, generating a misleading "Available on panic=unwind only" portability badge in the docs. This is the same `auto_cfg` limitation previously addressed in rust-lang#153964, rust-lang#154311, and rust-lang#156426: when an item is split into mutually-exclusive `cfg` variants that collectively cover all builds, rustdoc incorrectly marks it as conditionally available. Issue rust-lang#149786 pointed out `PoisonError::new` as another case of this pattern, but it hadn't been touched yet. This PR applies the same fix as rust-lang#156426 (adding `#[doc(auto_cfg = false)]` to both variants) and adds a regression test to cover this pattern going forward. r? @GuillaumeGomez
…uctive, r=BoxyUwU stepping into where-clauses during normalization may be productive fixes rust-lang/trait-system-refactor-initiative#273, see that issue for more info. Whether stepping into a where-clause is productive depends not on whether we're proving a `NormalizesTo` or `Trait` goal, but instead on how both the impl and the cycle rely on it. In the example in tests/ui/traits/next-solver/cycles/normalizes-to-is-not-productive-2.rs this is just a productive use given the way @Nadrieril and I are thinking about it right now. We're changing such cycles to be ambiguous for now, so this does not commit us to anything. This previously caused a lot of breakage when normalizing where-clauses, e.g. rust-lang/trait-system-refactor-initiative#176, however with rust-lang#158643 that is no longer an issue. We will need to figure out what to do here if we want to properly fix `ParamEnv` normalization in the future r? @BoxyUwU or @nikomatsakis
…=BoxyUwU when bailing on ambiguity, don't force other results to ambig A smaller version of rust-lang#149904 which doesn't cause the perf issue in bevy, or at least in the minimization While not necessarily necessary for rust-lang/trait-system-refactor-initiative#257 due to rust-lang#158643. This does fix the underlying issues there. This change does affect `binius_field`, the remaining issues are tracked in rust-lang/trait-system-refactor-initiative#274. The core idea is that for - A - B - A (cycle with initial result) - B <--- We normally run A until we reach a fixpoint. We don't do so in case trying to do so encounters overflow or the result of `A` ends up ambiguous to avoid performance issues. We want to generally keep the provisional cache entries which depend on A around. Evaluating these goals depends on the current provisional result of A. This means it is fine to keep them around if A reached a fixpoint. If we bail without reaching a fixpoint, the provisional result used while computing B differs from the final result of A. This means the entry for B is not valid and we'd need to discard it. Discarding all nested provisional cache entries when not reaching a fixpoint causes perf issues. In case the final result of A is ambiguous, then this PR keeps nested cache entries which are ambiguous and don't have any inference constraints around. That is sound, as having more goals be ambiguous is never an issue, the trait solver can always say ":shrug: idk". It also shouldn't cause any incorrect ambiguity errors issues, as changing the provisional result of A to be ambiguity should not change B to go from being ambiguous to something else. The current implementation mutated the result of all nested provisional cache entries to be ambiguous, which resulted in incorrect ambiguity errors in rust-lang/trait-system-refactor-initiative#257. This PR differs from that by dropping goals whose result isn't already ambiguous. That's means we don't keep quite as many cache entries around, which is potentially worse for perf, but from what I can tell this doens't cause issues in practice. r? BoxyUwU
…gau,aDotInTheVoid [rustdoc] Correctly handle output options with --show-coverage Fixes rust-lang#158929. The `-o` option was ignored with `--show-coverage`. This PR takes it into account and makes it closer to how these options are handled in the rest of rustdoc. Considering `calculate_doc_coverage` was never really a pass and that I needed `RenderOptions` (for the `-o` option), I moved it out of passes. r? @camelid
…ove-file, r=ChrisDenton
Fix(lib/fs/win): Fall back on Win32 delete for `Dir::remove_file`
The `test_dir_remove_file` test currently fails under Windows 7 on:
```
thread 'fs::tests::test_dir_remove_file' (2028) panicked at library/std/src/fs/tests.rs:2590:5:
dir.remove_file("foo.txt") failed with: The parameter is incorrect. (os error 87)
```
Looking into it, this is because the `FILE_DISPOSITION_INFO_EX` variant of the `SetFileInformationByHandle` API is used while it is only available starting from Windows 10 1607. However, `FILE_DISPOSITION_INFO` is still available since Vista.
This is therefore fixed by introducing a fallback to the latter API if the former fails. This is achieved by re-using some logic that is already available through `File::delete` and that does exactly this.
cc rust-lang#120426 @roblabla @the8472 @ChrisDenton @RalfJung
@rustbot label A-io T-libs O-Windows-7
…ssages, r=oli-obk Avoid `#[target_features]` The string `#[target_features]` is used in various error messages as well as the compiler's code. But there is no such attribute, which I found very confusing. I think it means "one or more target features", e.g. covering both `#[target_feature(foo)]` and `#[target_feature(foo, bar, baz)]`. We already use `#[target_feature(..)]` for that meaning in several places. So this commit changes all `#[target_features]` occurrences to `#[target_feature(..)]`. It also changes a few `#[target_feature]` (no plural) occurrences to `#[target_feature(..)]` for consistency with other mentions nearby in error messages. r? @oli-obk
Remove redundant `#[rustc_paren_sugar]` feature gate It is already gated on `rustc_attrs`. Alternatively we could update attribute parsing to optionally require multiple features, but that seems unnecessary. r? @JonathanBrouwer
rustbot
added
A-attributes
Member
Author
|
included PR being tested by accident |
rustbot
removed
the
S-waiting-on-review
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
17 participants
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.
Successful merges:
set_permissions_nofollowfor all primary platforms #158168 (Added implementation onset_permissions_nofollowfor all primary platforms)constoperand #138618 (Support using const pointers in asmconstoperand)extern "custom"function pointers #159780 (checkextern "custom"function pointers)Dir::remove_file#159439 (Fix(lib/fs/win): Fall back on Win32 delete forDir::remove_file)#[target_features]#159809 (Avoid#[target_features])#[rustc_paren_sugar]feature gate #159826 (Remove redundant#[rustc_paren_sugar]feature gate)r? @ghost
Create a similar rollup