According to [caniuse], these vendor prefixes aren't needed in any
supported web browsers as defined in [RFC 1985]
* The last version of Chrome that required a vendor prefix was version 9.
The current version is 108.
* Firefox 28 is the last version that required a vendor prefix. The
[current Firefox ESR] is version 102.
* The last version of Safari that required a vendor prefix was version 5.
The current version is 16.
* The last version of Safari/iOS that required a vendor prefix was version 4.
The current version is 16.
* Edge never required vendor prefixes.
* UCAndroid never required vendor prefixes.
[caniuse]: https://caniuse.com/?search=box-sizing
[RFC 1985]: https://rust-lang.github.io/rfcs/1985-tiered-browser-support.html
[current Firefox ESR]: https://wiki.mozilla.org/Releases
Abolish `QueryVTable` in favour of more assoc items on `QueryConfig`
This may introduce additional mono _but_ may help const fold things better and especially may help not constructing a `QueryVTable` anymore which is cheap but not free.
This may introduce additional mono _but_ may help const fold things
better and especially may help not constructing a `QueryVTable` anymore
which is cheap but not free.
HIR debug output is currently very verbose, especially when used with
the alternate (`#`) flag. This commit reduces the amount of noisy
newlines by forcing a few small key types to stay on one line, which
makes the output easier to read and scroll by.
```
$ rustc +after hello_world.rs -Zunpretty=hir-tree | wc -l
582
$ rustc +before hello_world.rs -Zunpretty=hir-tree | wc -l
932
```
Context is no longer Sync so this doesn't work.
error[E0277]: `*mut ()` cannot be shared between threads safely
--> library/core/tests/task.rs:24:21
|
24 | static CONTEXT: Context<'static> = Context::from_waker(&WAKER);
| ^^^^^^^^^^^^^^^^ `*mut ()` cannot be shared between threads safely
|
= help: within `Context<'static>`, the trait `Sync` is not implemented for `*mut ()`
= note: required because it appears within the type `PhantomData<*mut ()>`
= note: required because it appears within the type `Context<'static>`
= note: shared static variables must have a type that implements `Sync`
Encode spans relative to the enclosing item -- enable on nightly
Follow-up to #84373 with the flag `-Zincremental-relative-spans` set by default.
This PR seeks to remove one of the main shortcomings of incremental: the handling of spans.
Changing the contents of a function may require redoing part of the compilation process for another function in another file because of span information is changed.
Within one file: all the spans in HIR change, so typechecking had to be re-done.
Between files: spans of associated types/consts/functions change, so type-based resolution needs to be re-done (hygiene information is stored in the span).
The flag `-Zincremental-relative-spans` encodes local spans relative to the span of an item, stored inside the `source_span` query.
Trap: stashed diagnostics are referenced by the "raw" span, so stealing them requires to remove the span's parent.
In order to avoid too much traffic in the span interner, span encoding uses the `ctxt_or_tag` field to encode:
- the parent when the `SyntaxContext` is 0;
- the `SyntaxContext` when the parent is `None`.
Even with this, the PR creates a lot of traffic to the Span interner, when a Span has both a LocalDefId parent and a non-root SyntaxContext. They appear in lowering, when we add a parent to all spans, including those which come from macros, and during inlining when we mark inlined spans.
The last commit changes how queries of `LocalDefId` manage their cache. I can put this in a separate PR if required.
Possible future directions:
- validate that all spans are marked in HIR validation;
- mark macro-expanded spans relative to the def-site and not the use-site.
Document read_line gotchas
1. The "You do not need to clear the buffer before appending" advice is ambiguous, because it depends what you use this function for. For a rather common case of reading individual lines in a loop, it _is_ necessary to clear the buffer.
2. The docs warn about a DoS risk. I've added a hint how to mitigate unbounded memory growth.
