- Ensure MSVC license terms are clearly shown to the user.
- Simplify config of vc and vcpp slightly by extracting common stuff
into a group.
- Remove reference to MS privacy policy
This PR adds new C23 keywords from
https://en.cppreference.com/w/c/keyword. I have some FUD about always
highlighting things like `bool`, since what most people think of as C is
not C23. I think ideally we'd be able to only highlight C23 keywords
when `-std=c23` is being used, but that of course makes things a good
deal more complex. But also, it probably makes sense to just go ahead
and highlight these.
Possibly related to #6568.
<!-- THIS COMMENT IS INVISIBLE IN THE FINAL PR, BUT FEEL FREE TO REMOVE
IT
Thanks for taking the time to improve CE. We really appreciate it.
Before opening the PR, please make sure that the tests & linter pass
their checks,
by running `make check`.
In the best case scenario, you are also adding tests to back up your
changes,
but don't sweat it if you don't. We can discuss them at a later date.
Feel free to append your name to the CONTRIBUTORS.md file
Thanks again, we really appreciate this!
-->
Fix#6464, following the discord discussion.
2 protections are added here:
(1) Make the first code editor non-closable, to avoid an empty layout,
(2) If a loaded config has empty layout - fallback to the default
config.
Fix#6460: trying to access an `undefined` this.optRemarks.
The order of opt-view.ts invocations at opt-view pane open is:
1. `constructor`,
2. `registerButtons`,
3. `onCompileResult`
If someone manages to click the filter checkboxes after (2) but before
(3), then `showOptRemarks` would be triggered before `this.optRemakrs`
is initialized and this exception would ensue. The solution here is to
initialize `this.optRemakrs` at the constructor.
Couldn't reproduce, the solution is entirely hypothetical. If it would
happen again we'll revisit this.
Make MonacoPane calls `createDecorationsCollection` in a single place
instead of forcing many subclasses to remember to call
`initDecorations`. Some subclasses never use DecorationsCollection and
call init for no reason now, but it still seems healthier - this avoids
the possibility of a MonacoPane subclass trying to use an uninitialized
decoration collection.
Also remove the depracated `deltaDecorations` from stack-usage-view.
I overlooked this one. It is sort of important for these to be a
different color than the background:
```
static_assert
alignof
typeid
static_cast
sizeof
reinterpret_cast
dynamic_cast
decltype
asm
```
Fixed:
- Dropdown menu disabled color
- Dropdown menu active color
- General panel background color
- Separator line for minimap
- Output text-count color
- Remove pure white across theme
- Fix custom-select in popout
Adds a new theme based on the One Dark theme from the Atom text editor.
Adds a new line highlighting theme "Soft Dark Rainbow" that works better
with the One Dark theme.
Hey friends, it's been a while since last time :)
There are quite a few conditions/cases where the library alert will pop
up, without anything meaningful inside of it. This is particularly the
case for Rust where you have the 100 crates on stable, but zero support
in beta/nightly. I figured informing the user in cases like this would
be nice to have.
This PR adds a rather simple alerting mechanism to alert the user of any
conditions that might not be as apparent (such as Rust crates only being
on stable)
Below is a small gif of how it works. I'm not sure this is the easiest
way to convey this information (especially considering the modal popup
overshadows the alert) so please share any other ideas. Maybe it's
better to have the content fill the modal instead?
Relevant issues: #3766#6250
Demangled Rust identifiers under the `legacy` name mangling scheme rely
on a hash to disambiguate items with the same name, such as different
monomorphisations of the same function or different closures’
`call_once` methods.
In the `v0` mangling scheme, this is no longer a problem. However,
configuring the demangler to show hashes in `legacy` names will include
crate-id hashes in `v0` names, which are [mostly
unneeded](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html#appendix-a---suggested-demangling).
This PR introduces a new checkbox *Options...* → *Verbose demangling*
that lets the user select if they want to include disambiguating hashes
in demangled identifiers.
This checkbox is only shown for compilers that support verbose
demangling, and deactivated when the *Demangle identifiers* checkbox is
unchecked.
Resolves#1754.
Resolves#6255.
Compilers like to encode short-ish strings into immediate arguments to
various assembly instructions. This makes it hard to read the assembly.
To improve readability, show a string representation of a number’s bytes
when they’re valid UTF-8.
This now also shows a string representation for *unprintable* ASCII
characters, such as `10` being shown as `"\n"` or `1` as `"\u0001"`.
Resolves#6220.
## Examples
([link](https://godbolt.org/z/7hzn6b8YG))
* 8583909746840200552: `8'583'909'746'840'200'552 =
0x7720'2C6F'6C6C'6568 = 6.5188685003648344e+265 = "hello, w"`
* 1684828783: `1'684'828'783 = 0x646C'726F = 1.74467096e+22f = "orld"`
* -6934491452449512253: `-6'934'491'452'449'512'253 =
0x9FC3'BCC3'B6C3'A4C3 = -1.1500622354593239e-155 = "äöüß"`
* 1633837924: `1'633'837'924 = 0x6162'6364 = 2.61007876e+20f = "dcba"`
* 97: `97 = 0x61 = 1.35925951e-43f = "a"`
* 10: `10 = 0xA = 1.40129846e-44f = "\n"`
* 92: `92 = 0x5C = 1.28919459e-43f = "\\"`
## Open questions
* The code assumes little-endian encoding, so the string representation
is reversed compared to the numeric representation (see `integer`
example). Should this be configurable or should the bytes not be
reversed?
* Negative numbers are masked to 64-bit unsigned ints (same as in the
hex representation), so if the number is shorter than 8 bytes, it has
some leading `ff` bytes and is not valid UTF-8 (see
`small_negative_number` in the example link). Is this an acceptable
limitation?
* I'd like to add some tests for `getNumericToolTip`, but I’m not really
familiar with TypeScript. I tried to importing
`static/panes/compiler.ts` in a test file, but
([after](https://github.com/vitest-dev/vitest/discussions/1806#discussioncomment-3570047)
some [struggling](https://vitest.dev/config/#environment)) it seems that
that file needs a [specific DOM
element](3c26c64ca3/static/options.ts (L27))
that is not present during testing. The simplest solution I could come
up with is moving `getNumericToolTip` into another file (such as
`static/utils.ts`). Is that okay or is is it possible test
`static/panes/compiler.ts` some other way?
---------
Co-authored-by: Patrick Quist <partouf@gmail.com>
And change 'toggle' to 'hide' to better express the intention.
Fixes#6225.
<!-- THIS COMMENT IS INVISIBLE IN THE FINAL PR, BUT FEEL FREE TO REMOVE
IT
Thanks for taking the time to improve CE. We really appreciate it.
Before opening the PR, please make sure that the tests & linter pass
their checks,
by running `make check`.
In the best case scenario, you are also adding tests to back up your
changes,
but don't sweat it if you don't. We can discuss them at a later date.
Feel free to append your name to the CONTRIBUTORS.md file
Thanks again, we really appreciate this!
-->
Long numbers are sometimes hard to read in the numeric tooltip. To
improve readability, this PR adds language-specific digit separators to
the numeric tooltip.
Decimal numbers are grouped into chunks of three digits while
hexadecimal numbers are grouped into chunks of length four.
The digit separator is language-specific and chosen so that the number
is a valid token in the source language.
[Examples](https://godbolt.org/z/s86cMbjeK):
* for C++, hovering the number `8583909746840200552` shows this tooltip:
`8'583'909'746'840'200'552 = 0x7720'2C6F'6C6C'6568 =
6.5188685003648344e+265`
* for Python, hovering the number `-12345678` shows this tooltip:
`-123_456_789 = 0xFFFF_FFFF_F8A4_32EB = -2.66427945e+34f`
For languages that don’t have a `digitSeparator` set, the tooltip is not
changed.
