User Details
- User Since
- Feb 11 2014, 3:42 PM (362 w, 2 d)
Yesterday
Fix typo in commit message, 'state' -> 'stale'
Use getValueOr
clang-format changes
Dec 21 2020
Nov 24 2020
Nov 17 2020
I'd like if we only had to use one flag (-fallow-pcm-with-compiler-errors) and have it handle both modules and PCH. Could you make the flag also work for PCH and/or add a test that verifies it works?
You may only have to change
Opts.AllowPCHWithCompilerErrors = Args.hasArg(OPT_fallow_pch_with_errors);
to
Opts.AllowPCHWithCompilerErrors = Args.hasArg(OPT_fallow_pch_with_errors, OPT_fallow_pcm_with_errors);
Oct 29 2020
Oct 21 2020
Oct 15 2020
Thank you! Are you able to commit it by yourself?
Oct 8 2020
Oct 7 2020
Good catch!
Sep 3 2020
Sep 2 2020
Sep 1 2020
SourceRange cxloc::translateCharRangeToTokenRange(CXTranslationUnit TU, CXSourceRange R) is an expensive operation and I'm concerned it will be easy to start calling at places and introduce performance degradation.
Aug 31 2020
We may have places in the code where SourceRange is used as a pair of locations, and those locations are character locations instead of token ones, so essentially the information of whether the range is token-based or character-based gets lost, and we get into trouble when passing such a SourceRange to APIs that assume token-based.
AFAIK SourceRange is supposed to always represent a token range (begin loc points to beginning of first token, end loc points to beginning of last token). For representing a character range, CharSourceRange should be used, though IMO its IsTokenRange member was a mistake, CharSourceRange should have only being used to represent half-open character-based range. This distinction is thankfully more clear on the Swift side.
Jul 14 2020
Jun 29 2020
Jun 19 2020
May 20 2020
Mar 31 2020
Mar 28 2020
I agree it makes sense to disable CLANG_ENABLE_ARCMT if CLANG_ENABLE_STATIC_ANALYZER is also disabled.
Mar 7 2020
Feb 11 2020
Dec 20 2019
Dec 16 2019
Dec 12 2019
Oct 29 2019
Oct 8 2019
Aug 28 2019
Aug 24 2019
Aug 23 2019
Are you sure the difference is not random noise? It's not clear to me under which conditions you would encounter the same region in NewParsedRegions within the same TU. I assume this would be the case if the same file is parsed multiple times, but I'd expect this to be uncommon within the same TU.
I'd recommend to add some counters of when NewParsedRegions.count(region) is true and when ParsedRegions.count(region) is true, and print them at the end.
Aug 13 2019
Aug 7 2019
Sorry, it's not clear to me what is the issue.